Technical Reference Model for the Government …Government Procurement of Information Systems...
Transcript of Technical Reference Model for the Government …Government Procurement of Information Systems...
1
Technical Reference Model for the Government
Procurement of Information Systems (TRM) 2010
June 2011
Information Services Industry Division, Commerce and Information, Policy Bureau,
Ministry of Economy, Trade and Industry
Information-Technology Promotion Agency, Japan
This document has been translated by Erklaren Co., Ltd.
2
Contents
1. Introduction .................................................................................................................................. 4
1.1. Background ................................................................................................................................... 4
1.2. Objectives ...................................................................................................................................... 4
1.3. Audiences ...................................................................................................................................... 5
1.4. Coverage ....................................................................................................................................... 5
1.5. Document Structure ....................................................................................................................... 6
1.6. Overview of Revisions to the 2009 version ................................................................................... 6
1.7. Revisions Planned in the 2011 version ......................................................................................... 7
2. Overview ....................................................................................................................................... 8
2.1. TRM Relationships with Other Documents, Guidelines, or Reference Models ............................ 8
2.2. Structure of this Technical Reference Model ................................................................................ 11
3. Definition (Categorization of Technologies) ........................................................................... 18
4. Procurements and System Design Policies ............................................................................ 24
4.1. Functional Configuration Model .................................................................................................. 24
4.2. Physical Configuration Model ...................................................................................................... 34
4.3. Categorization of Service-Work................................................................................................... 37
4.4. Policies for Defining Business Application .................................................................................. 40
4.5. Policies for Common Databases ................................................................................................. 46
4.6. Policies for Implementing Common Business System for Ministries .......................................... 48
4.7. Virtualization Technologies .......................................................................................................... 49
4.8. Standpoints of Cloud Users ......................................................................................................... 52
4.9. Standpoints of Cloud Integration ................................................................................................. 63
4.10. Security Issues ............................................................................................................................ 68
4.11. Policies for Employment of Green-IT .......................................................................................... 77
4.12. Notes on Employment of IPv6 .................................................................................................... 79
5. Descriptions of Technological Domain ................................................................................... 80
5.1. BI/DWH/ETL ................................................................................................................................ 82
5.2. EAI ............................................................................................................................................... 94
5.3. iDC Facility .................................................................................................................................. 96
5.4. SOA Related Functions ............................................................................................................. 100
5.5. Maintenance Environment......................................................................................................... 109
5.6. Servers ...................................................................................................................................... 120
5.7. Storage ...................................................................................................................................... 134
5.8. Shared PC / Office Printer ......................................................................................................... 139
5.9. Operations Management/Security ............................................................................................. 158
5.10. EIP ............................................................................................................................................. 193
5.11. Open Web Server ..................................................................................................................... 196
5.12. Groupware, File Server, and Mail Server .................................................................................. 206
3
5.13. Integrated Account Management, Authentication, Authorization (Access Control) .................. 221
5.14. Integrated Directory ................................................................................................................... 233
5.15. WAN, Ministerial LAN, DNS/DHCP/Proxy, Remote Access ...................................................... 238
5.16. Workflow, BAM .......................................................................................................................... 267
5.17. Common Elements in Domains ................................................................................................ 268
6. Procurement of services ......................................................................................................... 269
6.1. Support for master plan formulation .......................................................................................... 271
6.2. Support for procurement ........................................................................................................... 278
6.3. System Integration (Design/Development) ............................................................................... 297
6.4. Operation ................................................................................................................................... 323
6.5. Helpdesk.................................................................................................................................... 348
6.6. Maintenance .............................................................................................................................. 372
6.7. Tasks incidental to procurement of devices .............................................................................. 425
6.8. Tasks incidental to procurement of iDC equipment ................................................................... 444
6.9. Network procurement ................................................................................................................ 466
6.10. Cloud service ............................................................................................................................ 504
6.11. Cloud construction .................................................................................................................... 505
6.12. Security ..................................................................................................................................... 506
6.13. Other ......................................................................................................................................... 538
7. Recommended Technology Standard .................................................................................... 539
7.1. Requirements for technology standards in conformity with the “Framework for Interoperability
Relating to Information Systems” .............................................................................................. 539
7.2. Items for technology standard evaluation cited in “TRM 1st issue: The Report on the Results of
Validity Examination” ................................................................................................................. 542
7.3. Guidelines for the Selection of Recommended Technology Standards .................................... 543
7.4. Recommended Technology Standard ....................................................................................... 550
Appendix 1 Case Examples of Procurement................................................................................ 555
Appendix 2 Case Examples: Service Procurement Specifications ........................................... 559
Appendix 3 Table: Guidelines on the transition of encryption algorithms ............................... 567
Appendix 4 References ................................................................................................................... 570
4
1. Introduction
This document provides information about procurement of information systems, aiming to be used
as a supplemental reference to the “Basic Guidelines for Government Procurement Related to
Information Systems.”
1.1. Background
The integration of separately-procured information systems following the
separation-of-procurement-policy recommended in the “Basic Guidelines for Government
Procurement Related to Information Systems,” effective from July 2007 (agreed at the Liaison
Conference of Chief Information Officers (CIO) of Ministries and Agencies, hereinafter referred to as
the Procurement Guidelines), could, in some cases, create problems due to the lack of
interoperability of the individual business systems with the common platform system caused by the
incompatibility of employed vendor-specific technologies, especially the interface for service-calls. In
addition, the individually implemented systems may often lack user-friendliness, because, situations
where the ministries and agencies have independently implemented their portal systems—home
pages or portals for electronic submission. The Japanese users are often required to have different
client systems for the different systems prepared by the ministries and agencies: those systems often
require unique software or a specific web browser for the client systems on the user-side, or a version
mismatch of execution environments interferes with the use of the systems. Moreover, even if the
systems implemented in the ministries and agencies through independent procurement are optimum
in the sense that they follow the Procurement Guidelines, the “Guidelines for Optimizing Operation
and Systems” (agreed at the Liaison Conference of Chief Information Officers (CIO) of Ministries and
Agencies in March 31 2006), and “Framework for Interoperability Relating to Information Systems”
(announced by the Ministry of Economy, Trade and Industry in June 29 2007, hereinafter referred to
as “Framework for Interoperability”), such systems might not be optimum from the stand point of the
government as a whole, due to the lack of applicability to other systems.
1.2. Objectives
The objectives of this “Technical Reference Model for the Government Procurement of Information
Systems” (hereinafter referred to as “Technical Reference Model”) are as follows:
• Improving user friendliness,
• Ensuring system integration of separately-procured systems,
• Minimizing total cost in the job-operations and systems lifecycle,
• Improving efficiency of procurement.
5
This Technical Reference Model, with the intention of being used as a reference for optimum
procurement and implementation of information systems, provides the following:
• Technical guidelines for ensuring separation of procurement and integration following the Procurement Guidelines (Ch. 4),
• Technical guidelines for realizing visualization, clouds, and green IT,
• Functional configuration model consistent with the typical procurement models (Ch. 4),
• Physical configuration model consistent with typical government information systems (Ch. 4),
• Definition of technology domains (categories) — possible minimum group of procurement items (Ch. 5),
• Example of neutral descriptions of requirements for each technology domain in cases of the procurement of goods (Ch. 5),
• Essentials of requirement descriptions for each procurement category in case of the procurement of services (Ch. 6),
• Interoperable open standards to be preferentially employed (Ch. 7),
• Supplemental case examples (Case examples of procurement),
• Notes on ensuring security (Encryption algorithm transfer issues).
1.3. Audiences
This Technical Reference Model is prepared with the assumptions that it is referenced by the
following audiences:
• CIOs, Deputy CIOs, and support staff in the ministries and agencies, the independent administrative institutions, and the local governments,
• Persons in charge of information system design / planning / operations in the ministries and agencies, the independent administrative institutions, and the local governments,
• Persons in charge of procurement in the ministries and agencies, the independent administrative institutions, and the local governments,
• Procurement supporters
• Vendors bidding for the government information systems procurement. Note that, in the application of this Technical Reference Model to the procurement of systems other
than government information systems, adjustments, according to individual procurement policies or
system integration policies, are necessary as for the scale of procurement items and the technologies
or open standards to be employed preferentially.
1.4. Coverage
This Reference Model provides technical information applicable typically to the following systems:
• Information systems of the central government,
6
• Information systems of the independent administrative institutions,
• Information systems of the local governments. Note that, although this Technical Reference Model is basically applicable to the implementation and
procurement by the above information systems, adjustment or customization is necessary in some
cases such as the application to systems other than those of the central government.
Note that this Technical Reference Model will be revised periodically, reflecting requests from
persons in charge of the government procurement of information systems, or for catching-up with
changes in the trends of system requirements or product-features.
Note that this Technical reference Model, in accordance with the Procurement Guidelines, is
prepared to help create procurement specifications having no ambiguity in requirements, having no
unrealistic requirements, and having no requirements or factors in favor of specific hardware or
software products or technologies.
1.5. Document Structure
Besides this Technical Reference Model, which provides technical information, the following
documents constitute the document family of the technical reference model for the government
procurement of information systems: “Utilization Manual of the Technical Reference Model for the
Government Procurement of Information Systems (TRM)” (hereinafter referred to as “Utilization
Manual”), and the List and Descriptions of Technologies, an attachment to the TRM published on the
website.
1.6. Overview of Revisions to the 2009 version
In the 2010 version, the following are added to the 2009 version or modified:
• Addition: classification of service procurement,
• Addition: essentials of descriptions of requirements in service procurement,
• Addition: technical guidelines for virtualization,
• Addition: technical guidelines for the utilization of clouds,
• Addition: technical guidelines for the implementation of clouds,
• Modification: improvement and augmentation of descriptions on information security,
• Modification: addition of detailed descriptions of guidelines for the selection of recommended technical standards,
• Modification: separation and publishing on the website of the technology list and descriptions of technologies.
7
1.7. Revisions Planned in the 2011 version
In the 2011 version, the augmentation of the descriptions is planned as follows:
• Revising the technical requirements for the procurement of goods,
• Adding typical requirement-descriptions for the procurement of services,
• Adding typical requirement-descriptions on the utilization of clouds,
• Adding typical requirement-descriptions on the implementation of clouds,
• Adding descriptions on the utilization of open standards in procurement specification documents.
8
2. Overview
This chapter provides the general overview of this Technical Reference Model.
2.1. TRM Relationships with Other Documents, Guidelines, or Reference Models
This Technical Reference Model provides the technological information necessary, in order to
prepare specific requirement-descriptions in a request for information (RFI) or a request for proposal
(RFP), for breaking-down the principles recommended in the following documents, guidelines, or
reference models:
•Guidelines for Optimization of Government Information Systems, described in the
Guidelines for Optimizing Operation and Systems,
•Guidelines for Government Procurement, described in the Procurement Guidelines,
•Guidelines for Interoperability of Information Systems, described in the Framework for
Interoperability,
•Guidelines for Information System Security described in the Standards for Information
Security Measures for the Central Government Computer Systems.
2.1.1. Relationship to the Guidelines for Optimizing Operation and Systems
This Technical Reference Model provides the technical information to implement the principles of
the following guidelines recommended in the Guidelines for Optimizing Operation and Systems:
[Guideline 4-1]
As for the computerization of the whole or a part of job-operations, if such operations are similar to
those executed in other ministries, agencies, divisions, or departments, etc, and the computerized
systems can be applied to the operations in other entities, construct a unified computer system and
share the system among the entities, for the purpose of consolidation and centralization of
information systems.
In addition, even in a case where distributed data-management by the individual ministry or agency
is preferable, reduce the cost required for system development and maintenance while keeping the
interoperability, through the unification and centralization of functions required by applications and the
unification of requirements for data management;
[Guideline 4-2]
Reduce the number of LANs used in ministries or agencies to one per a ministry or agency, by
consolidating mail or other basic job-operation systems and centralization of maintenance jobs;
9
[Guideline 4-3]
Use LAN terminals connected to ministry’s internal LANs for accessing information systems to
execute job-operations. Use ministry’s internal LANs or other infrastructure networks for
accomplishing server-to-server connection or server-to-user connection;
[Guideline 4-4]
Use the Kasumigaseki-WAN for the connection between ministries or agencies. Use the local
government wide-area network (LGWAN) for the connection of government ministries or agencies to
local governments;
[Guideline 4-5]
Employ hardware, software, and communication protocols that are open and conforming to
international or de-facto standards in the implementation of information systems;
[Guideline 4-6]
Consolidate and reduce the number of the connection points to the information systems used to
publish information on the internet such as home pages, and apply comprehensive security measures
covering other information systems connecting to such systems;
[Guideline 4-7]
Prepare back-up systems for the systems where integrity and high-availability is required, among
the systems shared by ministries and agencies, or the systems tightly linked to the citizens’ lives or
social / economic activities of Japan.
2.1.2 Relationship to the Procurement Guidelines This Technical Reference Model provides technical information following the Procurement
Guidelines, promotes flawless government procurement in accordance with the guidelines, and
supports trouble-free implementation of information systems. This Technical Reference Model
enables the followings:
• Separation of procurement along phases of design or development;
• Management of design or development processes;
• Completeness of information necessary for preparing proposals;
• Separation of the procurement of hardware and the procurement of software
• Separation of procurement in the phase of design, development and deployment, the procurement in the phase of operation, and the procurement in the phase of maintenance;
• Elimination of ambiguity in requirements; • Requirement description based on open standards.
Note 1: “Open standards” refer to the standards satisfying the following:
(1) The standards are agreed through a publicly-open participation process, and the specifications are public
10
down to the implementation levels; (2) No one is rejected to adopt the standards; (3) Multiple products that
implement the standards are available in the market.
Note 2: This Technical Reference Model uses the term the “common platform system” as a term collectively
referring to the “common platform system” used in the Procurement Guidelines and the “H /W infrastructure used
in the “Application Manual of the Basic Guidelines for Government Procurement Related to Information Systems”
(Ver. 2) (published in July 1, by Administrative Management Bureau, Ministry of Internal Affairs and
Communications, hereinafter referred to as the Application Manual). In the same way, Technical Reference
Manual uses the term “common platform system provider,” collectively referring to the “common platform system
provider” and the “H / W infrastructure provider.”
2.1.3. Relationship to the Framework for Interoperability This Technical Reference Model provides information following the Framework for Interoperability:
the provided information supports the preparation of procurement specifications in accordance with
the government policies on information system and the interoperability presented in the Framework
for Interoperability. This Technical Reference Model includes the following:
• Policies on the neutrality of requirements;
• Policies on the preferential employment of open standards;
• Policies on the selection of the optimum information system;
• Policies on the adoption of openness. In addition, this Technical Reference Model recommends that the individual business systems should
be loosely connected to the common platform system through loosely coupled services.. The
recommendation is in accordance with the following guideline presented in the Framework for
Interoperability:
Guideline: When procurements of systems are separated into individual functions, it is desirable to
avoid putting limitations on computers and platforms on which such functions are executed.
Therefore, service interfaces should be platform-independent, and the individual services are
asynchronously and loosely coupled.
2.1.4. Relationship to the Standards for Information Security Measures for the Central Government Computer Systems
This Technical Reference Model provides the technical information necessary for the preparation of
procurement specifications that are following the Standards for Information Security Measures for the
Central Government Computer Systems and in accordance with the Standards for Information
Security Measures for the Central Government Information Systems.
Note: The latest version of the Standards for Information Security Measures for the Central
Government Computer Systems was released on April 23, 2011. Refer to the following URL:
http://www.nisc.go.jp/active/general/kijun01.html
11
2.1.5. Relationship to the Security-by-Design Policy and the Risk-factor Reference Model This Technical Reference Model, in the section 4.10, provides the guidelines of security measures,
by introducing the generals of security-by-design and the risk factor reference model.
2.1.6. Relationship to the Government Shared Platform System This Technical Reference Model, in the section 4.8, provides the general idea of using “clouds,” the
idea will be applicable to the use of the Government Common Platform.
2.2.Structure of this Technical Reference Model
This Technical Reference model, in Ch.3 and in the following chapters, provides technical
information as summarized in the following sub-sections.
2.2.1. Ch. 3: Definition (Categorization of Technologies) Ch. 3 shows the technology categories defined in this Technical Reference Model and the
Separated appendix: Table of Technical Categorization (Technical Domains).
This Technical Reference Model, for the purpose of avoiding ambiguities in the communications
between the procurers and providers, categorizes the technologies from the view points of the both
parties. Ch.3 categorizes technologies from the view point of providers through layering of the IT
system structures, formalizing the layered structure according to the TRM framework, and mapping
the individual elements of technology onto the framework by their usages or features
12
Break-Down -Structure of the IT-Technologies
Top Level Second Level Technologies Specific Items
Functions
Hardware
Platform
PC /
In-Office-shared
Printers
Personal Computer
Thin Client
In-Office-shared Printer
Server Server Hardware Server Hardware
Storage Disk Storage
Tape Storage
Network LAN Switch
Secure Wireless LAN
WAN Router
Remote Access
Private Line Service
Business
Operation
Platform
PC / Office
Printer
Common Operation Environment OS Kernel
Peripheral Support
Command Line Interface
Web Browser
Video Viewer
Server Server Operating System OS Service
Thin Client Server
Network DNS / DHCP / Proxy DNS Server
DHCP Server
Proxy Server
VoIP
Application
Platform
Application
Execution
Environment
Web Server
AP Server
Data
Management
Meta Data Registry
DB Server
File Sharing
Integrated Directory
Data Exchange
/ Linkage
EAI
Data Adapter
Legacy-System Integration
Table 2.2-1: Technology Category (Part)
Figure 2.2-2 shows the technology domains mapped on the layer of TRM Framework.
13
Hardware Platform
(H/W) Server
Job-Operation Platform
(Server OS)
Application Platform
(General-Purpose
Middleware)
Base Applications
BI/DWH/ETL
iDC Facility
Sys
tem
Ope
ratio
n M
anag
emen
t
Sec
urity
EIP(Shared S/W)
File Server
Individual Business Applications
Com
mon
Tec
hnol
ogie
s to
All
Dom
ains
EAI(Web
Service)
(Protocol)
(H/W)WAN, Ministry’s
Internal LAN
Remote Access
(H/W) Shared PC, Shred-in-
Office Printer
(Client OS)
(Base S/W)
Groupeware, Mail Server
Public Web
Server
App
rova
l
Mai
nten
ance
Env
ironm
ent
Workflow, BAM
Legacy Integration
(Individual Business System)
SOA-Related
Functions(SOA)
(Ded
ecat
edM
iddl
ewar
e)
Authentication, Integrated Account
Management, Integrated Directory
(Net
wor
k S
ervi
ce)
Colors indicate where the technology in the box is used.
(H/W)Storage
(Common Business System)
DN
S, D
HC
P, P
roxy
Mainly used in client environments: PCs or printers
Mainly used in server environments: servers or storages
Same as described at the left
Network related technologies
Technologies common to the entire IT sphere: independent of specific environments
Figure 2.2-2 Technology Domains mapped on the TRM Framework
2.2.2. Ch. 4: Procurements and System Design Policies Ch.4, from the standpoint of procurers, shows the goods and services to be purchased in each
technical domain: domains are defined through classifying and categorizing the target functions,
making models—patterns—of functions for each unit of purchase, assembling necessary
technologies likely procured at one time as certain groups —domains—and allocating the functions to
the domains. At the same time Ch. 4 shows where, in the physical configuration of the ministry and
agency systems, each domain in the Function Configuration Model is allocated. Note that it is not
always required to realize each function shown in the configuration diagram with a separate piece of
hardware: from the standpoint of optimization, realization on a single server of functions allocated to
multiple technology domains would be preferable. For example server consolidation, utilization of
existing servers, or utilization of communication equipments for remote-access are preferable
methods. Elimination of redundant services or goods through optimization-assessment is essential.
Also, Ch.4, for the purpose of complementing the Guidelines for Optimizing Operation and
Systems, and the Procurement Guidelines, shows the policies of designing information systems to be
procured; and for the purpose of Request For Information (RFI), and Request For Proposal (RFP)
and procurement specifications, shows policies of designing business application, policies for
common databases, utilization of common business system for Ministries, policies of employing
green IT, policies of security, policies of virtualization, and policies of utilization and implementation of
clouds.
14
2.2.3. Ch. 5: Descriptions of Technology Domains
Ch. 5 provides the descriptions of Technology Domain from the standpoint of the procurers of
goods, with examples of requirement specifications for general — common to ordinary specifications.
Although the functional or non-functional requirements shown in those examples are realistic
because the technologies or goods are available and proven in Japan at the time of publication of this
Technical Reference Model. Those specifications are only general purpose examples. Therefore,
when applied to the actual procurement, the example specifications should be customized according
to the situations: the parameters (variables) in { } need to be modified, the example descriptions in [ ] needs to be modified or selected, and addition or elimination of requirements will be necessary. Note
that, in such customization, sufficient consideration or care is required for avoiding
unreasonably-severe conditions or putting in unnecessary requirements.
Also, note that it is not always necessary to procure all the technical elements shown in the
domains: previously procured technological elements or certain elements purchased in other
purchase orders may be reusable. Utilization of existing resources or elements included in other
purchases and avoidance of duplicated procurement through the optimization assessment is
necessary when actual specifications are prepared by applying the descriptions in Ch.5.
2.2.4. Ch. 6: Procurement of Services
Ch. 6 shows the categorization of services to be procured from the standpoint of procurers, and
then shows the overviews of services to be described in specifications for each of the categories
defined. Also, Ch.6 provides information on the following: prerequisite information prepared by
procurers to be described as a detailed requirement; outputs of services; essential points to be
described in procurement specifications and comments / interpretations; and project-dependent
points and information-system-feature-dependent points to be taken into account. Note that, in
comparison with Ch.5, Ch.6 does not provide information so that the descriptions can be copied to
actual specifications, for the reason that the service-procurement specifications will be more
dependent on project-specific factors than those of the procurement of goods, and therefore the
specifications must be prepared so that the outputs of the service-procurement in the proceeding
phase is sufficiently detailed.
15
Figure 2.2-3: Classification of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
16
Figure 2.2-4 Descriptions of the Services Service Service operation
6.1 Support for master plan formulation
Planning the systematization initiative and systematization plan creation
6.2 Support for procurement Service operations of supporting procurement for ministries: e.g. implementation of requirements definition, deciding on procurement policies/procedures, creation of procurement specifications, request for comment, evaluation of contractors, and project management.
6.3 System integration (design/development)
Service operations concerning information system integration: e.g. design, development, migration, operation, operation/maintenance design of information systems.
6.4 Operation Service operations concerning information systems (“6.5 Help desk” may be considered as part of the operations of 6.4; however, it is separately described in Chapter 6.5)
6.5 Help desk Service operations concerning help desk to respond to inquiries from users on system operationuse
6.6 Maintenance Service operations of information system maintenance: e.g. correction of information system faults, modification of system/software products after delivery and adaptation to changed environments
6.7 Tasks incidental to procurement of devices
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)
6.8 Tasks incidental to procurement of iDC equipment
Service operations such as installation and configuration of various equipment in facilities (data center) prepared by customers, and operation monitoring of relevant systems (and operations incidental to it)
6.9 Network procurement Services related to construction of networks, such as LAN and WAN (Wide Area Network), and service operations incidental to service procurement, such as WAN service and internet service.
6.10 Cloud service Service operations using cloud system services 6.11 Cloud construction Service operations to construct cloud systems 6.12 Security This section describes security cautions in procurement
of services and security approaches during construction of information systems
6.13 Other (to be created) Service operations not included in 6.1 – 6.12, such as procurement of business package software.
17
2.2.5. Ch. 7: Recommended Technology Standards Ch. 7 shows the open standards to be preferentially employed especially in the procurements of
government information systems. Note that those open standards are solely chosen for the purpose
of the separation of procurement recommended in the Procurement Guidelines, and will not cover all
the technologies to be procured. Also note that as for the employment of open standards, the
excessive employment of open standards to the layer where the interoperability is unnecessary may
limit the selection of technologies or products to open-standard conforming products. Therefore, open
standards in procurement specifications should be specified only in the following layers: the interface
between the elements of information systems to be procured separately; and the interface of the
existing environments and the newly procured elements of information systems. It is preferable to
leave the decision of open-standard employment of the lower levels to the vendors.
2.2.6. Separated appendix 1: Samples of Procurement Separated appendix 1 introduces the actual specifications of the government procurement as a
supplement to this Technical Reference Model, for the purpose of reducing the work load in preparing
high-quality procurement specifications. In preparing actual specifications, it is preferable to use the
examples as well as the descriptions in the main chapters of this Technical Reference Model. The
web page of the Ministry of Internal Affairs and Communications and the web pages of other
ministries publish procurement examples not shown in this separated appendix.
2.2.7. Separated appendix 2: Samples of Procurement Requirements of Service Separated appendix 2 shows a table, listing the actual procurement specifications, on which Ch. 6
is based.
2.2.8. Separated appendix 3: Encryption Algorithm Transition Separated appendix 3 introduces the necessity of the transition of the encryption algorithm SHA-1
and RSA1024 widely used at present to more secure algorithms.
2.2.9. Separated appendix 4: References Separated appendix 4 lists the documents or articles helpful to understand this Technical
Reference Model, and shows how to access them.
18
3. Definition (Categorization of Technologies)
The purpose of this Technical Reference Model in this document is to promote smooth and less
ambiguous communications between the procurers and the bidders by providing categorizations for
technologies that are well accepted by both the procures and the providers. Chapter 3 categorizes
technologies in technology domains mainly from the providers’ point of view, provides a layered
structure of IT systems, configures the TRM framework, and maps element technologies onto the
framework.
Hardware Platform
(H/W) Server
Job-Operation Platform
(Server OS)
Application Platform
Base Applications
iDC Facility
Syst
em O
pera
tion
Man
agem
ent
Secu
rity
Office Applications
Individual Business Applications
Com
mon
Tec
hnol
ogie
s to
All
Dom
ains
WebService
(Protocol)
(H/W) Network
(H/W) PC, In-office-shared Printer
(Client OS)
SOA-Related
Functions
Data ManagementApplication
Platform
Data Utilization
Information Access /
Collaboration
Business / Process
Management
Data Exchange / Linkage
Dev
elop
men
t / M
aint
enan
ce E
nviro
nmen
t
Net
wor
k Se
rvic
eColors indicate where the technology in the box is used.
Mainly used in client environments: PCs or printers
Mainly used in server environments: servers or storages
Same as described at the left
Network related technologies
Technologies common to the entire IT sphere: independent of specific environments
(H/W) Storage
Figure 3-1: TRM Framework
The Figure 3-2 can be used as a reference to how the technology domains are mapped in the layers
of the TRM Framework.
19
Hardware Platform
(H/W) Server
Job-Operation Platform
(Server OS)
Application Platform
(General-Purpose
Middleware)
Base Applications
BI/DWH/ETL
iDC Facility
Sys
tem
Ope
ratio
n M
anag
emen
t
Sec
urity
EIP(Shared S/W)
File Server
Individual Business Applications
Com
mon
Tec
hnol
ogie
s to
All
Dom
ains
EAI(Web
Service)
(Protocol)
(H/W)WAN, Ministry’s
Internal LAN
Remote Access
(H/W) Shared PC, Shred-in-
Office Printer
(Client OS)
(Base S/W)
Groupeware, Mail Server
Public Web
Server
App
rova
l
Mai
nten
ance
Env
ironm
ent
Workflow, BAM
Legacy Integration
(Individual Business System)
SOA-Related
Functions(SOA)
(Ded
ecat
edM
iddl
ewar
e)
Authentication, Integrated Account
Management, Integrated Directory
(Net
wor
k S
ervi
ce)
Colors indicate where the technology in the box is used.
(H/W)Storage
(Common Business System)
DN
S, D
HC
P, P
roxy
Mainly used in client environments: PCs or printers
Mainly used in server environments: servers or storages
Same as described at the left
Network related technologies
Technologies common to the entire IT sphere: independent of specific environments
Figure 3-2: Technology Domains mapped on TRM Framework
20
Table 3.1: Break-down Structure of IT-Technologies
Break-Down -Structure of the IT-Technologies
Top Level Second Level Technologies Specific Items
Functions
Hardware
Platform
PC /
In-Office-shared
Printers
Personal Computer
Thin Client
In-Office-shared Printer
Server Server Hardware Server Hardware
Storage Disk Storage
Tape Storage
Network LAN Switch
Secure Wireless LAN
WAN Router
Remote Access
Private Line Service
Business
Operation
Platform
PC / Office
Printer
Common Operation Environment OS Kernel
Peripheral Support
Command Line Interface
Web Browser
Video Viewer
Server Server Operating System OS Service
Thin Client Server
Network DNS / DHCP / Proxy DNS Server
DHCP Server
Proxy Server
VoIP
Application
Platform
Application
Execution
Environment
Web Server
AP Server
Data
Management
Meta Data Registry
DB Server
File Sharing
Integrated Directory
Data Exchange
/ Linkage
EAI
Data Adapter
Legacy-System Integration
Web Service ESB (Enterprise Service Bus)
21
Web Service Protocol Base Technology
Security Service
High-Reliability Messaging
Service
Transaction Service
Base
Application
Information
Access /
Collaboration
Mashup Portal
EIP Portal Sites
Personalize
Application Integration
Contents Management System
Groupware
Instant Message
Full Text Search
Web Conference
Screen Sharing Service
Business /
Process
Management
Business Process Management
Business Activity Monitoring
Business Model Simulation
Work Flow
Data Utilization Business Intelligence
Data Warehouse
ETL (Extract / Transfer / Load)
Data Mart
OLAP (Online Analytical
Processing)
ODS (Operational Data Store)
Data Mining
Dashboard
Reporting Tool / Service
SOA Related
Function
Management
Service Repository / Registry
Office
Application
Office Application Image Processing
Word Processing
Presentation
Spread Sheet
Facsimile
Image Publishing
22
Document Processing
Calculation
System
Operation
Management
System
Operation
Management
System Operation Management Availability / Performance
Management
Client PC Management
Server Management
Network Management
Storage Management
Service Desk
Security Security Security Management Trail Management Function
Virus Protection Function
Virus Gateway
Internet Content Filtering
Function
Firewall Function
Intrusion Detection / Protection
Function
Network Connection Monitoring
Function
Encryption Function
Anti-Spam Mail Function
Integrated Account Management
Directory Linkage
OS Access Control
Web Single Sign-on
Desktop Single Sign-on
Common
Technology to
All Domains
Common
Technology to
All Domains
Coded Character Set
Graphic Format
CD-ROM Format
DVD Format
Character Symbol
Tagset / Markup-language
Definition
Data Element Standard
Video Format
Compaction / Archiving
Magnetic Tape
Business Information
Geographic Information
23
Character Set / Data
Representation
Locale / Native Language
Support
Programming Language
Modeling Support
Accessibility
Network
Service
Network
Service
Communication Protocol
Time Service
Development /
Maintenance
Environment
Development /
Maintenance
Environment
Development Environment
Development Tool
Configuration / Version
Management Tool
Project Management Tool
Test Tool
Product /
Service
specific
Technology
Product /
Service specific
Technology
Video Processing
Voice Information Processing
CAD (Computer Aided Design)
Expert System
E-learning
Kiosk
Mobile Device
Product Information
Mobile / Wireless
IC Card
Media Distribution Service
Geographic Information Service
Document Management Service
TRM
Supporting
Technology
TRM Supporting
Technology
IT Service Management
Software Lifecycle Management
Internal Control Framework
24
4. Procurements and System Design Policies
4.1. Functional Configuration Model
This chapter, from the standpoint of procurers, shows the allocation of technology elements
configuring applications, the common platform systems, and networks to the technology domains in
the Functional Configuration Model. In particular, on the boundary between the common platform
system and networks, allocation of network-technology elements are defined as consistent as
possible with actual situation of technology elements procured. Note that the Functional Configuration
Model includes elements configuring private-cloud environments (a private cloud refers to a cloud
constructed and used locally within an organization.).
Application
Common Platform System
Network
Workflow / BAM
EAI
Function for SOA
Server
System Operation Management / Security
Common Business System
WAN /Ministry’s Internal LAN
Groupware / File Server
Remote Access Shared PC
In-office-shared Printer
EIP
Public Web Server
Legacy System Integration
Functional Configuration Model
Integrated Directory
Integrated Account Management / Authentication / Permission
Individual Business System
BI/DWH/ETL
iDC Facility
Maintenance Environment
: Technology Domains
Storage
Figure 4.1-1 Functional Configuration Model
4.1.1. Definition of Technology Domains
Technology Domains, defined through categorization and classification of technologies in such a
way that the items of actual procurement in the central government fit in, are also used as top level
classifications to coarsely categorize or classify the nonnegligible technologies or products belonging
to more than one domain, or difficult to precisely allocate.
The Technology Domains are defined as follows:
25
Application
Technology Domain Definition
Individual
Job-operations
• Job-operations defined in the Job-operation Manual
• Individual business applications of job-operation
Legacy System
Integration
• Mechanism existing in the application layer to make a linkage
between the job-operations realized on legacy systems and
those on the common platform system
• Note that EAI, etc. are excluded.
Common Platform System
Technology Domain Definition
Common Job-operation • Common job-operations defined in the Job-Operation Manual
available on the common platform system.
• The services commonly available to individual job-operations.
Workflow / BAM • A versatile mechanism to manage or monitor job-processes
• Note that web-service-based BPM is excluded.
BI /DWH / ETL • A versatile and high-performance mechanism for data
referencing / search / analyzing data, effective for reducing
individual implementation of job-operation input / output
display screens or forms.
• Also, refers to a versatile mechanism for data handling.
EAI • A versatile mechanism for linking job-operation systems.
SOA Related Function • Web-service-based framework for organizing the entire
operation systems through linking the web-services
• Also, refers to related technology standards to support the
framework.
System-operation
Management / security
• The entire mechanism for managing operations or preserving
security of the common platform system and applications.
• Note that mechanisms required to be implemented in the
individual applications are excluded.
Maintenance
Environment
• The mechanism for implementing the environments required
for the maintenance of the common platform system and
applications.
• Also, in cases, specifically refers to the mechanisms for
enabling maintenance including in-operation-maintenance
procedures, development tools, or automatic-testing.
Server • Server hardware and software supporting all the functions
26
described above so far.
• Required to be an integrated environment under unified
management with reliability, availability, and flexibility; and, in
cases, virtualized implementations are required.
• Network equipments such as routers or switches are
included.
Storage • Storage hardware and software supporting all the functions
described above so far.
• Required to be an integrated environment under unified
management with reliability, availability, and flexibility; and, in
cases, virtualized implementations are required.
iDC Facility • A physical environment and programmed operation /
maintenance services supporting the servers and storage
devices described above. (Physical environment: the entire
facility and location-environment including buildings /
machine-rooms / installation-spaces, and equipment for
power / air-conditioning / communication / fire-extinguishing
/security.)
Network
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.
27
Authentication /
Permission
• Unique IDs are allocated to all users for authentication and
access-control.
Integrated Directory • A meta-directory supporting the above-described Integrated
Account Management / Authentication / Permission.
• Desired to serve as a parent directory of various directories
implemented and used in other systems.
WAN Ministry’s Internal
LAN
• A main body of network services, including physical
communication lines and DNS / DHCP / Proxy.
• Desired to have basic security features.
Shared PC /
In-Office-Shared Printer
• PCs or Printers shared in offices.
• Must be equipped with mechanisms for implementing and
maintaining versatile and secured environments.
• Note that dedicated equipment for specific job-operations is
excluded.
Remote Access • A mechanism for accessing a ministry’s internal LAN from
outside of the ministry office.
• Desired to have supplemental security-protection functions
such as VPN or authentication, as well as a
network-connection environment.
28
4.1.2. Intended Items of Procurement This subsection shows the intended items of procurement where the definition of domains for
services and goods are listed separately, where services, designs and developments are described.
Note that expense of operation / maintenance, migration / transition, or installation is excluded.
Application
Common Platform System
Network
Design and Implementation of Workflow / BAM
Design and Implementation of EAI / External Linkage
Design and Implementation of SOA(Design and Implementation of ESB, BPM, Service Repository and Web Service)
Design of Operations and Development of Management Tools (including the following functions: Monitoring, Back-up, Trouble Administration, Recovery Operations, Configuration Management, Resource Management, Resource Planning)
Security Design and Construction (including network security and personal information protection)
Design and Development of Common Business System (including physical design of DB)
Design and Implementation of a WAN
Design and Construction of a Ministry’s Internal LAN
Design and Implementation of Groupware
Design and Implementation of a File Server
Remote Access Design and Implementation of Shared PCs
Design and Implementation of Printers shared in Of f ices
Design and Implementation of EIP
Design and Implementation of a Public Web Server
Structure of Items of Service Procurement
Design and Implementation of an Integrated Directory
Integrated Account Management / Authentication / Permission
Design and Implementation of BI / DWH / ETL
iDC facility
Design and Implementation of Maintenance Environment
Design and Implementation of Legacy-system Integration
Design and Development of Individual Business System (including physical design of DB)
Design, Implementation, Deployment and Installation of Server(Configuration Design / High Reliability Design / Performance Design / Integration and Virtualization Design / Physical Design of DB)
Design, Implementation, Deployment and Installation of Storage (Configuration Design, High Reliability Design, Functional Design, Integration / Virtualization Design)
Figure 4.1-2 Structure of Items of Service Procurement in Relation to Technology Domains
29
Workflow Products
BAM Products
Products for EAI
Products for SOA
(including ESB, BPM, Service Repository, Web-service Products)
System Operation Management Software Products
Security Software Products
Software Products used as an element or an engine of common business system
Communication-line subscription for WAN
Equipments for Ministry’s Internal LAN
Groupware Products
File Server Products
Mail Server Products
Products for Remote Access
Shared PC (PC, COE Management Software, OA Software Products, Security Software Products, OS)
Shared Printers in Offices (Hardware and Software Products for Management
Software Products for EIP
Software Products for Public Web Servers
Products for Remote Access
Structure of Items of Procurement of Goods
Software Products for Directory Management
Software for Integrated Account Management / Authentication / Permission
(Software Products working as a functional element or an engine in individual business system)
(Dedicated Terminals or Printers)
(AP Server, Development Tools)
Products of BDI / DWH / ETL
iDC facility
Maintenance Environment (including Development Tools and automatic-test tools)
Server Product (Server, Router, Switch, High-reliability Product, Integration / Virtualization Product, Web Server, AP server, DBMS, OS)
Storage Products (including storage devices, high-reliability products, products for integration or virtualization)
Application
Common Platform System
Network
Figure 4.1-3 Structure of Items of Procurement of Goods in Relation to Technology Domains
4.1.3. Guidelines for Necessity-judgment of the Employment of Technology Domains in Procurements
Note that the Functional Configuration Model or Categorization of Procurement described above
should be flexibly applied to actual procurement: unnecessary items, even if listed in such models,
should be excluded, and on the other hand necessary ones should be added. Basic ideas for
deciding whether a certain technology domain must be included in the procurement or not is shown
below:
Application
Technology Domain Necessity of Technology Domain
Individual job-operation ・ Mandatory
Linkage to legacy
systems ・ Optional (rarely required)
・ Required in case of the procurement of dedicated tools for linkage. Generally the function is included in job-operation
systems, EAI, or external linkages.
30
Common 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
Security ・ Mandatory
・ Note that the functional coverage should be determined carefully.
Maintenance
Environment ・ Mandatory
・ Note that the functional coverage should be determined carefully.
Server ・ Mandatory
・ Note that the functional coverage should be determined through a trade-off analysis with use of external resources.
Storage ・ Optional (not highly but likely required)
・ In cased of small configurations, storages will often be included in servers.
IDC and Equipment ・ Mandatory
・ Note that the coverage should be carefully determined through a trade-off analysis with use of external IDC
resources: whether having IDCs in-house is better or not than
using outside resources.
31
Network
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
File-server ・ Optional (highly required)
・ In some cases, a groupware, or a file-server is procured independently.
Integrated Account
Management,
Authentication, and
Permission
・ Optional (fairly required)
・ In some cases, those functions are included in procurement such as common job-operation systems or individual
business applications.
Integrated Directory ・ Optional (fairly required)
・ In some cases, the function is fulfilled in other procurements such as integrated-account-management, or authentication
and permission.
WAN and Ministry’s
Internal LAN ・ Mandatory
Shared PC and
In-office-shared Printer ・ Optional (highly required)
・ In some cases, those are procured independently.
Remote Access ・ Optional (fairly required)
・ The purchase decision depends on specific requirements of ministries and agencies.
Also note that, as for packaged software products or middleware software products described later
in “4.4. Policies for Defining Business Application,” decisions of procurement should be done after
trade-offs, such as whether the products should be procured for the use limited in the individual
job-operations, or whether they should be procured as an infrastructure shared by more than one
job-operation. For an example, CRM software products or RIA software products, not listed as an
infrastructure on the assumption that they are used in individual job-operations, are allowed be
procured included in shared infrastructures.
Refer to “5. Descriptions of Technology Domains” for preparing procurement specifications of
packaged software products or middleware software products, where “Basic Features”—functions
expected to be included in standard products—are effective to eliminate products not having
acceptable features, and “Additional Features” should be used to pick up products having features
32
that are expected to be effective or indispensable to the realization of the individual job-operation.
Especially for the procurement of large systems on which the separate-procurement rule is expected
to be applied, it is recommended to use fully “Additional Features” not to overlook indispensable
features from the standpoint of expandability or automation of system operation and management.
On the other hand, for a small-scale system, note that the “Basic Features” may be
over-requirements from the standpoint of functions, performance, and reliability, and trade-offs should
be made before picking up the features as indispensables.
4.1.4. Items of Procurement
Although services and goods should be procured separately, installation work requiring no design
work, such as carrying-in and emplacement of hardware or installment of software, can be included in
the procurement of goods and services as incidental work. Also, maintenance of hardware products
and software products should be included in procurement of goods.
In addition, in the case of low-budget procurement, services and goods are allowed to be
procurement simultaneously if such combined procurement of services and goods will be fully
expected to contribute to the simplification of the maintenance scheme or the simplification of
procurement process.
- Procurement of Service
As for a unit of service procurement, different policies should be applied to different phases — the
design / development phase and the maintenance / operation phase. These policies are described
below. Note that they are supposed to be applied to the procurement of service, and in other cases
they should be used only as references.
In the design / development phase, different policies are applied to individual job-operations and
common job-operations. Especially, for the case of common job-operation, treat all elements grouped
in the technical domains for the common platform system as a unit of procurement, and then,
according to the necessity of specialized technologies, determine the domains to be procured
independently while taking care to prevent the increase in the number of vendors by limiting the
targets of separation to as few as possible. At the same time, determine the unit of separation flexibly
but generally following technology domain separation.
In the maintenance / operation phase, it is essential to treat maintenance and operation separately.
Maintenance means handling problems, addition of functions, modification, and tuning, etc. by
vendors having sufficient knowledge of the system. Operation means system monitoring, preliminary
failure analysis, and back-up by vendors having no special knowledge of the system, and working
according to manuals. Note that hardware maintenance or software-product maintenance should be
procured as a part of the procurement of goods, and not dealt with here.
33
Generally, maintenance should be done continually by the providers of the design or development
in the design / development phase. Note that, though, because maintenance of packaged
software-products or simple systems done by minimal development effort requiring no special tuning
could be assigned to other vendors than the provider of the system. It is necessary to take the above
into consideration.
System operation, because less dependent to the vendors of design / development, will be
recommended to be consolidated as tightly as possible not simply following the unit of procurement in
the design / development phase or maintenance phase.
- Procurement of Goods
The procurement of goods should be consolidated so that the number of procurements is as small
as possible. Note that, however, special-not generally available-goods, goods not procured along with
other goods, or goods probably requiring contract-renewal on design modification or redesign will be
practically procured separately.
34
4.2. Physical Configuration Model
The Physical Configuration Model was prepared as a reference model for designing entire
information system configurations, providing tangible system configurations of the two types of
systems—“network systems” and “common platform systems,” which were accepted as realistic
models in the government and will be frequently referenced to in actual government procurement
processes.
Note that the Physical Configuration Model, represented in the diagrams below, should be used as
a configuration example. Therefore, it is not required to install individual physical devices or
equipment corresponding to the functions shown in the model: more than one functional element
could be realized by a single device, or some functional elements could be fulfilled by existing devices.
Items to be procured — systems or devices — should be determined by taking into consideration all
factors of the individual project, such as requirements of optimization or utilization of existing
resources.
Of the Physical Configuration Model, the Network Physical Configuration Model provides the entire
model-structure of networks used inside government ministries or agencies, and the Common
Platform System Physical Configuration model provides the basic model-structure common to the
servers on the Network Physical Configuration Model.
The Network Physical Configuration Model is based on the outputs of the 4th working group
(information security) of the Liaison Conference of Deputy CIOs, etc, providing the six model
segments of the internal network of the ministries and agencies — S1 to S6 — created through the
analysis of the information system optimization plans by the ministries and agencies, where the
segments S1, S2, S3, S4, S5, and S6 respectively correspond to DMZ, intranet servers, the central
government LAN, outside-the-central-government servers, network, and information remote-access /
extraction.
35
Figure 4.2-1: Physical Configuration model of Network
The Common Platform System Physical Configuration Model was created from the stand point of
servers in the ministries and agencies, providing the structural model, where common platform
system basic functions are fundamental functions commonly used in the ministries and agencies,
including the following: network access, user registration / authentication, common database
management (optional), API or protocols for individual business applications, linkage to other
systems (optional), common security infrastructure, system operation / maintenance infrastructure,
common applications (optional), common public portal (optional), common repository, and others
(“optional” indicates that the function is selectively required).
36
Figure 4.2-2: Physical Configuration Model of Common Infrastructure
37
4.3. Categorization of Service-Work
While, in the case of procurement of goods, the technology domains in the Functional
Configuration Model —defined with a focus on the procurement of gods, —is well-applicable, in the
case of procurement of service, a categorization according to the procurement phases of information
systems would be easier to understand and apply. Procurement of services starts with the planning
phase, and proceeds to the requirement definition phase, the development phase, and the system
operation / maintenance phase. Major categories of service-work are shown in Figure 4.3-1 in relation
with the phases of procurement. Refer to the Ch.6 for the details of service-work and the essential
points to be described in procurement specifications.
Figure 4.3-1: Categorization of Procurement of Service
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
38
The system development phase consists of the sub-phases — design, development, test, and
system-migration — and is followed by the system-operation / maintenance phase. Note that the
following are included in the category of system development: development from scratch (new
development); renewal of existing systems (system renewal); system migration required for renewing
hardware (hardware renewal); and addition of sub-systems for augmenting functions (functional
augmentation). Also note that application maintenance, in some cases, includes partial modifications
of existing applications. For details, refer to the Figure 4.3-2 for the relationship of maintenance
service-work to the categorization of the system development service-work (design / development).
Also, note that the procurement of service-work requiring design work (basic design or detailed
design), and the procurement of service-work (including correction of design documents) requiring no
design work are respectively categorized into the Section 6.3 System Integration (Design /
Development), and in Subsection 6.6.3 Application Maintenance of Section 6.3 Maintenance. Refer
to the Ch.6 for description in detail.
<Maintenance>
Application Maintenance
<Maintenance>
Application Maintenance
Design Development / Test / System MigrationMaintenance
(Scheduled Maintenance / Inspection)
■New Development■System Renewal■Hardware Renewal■Sub-system-level Functional Augmentation
Attributes of Service Service Items
<Design / Development in System Integration>New DevelopmentSystem RenewalHardware RenewalFunctional Augmentation
■Modification (Correction, Functional Augmentation, Bug-fixing)
■Procurement of Application Maintenance requiring no development work
Including Defect-warranty work
Including Defect-warranty work(Design Correction)
■Maintenance of others <Maintenance> Hardware Maintenance,Software Maintenance,System Infrastructure Maintenance
Including Defect-warranty work
Figure 4.3-2 Mapping of Application Maintenance on Categorization Chart of Design /Development
39
The Figure 4.3-3 shows the mapping of the categories of service work on the Functional
Configuration Model for Procurement of Service, suggesting the following: as for the development
phase, almost all the services in the Functional Configuration Model are categorized in system
integration, compared with the procurement of networks or incidental work to iDC equipment
categorized as individual services. As for the procurement of server or storage, design / integration
are contained in the category of system integration, and implementation / installment is categorized
as an incidental work to procurement of goods. System operation / maintenance are procured in the
system-operation / maintenance phase. Note that, in the Figure 4.3-3, the planning phase or the
requirement definition phase is not shown.
6.7 機器調達付帯作業
6.8 iDC設備調達付帯作業
6.9 Network procurement
6.4 Operation
6.6 Maintenance
6.7 Tasks incidental to procurement of devices
6.3 System construction
6.8 Tasks incidental
to procurement
of iDCequipment
6.9 Network procurement6.3 System construction
Figure4.3-3 Mapping of Services on the Functional Configuration Model for Procurement of Service
40
4.4. Policies for Defining Business Application
The applications in the Functional Configuration Model are defined according to the Job-Operation
Manual— the individual job-operations are defined in “application” and the common-job operations
are defined in “common platform,” respectively. However, as for common job-operations, the different
types of descriptions are generally used according to the following three cases:
A: Specific job-operations belonging to higher job operation layers such as electronic payment;
B: System functions provided by the common platform system such as BPM or BI;
C: The lower common-services used by the higher services defined in the SOA.
Generally, defining the boundaries of common jobs and individual jobs — more specifically,
extracting common job-operations from entire job-operations— is not easy. However, in the case of A,
because the functions are defined more clearly compared with other cases, definitions or extractions
as mentioned are easily accomplished by defining interfaces to and from individual job-operations
through clarifying the scope of the job-operations, functions and requirements.
As for B, the difficulty comes from the lack of consensus or clear image of the functiond provided by
the common platform system. This Technical Reference Manual is expected to solve this difficulty
through sharing knowledge of the functions provided by the common platform system. If the common
platform is used for the purpose of running applications on the common platform, it is indispensable to
have attitude to use various functions proactively; through the utilization of the common platform
system, it is expected to reduce the volume of development, risk and cost of the project, or
maintenance cost of application.
As for C, the degree of difficulty depends largely on the service granularity described in the SOA or
how the common job-operation is extracted and defined. Because widespread of SOA concepts and
related technologies such as SaaS are insufficient and the applications still remain in transitional
stages, the difficulty requires time to be resolved. Therefore, especially for C, it is recommended to
treat the category as one of the step-wise approaches described later, and at the first step, procure
individual systems closed to individual job-operations from the developers of individual job-operation
systems instead of procuring the common platform system from the developer of such common
platform systems.
In the following sub-sections, policies of application-system development of job-operations are
described.
4.4.1. Stepwise Approach and Redefinition of the Entire System Architecture
41
The Stepwise approach is one of the critical methods of the system configuration-design of
common job-operations, especially for category C described in the previous sub-section: because
when a project's scale is large and a long-term “waterfall-model” development approach should be
applied, the coverage, functions, and strictly-defined requirements are required to be completed prior
to the development, job-operation analysis including BPR, and “ToBe” type breakdown of business
processes from the highest concept to detailed processes is prerequisite — thoughtless acceptance
of the existing job-operation flows, or simple copy-paste of the existing displays would result in a
re-building of old legacy systems.
However, in many cases, such an approach like that described above is not easy to apply because
of a shortage of skills and experiences on either the procurer or provider side, especially in today’s
situation where the SOA or its related technologies such as SaaS are not proliferated and widely
accepted.
Therefore, a practical way is recommended as follows: first of all, squeeze the scale of a project
suspected to be a long-term-waterfall type, and then apply a stepwise-development approach.
For squeezing the scale of project, the following two approaches, except for cutting-down the
system coverage or reducing job-operation functions are generally applicable:
The first is division of project — dividing a project into reasonable pieces satisfying time and cost
conditions, where the job-operations are allocated to sub-systems that are loosely coupled by EAI or
some other similar methods: also, division into sub-systems is accomplished so that an integrated DB
based on DOA (data center) is placed at the center around which applications are placed. The
approach requires redefinition and reconstruction of the entire architecture. Note that the approach
will not produce a simple division of procurement in accordance with the structure of the existing
sub-systems.
The second is the application of package-products described later which will drastically reduce the
volume of development, where division of project and fundamental reduction of development-volume
should be simultaneously considered. Note that the clear definition of the entire architecture is
indispensable as a prerequisite of such considerations.
As described above, the project-scale squeeze and the development-volume reduction will make
up the application of the stepwise approach. The stepwise approach will desirably proceed along the
steps as follows: at the early stage, construct the system on the basis of services of large granularity
connected loosely by an EAI-like method; then, divide each service into services of smaller
granularity step-by-step; and finally specify common services.
Note that the stepwise approach should desirably be applied incrementally to a single flow of
design to system-operation, and cyclically over a long period.
The stepwise approach should be realized through the formulation of the entire architecture at first,
followed by proof-of-concept experiments or prototyping of the common platform system and pilot
job-operations, executed in the following processes or in the combinations of processes:
• Persons procurers, execute in the planning phase following the advices made by Deputy CIO;
42
• Contracted service provider executes architecture formulation, proof-of-concept experiments, and
prototyping;
• Contracted system providers execute in the “confirmation of basic requirements” work.
Through the processes in the stepwise approach, the systems are incrementally implemented, and
at the same time maintenance and restructuring of the entire architecture are necessary. This
Technical Reference Model is expected to support the formulation of the entire architecture and
smooth execution of subsequent work.
4.4.2. Fundamental Reduction of Development Volume through Employment of Packaged Products
Some of the computer systems used in public sectors, developed in the early days of computing,
still continue to use the architectures of those days.
Packaged software applicable to job-operations requiring no customization would be perfect for
fundamentally reducing system development volume. Although those applicable to the job-operations
in the ministries and agencies are rare, some of general-purpose packaged software products,
middleware products, and internet technologies will be applicable.
Therefore, although the best is to find and employ packaged products just-fit to the objective
job-operations, the application of packaged products, even if best-fit packaged products were not
available, could fairly reduce the development volume in some cases like those described below:
• CRM products: Case Management
CRM products are used in businesses for comprehensively managing customers — attributes,
sales-history, sales-promotion-history, conversations, and support-history including response to
complaints.
CRM software products will be applicable to the government job-operations requiring case
management to individually support citizens and private businesses, such as tax-related jobs or
health-insurance-related jobs: CRM products are expected to serve there as engines.
• Spreadsheet: Ledger Management
In job-operations requiring management of ledgers, spreadsheets will be desirably used for
creating electronic images of ledgers. In cases where the ledgers are shared among job-operators, or
large sheets exceeding the capacity of spreadsheet are used, RDBs on the back-end linked by SQL
or web-services to the front-end spreadsheets will serve well. Also, middleware software is applicable
there.
• BI tools: Reference / Search, Outputting in forms, and Statistical Processing
43
BI tools will be successfully applied to data reference / search / analysis, and printing-data-in-forms,
and drastically reduce development volume in case management, ledger-management, or in other
systems. Especially for statistical analysis jobs, the data-mining functions of BI tools are highly useful.
• RIA Technologies: Screen-handling Programs
In the screen-handling programs used in mainframes, due to various technical constraints, the
volume of information displayed on a screen is limited: job-operation screens were divided into pieces,
and the operators had to execute jobs through complicated job menus for the computer-system-side
convenience. Also, as for C / S based job-systems, it was a concern that as a consequence of an
easy transfer of C / S to Web, the user friendliness which the originals have had would be lost, or the
volume of information on a screen would be limited due to the limitation posed by the features of the
browsers used for screens.
Recently, RIA technologies such as Ajax enable web-based systems to provide user-friendliness
and sufficient information on screen: through the use of such technologies, the following is expected:
reduction of the number of screens and development volume; improvement of user-operability,
job-operation-efficiency, and user-satisfaction; and reduction of maintenance / training cost.
Moreover, because having superior functionality for linkage to services on the internet, the RIA
technologies are effectively applied to low-cost-use of information on the internet such as map
information or bibliographic information.
• PC Packages with SOAP Interface: Screens
One of the integration methods of job-operation systems using SOA is as follows: the servers
provide various types of functions usable as Web-services, and PC packages with SOAP interfaces
use the Web-services as the users of services. The approach will be effective for providing flexible
screens satisfying individual user requirements — with smaller development man-hours.
The PC software products for the above-described purpose are supposed to be the following:
software packages for OA such as spreadsheet-software; mailers; and dedicated products to the
job-operations. On the other hand, the Web-services on servers will be implemented in the following
ways: applying the products whose functions are usable as a web-service based on SOA; or
augmenting the existing systems by adding Web-service interfaces.
• BPM and Integrated Directory: Workflow Management of decision-making processes
Workflow management of decision-making processes is a mechanism for the management of
decision-making processes called “Ringi” where more than one decision maker sequentially reviews
and approves a circulated decision-request. In workflow management, in such processes,
44
considerable work is spent on the preparation of information necessary for decision-makers or the
arrangement and management of circulation routes. Utilization of BPM products available on the
common platform system and the integrated directory available on networks will be one of the
effective alternatives to specialized products for workflow management.
• Service-Reuse: BPM products and ESB Products
In cases where service-reuse is required, the utilization of BPM products or ESB products should
be considered first. One of the reasons that service-reuse is difficult in conventional application
systems is that how functions are combined or what branching conditions change the course of
processes is coded in the programs or JCLs. On the other hand, the utilization of functional services
through BPM products or ESB products is expected to promote the reuse, and as a result the
business applications are expected to become more flexible and more maintainable.
The concept of service-orientation — the base of SOA — puts more emphasis on reusability than
on system-development. Job-operation models, job-flow models, and common / standard functions
based on the concept of usability are becoming available, of which the application can be expected to
largely reduce the risk and the volume of development.
• Utilization of Cloud Services
The functions so far described will realistically be realized by cloud services in addition to the
utilization of packaged products (reference to “4.8: Standpoints of Cloud Users” for the utilization of
cloud services, and “4.9: Standpoints of Cloud Designers” is recommended.)
Because cloud services are expected to rapidly expand from those that have been described so far
and those currently available on the public cloud such as CRM, Spreadsheet, BI, and Groupware,
application of cloud services should be considered in every project in future.
Although the employment of cloud services has potential advantages such as low-initial
development cost, short lead-time, flexibility to increase / decrease of the operational requirements,
smaller operational work-load, or low energy consumption, assessments on the following should be
made before the decision of employment of cloud services: availability of services; institutional
constraints; security and BCP; and SLA. List and confirm the critical items of the service level
agreement (availability, reliability, data management, and security). Also note the following: the
application of cloud services still remains in its early stage, and the number of domestic applications
is still small; they will be procured by procurement-of-service, instead of procurement-of-goods; and
procurement of cloud services, especially public cloud services, will possibly lead to another
vendor-lock-in — narrowing the selection of vendors —, because market-availability is still small.
4.4.3. Requirement-Definition in the Application of Packaged Products, etc.
45
The easy duplication of requirements of the existing systems without re-evaluating the necessity, or
simple acceptance of the requirements by job-operators leads, in many cases, to a situation where
the application of packaged products is difficult and the estimated development-volume remains
large.
To avoid such situations, hold, as a goal, the application of packaged products and keep the policy
of satisfying the true job-requirements through the application of packaged products.
The design method strongly recommended is the following: at the early stage where the packaged
products to be used are not yet determined, design the system based on the generally available
functions referring to Ch. 5 of this Technical Reference Model and others, and after determining which
packaged products to use, review, make adjustments, and finalize the design.
4.4.4. Review Process in Stepwise Approach
The stepwise approach, in addition to the advantages in reduction of project-risk or development
volume, will greatly contribute to the implementation of a high-user-satisfactory system.
In the conventional waterfall-model approach, as a matter of practice, modification of design or
implementation following the users’ comments in a timely manner is not easy: request for comments
on the system design collects no responses because the users could not imagine how the systems
will be used in the actual job situation of them, and users return comments or complaints back just
after the implementation is completed when they touch the system; and those comments given in the
final phase are often not reflected in the system because such reflection would roll-back the project,
or even put the project into confusion.
In the stepwise approach, review of the actual system is strongly recommended in the design
phase: primary functions and screens, not necessarily all, are implemented in the design phase;
users are requested to operate the system and make comments; and those functions and screens
are modified to satisfy the users; and the rest of functions and screens are determined sequentially.
The review-on-the-system, described above, is largely expected to contribute, not only to
user-satisfaction, but to reduction of roll-back in the final stage and avoidance of project-risk, and
reduction of development-volume or promotion of packaged-product-application as a result of these
efforts to make the reviews easy.
46
4.5. Policies for Common Databases
On the reconstruction to a large extent of systems towards total optimization, data-review is also
indispensable: reviewing locally-optimized databases and then constructing the totally-optimized
common database (hereinafter referred to as a “common DB”) is expected to, through the
rationalization of the entire system, to contribute not only to the cost-reduction, but also to high-level
administrative work and the provision of services to citizens.
4.5.1 Definition and Realization of the Common DB
The following three types of databases orienting the common DB have been under consideration in
forward-thinking ministries and agencies:
Common DB as total optimization: optimized DB used by the whole government;
Common DB as core: DB used as a core of primary jobs of specific ministries;
Common DB for reference: DB widely-used for referencing the data related to specific jobs of
specific ministries.
The common DB as total optimization is expected to collectively store the fundamental data of
private businesses or citizens. For private businesses, total-optimization focusing on the corporate
financial / tax information data based on commercial-registration data is required, and for citizens,
optimization — spanning ministries, and local governments — focusing on the data on the Basic
Resident Register based on the census register is required. Because there are many problems of
concern due to a large number of stakeholders, big influence, and protection of personal information,
the common DB as total optimization is out of the scope of this document.
The common DB as core — well expected to be used for patent administration in the Japan Patent
Office — is expected to be an essential database for specific ministries and agencies required to do
particular jobs. However, the target ministries and agencies are limited.
The common DB for reference — well expected to be used for statistical analysis, etc. — is desired
to be planned or implemented in many ministries and agencies.
Although, whether the preparation of the Common DB is treated as an individual job or as a
common job is dependent on the decisions of the ministries and agencies, an architecture covering
the entire system that minimizes the overlaps over more than one job-operation. At the same time, a
common data base, even when implemented for the purpose of particular ministries and agencies, is
desired to be implemented in such a way that interfaces compatible with open standards for the
public access or referential access are prepared.
Note that such data as that expected to be prepared in particular common business system for
Ministries — personnel and payment, document management — is out of the scope of this document.
47
4.5.2. Policies for Job-Operation System-Implementation using Common DB
Systems using common DBs should be designed and implemented on the basis of software
products such as BI or CRM. Even implemented from scratch or add-on — customizing such
products and adding on the system, those systems should be designed so that, in accordance with
the concept of DOA, applications surrounding the database placed in the center of those applications,
use the database, instead of the data embedded and confined in applications.
Also, the systems should be designed so that processes related to data modification and
processes related to data reference are separated, for purpose of wide data-sharing. Especially in
cases where the SOA is applied, processes (services) related to data modification should be able to
provide the modified data as a service provider to allow the processes (services) related to data
reference to use the data as a service consumer: such service-functions such as providing and
referencing data will promote not only wide-sharing of common DBs, but system reuse.
4.5.3. Responsibility Sharing among Integration Service Providers on Common DB
As a general rule, physical design / implementation of common DBs is the responsibility of the
providers of common platform systems, and logical DB design / implementation is the responsibility of
the providers of individual job-operation systems.
However, note that in cases where construction of common DBs is treated as a common work
instead of independent work, the provider of common platform system will be responsible for
everything, because the provider does the work of DB logical design / implementation.
Note that system operation / maintenance is allowed to be assigned to the provider that did the
design / implementation work.
4.5.4. Stepwise Approach in Common DB Planning / Implementation
As for the common DB planning / Implementation, it is strongly recommended to apply the stepwise
approach — proof-of-concept experiment, implementation of parts of systems, and implementation of
the entire system.
Also in the early stages of the stepwise approach, it is recommended to arrange the development
structure so that the provider assigned to the logical design / implementation takes the responsibility
of physical design / implementation: it will improve the efficiency of work.
Note that individual DB-implementation will easily lead to problems such as inflation of
maintenance costs and troubles when the system is required to expand: it is desirable to consider as
seriously as possible the application of DBs that are widely shared.
48
4.6. Policies for Implementing Common Business System for Ministries
One of the purposes of common business system for Ministries is total optimization — optimizing
the government systems as a whole beyond the boundaries of ministries. Therefore, common
business system for Ministries must be visibly effective in reducing and streamlining
ministry-dedicated systems.
4.6.1. Policies for Connecting with Ministry-dedicated Systems
Common business system for Ministries should connect with ministry-dedicated systems through
interfaces that are as simple and as loose as possible, because common business system for
Ministries linked to other various systems, should be as immune as possible to the changes in those
systems, as generally required in system connections. For such loose connections, use interfaces
that are prepared by the common business system for Ministries, and do not implement unique
interfaces unless strongly required for some special reasons.
Workflow, authentication infrastructure, and other common functions prepared by the common
business system for Ministries should be proactively used, because such functions will be a
considered as a part of common job-operations. However, note that employment of such common
functions does not always result in the elimination of the necessity of ministry-dedicated
implementation of the functions. Ministry-dedicated systems are not only required tentatively and
temporally in the case of stepwise implementation / deployment, but required in the case of a
To-Be-model to satisfy particular requirements of ministries, where the simple and individual
implementation of ministry-dedicated systems would be more realistic than the complicated
application of common business system for Ministries. Note, therefore, that in any case, the decision
of individual implementation should be done after sufficient consideration and assessment.
4.6.2. More Total-optimization-oriented Implementation Approach
In implementing common business system for Ministries, arrangement and planning from the
standpoint of total optimization is strongly recommended even though implementation and migration
of common business system for Ministries is often planned on system-by-system basis, because
common business system for Ministries have mutual dependency in such functions as authentication,
workflow, and employee information.
In such total arrangement and planning, the following are included as major issues: deployment
schedule; data migration; and linkage to existing systems. In addition, covering existing systems and
also systems in the planning phase, arrangement and planning on the following is strongly
recommended: directory information, authentication, and character code including extended codes
49
4.7. Virtualization Technologies
Virtualization masks boundaries or physical features of IT resources by inserting a virtual layer
between a resource and a resource-user (OS or application) to enable flexible use of resources
(Figure 4.7-1) which originated in the technologies developed to improve the hardware utilization
efficiency in 1960s, Virtualization has recently been gathering attention as one of the solutions for IT
problems such as utilization-efficiency-decrease and cost-increase in infrastructure, cost-increase in
IT management, and increase in energy consumption. Section 4.7 provides policies for virtualization
where the IT resource is hardware, and the user is an OS (refer to *1). Note that there are two types
of virtualization mechanisms: realized by hardware for virtualization; and realized by software for
virtualization.
Hardware (Server, Storage, Network and others)
OS, Middleware
Application
Virtual Layer
Virtual Layer (*1)
Figure 4.7-1: Conceptual Diagram of Virtualization
4.7.1. Policies for Application of Virtualization Technologies
Virtualization technologies can enable improvement of the efficiency in IT resource utilization. Also,
hardware virtualization expectedly reduces footprint and power consumption, and in addition,
increases system flexibility that leads to a reduction in system-operation and management work load.
However, note that virtualization could increase system overhead, or in case of the virtualization of
existing systems, migration may sometimes require modifications of application programs.
4.7.2. Types of Virtualization ・ Server Virtualization
In one type of virtualization, more than one virtual server shares one physical server, and in another
type, one virtual server runs on more than one physical server utilizing all the power. This sub-section
describes the former, because it will be more realistic in the actual procurement. Server-virtualization
software products enable construction on a physical server of more than one virtual server running
independently by an independent OS. Virtual Machine Monitor (VMM) is one of such products,
50
providing independent virtual servers (virtual machine) through hardware simulation, — in some
cases the virtual server is called a “guest server,” and the OS on a virtual server is called the “guest
OS.” VMM software products are generally categorized by host-type VMM and hypervisor-type VMM,
which are shown in the Figure 4.7-2.
Host-type VMM
Hardware
Host OS
Application Application
Application
Application Application Management Tool
Guest OS Guest OS
Guest OS Guest OS Management OS
Virtual Machine Virtual Machine
Virtual Machine Virtual Machine Virtual Machine
Hardware
Hypervisor-type VMM
Host-type VMM Hypervisor-type VMM
Figure 4.7-2 Two Types of Server Virtualization
・ Storage Virtualization Various types of storage virtualizations are available: in “dividing storage,” one storage device such
as a hard-disk drive has more than one virtual storage; in “storage consolidation,” more than one
physical storage is consolidated into a huge virtual storage; and in “storage-capacity virtualization,”
the storage-capacity that a server will know, is not limited by the physical capacity. Note that by
storage-consolidation more than one physical server can be consolidated beyond the boundaries of
its chassis, in comparison with the storage device consolidation enabled by RAID.
・ Network Virtualization “VLAN” is a virtual network independent of physical connections, enabling terminal-grouping.
Another is “network device virtualization,” where a physical device such as a router, switch, firewall,
or load balancer works as more than one independent device, or more than one device is
consolidated to work as a single device.
・ Desktop Virtualization Desktop virtualization is a screen-transfer-type thin-client technology where the server processes
applications or saves data, and the client handles input / output devices such as a keyboard or mouse.
As shown in the Figure 4.7-3, screen-transfer is realized by server-based-computing, a blade-PC, or
a virtual PC (VDI). In the virtual PC scheme, more than one virtual client machine is composed on a
physical server where OSs or applications belonging to virtual machines are running.
51
Desktop AP
Desktop AP
Desktop AP
Desktop AP
Desktop AP
Desktop AP
Desktop AP
Desktop AP
Desktop AP
Terminal Service
Server OS
Hypervisor
Virtual Machine
Virtual Machine
Virtual Machine
ClientOS
Client OS
ClientOS
ClientOS
ClientOS
ClientOS
Blade Hardware
Blade Hardware
Blade Hardware
Server-based-computing Blade-PC Virtual PC Figure 4.7-3: Three Schemes of Desktop Virtualization
4.7.3. Points to Consider in Integration by Virtualization The following are points to consider in system-integration by applying virtualization technologies:
・ Design and assessment should be done for each unit of virtualized-resource allocation, physical resource, and resource-pool, instead of conventional hardware- resource sizing;
・ Consider application, in the virtualized layer, of an N-to-N model covering the entire resource-pool for the server-availability requirement, instead of the conventional design based
on one-to-one or N-to-one model in hardware layer;
・ Consider monitoring and security of the management-layer of the hypervisor, virtualized server, and cloud, in addition to the conventional system design;
・ Pay attention to the possible performance-degradation, invisibility of resources from the management side (difficult to view), and resource-conflicts in multi-tenant environments;
・ Confirm the compatibility of the hardware products planned to be procured with the virtualization scheme to be employed;
・ Confirm the compatibility of the software (program) products planned to be procured with the virtualization scheme to be employed;
・ Note that there is a possibility, in the migration phase to the virtualized system, that the virtually realized functions — especially those related to device drivers — do not work in the same way as
the originals.
・ Prepare migration plans (of sizing, verification, data-migration, and others) for the migration from physical environments.
52
4.8. Standpoints of Cloud Users
“Cloud” generally refers to an information processing mechanism using networks through which
information-services are provided or used on demand, which should be treated from the following two
standpoints: users' standpoints that a cloud is an environment through which information services are
provided to be consumed by users; and service-providers' standpoints that a cloud is a tool
implemented by providers to deliver services. This section describes the points that cloud users
should remember from the standpoints of users — who use services delivered through the cloud.
4.8.1. Basic Policies for Selecting Cloud Services Clouds, which could be categorized in many ways, are basically, according to the user-acceptance
policy, categorized into the following two: a public cloud constructed on the internet and providing
services on the assumption that it is accessible by the general public; and a private cloud providing
services constructed on the assumption that it is accessible only by specific users. Note that a cloud
closed to a “community” formed by users having common objectives is called a community cloud,
which can be categorized in between those mentioned above.
This section describes policies for selecting service-delivery mechanisms among the following:
commercial public clouds by private providers; the ministry clouds, closed in a ministry and agency;
community clouds such as the government common platform, shared by ministries and agencies; and
on-premise, a conventional service-delivery not categorized in clouds.
Note that, for classifying clouds, except for the categorization by openness mentioned above, the
following categorizations by what is delivered as a service is helpful: SaaS (Software as a Service),
where services are delivered to applications; PaaS (Platform as a Service), where services are
delivered to a platform (on which applications run); and IaaS (Infrastructure as a Service), where
services are delivered to an infrastructure (hardware or iDC).
Figure 4.8-1 shows the categorization of clouds along two axes; assumed users of services, and
provided services. Note here that, because combination of clouds, such as “hybrid” (combination of
different services) or “multi” (combination of services from different providers) can be allowable,
assessments matching the usage or purposes will be necessary.
53
Public Cloud Community Cloud Private Cloud
SaaS Commercial Service Providing Web-mail Related FunctionsCommercial Service Providing CRM Related Functions, etc.
Government Common Platform
Local Government Cloud (Local Government ASP)
Ministry Cloud (Common Job-operation)
PaaS Commercial Service Providing Business Application Environments
Government Common Platform
Local Government Cloud (Shared Service-Center)
Ministry Cloud
IaaS Commercial Service providing Infrastructures
Government Common Platform
Local Government Cloud (Shared Service-Center)
Ministry Cloud
On-premise
Business Application
Infrastructure
Figure 4.8-1 Categorization and example of clouds
Generally, clouds will contribute to cost reduction because of its scale merit, application of
virtualization technologies, and on-demand-based charging. In the case of IaaS, improvement of the
hardware-use-efficiency by the application of virtualization technologies is expected to reduce cost,
compared to the cases of on-premise systems where the server-configuration is determined to
ensure the availability of individual application systems at the peak load — at an off-peak, plenty of
resources are not utilized. In the case of PaaS, in addition to the effects by IaaS, cost-reduction is
expected in system-operation / software-maintenance which can be eliminated by the employment of
PaaS. In the case of SaaS, in addition to the effects mentioned above, cost-reduction is expected in
the development / maintenance of business applications in the same way as expected in the
employment of job-packages. Although additional cost is required due to a lot of factors in the
deployment of cloud-based systems, reduced cost surpassing such additional cost is generally
expected.
On the other hand, for the individual systems using clouds, it is necessary to determine which type
of service-delivery (including on-premise) is best. The essential factors to take into consideration are
the following: cost, swiftness, data-linkage, service-menu, legal-constraints, and service-level. Note
that, in cases where the best cloud service is not ready-to-use, it is necessary to figure-out alternative
solutions through the assessment of those factors. Assessment policies of those factors are
described as follows:
54
- Cost
Generally, a public could is the lowest-cost option, followed by a community cloud, a private could,
and an on-premise system— the highest: a public could is advantageous in scale-merit and expected
to contribute to the total efficiency — the existing reasonable fee structures including a contract option,
which, especially in case of using IaaS, allows users to contract a minimum configuration for their
normal time with an option of adding resources in their peak time or busy seasons. In addition, even
in temporal use, a public cloud is expected to contribute to cost-reduction because of its reasonable
cost-structure: such features of a public cloud would be another advantage in cost-reduction.
Note that because fee structures, which fundamentally determine cost, are determined and
controlled by individual providers, in some cases they may be out of the scope of general
assumptions: especially in cases of community clouds or private clouds constructed by the fund of an
organization in charge of construction, in some cases, the fee structure does not match the actual
expense paid by user-organizations because the fee structure is determined by non-economic
reasons, and requires users to decide the use of the service from higher standpoints, taking into
account the discrepancies between the user optimum solutions and the total-optimum solutions.
Also note that users are required to make an assessment of the total cost because, in addition to
the fee, extra expenses will be required for additional work such as re-structuring job-operation
systems, the hybrid-type use or the multi-type use mentioned above, implementation /
system-migration, and additional security measures.
- Swiftness
The on-demand-feature is one of the advantageous features generally expected for cloud services
such as PaaS or IaaS — meaning that services become instantly available when demanded — in
comparison with the cases of conventional systems where such convenience has to be realized on
prefabricated menus of standardized features for infrastructures designed / implemented on
order-made basis. Such swiftness is generally expected in PaaS or IaaS, whether based on a public
cloud, a community cloud, or a private cloud. Note, though, that in the case of community clouds or
private clouds, such swiftness might not be attainable due to the lead time and procedures required
before the service becomes available, as long as those in the case of conventional on-premise
systems, or additional time might be required for analyzing how the cloud will be used because of the
lack of care for on-demand capability on the constructor side. In some cases because of the lack of
integrity in service menus, extra time is required for devising appropriate application measures and, in
extreme cases, a longer time than that in on-premise cases will be required where detailed
consideration and negotiations between cloud-service users and providers, which are
time-consuming when several organizations are involved.
Also note that in the case of SaaS, because of the necessity of job-operation restructuring and
consideration on a linkage mechanism to services, significant advantages / disadvantages are not
55
generally certain advantages are expected only when public-cloud based applications are employed
in small job-operations or some particular job-operations.
- Data-linkage
In a community cloud such as the Government Shared Platform System, the data-linkage capability
is significantly required: the data-linkage capability, considered as a function of PaaS, enables
secured and low-cost implementation of high-level data linkage among the systems belonging to the
community through common functions provided by the clouds.
Such capability is expected to produce the most powerful effect in community clouds: the
Government Shared Platform System, the following are expected: data linkage across the borders of
ministries and agencies, system-linkage among the common business system for Ministries, and
finally the system linkage between the individual ministry systems that share the common
government systems.
Although the data-linkage capability is also expected to produce effects in private clouds, the effect
will be limited inside ministries.
In public clouds or on-premise-based systems, where conventional data-linkage mechanisms are
required, the capability will not produce any particular effects.
- Service Menu
Service menus should be selected so that the system modifications that would be required for
transferring the existing systems to the systems using services or applications available on clouds will
be minimized. As for IaaS, in most cases, the transformation will be feasible if the menu includes the
OSs or DBMSs required by the existing systems, and as for PaaS, beyond OS or DBMS,
system-operation management or processing might be modified. So, when comparing IaaS and
PaaS from the point of system-transfer to cloud, IaaS is easier but the effects are smaller, and PaaS
is harder but the effects are larger.
On the other hand, in the case of implementing new systems on clouds, a feasibility study should
start with SaaS and proceed to PaaS instead of IaaS. Procurement specifications should be created
based on the standpoints of cloud-utilization because the utilization of cloud would be unattainable if
the procurement specifications were created based on on-premise systems, lacking the standpoints
of utilization of clouds.
Note that, in case of hybrid-type or multi-type use, attentions should seriously be paid on interface
design, emergency measures, and responsibility-divide including security issues, even if their
employment is desired when a clear plan for the utilization exists and the effects are well expected.
- Legal Constraints
56
Generally, a public cloud is most likely to be legally constrained, followed by a community cloud, a
private cloud and an on-premise system where handling legal constraints are easy. Note that issues
on legal constraints are dependent on providers. Refer for details to “4.8.2. Institutional Issues.”
- Security Constraints
Generally, a public cloud is the most severely constrained on the server / data storage locations for
the security requirements on data archiving, followed by a community cloud and a private cloud of
which situations are most close to those of on-premise systems. Also, because data and systems are
concentrated, a public cloud is the most severely constrained, followed by a community cloud, a
private cloud, and an on-premise system.
Note that, however, large-scale clouds would have advantages with regard to security technologies
or security-management operations because it could be easier to concentrate the expert skills and
knowledge, or monetary resources in a case of a large-scale cloud.
Also note that security constraints are highly dependent on individual providers. Refer to “4.8.10.
Security Issues,” and “6.12. Security.”
- Service Level
Generally, in cloud services, because the computer systems or facilities, etc. owned by the
providers systems and their situations of operations are not the easily visible from the user side,
users are always concerned about the ambiguity in the responsibility-divide as well as the risk of
service-down due to system faults. Therefore, the providers must prepare SLAs (Service Level
Agreement) which are used for confirmation of mutual — users and providers — understandings with
regard to the quality assurance standard for service functions, service coverage, or service quality.
Because the service level is largely dependent on the provider, it can be assumed that no essential
differences derived from the differences of the types of clouds (public, community, or private) exist in
SLAs. Refer to “4.8.3 Selecting Providers or Services.”
4.8.2. Institutional Issues Institutional issues should be taken care of when clouds are used. In this sub-section, the details in
relation to the following are described: “Location of Data,” “Relations to the Act on the Protection of
Personal Information,” “the Guidelines for Safety Management of Medical Information Systems,” “the
Guidelines for Information Disclosure of Safety and Reliability of ASP / SaaS,” “Issues on the
Copyright Act,” “Relations to e-Document Act” and “Foreign Exchange and Foreign Trade Act”
- Data locations
One of the problems when using a cloud is that users are unable to know where the data is stored:
57
the data may be stored in a place belonging to a foreign county, or it may be hopping from one
country to another, without staying in some place. Because data archiving is restricted legally by the
laws of the country where the data physically exists, the laws and regulations of the countries where
data is archived should be investigated. Note that some cloud-service providers do not disclose
where data is stored.
On the use of clouds, it is necessary to know where data is stored: if the data is stored in the United
States, the users should pay attentions on a risk that the data could be seized legally for investigation,
because, while the Electronic Communications Privacy Act (ECPA) prohibits the disclosure of
communications to investigative authorities without a search warrant, the PATRIOT Act gives more
power to the investigative authorities, and furthermore, users should know that, in some countries,
other countries even the internet is censored.
- Relations to the Act on Personal Information Protection Act
In Japan, the Act of the Protection of Personal Information, Article 22 stipulates as follows: “When a
business operator handling personal information entrusts an individual or a business operator with
the handling of personal data in whole or in part, it shall exercise necessary and appropriate
supervision over the trustee to ensure the security control of the entrusted personal data.” Article 23
stipulates that, except in some particular cases, business operators are not permitted to provide
personal data to a third party without obtaining the prior consent of the person. Also the Article 16
stipulates that business operators are not permitted to handle personal information about a person
without obtaining the prior consent of the person beyond the scope necessary for the achievement of
the Purpose of Utilization specified at the time of obtainment. On the other hand, there are no legal
constraints on the location of preserved personal information. As a conclusion, in Japan, preserving
personal information on servers provided by the third party including foreign business operators is
permitted insofar as the obligations such as supervision of subcontractors stipulated in the “Act on the
Protection of Personal Information” are fulfilled.
The EU directive prohibits moving personal information of inhabitants in EU to the third countries
that do not assure sufficient protection. The following eight countries are certified to have sufficient
protection (as of November 2010): Switzerland, Canada, Argentina, Bailiwick of Guernsey, the Isle of
Man, Isle of Jersey, Faroe Island, and Israel. Registered business operators in the United States are
admitted as eligible for handling personal information according to the safe harbor rules. Business
operators in Japan, in some cases, would be judged as ineligible for handling personal information.
- The Guidelines for Safety Management of Medical Information Systems, version 4.1
(Feburuary,2010)
Using data centers in foreign countries for SaaS is practically — in order to follow the guidelines —
difficult, because the guidelines require as follows: “The applications, platforms, servers, and
58
storages, etc. used for providing ASP / SaaS services must be placed at the locations within the
jurisdiction of domestic laws and regulations in order to promptly submit the documents required by
laws to the supervisory authorities.”
- The Guidelines for Information Disclosure of Safety / Reliability of ASP / SaaS
Since April 2008, the certification system based on the “Guidelines for Information Disclosure of
Safety / Reliability of ASP / SaaS” has been effective as the scheme of information disclosure on
safety / reliability of ASP / SaaS providers. Note that the certification systems would not effectively
work unless the providers were prohibited to start business without the certification, and the
certification system was acknowledged by both domestic and international providers. As a conclusion,
the certificate could be used as a criterion for selecting providers, depending on to what extent the
certification system is acknowledged.
- Issues related to the Copyright Act
Since the effectuation of the revised “Copyright Act” on January 2010, certain improvements have
been made, such as the curtailment of rights of reproduction for information search services and the
curtailment of rights of reproduction for information analysis.
However, providers have been expressing concern that some services permitted and provided in
other countries, could be judged illegal by domestic laws, such as holding copyrighted works in trust
by storage service. As for analyzing copyrighted works on clouds and providing the added value, the
providers are worried about the risk of being judged as committing an “indirect violation of providers’
rights.” Other services, such as recommendation services or thumbnails referencing multimedia
copyright protected works, could be judged illegal.
- Relations to the e-Document Act
Since the effectuation in April 2005 of “Act on Utilization of Telecommunications Technology in
Document Preservation, etc. Conducted by Private Business Operators, etc.” (Hereinafter referred to
as “e-Document Act”), preserved electromagnetic records in addition to written documents have
become legally acceptable in cases of about 250 laws. However, the e-Document Act does not care
much about preserving such documents in the servers of third parties, because the main concern of
the act is computerization of written documents.
As a consequence, some particular laws or regulations still put limitations on data-preservation
measures: “Ordinance Enforcement of the Installment Sale Act” stipulates that the books shall be
preserved in principle sales-offices, and the “Ordinance for Enforcement of the Corporate Tax Act”
stipulates that the books shall be preserved at the location of tax payment. Therefore, for the jobs
related to such laws, use of publicly available cloud services is limited.
59
- Foreign Exchange and Foreign Trade Act
The “Foreign Exchange and Foreign Trade Act” (hereinafter referred to as “Foreign Exchange Act”)
stipulates that in order not to undermine the maintenance of international peace and security, a
resident who intends to provide specific technology in the specified region, or to specific
non-residents / corporations, shall obtain a permission from the Minister of Economy, Trade and
Industry, and in Article 25, Paragraph 3, that as for the “electronic transactions designed to provide
the specified technologies to specified countries,” the permission shall be obtained. Therefore, as for
transmission of information from a location inside Japan to a server of a third party located in a
foreign country, transmission to a server located in a foreign country owned by the sender of
information with an intention of providing information to users in foreign countries, or transmission of
the outputs of computational processing by the server resources located inside Japan, the sender, in
some cases, will be required to obtain such a permission.
The specified technology mentioned above refers to a technology related to weapons of
mass-destruction such as nuclear weapons or conventional weapons. Note that many technologies
used for non-military purposes, such as cryptographic technologies, are included in the restricted
technologies, and require careful handling.
4.8.3. Selecting Providers and Services For utilizing clouds, providers of services should be selected through careful assessment. Points of
the assessment are described below for each of the following factors: “Server / Data locations,”
“Management of Multi-Tenants,” “Information Security Measures,” “Business Sustainability,”
“Services,” “SLA,” “Service Continuity,” “Service Cost,” “Continuity of System Environment in case of
Changing Providers,” and “Evidence of Data-erasing on Service Termination.”
- Server / Data Location
Note that while cloud-service providers who use servers and storages located at several distributed
sites in an integrated way for ensuring the availability of services do not always disclose the site
information, in recent examples, providers on the request of users — especially corporate users —
disclose the geographical information of servers preserving the data of the user concern. Make the
selection of providers taking such locations issues into account.
- Management of Multi-Tenants
Generally, except for a so-called “private cloud,” more than one corporation and business entity
share the same environment — it is called multi-tenant type of cloud usage. In such multi-tenant
environment, additional measures for security and availability will be required to enable such shared
60
use. In some cases where as high confidentiality as that of a private cloud is required, an IPsec VPN
based environment is employed. Therefore, attentions should be paid to what security services are
provided by what providers.
- Information Security Measures
Attentions should be paid to providers’ actions or attitudes to the ISM system (JIS Q27001: 2006,
ISO / IEC 27001: 2005) and the privacy-mark system of the Ministry of Economy, Trade and Industry,
what providers have a system to accept “audit of contractors as a part of internal control,” or instead
to provide reports compatible with “SAS70 (Statement on Auditing Standards No. 70,” or “Audit
Committee Report No.18 ‘Assessment of Control Risk of Entrusted business’ — Report 18 Audit — of
“The Japanese Institute of Certified Public Accountants.” Note that in addition Type II of SAS70 is an
important assessment reference because the compliance of providers’ job-operations to the laws and
regulations is assessed.
- Business Sustainability
Because, when using clouds, users have no other choices than leaving their business
infrastructures to providers’ hands, attentions should be paid to the healthiness of management
foundations of providers. Note that, in some cases where providers are based in foreign countries, of
which the information of business is difficult to obtain, special cares should be taken such as
requesting providers for confirmations before making the decision to use their services.
- Satisfiability of Functions
Note that, because specifications of the provided functions are out of the reach of users — users
just use those functions— a FIT / GAP analysis and preparation of counter measures to “GAPs” is
necessary before selecting services, to the same extent as required in the case of employing
packaged products.
- Satisfiability of SLA with the Requirement
Providers rarely agree on user specific SLAs, because providers are doing business with a wide
range of users. Furthermore, even SLAs prepared by major providers are only on the availability of
services, not including performance, back-up, recovery from service downs, or level of security. Note
that it is necessary to understand the service level of the services to be provided, make assessments
on the satisfiability, and request confirmations to the provider as much as possible if the satisfiability
is not clear, before finalizing a contract.
Also note that it is necessary to make assessments on a proposed service level according to
61
system needs and estimations on the utilization, and pay attention to the trade-offs — higher costs for
higher functions — between service levels and costs not easily accepting the general tendency that
services with higher service level obtain higher evaluations.
- Service Continuity
Note the necessity of requesting confirmations from the providers on the continuity of services
because services are prone to be updated for improvement by providers. Request the provider to
announce version-ups well in advance and to assure that the same services are available after the
version-ups.
- Service Cost
In many cases of cloud services charging system is based on the quantity of service provided.
However, continuously note the possibility of the charging system modification due to the economic
conditions or the situations in competition, and at the beginning of service, prepare for such
modifications of the charging system. Also note the necessity of cost evaluation — focusing on
whether or not using cloud service will contribute to cost reduction — from the standpoint of total
life-cycle cost.
- Continuity of System Environments in case of Changing Providers
Note the necessity of the study in advance on whether the development-environment, the
development tools, or the data in use are transferable to another provider’s environment: especially,
in the case of SaaS, confirmations are necessary on whether the data in use is downloadable in a
ready-to use manner the data structure preserved.
- Evidence of Data-erasing on Service Termination
At the termination of service, the data in use must be saved and eliminated from the system
completely — to the extent that recovery is impossible — destroyed, not just erased. Note the
necessity of requiring a report certifying the completion of the elimination of data, especially for highly
classified data.
4.8.4 Points of Procurement and Contract In this sub-section, several points that need attentions in procurement or contract of cloud services
are described from the following standpoints: “Click-wrap Contract,” “Application of
Separation-of-Procurement Policy (Procurement Standards),” “Avoidance of Provider-lock-in,” and
“Preservation of Interoperability.”
62
- Click-wrap Contract (shrink-wrap contract)
Note that in some cases, subscription of cloud services is contracted by the click-wrap style—
similar to the shrink-wrap contract in the case of packaged software products — where the click on
the agreement document is deemed as the consent to the subscription. Although the validity of such
contracts is not clear in Japan — in the U. S. there is a judicial precedence supporting the validity of a
shrink-wrap contract, but none as for a click-wrap contract — , much attention should be put on
contracting procedures in the case of click-wrap.
- Application of Separation-of-Procurement Policy (Procurement Standard)
The policy recommends separation of procurement for applications or system infrastructures.
However, in the case of cloud services, the situation is different in the following ways: in case of SaaS,
because only services are procured, there are no procured objects that the policy may care about; in
the case of developing applications on PaaS, because details of the development depend on
providers, it is difficult to obtain estimations on applications before the selection of provider; and in the
case of making assessments on IaaS as a development base, because applications are to be
developed on the IaaS development base — estimations on applications is inseparable from that of
IaaS — decisions of use of IaaS should be done before procuring applications.
Furthermore, there exists a case where more than one provider is involved that provides SaaS
services on IaaS or PaaS. In such a case, it is essential to make the responsibility boundaries of
providers clear between IaaS / PaaS and SaaS.
- Avoidance of Provider-lock-in
In the government procurement system, a service is procured on a fixed term basis, and on the
expiration of the term, the contract is renewed through another competitive bidding for the purpose of
giving a chance of entry to all providers: it means that the service may be transferred to another
service provider. Therefore, it is critical to ensure a smooth transfer of service and data, especially in
case of PaaS, because the applications developed in the former environment may not work well in
the next environment, and in case of SaaS the smooth transfer of data is essential.
- Preserving Interoperability
In cases where the interoperability with other systems is required, a to-full-extent investigation of the
service on its interoperability is indispensable. Also note that an extensive investigation on the
possible problems on the service level or security level is necessary.
63
4.9. Standpoints of Cloud Integration
This section describes the essential points from the view of the cloud integrator— a person in
charge of the integration on the procurer side or an integrator on the provider side. The two different
standpoints are useful to each other and share the same objective of providing cloud services in cloud
procurement / integration.
Because most of the clouds to be implemented in the ministries or agencies can be classified in the
category of private cloud, the descriptions in this section are based on the assumption that the cloud
is a private cloud. Moreover, the descriptions will help , procurers or integrators on the provider sides
when they prepare for the cases where the cloud is to be shared by more than one ministry or agency
— community cloud, or to be composed of multiple clouds — hybrid cloud.
4.9.1. Components of Cloud Clouds consist of a variety of components, of which types and product-implementations are
dependent on the service type of the clouds — SaaS, PaaS, and IaaS. In the generally available
cloud, a “resource pool” preserves IT resources such as hardware and software available to users on
an on demand-basis: those resources are provided to users as information services on a network
through the “network infrastructure” and “operation / management infrastructure.” Note that with
regard to SaaS and PaaS, detailed element-by-element consideration or design are required.— for
example, what types of software resources such as application-software provided as a job-service,
operational environment for applications, or database, should be prepared, and how many of them
should be implemented and stored in the resource pool.
- IT Resource
Servers and storages are the basic components of a cloud. In clouds, through the application of
virtual technologies, physical components such as servers and storages are generally virtualized:
those virtual servers execute information processing jobs in collaboration with the virtual storages
composed of physical devices such as internal disk-drives embedded in physical servers or
independent disk-drives.
- Network Infrastructure
The major function of network infrastructures is the provision of LAN functions inside the cloud
system and connection-interfaces to external networks. NAS / SAN working for the high-speed and
large-capacity data-transmission between servers and storages is one of the major components of
network infrastructures. Through the application of virtualization technologies to networks, a
virtualized network such as VLAN is available. Note that, in some cases, specialized network
64
functions, such as load-balancing or SSL acceleration, are treated as an IT resource and stored in a
resource-pool.
- Operation-Management Infrastructure
Operation-management infrastructures provide cloud-specific monitor / control functions similar to
the monitor / control functions common to conventional systems. In a cloud, the application of
virtualization or automation technologies has made the execution / management functions for
dynamic provisioning and deployment indispensable. Except for those, the operation-management
infrastructures work for user ID / security management, provide user-interfaces such as
service-menus or management-portals, and manage SLA.
The Figure 4.9-1 shows an example of how the conventional system shown in the Figure 4.2-1 is
constructed through the application of cloud-resources, where some of conventional components
have been replaced by cloud-services. In the figure, the servers inside the round rectangles are
realized by the application of cloud resources. Note that a group of servers distributed in different
segments are realized through the application of cloud services. The purpose of the figure is to
illustrate how the components are connected by networks, so the details of network infrastructure or
operation-management are not shown.
Figure 4.9-1 Example of Cloud-Resource Application
65
4.9.2. Service Menu Service menus, in the case of clouds, list the standard services prepared by providers for users,
aiming for prompt and stable provision of services: in some cases, the service menu includes options
for a specific service or options applicable for the entire menu.
Basically, the service should desirably consist of a limited number of standardized functions —
even though modifiable to some extent by options — and what the service provides to users should
be clearly described in the menu: providing services in such a way as described above would lead to
the uniformity of service — similar kind of services provides similar level of functions — and
contribute to the efficient use of resources or improvement of service quality. It is worth adding that
automation of a part or the entire service-providing processes would contribute to a speed-up of
service delivery.
Service prices, are sometimes determined case by case, using the menus and options: such
flexibility of pricing in accordance with the user situations is expected to guide users to some
specifically patterned usage of services, or to promote reasonable sharing of resources.
Note that, although requiring the services not listed on service menus is possible, it could not
always lead to the total-optimization, or could be even disadvantageous from the point of investment
recovery, because, in some cases, due to additional development or procurement, extra time would
be required for defining specifications, making price-estimations, or finalizing the SLA (described in
the following sub-section), and in addition the start of service would be delayed.
4.9.3. SLA SLA, in the case of clouds, is prepared by providers, proposing the agreement on the quality of the
standardized services for the purpose of prompt service delivery — in some cases, the SLA can be
selected by users through making selections of menus or options mentioned in the previous
sub-section.
A cloud has no unique business factors for determining requirements of an SLA, or the
technological / operational factors involving the selection of an SLA, except for that, in comparison
with cases of conventional systems individually designed in accordance with a predefined SLA, cloud
services are designed by providers on some assumed level of service: it is such a large difference
that the consensus in case of cloud is built through such a process that the user selects the services
from the service menu including options prepared by the provider.
Note that, although it is possible that some cases require services that enable SLA requirements
not listed on the menu It might not always lead to total-optimization, and could be even
disadvantageous from the point of investment recovery, because, in some cases, due to additional
development or procurement, extra time would be required for defining specifications, making
price-estimations, and furthermore the start of service would be delayed.
66
4.9.4. Use Case and Defining Requirements Requirements for cloud services are defined by use-cases where defined players involved in the
integration of systems based on cloud services, or the use of services act according to their role.
Players and their roles are defined as follows:
- The provider: preparing environments for SaaS, PaaS, or IaaS
Required to care about the security of services and resources; maintainability, completeness, and
reliability of resources on the cloud; effective handling of resources on the cloud; and scalability in
data size, number of tasks, and number of users.
- The consumer: implementing services on the service-environment provided by the provider
Required to care about the short-lead-time to start-of-service, and pay-as-you-go charging policy.
- The end-user: using customer services implemented on the cloud
Required to care about the types and functions of services, the completeness of data and requests
on the cloud.
- The enabler (vendor): providing services or goods to providers and users
- The operator: operating the cloud environment
4.9.5. Points to Take Care Cloud Implementation The points to take care cloud implementation are listed below:
・ It is required to design systems and operations by selecting the optimum virtualization mechanism and suitable management infrastructures, depending on the scheme of
service-providing such as SaaS, PaaS, or IaaS.
・ It is required to prepare the service menus acceptable and suitable to the assumed users, and construct the operation and management infrastructure (including management portal,
monitoring / statistics system) to realize them.
・ It is required to keep watching the utilization situation of each tenant.
・ It is required to implement a system that can scale-in or scale-out dependent on demand.
・ It is required to take care of and eliminate a point-of-failure.
・ It is recommended to, for functions such as monitoring, back-up, job-execution, logging, or authentication, employ models sharable in the entire cloud system, whenever possible.
・ It is required to, in the case of a hybrid cloud composed through the combination of several cloud environments, consider the implementation of functions for authentication / user-management /
billing-management, etc.
・ It is necessary to present the responsibility-divides and SLAs to the users.
67
・ It is required to set-up suitable and acceptable SLAs for users, and implement monitoring / controlling systems for satisfying them.
・ It is necessary to, for the successful transfer of cloud-service environments, which is expected in future, prepare clearly defined validation criteria of transfer-completion.
・ It is required to pay attention to the necessity of checking security situations of the VM images or the environment to be provided.
・ It is necessary to, in case of resource-pool sharing by more than one user, properly execute performance designs / expansion plans / security designs.
・ Note that, in some cases, attentions must be paid on external constraints — domestic or foreign legal constraints such as the EU directive for data-protection or the U. S. Patriot Act,
geographical situations including earthquakes or weather conditions, power cost and capacity,
power-grid margin rate and reliability, and network-bandwidth.
68
4.10. Security Issues
Information security entails not only the security capability of information systems, but also
ensuring the “safety and reliability” of the social system and businesses: the objective of information
security is ensuring confidentiality, integrity, and availability of information through the construction of
ISMS (Information Security Management System).
Information systems are facing not only external “threats” such as computer virus, unauthorized
intrusions, or denial of service attacks, but internal “threats” such as lack of security capability, and
inappropriate software operation / management. “Vulnerability” refers to the possibility of problems
raised by those threats: completely eliminating vulnerability from an information system is impossible.
Threats exploit vulnerability, which is impossible to eliminate, raising “incidents” such as system
troubles. Such troubles give unfavorable “influence” to information systems, social systems, and
businesses. That is the chain reaction caused by insufficient security protection.
Cares for security-protection measures are necessary from the following three standpoints:
・ Technical Measures for Security Protection Embed security protection capabilities, including those in the individual technology domains and
security factors in non-functional elements, in the systems to be implemented.
・ Organizational Measures Prepare the organizational structure for security protection.
・ Operational Measures For protecting security, proper operations of information systems through utilizing the
organizational structure mentioned above are required: the points for the protection of security
are those described with regards to the common procurement of services, or those described
with regard to the categories of procurement of service.
Also note the following two security measures for avoiding security chain-reactions.
・ Security measures eliminating threats and vulnerability to avoid security incidents,
・ Security measures to prevent incidents from leading to damages, even if the occurrence of an incident could not be prevented.
Security could be enhanced as completely as possible if cost and operability is not taken into
consideration. However, to what extent the security is enhanced should be determined by the balance
of cost and operability in the employment of measures and also the following two issues:
・ The probability of the chain reaction — “incident” resulted from “vulnerability” exploited by a “threat.”
・ The severity of “influence” resulted from an “incident.”
69
4.10.1. Recent Changes in Threats to Information Security and Problems
It is necessary to pay attention to changes as shown below in threats to information security and
the problems, which can be seen in the trends in information systems and communication networks in
recent several years:
・ More diversified, sophisticated, and complex attacks to information systems and communication networks
Attacks to information systems and communication networks that had, although they had already
existed in the early days of the internet, have recently changed in their mechanisms and the
sophistication levels. In comparison with past cyber attacks such as the defacing of the web-pages of
governments or large corporations for the purpose of a demonstration of technical excellence, or a
publication of political propagandas, as well as an intrusion into corporate internal networks just for
pleasure — the attack mechanisms are comparatively simple the attacks in these days aim to steal
money using information obtained by deception and are executed in more coordinated ways. The
following are descriptions of such recent attacks (also refer to the Figure 4.10-1):
Attacks raising the attack-success probability by flexibly up-dating multi-staged attack means
according to the target.
Attacks using virus-subspecies for degrading virus-detection accuracy of protection software
using pattern matching.
Zero-day attacks exploiting unknown vulnerabilities to others, which are difficult to detect or
difficult to analyze due to the complexity of influence, or selective attacks picking off specific
targets.
Although the actions against security breaches have been executed simultaneously among
organizations inside or outside by sharing damage information, as for the attacks described above,
because of the difficulties of disclosing and sharing damage information, it becomes difficult to apply
effective measures by a single method.
70
Single Separated Attacker
Coordination (Botnet)
Unauthorized Intrusion / Defacing
Building Attack-Bases
2000 2004~Multi-staged Attack (based on Botnet)
Exploiting Authorized Services as Cyber-
attack Base
2009~2006~
Victimizing PCs and Defacing Homepages
?
Exploiting Authorized Sites/Services
Impact on e-Market Business or Settlement Business, etc.Deception of Account Collection Information, etc: Impact on Supply-chain Risk Management
Destruction of PC, Defacing of HPChanges in Aspects of Damages (Impact on Job-Operations)
Object: PC or ServerTarget: Information Systems (of Organizations or Businesses)
Information Deception, etc.
Unchanged Design Methodology
Countermeasures using Security Products (Available on Market)Design Methodology based on Security Products
Age of Less-Visible Full Aspect and Points of ThreatInformation Protection by Established Information-Operation Structure (Information Collaboration)Design Policy: Avoiding deep-level intrusions even allowing shallow-level ones Embedding Protection Mechanisms in System Designs or Network Topology Designs
Single-attack to Single-vulnerability
Coordination among AttackersMulti-Intension Attack(Information Deception)
Explosion of Virus Sub-species Sequential Malware (Multi-staged Attack)Using Zero-Day VulnerabilityVirus Production Using ToolsTargeting Information Systems
Tactical Attack
Figure 4.10-1: Comparison of Cyber Attacks; Traditional and Recent
・ Growing Ambiguity of Influence on Organizations and Responsibility Divides
These days, when information systems take critical roles as a business infrastructure participating
in various aspects in business processes, and the entities involved in information systems are widely
distributed having different and complicated relations to each other, it is not easy to know who should
take the responsibility on the occurrences of troubles, or what frameworks should be employed to
take actions.
Therefore, there exists an increasing necessity for a new approach for resolving problems.
・ Diversified meaning of security
These days, in a similar way that the meaning of information systems to the society has been
beyond a simple technology, the information-security field has been related to various social systems
or business processes. In addition, what the information process means is understood differently
depending on the standpoints of the involved social systems or business processes: it means that the
diversification of the meaning of information security is going-on along with the diversification of
understanding of security issues. In addition, the position of information security has been diversified
as well as it is different depending on the responsibilities and purposes of the involved job-positions,
71
(Refer to the Figure 4.10-2). Therefore, in discussing information security, it is necessary to sort-out
the acceptance-and-delivery processes of information, clarify the standpoints of the discussion, and
make a consensus.
Products and Solutions
Management of System Design (including security functions)
Incidence Report (CSIRT)
Judgment of Organizational Measures (Assessment of Influence on Organizational Operations)
Compliance and Information-management
Security Rating
Safety of Manufacturing Line and Cost Efficiency
Protection of Intellectual Property of Private Businesses, etc.Organizational
ChallengeTechnical Challenge
Business Challenge
Standards, Guidelines, etc.
What are your organizational objectives?What is your role?What influence is predicted to what extent?Who attacks and for what?
Information Integrity
National Security
Investigations of Public Security
Crime-Prevention, Criminal Investigations
Internet Security
Communication Integrity
Security Business
Legal ComplianceBusiness Continuity
Protection of Critical Infrastructures
Audit
Academic Research
Communication-Carrier (ISP), Service
Management Judgment
Intelligence
Economy
Figure 4.10-2: Related Fields to Information Security
Much attentions has been paid to CND (Computer Network Defense) fields, as the changes in
threats and problems about information security have been widely noticed.
72
4.10.2. Treatment of Security in Separation Procurement of Services It is necessary, in procurement of services, to make a security assessment and determine security
measures for each procurement-of-service category, where the points of assessment of security are
as follows:
・ Planning Phase Predict the severity of risks through making assessments of threats, vulnerability, and the severity
of influences, and then determine the level of the countermeasures required for complying with the
results of the assessments..
・ Requirement Definition Phase Define the requirements for security corresponding to the severity of risks and the level of the
required counter-measures determined in the Planning Phase.
・ Development Phase Break-down of the requirements for security defined in the Requirement Definition Phase and
define the requirements for security in operation / maintenance.
・ Operation / Management Phase Execute the security counter-measures defined in the Development Phase, and also, pay attention
to new threats, new vulnerability, and changes in influence across the ages.
4.10.3. Outline of Measures for Ensuring Information Security in Planning / Design Phase (SBD)
For implementing security measures, it is desirable to note that actions in the up-stream of projects
have influence the down-stream, and take actions for ensuring security in the earlier stages of a
project so that integrity of security policies and traceability is ensured, and that re-run of work from
earlier processes is avoided in every stage of procurement of service.
If security requirements are not explicitly specified in procurement specifications, disadvantages
both to the procurer and to the provider could be produced. Examples are as follows:
(1) Possibility of financial damages due to re-run of work or extra procurement as a result of a lack
of consensus between procurers and providers in the stages from procurement to operation /
maintenance caused by ambiguity or unfairness in procurement specifications of information
systems.
(2) Possibility of disadvantages due to improper — excessive or dissatisfying — security measures
implemented as a result of a lack of clear requirements for proper security.
For resolving such problems, in all the stages, even in the planning phase, flawless implementation
of proper security measures is ensured through reducing the disadvantages on both of procurers and
providers. For such purposes, in addition to this Technical Reference Model, on the request of the
Information Security Policy Conference, the National Information Security Center published, at the
end of FY 2010, the “Manual for Defining Requirements of Information Security in the Government
Organizations Related to Information Systems” as a result of discussions in the “Discussion Group for
73
Measures for Ensuring Information Security in Planning / Design Phase (SBD)” (hereinafter referred
to as “SBD Discussion Group”)
The manual, covering procurement jobs for information systems including “up-dating” and “new
development,” is expected to be used especially by the administrative job-operators in charge of the
procurement of information systems to define security requirements on their own responsibilities and
write them down in procurement specifications. Also, the Manual is expected to be used by providers
of information systems to obtain information (including information on the process of building the
Manual) supporting their understanding on security requirements specified in procurement
specifications.
It is expected that security measures matching the necessities are ensured by preferentially and
clearly writing essential and effective requirements in procurement specifications paying attention to
information-protection measures in information systems and measures against security breaches.
4.10.4. Outline of Risk Factor Reference Model (RM)
4.10.4.1. Fields of Security Covered by Risk Factor Reference Model (RM) Security measures of information systems are categorized into IA and CND as follows (refer for the
Figure 4.10-3):
IA (Information Assurance): The actions to be taken to manage the risks in data use / process /
preservation / transmission or the risks of systems / processes using data. This document
specifically uses the term (information assurance) as the protection measures against leakage
or falsification of information through managing information according to formalized guidelines
or standards.
CND (Computer Network Defense): The actions to be taken for protection / monitoring /
analysis / detection of misconducts, and actions for responding to them (response). This
document specifically uses the term (computer network defense) as the actions to be taken
against cyber-attacks from the outside, for protecting communication networks and information
systems, to keep the systems operating and to prevent information theft.
As for IA, since the Standards for Information Security Measures for the Central Government
Computer Systems were formalized, the protection measures, including the internal control system
as a major protection measure, have been systematically deployed. As well as the deployment of the
internal control system, the system requires, in the operation phase, the execution of PDCA
(Plan-DO-Check-Act) cycle and the management of information of a level higher than predetermined.
As for CND, security protection measures have been deployed on a particular-system basis, such as
the implementation of firewalls, employment of secure communication-protocols, or the employment
of virus-detection mechanisms, partly because the departments in charge of security have put their
power entirely on the task of preventing the individual cyber-attacks which are constantly being
changed and sophisticated.
In these days, when the threats and problems of information security have changed, more
74
systematic approaches are required for CND. For such purpose, it is essential that the early stages of
the procurement of information systems such as planning or design contain work for embedding
security measures.
What should be protected:
Target Field of Information Assurance
Type 4: Factors in management, etc. (human, facility, rules, etc.)
Target Field of Cyber-Attacks
Threats and risks come from outside of organizations
Threats and risks emerge in the organization
Organizational CapabilityBusinessTrustworthiness
Type 2: Information theft issues
Type 1: Attack Issues
Protection from state-of-the-art attacks
IA (Information Assurance)CND (Cyber-Attack Protection)
CND (Cyber-attack defense) and IA (Information assurance) have different objectives (different operations)
Type 3: Information Management Functions
“Information leakage by cyber-attack (theft)”
Figure 4.10-3: Field Covered by RM
In order to figure out effective measure in the cyber-attack field (CND) as described above, it is
essential to apply the “Design of Counter-measures Based on the Correct Knowledge on the Present
Attacks” based on the Risk Factor Reference Model (RM).
4.10.4.2. Philosophy of Risk Factor Reference Model (RM) The “Risk Factor Reference Model (RM)” is an approach that enables judgment, based on the
shared knowledge of present threats and issues of influence to organizations in the sophisticated
CND fields, of the necessity of measures in system design, and the application of the
effectiveness-proven design of counter-measures.
The conventional “measures by management,” which generally requires the application of uniform
measures in design, have problems in the confirmation of the necessity and effectiveness of the
measures, and in addition is prone to lead to an escalation of cost for measures.
On the other hand, the RM is an approach that makes the necessity and effectiveness of measures
clear, and to intensively apply measures by system design to the essential parts found through the
impact analysis.
75
Furthermore, since the emergence of these new-types of cyber-attacks, the measures based on
the conventional design approach of installation of security-solution products have become less
effective without the aid of other means. In order to solve such problems, the RM has employed a
new design approach so that the necessity and effectiveness of measures is judged based on precise
knowledge of the aspect of actual attacks and the impacts on job-operations (refer to the Figure
4.10-4).
The approach of analysis based on the RM is as follows:
(1) Analyze and categorize the actual cyber-threats in detail, define “attack patterns” based on the
analysis and categorization, and predict specific attack scenarios.
(2) Formulate the information system design models for each type or characteristic of systems.
(3) Attack the model system on a desktop using the attack scenarios and trace the attack
(simulated desktop-attack). Then, analyze impacts of the attack and the effectiveness of the
designed measures.
(4) Document the results of traced attacks (simulated desktop attacks) as “System-Design
Measures.”
The results of analysis based on the RM is assumed to be used by both the procurer and the
provider of information systems for sharing the consciousness of problems and specifying the
necessary requirements of procurements based on the “System-Design Measures.”
Analysis of Object Systems of ProtectionAnalysis of Threats of Attack
(1) Analysis of Attack Patterns and Formulation of Attack Scenario
(2) Categorization of System/design Model
Impact / Risk Analysis
Analysis of Measures
(3) Attack Trace (Simulated Desktop Attack)
(4) Formulate System-Design Measures from Trace of Simulated Attack
Classification of Severe Threat models and Analysis of Attack Specifications
Classification of object Systems of Protection into the Four Categories shown above
a. Intranet Model b. Closed Area Model
c. iDC Model d. SaaS Model
Analysis of Inf luence of Attack and Ef fectiveness of Measures Taking Job-mission Impact into Consideration
Figure 4.10-4: Analytic Approach Based on the RM
The basic models of cyber-attacks assumed in the RM, used as the basis of counter-measure
design concepts, are the following:
Analysis of various modeled patterns of attack has revealed that any attack consists of more than
one stage, the first to the third, and the success or failure of the third attack is, almost commonly to
76
any pattern, deeply involved in the mission-impacts.
Therefore, the RM has, taking into account the limited effect of measures in the first stage, included
in to the scope of the conventional measures, proposed the measures by design-management,
focusing on the avoidance of the attacks in the third stage.
The RM has, in addition to the conventional measures, categorized such measures as measures
by design for “Avoidance of the Final Impact on the Mission of the Organization.”
For avoiding the organizational influence (mission impact) caused by the current cyber-attacks,
re-definition of threats and re-analysis of design philosophy and organization-operation policy is
necessary.
★第2、3段階の阻止により組織インパクトを回避
The ultimate impact on organizations (systems) is avoidable by preventing the invasion of main attack units and attack-objectives (information theft) even for attack tactics on which vulnerability-patch or AV pattern measures is not effective.
Blocking the communication with DL servers executed in the second / third stage.
Avoid the ultimate damage by blocking the attacks in the second / third stage, and then clean viruses and execute anti-vulnerability measures.
Preliminary Stage: Object / Motivation / Attack Base
First Stage: Initial Invasion to System (by various means)
(1) Initial Attack by Malware attached to Selective-attack e-Mail(2) DL Server Inducement by Web Attack(3) Initial Media-Mediated Malwareetc.
Abuse of vulnerability
Second Stage: Induction to DL Servers and Drop of Attack Malware
Dropping Initial Attack Unit
Dropping Main Attack Unit
Formulation of Attack Plan
Identification and Trace of Attack Pattern
★戦術的攻撃バターンの全体像の把握とパターン監視
Extract the characteristics of the attacks, which will be the keys to measures by design, by tracing attack patterns (behaviors)
★Avoiding the mission-impact by blocking the second / third attack
★Blocking the attainment of the final attack objective, and then destroying the threats
★Figuring-out of the Entire Tactical Attack Pattern and Watching for the Appearance of Tactical Patterns
Use of attack-bases
Execution of Attack on Final Destination
Third Stage: Information Theft by Deception and Handing-over to Attack Commander
Basic Model of Tactical Attack Philosophy of Measures by Design
The Ultimate Threat to Organizations
Figure 4.10-5 Common Basic Models of Cyber-attack assumed in the RM
77
4.11. Policies for Employment of Green-IT
Green-IT refers to a philosophy of applying information technologies giving considerations to the
environment. In Japan, on the framework of the Basic Act for the Promotion of a Recycling-Oriented
Society, enacted in January 2001, the laws and regulations regarding the recycling of resources and
improvement of energy-consumption efficiency have been established or revised. The government
procurement of information systems, as well as contributing to the realization of environmental-load
reduction through proactive actions, which should be a model to the society, is expected from now on
to contribute to the reduction of power consumption through consolidation of equipment, employment
of low-power-consumption equipment and energy-saving technologies, and the optimization of
cooling and power-supply.
The Philosophy of Green IT generally consists of the “Consideration of Environment in IT” (Green
of IT) and “Consideration of Environment by IT” (Green by IT). The former is about the reduction of
environmental load imposed by the equipment installed for information systems: it is a subject to be
discussed mainly in the procurement of goods. The latter is about the reduction, by the proactive use
of information systems, of environmental load imposed by the existing job-operations, social activities,
and the social systems: it is a subject to be discussed mainly in the planning processes of the
government procurement of information systems.
4.11.1. Application of Green IT to Procurement of Goods
As for the application of Green IT to procurement of goods, the “Consideration of environment in IT”
is the main subject. Especially, as for the activities covering the entire purchase and procurement, the
“Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other
Entities (Act No. 100, May 31, 2000)” and the “Basic Policy for the Promotion of Procurement of
Eco-Friendly Goods (Revision to Cabinet Approval on February 5, 2010)” (hereinafter referred to as
“Act on Promoting Green Purchasing”) have been in effect. According to those acts, in the
procurement of specified goods for procurement by the government, independent administrative
agencies, etc., local governments, and local independent administrative agencies, the compliance to
the compatibility conditions stipulated in the Act of Promoting Green Purchasing is required as
procurement conditions. Relations of the specified goods for procurement to the technology domains
in this Technical Reference Model are shown below; the conditions stipulated in the Act on Promoting
Green Purchasing are described in Ch.5 as the basic items of non-functional requirements for each
technical domain, and, if there exists standardized green IT technologies in a technology domain
other than those specified in the Act on Promoting Green Purchasing, they are described in Ch.5 as
basic or desirable features.
78
Specified Goods for Procurement in the Act on Promoting Green Purchasing, FY 2009
Technology Domain, Technical Reference Model for the Government Procurement of Information Systems (TRM), FY 2010
Computers 5.6.3. Server hardware
5.8.2. Personal Computer
Magnetic Disk Drive 5.7.1. Disk Storage
Printer 5.8.6. Printer Shared in Office
Digital Printer 5.8.6.2. Multi-Functional Printer
Copy Machine(Multi-Functional Printer) 5.8.6.2. Multi-Functional Printer
Display 5.8.2. Personal Computer
4.11.2. Application of Green IT to Procurement of Service
By the “Consideration of Environment in IT (Green in IT),” the essentially a concept in the
procurement of goods, although the short-term effects on reduction of environmental load is expected,
the long-term and significant effects on the reduction of environmental load is difficult. On the other
hand, the idea of “Consideration of Environment by IT (Green by IT),” is expected to contribute to
significant reduction of environmental load necessary for the realization a of low-environmental-load
society, because it aims for the reduction of environmental load through the reformation of the
existing job-operations, social activities and social systems. Therefore, much more effort should be
put into the field.
More specifically, reduction of the consumption of paper (reduction of environmental load by the
reduction of paper) required in the existing job-operations through the utilization of BI, etc, reduction
of geographical transportation of workers (reduction of environmental load by the reduction of
automobile-run) through the utilization of electronic conferences will be the realization-examples of
the “Consideration of Environment by IT.” Also, the use of cloud services has an advantage for the
reduction of IT equipment on the side of the “Consideration of Environment in IT,” and, at the same
time, an advantage in the reduction of the procurement or operation-load on side of “Consideration of
Environment by IT.”
In addition, as for the use of data centers, the consideration of both of the energy efficiency of IT
equipment and the energy efficiency of incidental facilities such as cooling systems is required in
procurement.
79
4.12. Notes on Employment of IPv6
The reservoir of IPv4 global addresses necessary for the Internet connection has dried-up ,
and the allocation of new addresses has been impossible (newly allocated global address will be
IPv6). Therefore, addition of servers with IPv4 global addresses, or new construction of DMZ
with IPv4 is difficult in normal situations. In addition, because IPv6 has no compatibility with IPv4,
IPv6-based networks or servers are unable to communicate with those based on IPv4 by simple
means: special schemes are required, such as co-existence or parallel use of IPv6-based
environments with the existing IPv4-based environments.
As for the equipment, such as networks, servers, or PCs connecting to the internet, in order to
properly achieve such co-existence or parallel use, preparatory consideration must be made for
the details of operation / management / monitoring / maintenance and security measures as well
as those for design or procurement.
Refer to “Guidelines for IPv6 Support in e-Government Systems”
http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070402_5_bt1.pdf
80
5. Descriptions of Technological Domain
This chapter describes the Technology Domains from the standpoint of procurers, showing
representational examples of requirements to specify in procurement specifications. Note that, on the
application to the actual procurement specifications, the words and phrases shown in the examples
have to be modified according to the actual situations, as follows:
The words or phrases parenthesized in “{},” curly brackets, are variable elements dependent on the
systems to be procured. Replace them with the appropriate words in accordance with the
requirements of the actual information systems.
The words or phrases parenthesized in “[],” square brackets, are exemplifications for clearer
understanding. Replace them with appropriate information in accordance with the requirements of the
actual information systems. Many of those will refer to product-names or trademarks, etc. They must
be replaced with more than one product-name or trademark followed by “etc,” for clearly showing that
they are exemplifications, in order to avoid specifying particular products, unless there are no proper
reasons for explicitly referring exactly to particular products in cases where the assets procured in the
past are intentionally used. If such proper reasons exist, describe in detail the information identifying
the particular products.
In the tables in the following sections, which list requirements, the requirement items labeled as
“Basic” are fundamental requirements — normally available products will satisfy these requirements.
In the evaluation-by-total-score based procurement, it is allowable to use them as the indispensable
requirement technical points items. On the other hand, the label “Additional” indicates that the
requirement item is not always necessary, or not always satisfied by normally available products. As
for the evaluation-by-total-score based procurement, those items should be used as additional
technical point items, unless they are indispensable to the system to be procured. The label
“Selective” indicates that more than one of the items listed in the description is required to be
satisfied.
Note that, because those labels used in the sample requirement tables are given to the assumed
ordinary requirement items in the technology domain, it is necessary, when they are referenced for
creating actual procurement specifications, to consider which requirement items should be labeled as
“basic” or “additional.” Pay attentions on how the items in the examples are labeled as “basic,”
“additional,” or “selective. Also, note that, because some of the requirement items labeled as “basic”
might be over-specifications for small-scale systems, it is necessary to select the requirement items
carefully in the design or implementation phase. In addition, it is necessary to make adjustments so
that unnecessary items for the actual information system to procure are eliminated, and the
requirement items necessary for the actual systems are included, even if they are not listed in the
sample requirement tables.
81
The technologies listed in the table “Related Technology” are those supposed to be referenced in
procurements, or the related open-standards. Referencing them in procurement specifications
requires sufficient care and sufficient knowledge about those technologies. Simple copy of items
listed in the sample requirement items would in some cases lead to less possible procurement
realization — strikingly reduce the room of choice of products to be procured —, or lead to difficulties
in the utilization of the existing assets due to the discrepancies between versions of open-standards.
Therefore, in the reference of the sample tables, attention must be paid to total consistency in relation
to the procurement.
82
5.1. BI/DWH/ETL
5.1.1. Definition
BI / DWH / ETL collectively refers to a system that provides proper information in a proper style, at
a proper time, and to a proper user: it is a mechanism for referring to or analyzing data in
job-operations through searching, referencing, operating, transforming, and archiving in a integrated
and multi-purpose way.
In addition, it contributes to the reduction of person-months required for the development of
screens for analytic-operations or job-forms.
Figure 5.1-1 Elements and Usage in Job-Operations of Business Intelligence
Selectively combining the functions or services of BI / DWH / ETL listed in the table below, enables
the functions or services shown below. (Note that they are examples).
・ Business Performance Management
83
The objective is to realize productivity improvement — by measuring and monitoring the
effectiveness of job-operations, and making predictions through applying quantitative or qualitative
benchmarks — and to enable prompt detection of trends or risks.
It will support job-operators in every situation, by seamlessly connecting a series of
job-management activities, such as assured delivery of tactically important information of
job-operations or events, predictions on job-operations and problem-resolution, enabled by
integrating relational databases existing in data-marts, spreadsheets, and tools for analysis such as
data-mining, into a single large system.
・ Integrated Financial Analysis
Integrated Financial Analysis enables financial analyses such as a cost-effectiveness analysis
through providing all the decision-makers with the critical financial information on job-operations in a
secured and effective manner,.
It serves as an analysis tool in job-operations executed in a systematic and integrated way on the
platform consisting of data warehouses, ODSs or spreadsheets, and OLAP. Therefore, it also
requires correctness of data and high-level security.
In addition, it contributes to the effectiveness-improvement of the existing various job-operations
involving statistics.
Functions and Services of BI / DWH / ETL Functions and Services Definition / Description Business Intelligence (BI)
Refers to the following: an approach to utilizing a large-volume data output from job-operation systems, etc.; a mechanism or an activity enabling job-operations and predictions, based on a philosophy of establishing knowledge or insight available for making decisions through systematically and methodically storing, classifying, searching, analyzing, and processing factual data; and a system or technology supporting such activities. It aims to flexibly analyze the required information on job-operations and be utilized to provide improvement for various kinds of job-operations.
Data Warehouse(DWH) Refers to the following: a collection of time-series data organized and integrated in groups according to the objectives of use, without mechanisms for deleting or updating, where transaction data is extracted from job-operation systems, re-organized, and stored there to be used for information analysis or decision-making; and a decision support system based on large-scale databases, or an integration concept of such systems.
ETL — Extract / Refers to a series of data processes that extracts data,
84
Transform / Load (Functions for data extraction, process and saving)
transforms it so that it is easily used in a data warehouse, etc, and then loads it into target systems such as data warehouses, etc.; and a software function that supports such a series of processes.
Data Mart Refers to a database, in comparison with the central data warehouse integrating and managing the entirety of job-operation data, composed of data extracted from data warehouses, edited, and stored for specific departmental or private purposes; and a subset of data extracted for the use of specific departments or users.
OLAP — Online Analytical Processing (Tools for data collection or analysis)
Refers to a philosophy and the realization of an analytical application so that end-users directly search / tabulate data existing on a database for finding problems or actions to take: it is generally categorized in the following three ways: ROLAP using databases, MOLAP using multi-dimensional data bases, and HOPLS combining the two.
ODS — Operational Data Sore (temporal data saving system)
Refers to a collection of job-operation data, extracted and temporarily stored for auxiliary purposes such as search etc.
Data Mining Refers collectively to knowledge-finding methods or processes, by which, through the analysis of huge amount of data by different analytical techniques, the hidden knowledge on how the data links to each other or what the data indicates is uncovered. The models created through such processes will be available as the foundation of predictions or simulations.
Information dashboard Refers to a personalized software tool for accessing information on portals, or sharing information such as outputs of analysis: it is available for consolidating communication paths.
Reporting tool (Reporting service)
Refers to a tool for providing a variety of viewpoints for data generated through job-operations, by summarizing, classifying, prioritizing, and display: it supports creation, management, or delivery of written or interactive web-based reports.
Spreadsheet Refers to application software for tabulating or analyzing numerical data, by interpreting numerical data or mathematical expressions written in a cell at a cross section of a row and a column of a table, automatically executing the calculations, and putting the results into designated cells. Being equipped with interactive cross-tally tables, it is available as a front-end of BI by standardized open-formats or interfaces to web-services.
85
5.1.2. Business Intelligence (BI)
BI refers to an approach of utilizing an enormous amount of job-operation system output data, etc,
for decision-making, by storing, classifying, searching, analyzing, and transforming factual data: it
also refers to a scheme or an activity for realizing the idea of extracting useful knowledge or insights
in a systematic way and enabling business predictions, or systems and technologies supporting such
activities. Its objective is to utilize information for improving job-execution efficiency through flexibly
analyzing the required information.
In comparison with conventional data-analysis, which is closed in individual stand-alone systems,
along with the implementation of system-linkage infrastructure such as SOA, the cross-system
analysis of data separately stored in individual systems after being homogenized has become
necessary, and the mechanisms for the management and transformation of meta-data has been
implemented. Note that the corresponding mechanism (meta-data registry) has almost the same
functions as those of the combination of ETL and DWH. Functional Requirement 1 Basic Capability of storing / classifying / searching / analyzing /
transforming data in a systematic and integrated way. 2 Basic Mechanisms for enabling the production, through analysis, of useful
knowledge or insights. 3 Additional Capability of combining [data-warehouse, ETL, data-mart, OLAP,
data-mining] methods according to the needs. 4 Additional Capability of visualizing the results of analysis on [BSC, information
dashboard, reporting-tool, and spreadsheet, etc.] according to the needs.
5 Additional Mechanisms for interactively selecting various forms or graphs. 6 Additional Mechanisms for raising an alert for proper users triggered by a
predefined threshold. 7 Additional Mechanisms of meta-data registry (transformation of meta-data or
homogenization of data-quality at the exchange of data between systems), effective on the analysis of linked data on a system-linkage infrastructure.
Non-functional Requirements (write only when individually required) Backup Additional Functions of data-backup or data-recovery. Security Additional Permission for the explicitly authenticated users by IDs to
execute processes of data-search / data-check. Related Technologies Format of Meta-Data Registry
ISO / IEC 11179ISO JIS X4181-3 (JIS X4181-1, JIS X4181-2) — JIS standards fully-compatible with the international standard, ISO / IEC 11179)
86
5.1.3. Data Warehouse
A Data Warehouse refers to a collection of time-series data integrated and edited according to
purposes, which basically, have no mechanisms for data deletion or staying up-to-date: it is used for
information analysis and decision-support through extracting, re-organizing, and archiving transaction
data generated by job-operation systems. It also refers to a decision-support system based on a
large-scale data base, or the system-construction concept of such systems.
Functional Requirement 1 Basic Configuration as a collection of time-series data integrated and arranged
according to purposes. 2 Basic Capability of archiving, for a long time, raw data (detail data), not yet
transformed into forms suitable for analysis. 3 Basic Capability of extracting, re-configuring, and archiving transaction data. 4 Basic Application of independent development of business application systems. 5 Basic Deletion or updating of data is prohibited under normal conditions.
5.1.4. ETL — Extract / Transform / Load (Data Processing Capability)
ETL refers to a series of data processing that extracts data stored in job-operation systems, etc
(Extract), transforming into forms suitable for being used in data warehouses, etc (Transform), and
loading into target systems such as data warehouses, etc. (Load). It also refers to functions
supporting such data processing. ETL enables data-cleansing, etc.
Functional Requirement 1 Basic Capability of extracting data from various types of data-sources
[standard-format files, data bases, or FTP, etc.]. 2 Basic Provision of selections for consolidation / transformation of data
available [filtering, tabulation, division, binding, conditional branching, or derivation (creating row-values according to the formula embedded in the input row, and storing of the results as a new row or replacing an existing row)].
3 Basic Capability of loading data from target systems [data warehouse, or data mart, etc.].
Related Technologies Interfaces for DB Access
SQL
87
4 Basic Capability of exception-handling, for such cases as error events in various types of data-flows.
5 Additional Capability of setting / executing [various types of operations of data or flow-controls, etc].
5.1.5. Data Mart
A Data mart refers to a database consisting of the data extracted and reorganized, for departmental
or private purposes, from the archives in the data warehouse: it is a subset of data extracted
according to the operational needs of particular departments or users, while the central data
warehouse manages, in an integrated way, the entire job-operation data.
Functional Requirement 1 Basic Employment of databases consisting of the data extracted according
to purposes separate from the data archived in the data warehouse. 2 Additional Employment of a database of summarized data for efficiently
responding to requests of search or analysis.
Related Technology Interfaces for DB Access
SQL
Related Technology Interfaces for DB Access
SQL
88
5.1.6. OLAP — Online Analytical Processing (Data Tabulating / Analyzing)
OLAP refers to a philosophy and a system realization of an analytical application, allowing
end-users to directly search / tabulate data existing on a database for finding problems or actions to
take. It is generally categorized in the following three ways: ROLAP (Relational OLAP) using
relational databases, MOLAP(Multidimensional OLAP) using multi-dimensional data bases for
aggregating and tabulating data, and HOLAP (Hybrid OLAP) with high-speed preprocessing and
scalability.
Figure 5.1-2: Elements and Usage in Job-operations of OLAP
Functional Requirement 1 Basic Assurance of end users’ direct search / tabulation of data existing in
databases. 2 Basic Employment of a relational database or pre-optimized data-management
system. 3 Basic Provision of multi-dimensional conceptual views. 4 Basic Accessibility from a reporting function or a spreadsheet through
[pivot-table service (PTS), etc.]. 5 Basic Assurance of users’ easy access to data without the knowledge of
physical storage-structure of the data.
89
6 Basic Capability of providing any dimension or cell with functions of [slicing, dicing, or drilling, etc] with the equal performance.
7 Basic Uniformity of structure and operations in every dimension. 8 Basic Capability of executing dynamic matrix-processing. 9 Basic Accessibility by multiple-users simultaneously. 10 Basic No functional limitations of software in cross-dimension processing. 11 Basic Capability of flexible reporting. 12 Basic No limitations on the number of dimensions or members 13 Basic Capability of individually executing each processing [slicing, dicing, or
drilling, etc] without the help of menus.
5.1.7. ODS — Operational Data Store (System for Temporarily Preserving data)
ODS refers to a collection of data which consists of job-operation data extracted from job-operation
systems and temporarily stored for additional purposes such as search etc. Functional Requirement 1 Basic Function as database for extracting and temporarily storing data from the
job-operation system. 2 Basic Capability of storing volatile real-time data. 3 Basic Capability of the short-term preservation of data
Related Technology Interfaces for DB Access
SQL
Query Language
MDX (Multi-Dimensional Expressions) — used in obtaining or manipulating multi-dimensional data.
Related Technology Interfaces for DB Access
SQL
90
5.1.8. Data Mining
Data mining collectively refers to knowledge-finding methods or processes, by which, through the
analysis of huge amounts of data by various analytical techniques, the hidden knowledge on how the
data links to each other or what the data indicates is uncovered. The models created through such
processes will be available as the basis of predictions or simulations.
Figure 5.1-3: Elements, Processes, and Usage in Job-Operations of Data Mining
Functional Requirement 1 Basic Mechanism for, through the analysis of huge amount of data, finding the
hidden relationships of data or knowledge. 2 Basic Mechanism for visualizing relationships of data or knowledge. 3 Basic Mechanism for creating prediction-models from relationships or
knowledge, and functions for making predictions through the application of such models to a new data-set.
4 Basic Mechanism for assessing the accuracy of predictions. 5 Basic Mechanism for selecting algorithms [correlation rules, clustering,
decision-trees, naive Bayes, neural nets, etc.] to apply to the analysis. 6 Basic Mechanism for repeating analysis in a trial-and-error way aided by a GUI.
91
7 Additional Functions for data-access or output through [reporting tools or spreadsheets, etc].
5.1.9. Information Dashboard
The Information Dashboard refers to a personalized software tool for accessing portals, or sharing
information such as analysis outputs: it is used for the purpose of consolidating communication paths. Functional Requirement 1 Basic Capability of constructing portal sites without difficulty, satisfying specific
requirements from target users, based on the integrated portal framework. 2 Basic Capability of constructing more than one type of web site [private site,
departmental site, intranet site, extranet site, internet site, etc.]. 3 Basic Employment of authoring tools enabling easy content posting. 4 Basic Capability of allowing the owner of information to specify, through the built-in
functions, how and when to deliver the information to the specified users. 5 Basic Capability of personalizing the information to be delivered. 6 Basic Employment of a framework for comprehensively-integrating applications,
enabling construction of composite-applications. 7 Basic Functions for application-governance to detail-control the
application-execution environment.
5.1.10. Reporting Tool (Reporting Service) A Reporting tool refers to a tool for providing a variety of view points for data generated through
job-operations, by summarizing, classifying, prioritizing, and displaying: it supports creation,
management, or delivery of written or interactive web-based reports.
Related Technology Interfaces for DB Access
SQL
92
Figure 5.1-4 Elements and Usage in Job-Operations of Reporting Tools
Functional Requirement 1 Basic Capability of providing user-friendly visualized information through
[summarizing, classifying, or prioritizing, etc. 2 Basic Capability of allowing users to select data-sources and access methods. 3 Basic Provision to users of report-creation functions, report-templates, and
report-management screens. 4 Basic Functions for assisting the creation of written or interactive web-based reports
[creation and management of forms]. 5 Basic Capability of allowing users to specify the viewers in the publication or delivery
of reports.
5.1.11. Spreadsheet
Spreadsheet refers to application software for tabulating or analyzing numerical data, by
interpreting the numerical data or mathematical expressions stored in a cell at a cross section of a
row and a column of a table, automatically executing the calculations, and storing the results in the
93
designated cells. Being equipped with interactive cross-tally tables, it is available as a front-end for BI
through standardized open-formats or interfaces to web-services. Functional Requirement 1 Basic Capability of serving as a front-end of OLAP or data mining (or others
categorized in BI). 2 Basic Capability of embedding automatic-execution mechanisms or constraint
conditions. Note: Also, refer to “5.8.5 Definitions of Common Operations,” and “5.8.5.8 Functional
Requirements for Table Calculations.”
94
5.2. EAI
5.2.1. Definition EAI (Enterprise Application Integration) collectively refers to functions, middleware / application
packages, or integration technologies for linking / integrating different computer systems or business
application packaged products by means of a hub-and-spoke architecture, and providing strategically
enhanced functions or enriched information.
Conventionally, data-exchange between servers has been executed by means of a file-transfer or
messaging technologies. However, as the number of servers requiring data-exchange has increased,
the idea has emerged that it will be more efficient, if the development and maintenance cost is taken
into consideration, to establish such a data-exchange function as a standard function than to
individually develop and maintain each data-exchange mechanism. In EAI, which has emerged out of
such ideas, data-exchange is generally executed asynchronously (loosely coupled) for the purpose of
preventing ripple effects of EAI processing-delays to the inter-connected servers by allowing the
servers to execute processes independently and asynchronously.
Figure 5.2-1 Schematic Diagram of EAI
Definition of EAI Function and Service Name of Function or Service
Definition
EAI Function It links / integrates, in a organic way, different computer systems and business-packaged software products by means of a hub-and-spoke type architecture, and provides them as more strategic information resources. In addition, it provides more than one adapter for the purpose of inter-system connection, such as an application adapter enabling easy
95
connections to business packages, a technology adapter for enabling easy connections through standard protocols, and a mainframe adapter enabling easy connection to main frame computers.
5.2.2. Functional Requirement Functional Requirement 1 Basic Capability of format-transformation — transforming data or characters
written in individual formats or character-codes used in a system or an application connected to the EAI to other different formats or codes.
2 Basic Capability of routing — delivering data to more than one recipient according to the contents of the data.
3 Basic Employment of more than one connection support mechanism (adapter) prepared to reduce the interface development work on the side of servers to be connected to the EAI.
4 Basic Capability of process-control — enabling automatic job-execution by combining different functions such as routing and format-transformation.
5 Basic Capability of data-item-mapping — mapping a data-item used in a system to a data-item used in other system.
Non-functional Requirement (write only in a case of individual-purchase) Meta-Data Definition
Additional Employment of meta-data definitions in an industry standard format, such as SWIFT, FIX, or EDIFACT: by using the prepared format, users are able to greatly save the cost of developing meta-data from a scratch.
Development Environment
Additional Functions of EAI middleware products preparing GUI development environments where “drag & drop” or built-in functions enables “intuitive” development, instead of coding in a programming language: it will ensure high development-efficiency and maintainability (easy maintenance), because members without programming expertise can participate in the development.
96
5.3. iDC Facility
5.3.1. Definition iDC (Internet Data Center) Facility refers to a highly-secured and quake-resistant facility equipped
with high-speed telecommunication lines, power generators, and high-power air-conditioning systems
that hold servers, network-equipment, etc. (hereinafter referred to as “equipment,” etc.) on which
job-operation systems run. It is used for operation-work such as monitoring and troubleshooting of the
equipment, etc and the applications.
The services provided by an iDC are categorized generally into housing services and hosting
services. In the housing service, users install the equipment of their property in the iDC, and receive
services such as the internet connection or operation of that equipment. On the other hand, in the
hosting service, users use the equipment (dedicated to the user or shared) connected to the internet
of the providers’ property and receive the service of operational work: generally, the hosting service is
used for web servers or mail servers.
Note that, because in the case of a housing service, equipment etc is generally purchased
separately, therefore procurement specifications for such equipment are necessary. In normal cases,
because equipment, etc. is provided installed in a rack, the procurement specification should be for
such racked equipment, etc, where the items of the specification are as follows: rack-size; number of
racks; rack-weight (total weight of rack and equipment); power (maximum power consumption after
equipment-installation); amount of heat generation (total for all equipment installed); and
power-supply (voltage, shape of receptacle, and number of receptacles).
Also, note that purchase of telecommunication lines (including monitoring service) is categorized
as a separate-purchase, and is not included in the purchase of an iDC.
Functions and Services of iDC Facility Functions and Services Definition Location Requirement Refers to requirements for the location such that the iDC
will not lose the ability of providing services even in a situation caused by a natural disaster such as an earthquake where the iDC is damaged.
Facility / Machine-room Requirement
Refers to a requirement for facility-structures such as quake-resistance of the building or duplexing of communication equipment such that the iDC will not lose the ability of providing services. A machine requirement refers to a requirement for installation-environments (sites) of the racks loaded with equipment, etc.
Power / Air-conditioning Requirement
Preservation of redundancy such as duplexing of power / air-conditioning system such that the equipment, etc. (or the services) will not lose the ability to run due to problems in the power / air-conditioning system.
97
Security Requirement Physical security measures preventing illegal intrusions / interferences / destruction, or illegal access to the properties in the iDC that are closed to public, excluding work on implementing security measures on equipment, etc. which are categorized as operational services separately purchased. As for such operational services, refer to “5.9. System-Operation Management / Security.”
Operation Requirement Maintenance / management of iDC facility, excluding monitoring, configuration, malfunction-control, or storing backup equipment, etc., which are categorized as operational services separately purchased. As for such operational services, refer to “5.9. System-Operation Management / Security.”
5.3.2. Location Requirement A location requirement refers to a requirement of location for an iDC. Functional Requirement 1 Basic An iDC shall be located in a place where earthquake damage is expected
to be minimal. (Be sure to avoid places close to active faults pointed-out in documents, or places pointed-out in documents that have suffered liquefaction damage in the past.)
2 Basic An iDC shall be located outside of dangerous zones designated in hazard-maps, etc. publicized by the MLIT or the local governments
3 Basic An iDC shall not be located in a place where a flood caused by tsunamis, high-tides, or torrential rains is expected.
4 Basic An iDC shall not be located in a place within {100 meters} of which the total number of hazardous-material producing facilities or high-pressure-gas producing facilities located exceeds that designated by the Fire Defense Law.
5 Basic An iDC shall be located in a place accessible by maintenance-service providers within {30 minutes}.
5.3.3. Facility / Machine Room Requirement A facility requirement refers to a requirement for a facility, such as quake-resistant structure of a
building or duplexing of telecommunication equipment. A machine room requirement refers to a
requirement for the installation environment for racks or equipment, etc.
Functional Requirement 1 Basic Employment of a quake-resistant or quake-absorbing structure against
an earthquake of intensity 6 upper. 2 Selective Employment of a fire-alarm (fire-protection) system compliant with the
Building Standard Act and the Fire Defense Law, or a system capable of sensitively catching changes in the room environment to detect early signs of a fire.
98
3 Selective Employment of fire-extinguishing equipment that is water-proof against the floods caused in fire-fighting activities, and of zero-ozone-depleting coefficient. Or, employment of nitrogen-fire-extinguishing equipment for the purpose of protection against the floods caused by fire-fighting, environmental protection, and the avoidance of influence on human bodies.
4 Basic Buildings with more than {2} doorways for ensuring more than one evacuation route available.
5 Basic Capacity for installing more than {2} provider-independent telecommunication lines running on different routes.
6 Basic Structure of machine rooms protecting the rooms from being viewed from outsides, such as a windowless structure.
7 Basic Free-access floor that resists against more than {500} gals of maximum of acceleration. In the case where the building is of quake-absorbing structure, the building or the quake-absorbing equipment shall resist against the acceleration mentioned above.
8 Basic Machine-room with ceiling height of more than {2,400} millimeters, excluding the height of a free-access floor.
9 Basic Free-access floors able to resist against more than {600} kg / m2 of the floor load including the equipment separately purchased and the racks implemented with equipment.
10 Basic Machine-rooms compartmented against fire. 11 Basic Provision, for security reasons, of individual compartments separated
from the spaces for other users. Or, the racks are able to be locked user by user for the separation of users.
12 Basic Provision of the installment environment (functions) specified in the specification of racks or equipment separately purchased.
Non-functional Requirement (write only when individually specified) Environmental Requirement
Basic Certification of compliance with the international standards of environmental management systems, ISO14001.
5.3.4. Power / Air-conditioning System Requirement A power / air-conditioning system requirement refers to a requirement for power / air-conditioning
systems for redundancy-ensuring such as duplexing of those systems. Functional Requirement 1 Basic Full-non-interruptive access to electricity even during periods of legal
inspection. 2 Basic Employment of uninterruptible power supply systems (UPS), constant
voltage and constant frequency units (CVCF), and power generators. The generators shall be operative fully-undisrupted, by re-fueling through all the period they are used,
3 Basic Availability of more than {2} external power-supply routes / methods, and redundancy of electricity ensured in the facility by duplexing, etc.
99
4 Basic Employment of air-conditioning systems with redundancy ensured by duplexing, etc. Such systems shall be continuously operable for more than {24} hours in a situation where water supply is lost due to natural disasters.
5 Basic Capability of providing the power supply systems (functions) specified in the procurement specifications of racks or equipment separately purchased.
6 Basic Capability of providing the air-conditioning systems (functions) specified in the procurement specification of racks or equipment separately purchased.
5.3.5. Security Requirement A security requirement here refers to a physical security requirement.
Functional Requirement 1 Basic Authentication-for-security mechanisms for the entry to the building and for
entry to the machine room are independent to each other; and in addition, security measures at the entrances, by such means as the stationing security guards.
2 Basic Automatic security systems [such as intrusion detectors, surveillance cameras, or entry / exit management systems, etc.]
3 Basic Management of entry / exit operating on a 24 hour / 7 day basis. 4 Basic Employment of Identification systems, such as IC card systems or
biometric identification systems for managing entry / exit to / from the rooms inside the iDC, and monitoring cameras in shared spaces or server rooms.
Non-functional Requirement (write only when individually specified) Assessment / Certification of Security
Basic Certification of compliance with “Information Security Management System (ISMS) Compliance Evaluation System (JIS Q 27001, ISO / IEC27001),” and a permission as a business operator to use the privacy mark.
5.3.6. Operational Requirement An operational requirement refers to a requirement for maintaining / managing the iDC facility
Functional Requirement 1 Basic Development of a management unit on a 24 hour / 7 day basis of iDC
facilities and a contact office for problem management, etc. 2 Basic Execution of inspections of the iDC facilities based on time table, etc.
5.3.7. Compatibility with Virtualized Systems Functional Requirement 1 Basic Capability of implementing the software products used in the
physical-server environment in the environment realized by virtualization mechanisms, etc., which consist of virtualized guest-servers and virtualized networks, so that such software products work in the same way as they do in the physical environment.
100
5.4. SOA Related Functions
5.4.1. Definitions 5.4.1.1. SOA(Service Oriented Architecture)
SOA is an architecture that enables “services” — software functions corresponding to the individual
job-operations — to be accessible and linked to each other on a network by the standardized
protocols and work as an integrated system. At present, such architectures are generally compliant
with the Web service technical specifications. The architecture also ensures prompt system
constructions and high maintainability, by defining interfaces between services and linking them on
the network.
Enterprise Service Bus
Business Process Management
Mashup Portal
Adapters
Management Development Environment
Service Repository /
Registry
Business Activity Management
Service Intermediation, Security / Policy Management
Messaging, Connection, Information Delivery
Application Monitoring, Management of SLA and KPI
Organizing Business Processes Compatible with Standards, Workflow Management
Providing Connections to Web Services, Legacy Systems, Data Bases, ERPs, banckback-end Systems, Custom-Application & Service, or JCA
Providing IDE or Application-Development Framework
Providing MashupService as the Front-Gateway
Web Services Protocol
Infrastructure Security, High-Reliability Message, Transaction
Centralized Management of Information on SOA Services
ERP / Legacy Application Custom Application / ServiceWeb Service Business Intelligence
Figure 5.4-1 Major Components in SOA
Functions and Services of SOA Function / Service Definition Business Process Management
Supports the execution of business processes through defining combination and flow control for different services.
Enterprise Service Bus Realizes the integration of services by enhancing the independency of services from others and assuring the message reliability by means of encapsulation of interfaces between the applications distributed.
Management Intermediates services and manages security and policies.
101
Mashup Portal Works as a front gate way and provides the mash-up services. Business Activity Monitoring
Monitors job-operations and processes, associates SLA or KPI (Key Performance Indicators) with the actual business processes, and visualizes them.
Development Environment
Provides IDE for the development of SOA services and a framework for the development of applications.
Service Repository / Registry
Enables the life-cycle management of services through registering, publicizing, and searching the information on SOA services, and at the same time enables job-applications to call services dynamically.
Adapters Provide connections to web services, legacy systems, databases, ERPs, back-end systems, custom applications, and services.
Web Services Protocols Enable integration of applications existing on the different platforms using the internet technical standards. For details, refer to “Function / services of web service protocols.”
Note that the following are additional descriptions on some of the functions or services in the table
above:
An Enterprise Service Bus provides messaging or data-conversion functions for the realization of the
integration of applications;
Business Process Management, which manages individual services, realizes job-applications by
combining services and controlling their execution by use of adapters (through web service
protocols);
Business Activity Monitoring collects the performance data and alert information from the Business
Process Management, and displays it as job-process information in a visualized form;
Mashup Portal Service receives information-contents or data from the Business Process
Management, and provides the users of the system with the contents or data in a mashed-up form;
Service Repository / Registry will support the environment for easy mash-up development through
providing the SOA information.
System administrators and developers on the provider side also benefit from the SOA functions for
management in the collection of service-log information or statistical monitoring information. In
addition, from the development, they benefit from the development environment because it provides
an integrated environment for the development of applications with resistance to changes because of
the separation of services and interfaces.
102
Figure 5.4-2: SOA Components and Their Relations
5.4.1.2. Web Service Protocol Web Service Protocol collectively refers to technologies for linking applications distributed on
networks: it is a mechanism enabling collaboration with applications on a different network, or a
mechanism enabling the creation of new applications or services by linking web-services realized on
the basis of web service protocol.
Figure 5.4-3: Fundamental Component of Web Service Technology
103
Functions / Services of Web Service Protocol Function / Service Definition Base Technology Publicizes descriptions of services — what functions the
web-service has, or what requests are required for using them. In addition, it authenticates a service published for use to exchange messages.
Security Service Component
A Service component, selective and usable with others: it enables a web service to enhance its function to realize the integrity and confidentiality of a message.
High-Reliable Messaging Service Component
Service components, selective and usable with others: They enable a web service to enhance its function to improve message-reliability in the communications with applications distributed on networks.
Transaction Service Component
Service component, selective and usable with others: it enables a web service to enhance its function to realize transactions to applications distributed on networks.
5.4.1.3. Common Technology Standard It refers to a standardized technology, commonly used as the basis of SOA or web service protocol:
it ensures the realization of highly-interoperable functions or services.
Function / Service of Common Technology Standard Function / Service Definition Common Technology Standard
Technology standard used as a basis of SOA or Web service protocol
5.4.2. Business Process Management Functional Requirement 1 Basic Provision of data-manipulation functions for defining data or control-flows for
business process 2 Basic Capability of defining processes by combining and using functions such as
service-calls, data-manipulation, malfunction notification, exceptional processing, or process-termination
3 Basic Capability of executing management jobs according to the standards for communicating with services (Web service protocol, etc.) or implementation-rules.
Non-functional Requirement (write only when individually required) Backup Additional Saving backup of business process configuration information
5.4.3. Enterprise Service Bus Functional Requirement 1 Basic Provision of a common back-bone with a configuration independent from particular
network-transport technologies for linking different systems 2 Basic Capability of transforming data or communications based on one protocol to that
based on a different protocol
104
3 Basic Capability of converting data in one format to that of other format 4 Basic Capability of routing messages according to their contents 5 Basic Capability of sending messages without loss between remotely-distributed
applications in a situation when malfunctions in applications or the network occurs, in order to enable roll-back transactions to notify errors, or re-sending transactions after the problems have been resolved
6 Basic Capability of being used independently from, or without disturbing, the processes of other components using the bus
Non-functional Requirement (write only when individually required) Backup Additional Saving for backing-up the setting information of service linkage
Related Technology XML Query Language
X Query: Query language of XML data
XML Transformation Language
XSLT: language for specifying transformation scheme of XML data
5.4.4. Management Functional Requirement 1 Basic Capability of defining policies for controlling service-operations (access-policies,
logging-policies, or contents-verification, etc.), or monitoring schemes for access or execution of services
2 Basic Capability of applying policies without modifying existing services 3 Basic Capability of centrally managing and visualizing statistics of monitored information
Non-functional Requirement (write only when individually required) Backup Additional Saving backup of policy-settings and statistical monitoring information
105
5.4.5. Mashup Portal Functional Requirement 1 Basic Provision of functions for combining more than one service interface into one portal
application 2 Basic Capability of modifying UI without needing to modify the business logics of existing
applications
Non-functional Requirement (write only when individually required) Backup Additional Saving backups of settings related to the configuration of portal
applications
5.4.6. Business Activity Monitoring Functional Requirement 1 Basic Provision of functions for monitoring job-operations or processes and visualizing
them 2 Basic Provision of functions for analyzing the actual business processes in comparison
with an SLA or KPI, and visualizing them 3 Basic Provision of functions for monitoring job-operations and processes and raising alerts
Non-functional Requirement (write only when individually required) Backup Additional Saving backup of information obtained through business process
monitoring
5.4.7. Development Environment Functional requirement 1 Basic Provision of the Integrated Development Environment (IDE) for developing SOA
services 2 Basic Provision of an application development framework for developing SOA services 3 Basic Capability of supporting the entire life-cycle of SOA service development (modeling,
program-development, debugging, testing, profiling, tuning, deployment). In addition, to be executable from the IDE
Non-functional Requirement (write only when individually required) Backup Additional Saving backup of source-codes and configuration settings used in the
SOA service development
Related Technology Design Notation UML (Unified Modeling Language): an unified notation for program-design
used in the software development phase, developed by OMG and based on the object oriented method
106
5.4.8. Service Repository / Registry Functional Requirement 1 Basic Provision of a mechanism for registering, publishing, and searching of information on
SOA services, based on the standards 2 Basic Capability of imposing access-permission of search, acquisition, modification, or
deletion on any component 3 Basic Provision of management-interfaces for registering, publishing, or searching
published SOA services
Non-functional Requirement (write only when individually required) Backup Additional Saving backup of settings on service repository / registry 5.4.9. Adapter Functional Requirement 1 Basic Connections to [web services, legacy systems, databases, ERPs. Back-end
systems, or custom application systems] 2 Basic Capability of allowing synchronous-calls of application- transactions, work-flows,
query-application data 3 Basic Capability of allowing transmission or receipt of events to or from
central-job-application
Non-functional Requirement (write only when individually required) Backup Additional Saving backup of connection settings
Related Technology Web Service Description Language
WSDL (Web Service Description Language): a specification of description of web-service interfaces in XML language
Industry Standard
Industry standards used in business fields, such as XBRL (eXtensible Business Reporting Language: XML vocabulary for financial data description, UN / CEFACT CCL (Core Component Library): coded information-items used in various industry segments), or the government standard
5.4.10. Web Service Protocol 5.4.10.1. Web Service Protocol (Base Technology) Functional Requirement 1 Basic Use of internet-standard communication protocols (TCP / IP or HTTP) 2 Basic Provision of a mechanism for realizing message-exchange or procedure-call based
on XML 3 Basic Provision of an environment for developing and deploying web services 4 Basic Provision of a mechanism for realizing data-transmission or receipt to or from web
services
107
5 Basic Capability of defining what function a service has or what request is required for using the service
Non-functional Requirement (write only when individually required) Performance Additional Configuration with a sufficient processing power for avoiding an
unallowable delay of the processing of the existing programs, while a web service protocols are being processed
Backup Additional Saving backup of settings of web service interfaces
Related Technology Web Service Communication Protocol
SOAP (Simple Object Access Protocol): XML-based protocol for calling data or services existing on other computers
Web Service Description Language
WSDL (Web Service Description Language): specifications for describing web-service interfaces in XML format
Web Service Interoperability Profile
WS-I Basic Profile: a guideline for the enhancement of the interoperability of SOAP-message-exchange or WSDL descriptions. The V1.1 agreed in WS-I is the present ISO standard as follows ISO / IEC 29361::2008 — WS-I Basic Profile Ver. 1.1 ISO / IEC 29362::2008 — WS-I Attachments Profile Ver. 1.0 ISO / IEC 29363::2008 — WS-I Simple SOAP Binding Profile Ver. 1.0
5.4.10.2. Web Service Protocol (Security Service Related Component Functional Requirement 1 Basic Provision of a mechanism to assure the integrity and confidentiality of message
content 2 Basic Ensuring of the availability of [the attachment of a digital signature, the attachment of
user-authentication data (token), or the encryption of messages]. In addition, the capability of protecting the security of them.
3 Basic Configuration allowing any standard signature or encryption algorithm 4 Basic No requirements of modifications on the processes of components related to other
web-service protocols
Non-functional Requirement (write only when individually required) Performance Additional Configuration with sufficient processing power to prevent running
programs from disturbance during signature processing or encryption processing.
Backup Additional Saving backup of settings for message integrity and confidentiality of a message
Related Technology Web Service Security
WS-Security: technology base for realizing the security of web-services, by specifying the method of implementing the existing security technologies such as XML-signature or XML encryption into a header of a SOAP message, and providing a common base for integrating security
108
technologies. Secure Communication Protocol
SSL (Secure Socket Layer): protocol for transmitting or receiving encrypted data on the internet
5.4.10.3. Web Service Protocol (High-Reliability Message Related Service Component) This sub-section stipulates here only the title, because more discussions are expected to be
required before such an item is actually procured.
5.4.10.4. Web Service Protocol (Transaction Related Component) This sub-section stipulates here only the title, because more discussions are expected to be
required before such an item is actually procured.
5.4.11. Common Technical Standard
Related Technology XML Description Language
XML (eXtensible Markup Language): a markup language for describing structured data or documents
XML Schema Language
W3C XML Schema: a schema language for defining structures or data-types of XML documents
109
5.5. Maintenance Environment
5.5.1. Definition Maintenance Environment refers to a physical work-environment for maintenance or management
of systems: it is, after systems’ cut-over, used for functional enhancement of application programs, or
verifications of version-ups, required on the expiration of the support contract, of software, such as an
OS, commercial software packages, or open-source software, etc. More specifically, it contains
maintenance process manuals for methods and maintenance procedures of systems including the
(actual) operation-environment, hardware / software used in maintenance work, maintenance tools
(development tools), and automatic test tools.
The maintenance environment is completely independent of the “development environments”
installed in vendor sites and used for software development: it consists of the following; the Software
Engineering Environment used for support works such as software maintenance, modification, or
correction, etc.; and the Software Testing Environment used for software tests.
PCs for Development-work in Maintenance
Development Tool (Maintenance Tool)
Test Tool (for unit-test or functional test)
Version Management (Configuration Management Tool)
Conf iguration Management Server
Staging Environment
Test Tool (for Vulnerability Test)
Test Tool (for Stress Test)
Test Environment (for Acceptance Test)
Build Tool
Development LAN
Job-Operation (actual) Servers
PCs for LAN System Operator
Job-Operation (actual) LAN
Inter network (Bridge) LAN
Maintenance Environment
Software Engineering Environment Software Test Environment
Test LAN
Firewall (or Router)
Firewall (or Router)
Figure 5.5-1 Schematic Diagram of Maintenance Environment
110
The following table describes the definition of functions or services in the maintenance environment.
Function / Service Definition Maintenance Process Refers to methods and procedures for correcting or modifying
system configuration items (CI) such as hardware or software, etc. Audit Process Refers to methods and procedures for confirming that the
information security rules have been applied compatibly and properly.
Development Tool Refers to methodologies, processes, and tools for design / development / maintenance, or an aggregation of tools (Integrated Development Environment: IDE)
Configuration / Version Management Tool
Refers to a tool for managing versions of application programs or documents — design documents or procedure manuals — expected to be updated frequently: it is used for, controlling and recording modifications on hardware, software, or firmware throughout systems’ lifetimes., By collectively managing the information of configuration items (CI) used in development or operational environments, it provides configuration information for maintaining the integrity of the system.
Development LAN Refers to an internal LAN used by the software engineering environment: for the security reasons, it is physically and logically separated from the job-operation (actual) environment.
Test LAN Refers to an internal LAN used by the software test environment: for the security reasons, it is physically and logically separated from the job-operation (actual) environment
Inter network (Bridge) LAN
Refers to an internal LAN used for connecting the development LAN and the job-operation (actual) LAN: in some cases where those LANs are separated logically, the inter network (Bridge LAN) is replaceable with equipment such as switches or routers, etc.
Test Environment (for Acceptance Test)
Refers to an environment for verification work such as builds, connection tests, system tests, or regression tests of the application programs after completion of a unit test by the vendors
Test Tool Refers to a test tool used in the maintenance environment, for the purpose of preventing system deterioration or performance-degradation accompanying system modifications, to ensure efficient execution of regression tests or performance tests
Staging Environment Refers to a test environment of a similar scale of system configuration (both hardware and software) to that of the job-operation (actual) environment: it is used for checking security-patches or bug-fix patches before the application to the job-operation environment for confirming that the application of those patches causes no troubles. In some cases, it is constructed on visualized servers and storages.
111
5.5.2. Functional / Non-functional Requirements for Maintenance Processes The Maintenance Process defines the actions, methods, and procedures required in a case of
hardware or software malfunctions or functional modifications, in job-operation (actual) environments
or development environments.
Functional Requirement 1 Basic Complete definition of methods or procedures of works to be done in the phase
starting at the completion of development and the beginning of system operations, and ending at the termination of operations and abolishment of system
2 Basic Clear definition of rules such as a rule of request for modification or a rule of approval of modification
3 Basic Definition of maintenance process for each of the job-operation (actual) environment and the maintenance environment
Non-functional Requirement (write only when individually required) Integrity Basic Definition of the maintenance process consistent with the
system-lifecycle and the requirements defined in procurement plans, procurement specifications, and basic system design documents.
Related Technologies IT Service Management
Refers to a mechanism for executing the management and operations of IT services matching the level of customer-requirements, and continuously improving the service quality. ISO / IEC 20000, JIS Q 20000, ITIL v. 3
Software Maintenance
Refers to a series of modification-work of codes and documents of software for resolving malfunctions, or satisfying requests for improvement or requests for compatibility to new environments. ISO / IEC 14764, JIS X 0161
Software Lifecycle Process (SLCP)
Refers to a framework on which the parties involved in software development define the details of various works to prevent mutual misunderstanding among them. ISO / IEC 12207, JIS X 0160, Common Frame 2007
Information Security Management
Refers to a management method of establishing, implementing, operating, monitoring, reviewing, and improving / maintaining information security in accordance with polices for avoiding business risks. ISO / IEC 27002, JIS Q 27002
Software Engineering
Refers to activities for improving software or its development / maintenance work, through using theories, methods, and software development or maintenance expertise. SWEBOK2004 (ISO / IEC TR 19759)
112
5.5.3. Functional / Non-functional Requirements for Development Tools Development Tools consist mainly of an IDE used for upgrading or functionally enhancing software,
and test tools for automatically testing application-programs under development.
Functional Requirement 1 Additional Capability of debugging programs source codes 2 Additional Capability of assisting source-code-refactoring in a case where
object-oriented languages are used 3 Additional Capability of, in coordination with test tools, automatically executing tests
and automatically generating templates of test-programs suitable for test targets in a case where object oriented languages are used
4 Additional Capability of automating code-generation processes in coordination with build-tools
5 Additional Capability of assisting team-development through the coordination with the configuration management / version management tools
6 Additional Availability of stand-alone development terminals in a local environment or alternatively, a team environment which allows access to the resources of the development environment through network connections
7 Additional Capability of coordinating with configuration / version management tools 8 Basic Capability of compiling source-codes to binary codes, and packaging the
compiled codes 9 Additional Capability of automating build-work or preparing scripts for build-work, for
the purpose of improving quality and productivity
Non-functional Requirement (write only when individually required) Compatibility Basic Version-level-compatibility with the languages such as [C#, Java,
C++, etc.], and the development frameworks such as [OSS such as Struts, Turbine, Spring, Hibernate, Seasar2, etc., or compatible commercial products], used in the development phase
Related Technologies Development Language
C# JIS X 3015 2006, ISO / IEC 232702006 JAVA TRX X 0005-1: 2006 COBOL85 JIS X 3002. 1992, ISO / IEC 1899: 1985 COBOL2002 ISO / IEC 1989: 2002 FORTRAN77 JIS X 3001:1982, ISO / IEC 1539: 1980 FORTRAN90 JIS X 3001. 1994, ISO / IEC 1539: 1997 FORTRAN95 JIS X 3001-1: 1998, ISO / IEC 1539: 1997 C++ JIS X 3014: 2003, ISO / IEC 14882: 2003 C JIS x 30102003, ISO / IEC 9899: 1999
Development Framework
Apache Struts (1.2.x, 1.3.x.), Apache Struts2 (2.0.x.): Application framework designed based on MVC design Jakarta Turbine: Application framework based on servlet. Version 2.3.x. and its derivatives are mainly used. Spring 2.5.x: Application framework composed by small components framework Hibernate 3.3.x: Object-Relation Mapping framework
113
5.5.4. Functional / Non-functional Requirements for Configuration / Version Management Tools
The Configuration / Version Management tool manages modifications on the following in the entire
system life-cycle, from development to abolishment, through the collective management: all
information of the configuration items (CI) used in the system; hardware configurations; and versions
of application-source / execution files.
Functional Requirement 1 Additional Capability of recording all information on modifications on the configuration
items (CI) used in the system — including why, what, and by whom the modifications were executed, through the coordination with back-tracking tools
2 Basic Capability of centrally managing versions of the entire system 3 Basic Capability of simultaneously allowing more than one vendor to implement the
modifications, and merging differences in any revisions resulted from such parallel development
4 Basic Authentication function for prohibiting non-authorized users from system access 5 Additional Capability of permitting checking-in or checking-out, in coordination with the
integrated development environment (IDE) included in the maintenance tool 6 Additional Capability of finding what and how, according to which
specification-modification, files have been modified by collectively managing all the revision information preserved in the configuration management repository
Non-functional Requirement (write only when individually required) Availability Additional Employment of a hardware configuration with enhanced availability
by means of redundant hard-disk drives Security Basic Employment of a configuration protective against security risks such
as illegal access, information leakage, or falsification of settings, etc.
Performance Additional Configuration ensuring sufficient processing power satisfying the performance-requirements derived from predictions of processing-peaks or maximum number of users, etc.
Expandability Basic Configuration allowing flexible performance enhancement for catching up with the expansion of target systems or the contents
Back up Basic Capability of backing-up all the preserved data and the entire environment
Related Technology Software Configuration Management Process
Refers to activities of keeping records of changes in software configurations or configuration items throughout the software lifecycle, for the purpose of re-creating any of the situations in the past as required. ISO/IEC TR 15846
・The chapters or sections shown below of the Operation Manual describe what mentioned is above: 3.(2){3}a Management of Source-Code Modification History, etc. (pp.49), Chapter 3 Procedures of Separated Procurement; 4(3) Source Code Related Matters (pp. 66), Chapter 4: Management of Project on Separated Procurement
114
5.5.5. Functional / Non-functional Requirements for Test Environments (Acceptance Test Environment)
Test Environment (Acceptance Test Environment) refers to an environment for executing builds,
integration tests, and system tests for applications produced on the development environments of
contracted venders.
Functional Requirement 1 Basic Capability of executing builds of program sources generated on development
environments 2 Basic Capability of executing integration tests, system tests, and software validation tests 3 Basic Capability of creating and maintaining more than one environment in a physical test
environment (Acceptance Test Environment) by means of creating more than one AP server, or utilization of virtual environments, etc.
4 Basic Authentication function for prohibiting un-authorized users from access
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
115
5.5.6. Functional / Non-functional Requirements for Test Tool The Test Tool refers to a system for testing: it consists of tools for automatically executing
procedures for individual test cases, and management tools for preserving test-results in databases.
Functional Requirement 1 Additional Capability of automating tests by means of automatic execution of test scripts
(test cases) or test tools 2 Additional Capability of managing test-results in conjunction with test-cases through
coordinating with configuration management tools 3 Additional Capability of managing, in an integrated way, information on testing such as
requirements (specifications), test-cases, test-scripts, or test-results, etc. 4 Additional Capability of automatically collecting, summarizing, and analyzing test-result
data generated by automatic-test tools 5 Additional Capability of allowing the Integrated Development Environment (IDE) to
integrate and use the test-tools for unit-tests or function tests 6 Additional Employment of stress-test tools with a capability of generating large amounts
of transactions by multiple servers, and functions for collecting test-results generated by the servers-on-test onto test-control terminals, so that functions for distributing loads, such as load balancing, are testable
7 Additional Capability of executing regression tests
Non-functional Requirement (write only when individually required) Availability Additional Employment of a hardware configuration with enhanced
availability by means of redundant hard-disk drives, etc. Security Additional Employment of a configuration protective against security risks
such as illegal access, information leakage, or falsification of settings, etc.
Performance Additional Configuration ensuring sufficient processing power satisfying the performance-requirements derived from predictions of processing-peaks or maximum number of users, etc., in addition, a hardware-software configuration with performance and functions equivalent to those of the operation-environment in the case of performance tests.
Expandability Additional Configuration with flexible expandability for keeping up with the addition of test-tools or updates
Back up Additional Capability of backing-up test environments and test data
116
5.5.7. Functional / Non-functional Requirements for Staging Environment The Staging Environment refers to an environment used for checking whether software
modifications will cause troubles or not, such as the application of patches on OSs or software, etc.
for the enhancement of security levels. Note that the Government Standards recommends that the
verification of those patches should be executed on the environments such as a Staging Environment
for evaluation in advance of their application to the job-operation environment.
Functional Requirement 1 Additional Employment of hardware and software configuration equivalent to that of the
operation (actual) environment with the equivalent functions and performance 2 Additional Capability of constructing staging environments on the basis of virtual servers
and storages realized by virtualization software products, in a case where the equivalent hardware devices to those used in the operation(actual) environment are not available. In the staging environment realized in the virtual environment, the equivalent software products equivalent to those used in the operating environment shall be installed and perform the equivalent functions to those in the operating environment.
3 Additional Availability for users’ education / training of procedures inexecutable in the operation (actual) environment including updating processes
4 Additional Capability of executing performance-tests or stress-tests, etc. with same level of data or load as that of the operation (actual) environment in cases of constructing the staging environment without using virtual environments
5 Basic Implementation on a different physical environment or on a virtual environment existing on a different physical environment from the operation (actual) environment, so that evaluations of patches required in advance of the application to the operation (actual) environment, or tests by re-creations of malfunctions on the operation environment are executable.
6 Basic Authentication function for prohibiting un-authorized users from access
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.
117
5.5.8. Functional / Non-functional Requirements for Development LAN, Test LAN, Inter network LAN (Bridge LAN)
The Development LAN and Test LAN are internal networks closed off in a building and dedicated to
the maintenance environment. An Inter Network LAN (Bridge LAN) is a network to connect a
Development LAN and Test LAN to the operation (actual) LAN. The government standards requires
the clear separation of the maintenance environments from the operation environment.
Functional Requirement 1 Basic Separation of Development LAN / Test LAN from the operation (actual)
LAN by physical configurations or by VLAN, etc. 2 Additional Implementation of communication equipment such as switches or
routers, at the connection points of the Development LAN or Test LAN to the operation (actual) LAN, for the purpose of blocking communications except for those between permitted terminals or servers.
3 Additional Dedication of the Development LAN, Test LAN, or Inter network LAN (Bridge LAN) for internal use without connections to external networks such as the internet.
Non-functional Requirement (write only when individually required) Availability Additional Capability of redundantly installing network-equipment
according to situations Security Basic Capability of controlling communications between the
maintenance environment and the operation (actual) environment by means of filtering functions of routers or switches, etc.
Performance Additional Configuration ensuring sufficient processing power as a test environment for the maintenance environment, by clearly defining the performance requirements in advance
Expandability Basic Configuration that allows flexible enhancement of processing power for keeping up with functional enhancement or version-up of the maintenance environment
Related Technology Refer to “Related Technology” in 5.15. WAN, Ministry’s internal LAN. DNS / DHCP / Proxy.
118
5.5.9. Audit Process Audit Process refers to a process for verifying / evaluating how properly the risk control is prepared
/ executed in accordance with the risk assessment. Auditing activities include internal audits by the
internal-auditing department, and third-party audits by external organizations.
Functional Requirement 1 Additional To periodically execute internal audits and external audits (third-party
audits) on the operation environment, the development environment, and the test environment according to the “System-Audit Standards” prepared by the Ministry of Economy, Trade and Industry
2 Additional To confirm that proper actions have been taken according to the advice and recommendations by auditors.
3 Additional To be compatible with the “System Audit Standards” (revised on October 8, 2004), “Information Security Management Standards” (formulated on March 26, 2003), and the operational guidelines, prepared by the Ministry of Economy, Trade and Industry.
4 Basic To prepare medium-to-long term plans for system audits in order to effectively and efficiently check and evaluate information strategies and information systems for the fulfillment of business objectives. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government.
5 Basic To prepare basic plans for system audits annually according to the medium-to-long term plan. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government.
6 Basic To prepare individual plans for system auditing according to the medium-to-long term plan and the basic plan. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government.
7 Additional To, give a contract to experts outside the government for a part of the audit in accordance with the situation.
8 Basic To audit according to the individual audit plan 9 Basic To confirm that the design / development / operation / maintenance of the
target-system of the audit has been executed properly from the standpoint of reliability, safety, and efficiency
Non-functional Requirement (write only when individually required) Independency Basic The auditor shall not have strong position of interest with the
audited entity. Expertise Basic The auditor shall have the proper education and experience for
auditing, and have the knowledge and expertise for auditing. Authority / Responsibility
Basic The authority and responsibility of the auditor shall be clearly defined in documented rules or contract agreements.
119
Related Technology IT Internal Control Framework
IT Internal Control Framework refers to an IT-based mechanism for managing, monitoring, and assuring evidence that the job-operations are, according to rules and procedures of the organization, executed without illegal activities, irregularities, mistakes, or errors,. ISO/IEC 38500:2008、COBIT(R)4.1
CORBIT (R) is a trademark of the Information System Audit and Control Association: ISACA / IT Governance
Institute: ITGI). Descriptions on the contents of COBIT (R) are protected by the copyright of ITGI (R).
120
5.6. Servers
5.6.1. Definition A Server refers to a computer that provides functions, data, and services on the common platform
system, etc.
Because servers process requests from the terminals connected to the ministry’s internal LAN /
WAN or the individual business systems and return the results of processing, the server hardware
and the network, as well as its configuration, responsible for communications between servers, is
required to have high reliability, availability and maintainability.
Servers work for different roles (Web server, DB server, AP Server, etc.) according to the services
and functions they provide. The proper configuration or placement of such different types of servers is
indispensable: especially for the purpose of stable provision of services or for the preparation for the
future increase in system load, the expansion / enhancement method matching the server type must
be available, such as a scaling-up method (server configuration method enabling performance
increase by enhancing the performance or adding the number of the CPUs, etc. into a chassis) or a
scaling-out method (server configuration method enabling performance enhancement by adding a
server-chassis for parallel processing).
In addition, functions provided by servers are required to be allocated or configured so that a group
of servers providing the individual services can, by the application of virtualization software, be
implemented in a single physical server. Virtualization software, which refers to software that enables
a single hardware server to run more than one virtual machine, enables more than one operating
system to run on single server hardware with minimum loss of performance: the individual operation
system is allocated virtual CPUs, network interfaces, and storages. (Refer to Figure 5.6-2.)
Highly reliable, highly available, and highly maintainable servers, collaborating with storage
mentioned in Section 5.7, are able to realize distributed processing, and are expected to be further
visualized, consolidated, or integrated because of their adaptability to centralized and integrated
management.
Note that this subsection describes the servers installed in server rooms, and the network on the
server firmware access-layer (server LAN). For the descriptions on the core edge access layer such
as the ministry’s internal LAN / WAN, or the network as a whole, refer to the subsection 5.15.
Function / Service of Servers Function / Service Definition Server hardware Refers to server devices to process functions or services available
on the common platform system: it is required to have functions and configurations with high efficiency, reliability, availability, flexibility, and maintainability so that those functions and services work well even in a situation where operating systems, middleware, or applications are added, or changed, or the volume of information to
121
process is increased. Server LAN Refers to LANs or network equipment for communication between
servers on the common platform system Web Server Refers to software responsible for web-based information delivery or
hardware configured for the execution of such information delivery: it provides services for saving the data such as HTML documents or images, or retrieving and arranging, and delivering such data to the client on the request from web-browsers, etc.
DB Server Refers to programs that provide the services of saving and retrieving master-data or transaction data processed by the functions and services available on the common platform system, or the hardware configured for the execution of such services: it has the capability of high-speed processing of queries written in query languages. Note that the information on DB servers should be arranged so that it is available to queries made by the services or functions on the common platform system in such a way that the performance requirements (response time, throughput, capacity) are satisfied.
AP Server Refers to programs that execute and manage business logics contained in the services available on the common platform system, or the hardware configured for the execution of such logics: it works for providing interfaces to web services available on the common platform system, executing business logic, managing transactions, and connecting to databases, etc.
5.6.2. Schematic Diagram The diagram below shows the allocation of functions or services (server hardware, Server LAN,
Web Server, DB Server, and AP Server) in the infrastructure configuration model.
Server Hardware
Server LAN Storage
DB Server Web Server AP ServerTechnology Domain
Legacy Integration
Individual Job-Operation
Workflow BAM
Common Job-Operation
Legacy System
Back (Indiv idual)
Server
ERP Server
Workflow Server
System Linkage
Personnel and Payment System
Document Management
System
Budget Implementation Management
System (SEABIS)
Application Software Region
EAI External Linkage
Channel Region
Remote PC
the Internet Communication Equipment
Load Balancer
Load Balancer
Authentication Server
Public Web Server
Mail Server
Ministry Web
Server
Portal Server
Directory Server
Ministry Mail
ServerWeb-Service-Related Function
SOA-Related Functions(ESB, BPM, UDDI / Service Directory, Service Management)
Job-Operation PC
Process Region
Com
mun
icat
ion
Equi
pmen
t
Development Server
Application-Core Service
Technical Support
Maintenance Environment
Application Platform Region
Information (Data) Region
DB Server
DWH ServerData
Exchange Server
Server
Legacy System
Common Element Region
Operation Management
Server
Operation Management
Security
Server / Storage (AP Server, Web Server, DB Server, etc)
Figure 5.6-1: Allocation of "Server" Services or Functions in the Infrastructure Configuration Model
122
Figure 5.6-2: Virtualization of Server Environment by Virtualization Software
5.6.3. Server Hardware Functional Requirement 1 Basic Capability of allowing the following to run;
an execution-basement for application programs operating on servers; and operating systems able to provide interfaces between the application programs and the execution-basement [Linux, Windows, and Commercial Unix, etc.]
2 Basic Capability of booting the operating system [Linux, Windows, and Commercial Unix, etc.] from the embedded disk-drive or an external disk-drive
3 Basic Network-equipment interfaces [Ethernet (IEEE 802.3) and RS-232C, etc.], and, in a case where connections to peripherals are required, [Serial ATA, PCI, SCSI2, SCSI3,iSCSI, SAS, Infiniband, FibreChannel, etc.
4 Additional Capability of collecting information for problem-management (including protection or detection) and providing information for that purpose, and the features of [e-mail delivery of failure point information, or failure-notification by SNMP trap, etc.]
5 Additional Capability of monitoring configuration or status-information of the server through interfaces compatible with the standard specification [SNMP or CIM, etc.]
6 Basic Operating system having a capability of providing the application programs with services and functions through APIs (Application Program Interfaces): the API shall be compatible with standardized and widely accepted specifications.
7 Basic Operating system is to be compatible with standardized and widely accepted specifications or equipped with command-utility functions based on CUI (Character-based User Interface), which is widely accepted
8 Basic A program (devise-drive program) that is able to control all the devices and executable on the operating system shall be available.
123
Non-functional Requirement (write only when individually required) Install Space (Chassis)
Basic The following shall be included in the server chassis, when it is referred to: processors (CPUs), memory, main boards, internal disk-drives (not required in case of servers where no internal disk-drives are necessary), peripheral interfaces, and power supplies, etc. • A server chassis shall have a configuration of [rack-mount, blade, tor tower, etc.] • In the case of a rack-mount configuration, each server shall be installable in a 19-inch server-rack {4U} compatible with EIA (Electronic Industry Alliance) standards. • In the case of a blade configuration, up-to six blades shall be installable in a 19-inch server rack {7U} compatible with EIA standards. • In other configurations than those mentioned above, the foot-print is {190 cm W x 200 cm D x 220 cm H} and the maximum weight per unit area shall be less than {100 kg / m2}. The load capacity of an ordinary office is around 100 kg /m2. However, because the load capacity over 1,000 kg / m2 is not extraordinary for data centers, server-equipment with the weight per unit of over 1,000 kg / m2 will be purchased under the condition that it is installed in a data center. Therefore, on the application of the specifications here, especially the exemplifications in {}, pay sufficient attention, and modify the value in {}, according to the facilities where the servers will be installed. If the facilities where such equipment will be installed are not determined, use the above-mentioned load capacity of office or of data center as a reference value.
Performance of Processors
Basic Sufficient power for satisfying requirements of job-operations. The processor power shall exceed {64 bit, operating frequency of 2 GHz, and 4 cores}, or satisfy the following: • The performance value in {SPECint 2006 base} shall be {30} or more. • The performance value in {SPECweb 2006 base} value shall be {5,000} or more. • The performance value in {SEPCfp 2006 base} value shall be {30} or more.
Processor Instruction-set Architecture
Basic Executable instruction-set architecture already made public, allowing third parties to develop application. [x86, x64, IA64, POWER, or SPARC, etc.]
Expandability of Processor
Additional Capability of expanding processors by adding processors or upgrading the processing power, in preparation for the expected performance-enhancement requirements of the future. However, in a case where the software running on the server is required by specifications to be expandable in
124
performance by means of scaling-out, the expandability on the side of servers is unnecessary.
Backup Basic Configuration that allows each of the operating systems used in the server to back-up the system or data stored in the internal or external disk drives.
Memory Capacity Basic Sufficient memory capacity to satisfy job-operation requirements or to process data: the volume of the mounted memory shall be {4 GB} or more, or {4 GB} or more of memory per a core processor shall be mountable.
Memory Expandability
Basic Capability of expanding the memory capacity in order to satisfy the processing requirements, to {16GB} or more at maximum, except for the cases where the software running is, according to its specification, capable of expanding its processing capacity by means of scaling-out.
Memory Availability
Basic Capability of, on the occasion of single-bit-errors, not depending on the operating system, automatically correcting the error in data without stopping hardware functioning, to continue processing
Additional Capability of, on the occasion of multi-bit-errors, not depending on the operating system, automatically correcting the error in data without stopping hardware functioning, to continue processing
Expandability of I / F transmission capacity
Additional Capability of expanding the data-transmission capacity by means of combining more than one I / F card, etc. in a situation where the required data-transmission capacity is not attained, except for the case where the software running is specified to have a capability of expansion of processing power by means of scale-outing, the expandability of I / F transmission capacity of the server is unnecessary.
I / F Availability Additional Capability of automatically continuing processing by the other healthy I / O interfaces of the same type when an I / O interface is in trouble due to a failure
I / F Maintainability Additional Capability of allowing the replacement of the troubled interface during system operation, or a capability of, by means of clustering, etc., allowing the replacement of the troubled interface without stopping the services provided by the system
Capacity of Internal / External Disk Drive
Basic Disk area capacity more than {100MB}, where the capacity means “physical capacity.”
Availability of Internal or External Disk Drive
Basic Capability of combining more than one [disk drive, or SSD, etc.] so that it works as a single device, for the purpose of preventing a loss of data a or stop of job-operations
Additional Capability of allowing the replacement of disk drives without stopping the server
Expandability of Disk Area
Basic Capability of expanding the data area up to {200 GB} maximum
Capacity of Power Basic Capability of supplying sufficient power to keep the server
125
Supply running Maintainability of Power Supply
Additional Capability of allowing power supplies to be replaced without stopping the server.
Availability of Power Supply
Additional Duplex configuration of power supplies to keep supplying the necessary power even in a situation where a single power supply is in trouble due to a failure
Availability of Power
Additional • Capability of keeping the server running for {longer than five minutes} by means of using an uninterruptible power-supply systems (UPS, etc.), in cases of problems in the power-lines such as an electricity outage • Capability of automatically putting the system in normal termination, in a situation where the abnormal state continues for longer than {five minutes}
Duplexing of Power Lines
Additional Power-line configuration of two power lines to supply power to the server for operation even in the case of maintenance / construction of the facility
Fault-tolerance Capability of Uninterruptable Power Supply System
Additional Capability of, even on the occasion of UPS malfunctions, continuing power supply by means of by-passing the UPS circuit, or a capability of the equivalent level of backing-up by means of a two power-line configuration, and notifying the system administrator of troubles.
Maintainability of Uninterruptable Power Supply System (UPS) Battery
Additional • Capability of self-diagnosing during running and notifying the administrator of abnormalities • Capability of sending a message to recommend battery replacement to the system administrator in advance before the system fails to continue normal operations • Capability of automatically executing battery checks every period of less than {two weeks} • Capability of raising battery alarms by an SNMP trap
Redundancy of Hardware Module
Additional Configuration to enable a single or a combination of more than one hardware chassis to duplex the major components [CPU, Memory, Hard-disk Drive, Power Supply, and Fan, etc.] for the purpose of continuing job-operations in a situation of failures on a single component. Not that, in the case where such redundancy is ensured by software functions, the requirement is unnecessary.
Procurement Lead-Time
Basic Time required for the addition of servers or implementation of new servers (Procurement Lead-Time) is less than {eight weeks} in normal situations.
Addition of Hardware Components
Additional Capability of executing the addition of hardware components of server — specifically, [processors, memory, physical disk-drives, or peripheral interface-boards, etc.] — without stopping the server, or to have a system configuration allowing the addition of hardware components without stopping services of the system by means of clustering.
Maintainability of OS / Middleware
Additional The following features are for maintenance: • Down time of the system service required for the application
126
of security patches to the system is shorter than {two hours}. • Time to the expiration of maintenance / support is longer than {five} years. • Down time of the system service required for the application of correction patches is less than {two hours}. • In a situation where the service-down-time required for the application of security or correction patches is predicted to exceed {two hours}, the down time of job-operations for longer than {two hours} shall be prevented by the manual operations of allocating the job-operations to an auxiliary server in the system with a redundant server configuration such as clustering, etc.
H / W Maintenance Term
Basic Term of support for the failures of hardware composing the server longer than {five} years.
Green Procurement
Basic Compatibility with the basic polices based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities,” — compatible with the basic policies stipulated in the “Computer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”
International Energy Star (Green IT)
Additional Compatibility with the International Energy Star Program
Related Technology Protocols for Monitoring and Control / Standard Interface Specifications for Server Management
SNMP (Simple Network Management Protocol) CIM (Common Interface Model)
Network Interface, or Peripheral Interface
Serial ATA, PCI, RS-232C, Ethernet (IEEE 802.3), Fiber Channel, SCSI2, SCSI3, iSCSI, FC-AL, FC-SW, and Infiniband
EIA Electronic Industries Alliance “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”
http://www.env.go.jp/policy/hozen/green/g-law/archive/bp/h19bp.pdf
SPEC SPEC (Standard Performance Evaluation Corporation) SPECint, SPECfp
Kernel API Standard POSIX API Standard (ISO / IEC 9945-1) Linux Standard Base
Operating System Command / Utility Standard
POSIX Command Standard (ISO / IEC 9945-2.1993 Information Technology, IEEE Std. 1003.2)
Specifications of Battery Failure Notification / UPS Abnormality Notification
JEMA (Japan Electrical Manufacturers' Association) http://www.jema-net.or.jp/Japanese/standard/ups/
Criteria, etc. for Decisions of Manufacturers, etc. on
Criteria, etc. for Decisions of Manufacturers, etc. on Improvement of Performance of Electronic Computer,
127
Improvement of Performance of Electronic Computer
Announcement No. 194, Ministry of International Trade and Industry, March 31 1999, Final (Complete) Amendment, Announcement No. 50, Ministry of Economy, Trade and Industry, March 29 2006
5.6.4. Server LAN Functional Requirement 1 Basic Capability of communicating based on TCP / IP 2 Basic Capability of packet-switching in the data-link layer / network layer 3 Additional Network equipment with management-interface functions 4 Additional Function of traffic-control for setting or modifying bandwidth-limitation 5 Basic Function of a fire-wall, and to be equipped with communication lines with the
maximum effective-performance of {1 Gbps} or more and the maximum number of packets of {2 Mpps} or more
6 Basic Function of intrusion-detection and protection for the purpose of detecting and blocking an illegal access, with the maximum bandwidth of the connection being {1 Gbps} or wider
7 Basic Function for detecting falsification with a performance — the packet processing performance of the detector — of {2 Mpps} or more
8 Basic Function of virus-detection with a performance — the packet processing performance of the detector of {2 Mpps} or more
9 Basic Capability of configuring load balancers redundantly by means of implementing more than one load balancer; and, in a situation where a load balancer is experiencing problems, letting another pre-determined load balancer take over the sessions held by the troubled server in order to keep the users’ accesses undisturbed.
10 Basic VLAN feature for, creating virtual groups in the data-link layer independent of the physical connections: the group-creation capability of the VLAN feature is {16} or more.
Non-functional Requirement (write only when individually required) Bandwidth Basic Capability of realizing the communication speed of {1 Gbps,
theoretical} or higher Availability of Router / Switch
Additional Redundancy ensured by full-duplex internal-configuration of routers or switches or duplexing devices
Maintainability of Router
Additional Capability of completing the update of routing information or firmware held in a router within {five minutes} or less, or switching the network connection to redundant equipment, so that said up-date will not disturb the job-operations.
Easiness of Maintenance Activity of Router / Switch Operators
Basic Capability of managing routers / switches via the network. In addition, operations required in a problem situation, such as deactivation of ports or re-writing of routing information are executable via a different network reserved for maintenance.
Maximum Down Time
Additional Down-time of the LAN in the common platform system — the monthly longest time-span while the LAN is not available — is {one hour} or less.
128
Average Response Time
Basic Monthly average of node-to-node round-trip delay time (node: communication equipment or server) shorter than {100 ms}. Note that an assumption is available here that the network usage rate is within {30 %}.
Availability of Routing Function
Additional Capability of redundantly configuring paths in the data-link / network layer
Availability (Duplexing LAN)
Additional LANs have redundant configurations.
5.6.5. Web Server Functional Requirement 1 Basic Capability of, in return to a request from client PCs such as web browsers,
delivering the contents preserved on the Web server by HTTP or a compatible protocol; and creating and returning HTML data by executing programs
2 Basic Function of session-management for controlling log-in states or screen-transition
3 Basic Capability of, by means of IP authentication or user authentication, etc., authenticating web sites to give permissions (approval) to the sites; and collaborative authentication or permission with external directory services
4 Additional Capability of logging access-related information: IP address of the origin of access, time and date; accessed file names; destination page of link; name of the web browser used for access, or name of the OS; time consumed for processing; number of bytes received; number of bytes transmitted; and the service status code, etc.
5 Additional Capability of notification of an audit event: notifying, on a real-time basis, the administrator of an event of access-denial or non-authorized access.
6 Additional Capability of preparing audit reports: preparing summaries of log information as a report reviewable and browsable
7 Basic Capability of encrypting WWW-communication data, using protocols such as SSL or TSL, etc. — for the purpose of protection against data-spoofing, data-falsification, or spoofing)
8 Additional Capability of monitoring the services or functions provided by web servers for confirming that they are functioning normally; and, on the detection of performance degradation, notifying the integrated management tool of the problematic events, and saving data for later analysis and identification of the type and cause of problems.
Related Technology Communication Protocols TCP/IP LAN Standard Ethernet Virtual LAN (VLAN) IEEE 802.1Q Monitoring / Control Protocols SNMP(Simple Network Management Protocol) Green Procurement “Basic Policy for the Promotion of Procurement of
Eco-friendly Goods” http://www.jkiss.or.jp/green/siryo2.pdf
129
9 Additional Capability of managing configuration information of servers through PCs placed in remote sites
10 Basic Capability of load-balancing — collectively receiving processing requests bound for servers, managing the requests, allocating the requests to more than one server-group, and transmitting the requests to the allocated servers
11 Basic Capability of selecting the load-balancing method from the round-robin method and the response-time-based load-balancing method; and, in either method, terminating the allocation of processing to the servers that have failed to send-back responses within a predefined response-time
Non-functional Requirement (write only when individually required) Processing Power Basic Sufficient processing-power (number of requests processable per
second) estimated on the basis of the assumed service-request-level and peak value of usage
Server Expandability
Basic Capability of enhancing processing efficiency by means of balancing the load on more than one server for multiplex-processing
Server Expandability
Basic Capability of executing enhancement-work — addition or enhancement of web servers — without interrupting job-operations
Availability Basic Capability of, in the event of a problem on a single server, letting web-server software run on more than one server-hardware in order for the other healthy servers to take over the acceptance of requests coming after the event
Service Hours Basic Capability of providing web-services during the following service hours; {from 8 a.m. to 10 p.m. on weekdays}
5.6.6. DB Server Functional Requirement 1 Basic Composed of systems that manage databases of relational-type
data-representation (relational database management system) or XML database systems with a capability of handling XML data
2 Basic Capability of defining a database, accessing data, and controlling access, by executing programs written in a query language (Data Definition Language: DDL), a data manipulation language (DML), or data control language (DCL)
3 Basic Capability of transaction-processing
Related Technology Mark-up Language HTML Directory Service LDAP Dynamic Web-page Generation
JSP (Java Server Pages) Java Servlet ASP.NET
130
4 Basic Authentication and Permission: Capability of authentication and permission — by an identifier, identifying a user trying to access databases, and permitting the access when the user is authorized or denying otherwise Capability of, according to the user’s job-assignment, restricting user actions on each type of database object (table, view, or column)
5 Basic Capability of encrypting or decrypting data that is managed and maintained in a database; and choosing encryption scheme
6 Basic Audit: Function for auditing databases — logging the execution history of SQLs by users, notifying the management-tools, etc. of unauthorized accesses beyond the range of permission, or preparing a reviewable or browsable report summarizing the information saved in the logs
7 Basic Performance Management: Function for managing performance — monitoring the performance indicators of server components (transaction-processing throughput, and response-time, etc.) to confirm the normal provision of services, and, on the detection of evidence of performance degradation, optimizing processes automatically or manually.
Non-functional Requirement (write only when individually required) Availability Basic Configuration of one or the combination of the following to, in a
case of a malfunction, automatically detect abnormalities, and resume DB accesses in {ten minutes} or shorter:; • Fault tolerant • Hot-standby • Clustering • Mirroring
Processing Power Basic Sufficient processing-power to satisfy the performance requirements for databases (such as throughput or response time)
Data Capacity Basic Sufficient capacity to store the data handled in the common platform system with a volume of {2 TB}.
Expandability of Processing Power
Basic Capability of improving processing efficiency of database access by load balancing on more than one server by multiplexing processes, or by adding computational resources inside the database server
Database Fault-Tolerance
Basic Means for recovering the database-system and the data handled in the data-base system in a problem situation such as the destruction of data
Backup Basic Capability of online back-up Basic Capability of backing-up the difference or entirety of a table or
database Additional Capability of backing-up a whole storage medium (device)
Service Hours Basic Capability of providing database-functions during the following service hours; {from 8 a.m. to 10 p.m. on weekdays}
131
5.6.7. AP Server Functional Requirement 1 Basic Capability of providing web services, based on web-service technologies such as
SOAP or WDSL, etc. 2 Basic Employment of an infrastructure on which component applications made of Java
components or .NET components, etc. are created and executed 3 Basic Function and interfaces for the application programs running on the AP server to
connect to a database on the DB server for accessing data, 4 Basic Distributed Transaction: Capability of distributed transaction-processing —
processing a data-update request involving more than one database or server, as a single transaction
5 Basic Distributed Object: Function for enabling distributed-objects — programs located in remote-servers — to exchange messages with each other
6 Basic Security: To have security functions for protecting the AP server and the applications against the following threats: • Network Spoofing (between a Web server and an AP server, between an AP server and a DB server) • Illegal Access Where the protection functions are not necessarily implemented in the AP server it is possible such network spoofing functions are realized as a function of the entire system by using functions provided by network equipment, etc.; that protection against network spoofing does not necessarily require the encryption of communication if there is no possibility of AP communication packet-flows except for those between a Web server and an AP server or between an AP server and a DB server; and that, if the accesses to APs are limited to those from a Web server by address-restriction, the requirement for protection against illegal accesses is considered to be satisfied.
7 Basic Performance Management: Capability of managing performance with functions for monitoring the performance of DB-server components (transaction-processing throughput, and response-time, etc.) to confirm the normal provision of services; and, automatically or manually, optimizing performances on the detection of signs of performance degradation.
8 Basic Capability of delivering and broadcasting application programs and services to AP servers, and activating those applications and servers into a ready-to-use state
Related Technology DB Query Language SQL92
SQL99 SQL2003 XQuery Xpath
Directory Service LDAP Data Encryption Technology DES
AES RC4
132
9 Basic Capability of authenticating and permitting (approval) process-requests to an AP server; and executing such activities in collaboration with directory services outside the AP server.
Non-functional Requirement (write only when individually required) Processing Power Basic {Average number of transactions processed per second} {30} or
more. Server Multiplexing (Load Balancing) Function
Basic Capability of improving processing efficiency by distributing processes to more than one server
Multiplexing Threads (Mulithread Processing)
Basic Capability of improving the overall efficiency by creating and executing more than one thread in the server
Reliability of Request under System Overload
Basic Capability of, in a situation where the processing requests to the AP server are increasing (Heavy Load), queuing requests in wait on the AP server for preventing the loss of requests
Server Expansion and Dynamic Re-configuration
Basic Configuration that ensures server expansion, and execution of the expansion while the system is running — without interrupting the system
AP Server Availability
Basic Capability of monitoring the services and functions for confirming whether they are functioning normally (Alive Monitoring); and automatically detecting and recovering from malfunctions
Service Hours Basic Capability of providing services of an AP server for the following service hours; {from 8 a.m. to 10 p.m. on weekdays}
Related Technology Web Service Related Technology
Basic SOAP WSDL
Component Program Execution Infrastructure
Basic J2EE .NET
Database Access Technology
Basic OLE DB ODBC JDBC ADO.NET
Distributed Transaction Technology
Basic Java Transaction API (JTA) COM+
Directory Service Technology
Basic LDAP
133
5.6.8. Preparation for Virtualization 1 Basic Capability of installing the software equivalent to that in the physical server
environment, and allowing it to perform the equivalent functions in the virtualized environment composed of virtual guest servers, virtual storages, or virtual networks, realized by virtualization mechanisms
134
5.7. Storage
5.7.1. Definition Storage refers to an external memory device to store the information handled in the common
platform system.
The device assumed as storage in the common platform system is a hard-disk drive or tape drive.
High reliability and high performance is required for storage because it is used for storing data on the
requests from the terminals connected to the ministry’s internal LAN / WAN or the individual business
systems.
Storage must enable distributed processing through having high reliability, availability, and
maintainability in close linkage with the server described in 5.6. At the same time, because storage is
well controlled in an integrated way, further virtualization, consolidation, or integration will be
expected.
Functions and Service of Storage Function / Service Definition Disk Storage Refers to an external memory device for storing mainly the data,
database, and system data handled in the common platform system: here, a hard-disk drive is assumed as storage.
Tape Storage Refers to an external memory device for backing-up/ archiving / migrating / data-exchanging mainly the data, database, and system data handled in the common platform system.
5.7.2. Disk Storage Functional Requirement 1 Basic Capability of activating operating systems [Linux, Windows, or Commercial
UNIX, etc.]. 2 Basic Capability of combining more than one disk drive to make it work as a single
device for the prevention of data-loss or job-operation interruption in the case of a malfunction in a single drive
3 Additional Employment of a means of handling a situation of simultaneous malfunctions on more than one drive
4 Basic Space in an array device to install more than one spare disk 5 Basic Capability of access-controlling through zoning features [Fiber-channel
switches], or settings on the disk-drive 6 Basic Access control function of shared storages — a capability of denying
accesses from the unnecessary servers by using logical unit numbers [LUN] 7 Additional Employment of redundant configuration and sufficient capacity of power
supplies for preventing service-shutdown in a situation of a malfunction on a single power supply
8 Basic Employment of an I /O interface on a storage device, such as [TCP / IP, FC, FCIP, FCoE, SCSI, SAS, Infiniband, etc.]
135
9 Basic Function for assisting adjustment work such as access-performance tuning inside the storage, or optimization or expansion of configuration
10 Additional Capability of realizing malfunction management features for the proper management of storage — through the collection of information for fault detection and protection on the configuration modules (physical disk-drives, tape-drives, power supplies, cooling fans, I / O, control-devices and interfaces, cache memories, or I / O ports, etc.), using the functions owned by the storage, or operation management tools, etc.
11 Basic Function for remote-controlling — preserving configuration information and status of the storage, sending such information to the remotely-located integrated-management system or tools, or receiving requests for configuration changes from the remote sites
12 Additional Employment of, for the purpose of remote data-recovery, functions for saving the coherent data in a remote site to be recovered in the situation of a disaster for resuming job-operations or businesses
Non-functional Requirement (write only when individually required) Availability of Array Device
Basic Capability of accepting data-accesses continuously in a situation of a failure in disk drives through RAID technology, etc.; and automatically recovering data-redundancy.
Maintainability of Array Drive
Additional Capability of adding or replacing disk-drives without interrupting the operation of the storage
Configuration Change of Logical Disk Volume
Additional Capability of enabling the operating systems, which use the storage, to modify the configuration of the logical disk-volume, and add or replace logical disk-volume, without interrupting the system operation
Availability of I / O Interfaces
Additional Interfaces [TCP/IP, FC, FCIP, FCoE, SCSI, iSCSI, SAS, or Infiniband, etc.] of storage should have redundant configurations.
Bandwidth of Storage Data
Basic Employment of maximum data-transmission capacity between server and storage of {100 Mbytes / sec} or more
Expandability of Channel / Host Interface
Additional Capability of expanding data-transmission capacity by binding more than one interface of the same type, for a case where the required data-transmission capacity is unattainable
Transmission Capacity of Channel / Host Interface
Basic Data-transmission capacity of I / O channels or host interfaces {100 m bytes / sec} or more.
Data Capacity Basic Sufficient capacity to store {2 TB} of data handled in the common platform system
Data Volume Allocatable to User
Basic Capability of allocating an area of {1 GB} or more per user at maximum when users request allocation of memory-areas in NAS or file servers, etc.
Modification of Volume of Data Allocation
Basic Capability of enabling operation systems, which use the storage, to dynamically enlarge the allocated memory volume of the server where the operating system is installed
136
Back-up Additional Capability, as a feature of the storage device, of making a copy of a volume, independently of the operating system.
Availability of Power
Additional • Capability of keeping the storage alive {for five minutes or longer} by using uninterruptable power supply systems (UPS), etc., in the case of failures of power lines such as a power outage • Capability of automatically putting the storage in normal termination after {five minutes} or longer have passed since the abnormal event occurred
Multiplexing of Power Line
Additional Configuration of two-power-line-electricity-acceptance for holding power to keep the storage alive even during inspection / construction works
Fault Tolerance of Uninterruptable Power Supply System (UPS)
Additional Capability of continuing the supply of power in the case of UPS failure by bypassing the UPS circuit; or by a configuration of two-power-line-electricity-acceptance enabling the equivalent effect to that of USP-by-passing; and notifying the system administrator of the failure.
Maintainability of Batteries in Uninterruptable Power Supply System
Additional Capability of making a self-diagnosis during operation; and notifying the system administrator of the detected failures. • Capability of sending a message of recommendation about battery replacement in advance before the system falls into a state unable continue the normal operations • Capability of automatically executing battery checks every {two weeks} • Capability of raising battery alarms by an SNMP trap
Procurement Lead Time
Basic Time required for addition of storages or implementation of new storages (procurement lead-time) less than {eight weeks} in normal situations.
HW Redundancy Additional Hardware components composing a storage unit shall have redundant configurations, except for an emergency stop switch, back-boards, or a chassis, etc.
System Performance Value
Basic I / O performance value of the storage operations {larger than 10,000 SOC-1 bench mark} or equivalent.
Expansion of Storage Capacity
Basic Capability of allowing post-installation expansion of storage capacity up-to {5 TB} in total
Term of HW Maintenance
Basic Term of warranty for failures of storage hardware is longer than {five years}.
Green Procurement (Green IT)
Basic Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Disk-Drive” of the “Basic Policies for the Promotion of Procurement of Eco-friendly Goods”).
137
5.7.3. Tape Storage Functional Requirement 1 Additional Employment of a redundant configuration and sufficient power-capacity for
preventing failures of a single power supply from causing service-interruptions
2 Basic Employment of I / O interfaces such as [SANFC、SCSI、or SAS, etc.] 3 Basic Capability of, by using features of the storage device or operation
management tools, etc., enabling malfunction-management functions for the proper management of failures through collecting information necessary for the detection and protection from failures on the configuration modules [tape-drive, power- supply, cooling-fan, control device and interface, cache memory, and I / O port, etc.]
4 Additional Function of automatically detecting or eliminating data-duplications on the occasion of data-saving
Non-functional Requirement (write only when individually required) Data Bandwidth of Tape Storage
Basic Maximum data-transfer volume between server and tape-storage {80 M bytes / sec} or more
Channel Transfer Capacity
Basic Data transfer capacity of I / O channel / host interface {100 M bytes / sec} or more.
Equipment Lead-Time
Basic Time required for the addition of storages or implementation of new storage procurement lead-time) shorter than {eight weeks} in normal situations..
Data-store Capacity
Basic Maximum volume of data storable in the tape-storage {10 TB} or more.
Related Technology Technologies for Reliability Improvement of Disk Drive
RAID, and Grid Storage
Storage Interface Fibre Channel (FC-AL, FC-SW), SCSI, LAN (iSCSI / NAS), SAS, and Infiniband
Monitoring / Control Protocol SNMP (Simple Network Management Protocol) “Basic Policy for the Promotion of Procurement of Eco-friendly Goods
http://www.env.go.jp/policy/hozen/green/g-law/archive/bp/h19bp.pdf
Battery Alarm Specifications / UPS Alarm Specification
JEMA (Japan Electronic Manufacturing Industry) Refer to http://www.jema-net.or.jp/Japanese/standard/ups/
Criteria, etc. for Decisions of Manufactures, etc. on Improvement of Performance of Magnetic Disk-Drive
Criteria, etc. for Decisions of Manufacturers, etc. on Improvement of Performance of Magnetic Disk-Drive, Announcement No. 195, Ministry of International Trade and Industry, March 31 1999, Final (Complete) Amendment, Announcement No. 51, Ministry of Economy, Trade and Industry, March 29 2006
138
5.7.4. Preparation for Virtualization 1 Basic Capability of installing the equivalent software to that used in the physical
environment and allowing it to function equivalently in the virtual environment composed of virtual storages and others realized by virtualization software
Related Technology Storage Interface Fibre Channel (FC-AL, FC-SW), SCSI, LAN (iSCSI / NAS), SAS,
Infiniband Monitoring / Control Protocol SNMP (Simple Network Management Protocol)
139
5.8. Shared PC / Office Printer
5.8.1. Definition
A Shared PC / Office Printer refers to a terminal used by individuals for the purpose of accessing
information systems, or executing office-work such as the preparation of documents. In this section,
the computer software providing the operational environment, etc. and used by the shared PCs is
referred to as the common operation-environment. Shared PCs are categorized into two ways;
personal computer, stand-alone and able to access the common operation-environment; and
thin-client, working as a client of a thin-client-server, able to access the common
operation-environment through the thin-client-server. The items of Shared PC / Office Printer are
defined as follows;
Shared PC / Office Printer Item Definition Personal Computer Refers to a stand-alone terminal able to use the
common-operation environment Thin-Client Refers to a terminal connected to a thin-client server, etc. Office-Printer Device Refers to a computer peripheral that prints information, etc. on
sheets of paper, according to the instructions by information systems
Note that a thin-client server is defined as a server that provides thin-clients with the common
operation environment and accepts their connection requests through network.
5.8.2. Common Functional Requirements for a Shared PC / Office Printer
The following are the common functional requirements for a Shared PC / Office Printer:
Common Functional Requirement for Shared PC / Office Printer 1 Basic Accessibility via the network by terminals that are operative
(Note that the requirement mentioned above should be applied to terminals operative inside the ministry building. The condition “operative” should be eliminated for the terminals that have been carried out on a business trip.)
Common Non-functional Requirement for Shared PC / Office Printer Term of Hardware Maintenance Contract
Basic Term of warranty for hardware components (maintenance term) is longer than {five years}.
140
Related Technology Accessibility JIS X 8341 Series
ISO 9241-20 ISO / IEC 10779
5.8.3. Functional / Non-functional Requirement for a Personal Computer Functional Requirement 1 Basic Capability of using the common operational-environment 5.8.3.1. Desk-top Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU higher than {1.0} GHz.
On-chip cache memory shall have a capacity larger than {4} MB. Capability of execution of more than {two} threads simultaneously.
Basic Employment of internal memory for main memory of a volume larger than {1} GB
Basic Employment of an internal disk-drive of a capacity larger than {80} GB
Expandability Basic Employment of more than {one} LAN port compatible with 1000 BASE-T, 100 BASE-TX, and 10 BASE-T embedded
Basic Employment of more than {three} USB 2.0 ports embedded Basic Keyboard connected through PS2 or USB. Additional Modem functions unavailable to an isolated — stand-alone —
personal computer. Size Basic Body / keyboard, etc. fitting in a space (referred to as “body
size”) of {60} cm wide, {40} cm high, {40} cm deep; and with a weight less than {10} kg.
Display Basic Screen size of {14} inches — {35.56} cm — or more with a resolution of {1024} pixels or more in horizontal direction, and {768} pixels or more in vertical direction. [Conventional-type screen] Aspect ratio — width: height — of 4:3 or 5:4 [Wide-type screen] Aspect ratio of 8:5 or 16:9
Security Additional Capability of attaching a theft-protection lock or wire Additional Feature of BIOS password lock Additional Feature of hard-disk password lock
Green Procurement (Green IT)
Basic Compatibility with the basic polices of the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities,” — compatible with the basic policies stipulated in the “Computer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”
141
Basic Procurement of products compatible with the International Energy Star Program (Ver. 5.0), notified to the government lead office, and registered
Internal Drive Additional Employment of an internal DVD super multi double drive (compatible with DVD-R {8x speed} or faster, DVD-RW {4x speed} or faster, CD-R {24x speed} or faster, or CD-RW {10x speed} or faster, or a capability of attaching such a drive externally
Mouse Additional Employment of a USB connectable two-button optical mouse with scrolling feature and 400-count resolution or finer
Key-Board Basic Bundling with the following features: JIS Standard Key-Arrangement (109 key), or OADG-compatible (109 key) or equivalent; Connectable to the PC through PS2 or USB
5.8.3.2. Note-Book Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU shall be higher than {1.0} GHz.
Cache memory on the chip shall have a capacity larger than {4} MB. Execution of more than {two} threads simultaneously.
Basic Employment of internal memory of a volume larger than {1} GB, used as main memory
Basic Employment of an internal disk-drive of a capacity larger than {80} GB
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 Capacity
Additional Operability for more than {two} hours measured according to JEITA Battery Operation Hour Measurement Method
142
Green Procurement (Green IT)
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 Compatibility with the International Energy Star Program (Ver. 5.0), notified to the government lead office, and registered
Drive Additional Employment of an internal DVD super multi double drive (compatible with DVD-R {8x speed} or faster, DVD-RW {4x speed} or faster, CD-R {24x speed} or faster, or CD-RW {10x speed} or faster, or capability of attaching such a drive externally
Mouse Additional Employment of a USB connectable two-button optical mouse with scrolling feature and 400-count resolution or finer
Key-Board Basic JIS Standard Key-Arrangement (87 key), or OADG-compatible (86 key) or equivalent, embedded in the body of the computer
5.8.3.3. Portable Note-Book Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU higher than {1.0} GHz.
Cache memory on chip with a capacity larger than {4} MB. Capability of executing more than {two} threads simultaneously.
Basic Employment of internal memory of a volume larger than {1} GB, used as main memory
Basic Employment of an internal disk-drive with a capacity larger than {80} GB
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 Capacity
Additional Operability of more than {two} hours measured according to JEITA Battery Operation Hour Measurement Method
143
Green Procurement (Green IT)
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
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 A keyboard having the following features: JIS Standard Key-Arrangement (85 key), or OADG-compatible (85 key) or equivalent
Related Technology Hardware OADG Technical Reference (Hardware) Power Saving International Energy Star Program (Ver. 5.0) Peripheral Connection
USB 2.0
Display Connection
Analog RGB (D-Sub 15 pins), DVI-D, HDMI, Display Port
Wired LAN 1000 BASE-T / 100 BASE-TX / 10BASE-T Wireless LAN IEEE 802. 11 a / b / g / n Bluetooth Bluetooth 2.1+EDR
5.8.4. Functional / Non-functional Requirements for Thin-Client / Thin-Client Server 5.8.4.1. Thin-Client
A Thin-client refers to a terminal that uses functions belonging to the other systems on the network
for a part of its functions executed by its configuration items. In some types of thin-clients, only the
storage function is executed on the network, and in other types, the entire processing excluding
screen-display-processing or user-key-entry processing, is executed by a server on the network.
Functional Requirement 1 Basic Capability of connecting to thin-client servers 2 Basic Capability of using the common operation environment through functions
on the server — in some cases, some of the features of the client might
144
help 3 Basic Employment of no recordable medium — hard-disk drive, etc. —
embedded in the body and available to users
5.8.4.2 Thin-Client Server
Thin-client server refers to a server that provides the common operation environment, and accepts,
via the network, connection requests to the environments from thin-clients. The configurations of a
thin-client server are categorized in a configuration where a single OS instance accepts more than
one session, a configuration where a virtual machine is created for each session, and a blade
configuration where an individual hardware is assigned to an individual session.
Functional Requirement 1 Basic Capability of accepting accesses from personal computers or from
thin-clients
5.8.5. Definition of the Common Operation Environment
The Common operation environment refers to a system composed of software that executes
hardware management, application execution, and file manipulation. The environment is available to
personal computers or thin-clients. The following are functions and services of the common operation
environment.
Common Operation Environment Function / Service Definition OS Through working operations of the system, executes
the fundamental functions, such as the management of resources — CPU or memory, etc. — or the management of accesses to such resources, etc.
Virus Protection To periodically scan memory devices to detect virus infections, continuously monitor inputs / outputs of files or communications on the network, and to take the necessary actions such as virus-cleansing on the detection of virus infections
Web Browser Web browser refers to a program for browsing the WWW.
Personal Fire-wall Quarantine To monitor inbound or outbound communications and give permissions only to the communications from authorized applications
Image Processing To create or modify images Document Creation To create or modify documents Presentation To create or modify slides for presentation Spreadsheet To create or modify tables, or to execute calculations
145
on tables Mail Client To send or receive electronic mails Viewing Video To view video files Web Page Creation To edit HTML and post on a web site Creation of Electric Printed Document
To create an electronic printed document through virtual printers using the application print function
Command-line Environment To execute file-manipulation or configuration-modification using command-lines or batch-processing
Japanese Character Input (Kana-Kanji Conversion)
Conversion of Japanese characters entered by the alphabet-entry-method or kana-entry-method, to kanjis
Reception of Software Function for receiving software or corrections delivered from the software management server
Collection of Inventory Information
To create a list of software, correction programs, signatures of anti-virus software, or user-saved files, etc. installed in the terminal and send it to the server
Encryption To encrypt the system, files, or passwords, etc. Protection against Information Leakage
To restrict copying and delivering information via USB memory devices, etc.
Related Technology Web Browser HTTP, FTP, SSL/TLS, Java Script
HTML 4.1 Document Creation, Presentation, Spreadsheet
ISO/IEC 26300 Open Document Format (ODF) ISO/IEC 29500 Office Open XML Format (OOXML)
Still Image JPEG, GIF, PNG Video MPEG-1, MPEG-2, MPEG-4/H.264, SMPTE VC-1 Printed Document
Adobe Portable Document Format Version 1.7 (PDF) ECMA-388 XML Paper Specification (XPS)
Document Compression
ZIP
5.8.5.1. Functional / Non-functional Requirements for OS OS, through working operations of the system, has the role of executing the fundamental functions,
such as management of resources — CPU or memory, etc. — or management of accesses to such
resources, etc.
Functional Requirement 1 Basic Capability of collecting CPU utilization on a real-time basis 2 Basic Capability of collecting usage rates of physical hard-disk drives 3 Basic Capability of collecting information on input / output performance of
physical hard-disk drives
146
4 Basic Capability of collecting information on free space in physical memory devices
5 Basic Capability of collecting information on free space in virtual memory devices
6 Basic Capability of collecting information on the number of processes in the active state simultaneously
7 Basic Capability of collecting the utilization of CPU and usage rate of virtual memory devices for each process
8 Basic Capability of collecting input / output information on network interface cards
9 Basic Capability of recording and monitoring system events 10 Basic Capability of monitoring the statuses of services (daemon processes)
active on the OS 11 Basic Capability of preserving data for a term sufficient for internal control
audits 12 Basic Capability of allowing usage in multi-user mode (ordinary users and
administrators, etc.) 13 Basic Capability of browsing device information [CPU, memory, physical disks,
logical disks, MAC address, and external devices, etc.] 14 Basic Capability of browsing information on installed software 15 Basic Capability of browsing information about the OS [OS, version, computer
name, and network information such as IP address, etc.]
Non-functional Requirement Back-up Basic Capability of saving collected data into external storage devices
according to the situations in such a way that it can be recovered at any time required
5.8.5.2. Functional / Non-functional Requirements for Virus Protection The Virus protection function periodically scans memory devices to detect viral infections,
continuously monitors inputs / outputs of files or communications on the network, and, on the
detection of viral infections, takes necessary actions such as virus-cleansing. Refer to 5.9.7.1 for the
requirements.
5.8.5.3. Functional / Non-functional Requirements for Web Browser
The Web browser has functions for browsing the WWW. Refer to 5.9.7.2 for the requirements. Functional Requirement 1 Basic Capability of having communications with web servers to obtain
information from the designated URL 2 Basic Capability of displaying the web contents created by using only the
functions compatible with the W3CHTML Standard and the ECMA Script Specifications, and accepting inputs through input forms
3 Basic Capability of displaying images with the data-format of JPEG, GIF, or Adobe Flash
147
4 Basic Capability of controlling automatic data-downloading 5 Basic Capability of controlling pop-up windows 6 Basic Capability of controlling access to the URLs of phishing sites 7 Basic Capability of selecting encoding
5.8.5.4. Functional / Non-functional Requirements for Firewall Quarantine A Firewall has a capability of monitoring inbound and outbound communications to permit only the
communications from the authorized applications to pass.
Functional Requirement 1 Basic Capability of controlling communications to permit or deny access
according to port numbers 2 Basic Compatibility with both of the protocols of IPv4 and IPv6 3 Basic Capability of saving logs
Non-functional Requirement Performance Basic Capability of continuing processing normally on the receipt of a
large amount of packets Availability Basic Not to lose functioning due to piled-up logs
5.8.5.5. Functional Requirements for Image Processing Image Processing has functions for creating or editing images. Images here refers to images built
in a format compatible with one of the standard formats mentioned in the sections relating to standard
formats.
Functional Requirement 1 Basic Capability of reading image files 2 Basic Capability of creating images 3 Basic Function of image-editing such as [cut, copy, paste, edit-color, and
scaling, etc.] 5.8.5.6. Functional Requirements for Document Creation
Document Creation has functions for creating or editing a document.
Functional Requirement 1 Basic Capability of creating a document 2 Basic Capability of editing a document, such as [cut, copy, paste, or
edit-color, etc.] 3 Basic Capability of starting addition from any line in the document without a
sequence of operations for changing lines 4 Basic Capability of creating, reading or editing a document written vertically 5 Additional Capability of reading image files 6 Additional Capability of saving a document in a standard format
5.8.5.7. Functional Requirements for Presentation Presentations have functions for creating or editing slides.
148
Functional Requirement 1 Basic Capability of creating a slide 2 Basic Capability of editing a slide, such as [Cut, copy, paste, or edit-color,
etc.] 3 Basic Capability of executing a slide show 4 Additional Capability of reading image files 5 Additional Capability of reading audio files 6 Additional Capability of reading motion-image files 7 Additional Capability of saving a slide in a standard format 5.8.5.8. Functional Requirements for Spreadsheets
Spreadsheet has functions for creating, calculating, or editing a table.
Functional Requirement 1 Basic Capability of creating a table 2 Basic Capability of calculating a table (including applications of
mathematical operators or basic functions) 3 Basic Capability of editing a table, such as [cut, copy, paste, edit-color, or
insert / delete line, etc.] 4 Basic Capability of creating a graph from data in a table 5 Basic Capability of editing a graph, such as [setting of an axis, etc., or
edit-color, etc.] 6 Additional Capability of reading image files 7 Additional Capability of saving a sheet in a standard format 5.8.5.9. Functional Requirements for Mail Clients
A Mail Client has functions for sending or receiving electronic mail messages
Functional Requirement 1 Basic Capability of having connections through protocols commonly used in
mail servers (SMTP, POP3, and IMAP) 2 Basic Capability of full-text-searching mails using a combination of sender
name, address (destination), title, body, and date 3 Basic Capability of setting of mail-transfer 4 Basic Capability of setting a notice of absence 5 Basic Capability of controlling the automatic downloading of images to be
displayed in the body of an e-mail for the purpose of protecting against web beacons,
6 Basic Capability of encrypting data saves locally 7 Basic Capability of blocking attached-files with a file-extension raising suspicion
of virus infection 8 Basic Capability of encrypting mail body or attachment files and restricting
available functions for the mail (printing, etc.) 9 Basic Capability of applying SMTP authentication 10 Basic Capability of displaying an address book using LDAP 11 Basic Capability of auto-complete function for address, such that a part of
address entered is automatically completed
149
12 Basic Capability of using encrypted mailboxes or address books 13 Basic Capability of accepting and responding to a mail requesting a read
receipt 14 Basic Function for reading an HTML mail in text or rich-text format 15 Basic Capability of displaying an HTML mail without help help of browsers 16 Basic Function for filtering out SPAM mails 17 Basic Capability for allowing a user to easily know whether a mail has an
attachment or not 18 Basic Capability of sorting a mail into folders according to a pre-defined
character string included in the mail-body or title, or sender information, etc.
19 Basic Capability of sorting mails in order of title, date, or sender, etc. 20 Basic Capability of exporting a mail message in a text format or in other
commonly used format 21 Basic Capability of exporting or importing an address-book in CSV format or
another commonly used format such as vCARD 22 Basic Capability of optimizing a mail box
5.8.5.10. Functional Requirement for Viewing Video Viewing Video has a function of viewing video files.
Functional Requirement 1 Basic Capability of viewing video and still images, and playing audio compatible
with MPEG1, MPEG2, and MPEG4
5.8.5.11. Functional Requirements for Web Page Creation Web Page Creation has a function for creating and editing HTML pages, and posting them on web
sites.
Functional Requirement 1 Basic Capability of editing a HTML page 2 Basic Capability of posting a HTML page on a web site 5.8.5.12. Functional Requirements for the Command-Line Environment
The Command-Line Environment has functions for manipulating files or modifying settings through
command lines or batch processes.
Functional Requirement 1 Basic Capability of manipulating files or modifying settings through command
lines 2 Basic Capability of batch-processing
5.8.5.13. Functional Requirements for Japanese Character Entry (Kana-Kanji Conversion) Japanese Character Entry has functions for entering Japanese characters by the alphabet-entry
method or the kana-entry method, and converting them to kanji.
150
Functional Requirement 1 Basic Employment of the basic functions necessary for entering Japanese
words, such as consecutive clause conversion, learning features, and alphabet / kana entry, etc.
2 Basic Function for converting a word to kanji 3 Basic Capability of entering at least the JIS X 0208 Character-set 4 Additional Capability of showing differences of meaning or example sentences
for homonyms 5 Additional Function for assisting conversion of zip code to addresses, and entry
of date 5.8.5.14. Functional Requirements for the Receipt of Delivered Software
The Receipt of Delivered Software has functions for receiving software and correction programs
delivered by the software-management server.
Functional Requirement 1 Basic Capability of receiving software and correction programs (including
virus-pattern files) 2 Basic Capability of confirming the results of the installation of the received
software and correction programs 3 Basic Capability of, in a case where restarting the computer after the
completion of receiving and installing is required, displaying a prompt-message requesting restart, to a user working at the display
4 Additional Capability of suppressing or hiding GUI displays while installing received software or correction programs in order to avoid disturbance to a user working at the display
5 Additional Capability of allowing ordinary installers to execute set-up jobs
5.8.5.15. Functional Requirements for Collection of Inventory Information Collection of Inventory Information has functions for creating and sending to the server, a list of
software installed in the terminal, correction programs, signature files of anti-virus software, and
user-saved files. Functional Requirement 1 Basic Capability of creating and sending to the server, a list of software installed
in the terminal, correction programs, signature files of anti-virus software, and user-saved files
5.8.5.16. Functional / Non-functional Requirements for Encryption Encryption has functions for encrypting a file or a password, etc.
Functional Requirement 1 Basic Capability of automatically encrypting a hard-disk and managing it by the
decryption key, collectively in collaboration with the authentication authority
2 Basic Capability of encrypting file by file, in collaboration with the authentication authority
151
3 Basic Capability of encrypting folder by folder, in collaboration with the authentication authority
4 Basic Capability of executing encryption / decryption by a simple operation 5 Basic Capability of easily encrypting a file when stored in an external medium
Non-functional Requirement Back-up Basic Capability of recovering an encrypted file with a backed-up
decryption key in a situation of a failure of the terminal where the encryption was executed
5.8.5.17. Functional Requirements for Protection against Information Leakage Protection against Information Leakage has functions for protecting information against leakage.
Functional Requirement 1 Basic Capability of controlling access to classified documents (review, print,
or up-date, etc.) on a file-by-file basis in collaboration with the authentication authority
2 Additional Capability of inhibiting the making copies onto external devices such as USB memory devices
3 Additional Capability of inhibiting transmission or transfer, etc. of files attached to an e-mail, in collaboration with the authentication authority
152
5.8.6. Functional / Non-functional Requirements for an Office Printer Device
An Office Printer Device refers to a printing device installed and used in an office environment.
Among them, a printer that is shared, works as a data-processing machine and has no other
functions than printing characters, graphics or photos, etc. onto sheets of paper is defined as an office
printer; a printer that is dedicatedly connected to an individual PC is defined as a small printer; and a
printer that, in addition to functions for printing, has functions of copy machine, scanner, or
fax-machine, etc. is defined as a multi-functional printer.
5.8.6.1. Functional / Non-functional Requirements for Printer
A Printer refers to a printing device that is shared, works as a data-processing device, and records
characters, graphics, or photos, etc. on paper.
Functional Requirement 1 Basic Capability of printing data on a sheet of paper according to instructions from
a terminal 2 Basic Capability of sorting pages and stapling, in the case of printing a
multiple-page document 3 Additional Capability of, by electronic means, sorting pages, or collating pages, etc. in
the case of printing more than one copy of document 4 Basic Printing options, independent of the style of a document, for printing multiple
pages on a single page (n-up printing, both-side-printing, or monochrome-printing, etc.) in the case of making more than one copy of a document
5 Selectable No limitations on printing functions or options available for thin-clients (sheet selection, number of copies, both-side-printing, page-arrangement in book style, or sorting, etc.)
6 Additional Function for restricting network band-width available for print-data transmission
Non-functional Requirement (write only when individually required) Printing Speed
Basic Capability of printing {30 pages in monochrome, or 30 pages in color} or more A4 pages per minute
Sheet Size Basic Capability of printing a sheet up-to the {A3, A4} size Color Selectable Capability of {multi-color / color} printing Printing Resolution
Basic Capability of printing with a resolution equivalent to {1200} dpi or finer
Printing Basic Employment of laser printing, LED printing, ink-jet printing or
153
Method sublimation / thermal transfer printing Maximum Power Consumption
Basic Less than {2.0 K} W
Size Basic Size, excluding attachments, smaller than {1,200} mm wide x {1,000} mm deep, and {1,500} mm high
Weight Basic Weight, excluding attachments, of lighter than {300} kg Power Basic Requirement of no other special power arrangement than
ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan)
Tray Capacity
Basic Capability of using an auto sheet-feeder and feeding {500} sheets or more
Interface Basic Employment of an interface of standard parallel or USB connection, or both
Basic Employment of interfaces (10BASE-T, 100BASE-TX, or 1000BASE-T, etc.) for connecting to information systems
Security Additional Capability of restricting the taking-out of printed sheets Additional Capability of restricting the receipt of data (printing) using IP
addresses Additional Capability of authentication for access to setting information Additional Capability of deleting print-data saved in the equipment in order to
prevent the data from being re-used Management Additional Capability of confirming or modifying settings remotely
Additional Function for the realization of an integrated management method including status-monitoring or settings, or page-count management or monitoring of multiple devices
Additional Capability of restricting available functions by user groups [color-printing]
Additional Capability of installing driver programs through a single install program
Green Procurement (Green IT)
Basic Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Printer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”).
Basic Product compatible with the International Energy Star Program, notified to the government lead office, and registered
Additional Eco-mark certified product
5.8.6.2. Functional / Non-functional Requirements for Small Printers
A Small Printer refers to a printing device that is dedicatedly used and prints characters, graphics,
or photos, etc. onto sheets of paper.
154
Functional Requirement 1 Basic Capability of printing data on a sheet of paper according to instructions
from a terminal 2 Basic Printing options, independent on the style of documents, for printing
multiple pages on a single page (n-up printing or monochrome-printing) in the case of printing a document
3 Additional Printing options, independent on the style of documents, for printing two pages on the both sides of a sheet in the case of printing a document
4 Selective No limitations on printing functions or options available for thin-clients (sheet selection, number of copies, etc.)
5 Additional Function for restricting network band-width available for printing data Non-functional Requirement (write only when individually required) Printing Speed
Basic Capability of printing {10 pages in monochrome, or 10 pages in color} or more A4 pages per minute
Sheet Size Basic Capability of printing a sheet up-to the {A3, A4} size Color Selectable Capability of multi-color / color printing Printing Resolution
Basic Capability of printing with a resolution equivalent to {1200} dpi or finer
Printing Method
Basic Employment of laser printing, LED printing, ink-jet printing or sublimation / thermal transfer printing
Maximum Power Consumption
Basic Less than {30} w for a portable type, or {450} w for a stationary type
Size Basic Size, excluding attachment, smaller than {350} mm wide x {180} mm deep, and {85} mm high for a portable type, and {450} mm wide x {450} deep x {450} high for a stationary type
Weight Basic Weight, excluding attachments, lighter than {2.2} kg for a portable type, and {20} kg for a stationary type
Power Basic Requirement of no other special power arrangement than ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan)
Additional Capability of operating using AC (100-240)V. Power plugs compatible with the receptacles used in other countries should be available
Tray Capacity
Basic Capability of using an auto sheet-feeder and feeding {30} sheets 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
155
Management Additional Function for the realization of an integrated management method including status-monitoring or settings, or page-count management or monitoring of multiple devices
Additional Capability of installing driver programs through a single install program
Green Procurement (Green IT)
Basic Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Printer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”).
Basic Product compatible with the International Star Program, notified to the government lead office, and registered
Additional 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)
156
Printing Speed
Basic Capability of printing {30 pages in monochrome, or 30 pages in color} or more A4 pages per minute
Sheet Size Basic Capability of printing a sheet up-to the {A3, A4} size Color Selectable Capability of {multi-color / color} printing Printing Resolution
Basic Capability of printing with a resolution equivalent to {1200} dpi or finer
Printing Method
Basic Employment of laser printing, LED printing, ink-jet printing or sublimation / thermal transfer printing
Maximum Power Consumption
Basic Less than {2.0 K} W
Size Basic Size, excluding attachments, smaller than {1,200} mm wide x {1,000} mm deep, and {1,500} mm high
Weight Basic Weight, excluding attachments, lighter than {300} kg Power Basic Requirement of no other special power arrangement than
ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan)
Tray Capacity
Basic Capability of using an auto sheet-feeder and feeding {500} sheets or more
Copy Function
Selectable Capability of selecting color / monochrome copying
Automatic Document Feeder
Basic Capability of automatically feeding a document consisting of more than one page (single-sided, double-sided, different sized), in the case of scanning, facsimile-sending, or copying
Fax Functions
Basic Capability of registering or managing the fax-destination phone numbers
Scanning Function
Basic Capability of attaching scanned-data files to an e-mail Basic Capability of storing scanned-data files into private folders or
shared folders on the network Basic Capability of viewing, loading or deleting the tentatively saved
data by operations on terminals through the network Basic Capability of selecting color-scan, or monochrome-scan Basic Capability of scanning with a pre-defined resolution [200dpi,
400dpi, or 600dpi, etc.] Basic Capability of selecting a format for saving scanned data (PDF,
XPS, JPEG, or TIFF, etc.) Interface Basic Employment of an interface of standard parallel or USB
connection, or both Basic Employment of interfaces (10BASE-T, 100BASE-TX, or
1000BASE-T, etc.) for connecting to information systems Security Additional Capability of restricting the taking-out of printed sheets
Additional Capability of restricting the receipt of data (printing) using IP addresses
Additional Capability of authentication of access to setting information Additional Capability of deleting [copy, fax, scan, or print, etc.] data saved in
the device, in order to prevent the data from being re-used
157
Management Additional Capability of confirming or modifying settings remotely Additional Function for realization of an integrated management method
including status-monitoring or setting, or page-count management or monitoring of multiple devices
Additional Capability of restricting available functions [copy, fax, scan, or print data, etc.] by user groups
Additional Capability of installing driver-programs through a single install program
Green Procurement (Green IT)
Basic Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Copy Machine” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”).
Basic Product compatible with the International Energy Star Program, notified to the government lead office, and registered
Additional 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
158
5.9. Operations Management/Security
Operations management represents the activities needed to maintain unerring control of the environment, thus enabling the various systems running, mainly on computers, to provide various services to their users without interruption that may be triggered by unexpected external causes. Security refers to the construction and maintenance of environments that safeguard information assets from internal/external threats, such as viruses or unauthorized access, thus ensuring a safe and secure computer environment for all users.
Management screen
Connection control
Various dataNetwork devices
Incident
Management server
Agent
Anti-virus software
Agent
Anti-virus software
Agent
Anti-virus software
Agent
Anti-virus software
Client PC
Help deskClient PC
management
Security
Figure 5.9-1 Schematic Overview of Operation Management (Client PC system)
159
Management screen
Network devices
Incident
Management server
Objects of management (Web server, AP server, DBMS, etc.)
SAN storage
Help deskAvailability/performance
management
Network management
Storage management
Server management
OS
Agent
OS
Agent
OS
Agent
OS
Agent
Web server AP server DBMS
Agent
Internet protocol response time measurement server
Symbols
Response time measurement
Viability monitoring
Various data
SAN
Figure 5.9-2 Schematic Overview of Operation Management (Server system)
External hub
Office room
Server room
Anti-virus gateway server
Spam mail filter
Contents filer server
Proxy server
Log collection server
Mail server
Business server
FWVPN
DMZIDS/IPS
Operation/management segment
Floor segment
Floor segment
Virus pattern distribution server
Internal segment
Internet content/spam
filter
Anti-virus gateway
Intrusion detection/protection
Trail management
Encryption (VPN)
Encryption (file)Virus protection
function (of fice PC)
アクセスログAccess log
Measures against information take-out
Internet
Figure 5.9-3 Schematic Overview of Security System
160
The functions and services provided by the operation management and security are defined as follows. Function and service
Definition
Performance management
Performance management provides centralized administrative control over availability information of OSs and applications, and, when a failure takes place, supports causal investigation based on the gathered data
Client PC management
Client PC management provides centralized gathering and administrative control of information of the client PCs (hardware configuration, OSs and applications running on them) deployed in the network compatible environment. It also provides resource distribution functions – configuration management and introduction/deletion of software to/from the networked PCs – as well as remote controlling of the PCs.
Server management
Server management monitors operational status and loading conditions of the business servers that constitute the information system within the Cabinet Office and the Ministries, takes measures against data destruction in case of disaster (installation of a duplicated system in a remote location, storage of backup media in a remote location), and manages ancillary facilities (uninterrupted power systems, rack temperatures) in the server installation environment. In all, the server management assumes the job scope usually covered by the system operation administrator, or its equivalent. Note, however, that it leaves out consideration for a case in which the operation of the servers within the Cabinet Office and Ministries is outsourced to external service providers. Nor does it take into consideration requirements imposed on the data center business operator (e.g. business size).
Network management
Network management assumes the following functions: (1) Operation of the network within the Cabinet Office and Ministries consisting mainly of L2-L3 equipment (switches, routers, etc.) (2) The functions normally covered by the information system operator within the Cabinet Office and Ministries from the viewpoint of ICT system administration (3) The functions required to enhance quick recovery from a network failure, and to minimize business disturbances caused by it, as well as to provide effective preemptive measures against it Note, however, the requirements for the following business operators are
not taken into consideration: NI/SI business operators that act as a maintenance proxy, and iDC business operators.
Storage management
Storage management provides functions for effective centralized management of external memory unit resources (storage devices) used to store data and programs, including such additional functions for performing configuration display, performance/state monitoring, and various event notification.
Service desk Service desk provides such functions that enable it to work as the one-stop center for accepting problem notifications and various usage inquiries regarding the information system. The events are accepted through telephone or e-mail and their contents will be registered to a database, which is open to user access. Through linkage with other system’s fault
161
control and configuration management capabilities, these functions can be utilized for resolving problems when they occur.
Security Security provides functions for detecting unauthorized access to computers and viruses, and for monitoring the status of information security – e.g. frequency of access denials performed by the contents filtering server. It also provides the hazardous event notification function that issues an appropriated level of alarms depending on the severity of the event. In addition, it includes such functions as giving graphically-represented statistical reports for monitoring results that include analysis and improvement proposals.
Job management
Job management provides functions to compile procedures for routine tasks, and execute them regularly at given intervals or link them with particular events for triggering.
5.9.1. Functional and Non-Functional Requirements for Performance Management 5.9.1.1. Centralized management of server availability information
This function is used to centralize availability information of the monitored objects for unified
control.
Functional Requirements 1 Basic Capability to manage both OSs and applications from single screen. 2 Basic All operations for OS and application monitoring must be communalized. 3 Basic The objects to be monitored must have a hierarchy structure for easy
localization of failure events. 4 Basic Quick and easy access to the report screen pertaining to the monitored object. 5 Basic Restriction of the scope of operations depending on the user’s authority. 6 Basic Accessibility to operational viability information of the monitored server. 7 Additional Availability of the operations history (operation log) for setting changes, etc. 8 Basic Capability to monitor the operational status of the management server and
monitored processes. 9 Additional Centralized management method easily applicable to the management of
virtualized resources. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Clustered configuration capability of the management servers. Security Basic Availability of login management to avoid unauthorized
modification of configuration information etc. Extendability Basic Capability to store necessary amounts of gathered data (sufficient
to cover the audit period for internal control). Backup Basic Backup capability of configuration definition information and
operational log.
162
5.9.1.2. Information Gathering and Management of Performance Target location for Information gathering and abnormality detection includes the management
servers and the units under monitoring.
Functional Requirements 1 Basic Provision of default monitoring items (threshold valued included). 2 Basic Capacity for creating monitoring items freely. 3 Basic Functionality that allows e-mail dispatch and command execution in case a
measurement value exceeds a given threshold. 4 Additional Setting option not to store data (i.e. threshold monitoring only) 5 Basic Capability to consolidate the gathered data regularly (on hourly, daily, weekly,
and monthly basis). 6 Basic Capability to automatically delete old data when a given storage period
expires. 7 Basic Capability to gather arbitrary measurement data as defined by the user. 8 Basic Functionality to avoid data loss even in the case of communication failure
between the management server and monitoring agent. Non-functional Requirements (description provided only when relevant requirements are given) Backup Basic Capability to backup monitoring definitions. Extendability Basic Capability to store necessary the amount of gathered data (sufficient to
cover the audit period for internal control). 5.9.1.3. Report Management
Report management provides methods to create graphical representation of the gathered
operation qualification data.
Functional Requirements 1 Basic Provision of multiple graphical format options (bar graph, line chart, pie chart,
etc.) 2 Basic Provision of report templates as a default report format. 3 Basic Provision of a method to freely create new templates. 4 Basic Capability to display a multiplicity of measurement data - multiple monitoring
items of OS and applications – in a single graph. 5 Basic Capability of overwriting large amounts of data from different points in time
(current data and past data from any given point in time). 6 Additional Provision of a report saving function on the display screen. 7 Basic Capability to save reports and measurement data automatically. 8 Basic Capability to freely adjust the time window of the graphical display. 5.9.1.4. OS Performance Management
This function provides methods for gathering information regarding the performance of OSs.
Functional Requirements 1 Basic Capability to gather operation data of CPU utilization. 2 Basic Capability to gather operation data for each CPU (in case of a multi-CPU system).
163
3 Basic Capability to gather operation data for each CPU core (in case of a multi-core CPU system).
4 Basic Capability to gather utilization information of physical hard disks. 5 Basic Capability to gather I/O performance information of physical hard disks. 6 Basic Capability to gather free space information of physical memory. 7 Basic Capability to gather free space information of virtual memory. 8 Basic Capability to get the number of concurrently running processes. 9 Basic Capability to gather information of CPU and virtual memory utilization on a
process-by-process basis. 10 Basic Capability to gather I/O information of a network interface card. 11 Basic Capability to monitor event log. 12 Basic Capability to monitor the state of services provided by OS (i.e. daemon
processes). Non-functional Requirements (description provided only when relevant requirements are given) Extendability Basic Capability to save gathered data in external storage devices on an as
needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to
cover the audit period for internal control). 5.9.1.5. DBMS Performance Management
This function provides methods for gathering information regarding performance of DBMSs.
Functional Requirements 1 Basic Capability to gather utilization information on a table-by-table basis. 2 Basic Capability to gather information on the SQL statements currently executing. 3 Basic Capability to monitor the state of connections. 4 Basic Capability to obtain the dispatcher IP address and program information of an SQL
statement. 5 Basic Capability to monitor the occurrence status of locking. 6 Basic Capability to gather input/output information (number of times, etc). Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered DB servers, the management agent must be able
to manage all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as
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
164
1 Basic Capability to gather access number information. 2 Basic Capability to obtain the number of garbage collections that have taken place. 3 Basic Capability to obtain the execution time required by a garbage collection. 4 Basic Capability to gather information on the heap usage required for running component
applications (Java components, NET components, etc.). 5 Basic Capability to gather average response time information of Web services. 6 Basic Capability to obtain the number of sessions. 7 Basic Capability of obtain the number of queuing threads. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered AP servers, the management agent must be able
to manage all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as
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
165
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 Transfer Protocol
HTTP(Hyper Text Transfer Protocol) A protocol used for transmission and reception of data between Web servers and clients (e.g. Web browser), capable of transmitting/receiving HTML and other various formatted documents with their attached files (images, sound, and animation) and representation information. IETF standardized HTTP/1.0 as RFC 1945, and HTTP/1.1 as RFC 2616. HTTPS(Hyper Text Transfer Protocol Secure) A protocol derived from HTTP - used for transmission and reception of data between Web servers and clients (e.g. Web browser) - with addition of encryption capability using SSL. It enables secured communication that involves confidential information (privacy information, credit card numbers, etc.) through encryption of correspondence between the server and browser. Major Web browsers (Internet Explorer, Firefox, Safari, etc.) are compatible with this protocol, making it the de facto standard. SSL is an encryption protocol propounded by Netscape Communications. In addition to HTTP, it is also applicable to such protocols as FTP and TELNET.
Dynamic Host Configuration Protocol
DHCP(Dynamic Host Configuration Protocol) A protocol to automatically assign necessary information (an IP address and others) to a computer connecting temporarily to the Internet. A DHCP server is allocated with a pre-defined range of IP addresses (to be assigned for Gateway servers and DNS servers, and for subnet masks and clients), and it provides necessary information to the computer that is accessing the server through dial-up or through other schemes. When a client terminates its communication, the DHCP server automatically recovers the address for use with other computers. The use of DHCP enables even the casual users – who may not be familiar with network settings - to establish connection to the Internet without difficulties. It also enables the network administrators to manage large numbers of clients in a unified fashion.
Domain Name System
DNS(Domain Name System) A system to match a host name in the Internet to a IP address. This is a distributed database through which the DNS servers all around the world make concerted operations. A host name can be searched from an IP address, and vice versa. Each DNS server maintains a set of domain information under its control, and registers the domain name and its own address to the route servers (approx. 10 route servers are in operation around the world). A client program (called “resolver”) resolves the conversion by first making inquiries about the domain name (or IP address) with the route server, and then examining the DNS server that manages the domain, followed finally by extracting necessary information from the DNS server. A majority of the DNS servers operating in the Internet use the BIND server, which was developed by UCB (University of California at Berkley).
166
5.9.1.8. Performance Management of the Job Management Server
This function provides mechanisms for gathering information regarding performances for job
management servers.
Functional Requirements 1 Basic Capability to gather the number of jobs currently executing. 2 Basic Capability to gather the number of jobs that have failed. 3 Basic Capability to gather the number of jobs that are staying dormant. 4 Basic Capability to gather the number of jobs that are delayed in their execution. 5 Basic Capability to gather information regarding the operational status of DBMSs in use. 6 Basic Capability to gather latency time information of the jobs. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered job management servers, the management
agent must be able to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as
needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient
to cover the audit period for internal control). 5.9.1.9. Performance Management of Web Server Management Software
This function provides mechanisms for gathering information regarding performance for Web
server management servers.
Functional Requirements 1 Basic Capability to gather access count. 2 Basic Capability to gather the count of “Not Found” (*) occurrences. 3 Basic Capability to gather throughput information. 4 Basic Capability to gather transfer rate information (transmission and reception). (*)“Not Found” count: the number of times when the Web site is not located using the given URL. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered Web servers, the management agent must be able
to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as
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.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).
168
5.9.1.12. Performance management of distributed transactions This function provides mechanisms for gathering information regarding performance for distributed
transactions.
Functional Requirements 1 Basic Capability to gather performance information related to RPC (Remote Procedure
Call). 2 Basic Capability to gather the number of accesses done to files. 3 Basic Capability to gather the number of commits/rollbacks. 4 Basic Capability to gather communication status information of the distributed
transaction servers. 5 Basic Capability to gather information relating to the queue manager’s operational
status. 6 Basic Capability to gather information relating to the handle status. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered distributed transaction servers, the management
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.2. Functional/Non-Functional Requirements for Client PC Management 5.9.2.1. Client PC configuration management
Client PC configuration management provides functions to gather information regarding the
hardware and software implementation of the client environment, thus enabling unified control of it.
These functions can also be used as a security measure and serve to detect network connection
attempts from unauthorized clients and use of malicious software.
Functional Requirements 1 Basic Capability to browse device information – CPU, memory, physical disk, MAC
address, external storage devices, etc. 2 Basic Capability to gather information regarding the software implemented on each
terminal.
Related technologies Remote Procedure Call
RPC (Remote Procedure Call) A procedure, developed by Sun Microsystems, used to enable processing among dissimilar machines deployed on the Internet. This technology has widespread use in UNIX systems, and is also finding its implementation in Windows NT. The DCOM – Microsoft’s distributed object technology – was developed based on RPC.
169
3 Basic Capability to browse OS information – type and version of OS, computer name, and network information (IP address, etc.).
4 Basic Capability to gather configuration and other information at any time, on a group-by-group and user-by-user basis.
5 Basic Selectability of the terminals used to gather information. 6 Basic Capability to stop displaying (or hide temporarily) GUI elements while information
gathering is taking place (a measure to avoid interrupting user operation). 7 Basic Capability of unifying all management, and browsing and conditional searching of
the information gathered.
5.9.2.2. Resource Distribution Management
Resource distribution management provides the server with the methods to perform software
distribution services – e.g. remote installation of common standard software and security patches – to
multiple client PCs en block.
Functional Requirements 1 Basic Capability to distribute software from the server to the terminals. 2 Basic Capability to distribute to all the terminals. 3 Basic Capability to stop displaying (or hide temporarily) GUI elements while the
distribution process is being carried out (a measure to avoid interrupting user operation).
4 Basic In case a system restart is required at the end of the distribution operation, a message must be displayed to prompt the working user to reboot the system.
5 Basic Capability to handle setup operations using major installer formats (msi, exec, etc.)
6 Basic Capability to define the types of software that can be installed/uninstalled for each terminal and for each group.
7 Basic Capability to distribute only to specified terminals and groups. 8 Basic Capability to verify the results of the software distribution. 9 Basic Capability of performing the following cycle: powering-on of a terminal,
distribution of software, followed by an automatic powering-off of the terminal. 10 Basic Capability to automate resource distribution operations (user operations from
installation to system restart) and scheduled execution of them.
Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic Availability of active client PCs even in the case of management
server failure. Performance Basic Capacity of controlling multiple PCs (up to several thousand) through
synchronization. Extendability Basic Extendability of the range of control up to several thousand PCs by
utilizing distributed servers and other schemes. Security Basic Access authority to the gathered PC configuration information must
be assigned only to qualified personnel.
170
11 Basic Capability to allocate distribution load appropriately to minimize its effect on other services, especially in the case of a large scale resource distribution such as a service pack.
12 Basic Capability to detect, after resource distribution, the client PC where normal distribution failed, enabling a retry of distribution.
13 Basic Capability to perform an installation/version upgrade of software without any user operations, even if it does not normally allow silent-mode installation. Note that, this requirement is considered to be met if distribution operation can be performed based on the installation operation log and its modifications on a particular terminal.
Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capacity to control multiple PCs (up to several hundred thousand)
simultaneously. Extendability Basic Extendability of the range of controllable PCs up to several million by
utilizing distributed servers and other schemes. Security Basic Only the authorized users are allowed to perform distribution
operations, and refer to the distribution resources. 5.9.2.3. Remote Operation
Remote operation is a part of management functions that enables the server to perform remote
client operations to the client PCs.
Functional Requirements 1 Basic Capacity of controlling multiple PCs (up to several hundred thousand)
simultaneously. 2 Basic Capability to remotely restrict the users that are authorized for connection. 3 Basic Capability of remote connection and file transfer to the connected terminal. 4 Basic Capability of remote connection and restart of the connected terminal. 5 Basic Capability to remotely control a client PC even while it is not logged in. 6 Basic Capability of encrypting communication contents for remote operations, and
recording operation details. 7 Basic Capability to record operations, as log information, performed to change the state
of operational objects (i.e. terminals) – logon, shutdown, restart, etc. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capability to perform operations through the network, which requires
the capacity to reduce line load (required band-width) depending on the line speed employed.
5.9.2.4. Others Functional Requirements 1 Basic Capability to record the operations log performed to the client PCs, and the
information must be browsable. The operations log must at least include program invocations and file operations.
171
5.9.3. Functional/ Non-Functional Requirements for Server Management 5.9.3.1. Server configuration management
Server configuration management includes functions that enable control of hardware and software
information required to define the configuration of the server.
Functional Requirements 1 Basic Capability of the centralized management of the latest set of configuration
information for all servers, including device information, system information (OS, CPU, memory, etc.), software information, network information, and disk information.
2 Additional Capability to display the revision history of server configuration information, and changes before and after a modification.
Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Operations, except for those related to server configuration
management, must be available to the terminals (console terminals) even while the management server is down.
Performance Basic Capacity to control multiple servers (up to several hundred) simultaneously.
Extendability Basic Extendability of the range of controllable servers up to several hundred.
Security Basic Accessibility to all of the gathered server configuration information (device/system/software/network/disk information) must be appropriately provided.
5.9.3.2. Performance Management
Performance management includes management functions to monitor the level of performance
required by the server. Functional Requirements 1 Basic Capability to the gather kernel configuration information of each OS. 2 Basic Capability to gather performance information of such system elements as IO,
memory, cache, space, deadlock, and database usage (e.g. SQL frequency). Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Any failure in performance management functions must not have an
effect on the execution of other services (functions), and methods must be provided for easy restoration.
Extendability Basic The performance management must be capable of controlling multiple databases and OSs.
Extendability Basic The performance management must have the flexibility to meet the requirements of new versions of databases and OSs.
5.9.3.3. Fault Control
Fault control provides functions to detect server failures, and to cope with irregular situations in the
servers comprising the business system.
172
Functional Requirements 1 Basic Capability to monitor the output functions of specified log information, and
issue a notification (e.g. alarm) to the administrator in case it detects one of the given events.
2 Basic Capability to record operations, as log information, performed to change the state of operational objects (i.e. terminals) –shutdown, reboot, etc.
3 Additional Capability to perform polling on each of the server communication ports under the control of various services and daemons (e.g. HTTP/HTTPS, DNS, SMTP, and any other specified ports).
4 Basic Capability to monitor the operational status of various services, daemons, and processes that are resident on the server.
5 Basic In the event of hardware failures and other abnormal events, the system configuration must have the provision to notify staff members, maintenance contacts, and the administrator in charge by means of e-mail (including e-mailing to mobile phones). This function must cover all the servers installed in a given machine room.
6 Basic Capability, when a failure occurs, to identify and locate the range of the affected area.
7 Basic Capability to manage failure history information. Non-functional Requirements (description provided only when relevant requirements given) Extendability Basic The failure management functions must be compatible with multiple
databases and OSs 5.9.3.4. Resource Management
Resource management provides management functions to display/notify the utilization information
(used/free space) of the hard disks incorporated in the server.
Functional Requirements 1 Basic Availability of graphic display and file output of hard disk utilization information
(used and free space) incorporated in all server hardware. 2 Basic Availability of a function to monitor disk usage threshold, and automatic notification
to the person in charge. 5.9.3.5. Backup Management
Backup management provides controlling methods against data destruction that may be caused by
disasters and system failures (including human errors).
Functional Requirements 1 Basic Capability of online backup (for the software compatible with online backup). 2 Basic Compatibility with scheduled backup. 3 Basic Availability of both full and incremental backup. 4 Basic Capability of monitoring backup operation status (success and failure) 5 Basic Restoring capability on file, folder, logical volume, and server basis. 6 Basic Accessibility to restore operations from other servers than that obtained the
backup.
173
7 Basic Capability to create backup media that can be used for system area restoration.
8 Additional Capability of the backup media to start and perform system area restoration operations.
9 Basic Additional implementation of segments dedicated for backup operations, in cases where there are concerns that the backup operations might overload the business use of the network.
10 Basic Capability of the management of backup media generation. Linkage with library equipment is required to archive the given number of data generations in the media.
Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Backup must not trigger operational discontinuation of the server, nor
produce the need for a system reboot. Security Basic Authority to make a reference to the backup media must be strictly
limited only to the authorized users. 5.9.3.6. Inter-Equipment Linkage
Inter-equipment linkage provides functions to manage irregular events that may occur in the related
set of equipment essential for system operation.
Functional Requirements 1 Basic Capability to monitor the status of equipment installed in a given machine room
(air-conditioning, power unit, water leakage, temperature, etc.), and to provide notification for the occurrence of irregular events.
2 Basic Provision of assistance functions for the operator/administrator to control and shutdown the equipment installed in the machine room where irregular events are taking place.
Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Capability to issue a server shutdown command in no uncertain
manner when an equipment failure is detected. Extendability Basic Provision of an interface enabling detection of equipment failures. 5.9.3.7. Resource Distribution Management
This function provides the management server with management functions to perform software
distribution services – e.g. remote installation of common standard software and security patches – to
multiple servers en block.
Functional Requirements 1 Basic Capability of the management server to distribute software to target servers. 2 Additional Capability to stop displaying (or hide temporarily) GUI elements while the
distribution process is being carried out (a measure to avoid interrupting user operations).
3 Basic In case system restart is required at the end of a distribution operation, a message must be displayed to prompt the working user to reboot the system.
174
4 Additional Capability to handle setup operations using major installer formats. 5 Basic Capability to define the types of software that can be installed/uninstalled for
each server and for each group. 6 Basic Capability to distribute only to specified servers and groups. 7 Basic Capability to confirm the results of the software distribution. 8 Additional Capability to automate resource distribution operations (user operations from
installation to system restart) and scheduled execution of them. 9 Basic Capability to allocate distribution load appropriately to minimize its effect on
other services, especially in the case of a large scale resource distribution such as a service pack.
10 Basic Post-distribution capability to locate the server on which normal distribution failed, enabling a retry of distribution.
11 Additional Capability to perform software installation (or version upgrade) without any user operations, even if the software does not normally allow silent-mode installation.
Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capacity of controlling multiple servers (up to several hundred)
simultaneously. Extendability Basic Extendability of the range of controllable servers - up to several
hundred - by utilizing distributed management servers and other schemes.
Security Basic Only the authorized users are allowed to perform distribution operations, and refer to the distribution resources.
5.9.3.8. Others Functional Requirements 1 Basic Capability to record an operations log performed to the servers, and the log
information must be browsable.
175
5.9.4. Functional/ Non-functional Requirements for Network Management 5.9.4.1. Network configuration management
Network configuration management includes functions that enable the control of network
equipment and software information required to define configuration of the network.
Functional Requirements 1 Basic Capability to automatically create the network map from network
configuration information. 2 Basic Capability to automatically gather arbitrary MIB information from each node. 3 Basic Capability to manage installation and setting information of the network
devices. 4 Basic Capability to manage the number of installations of network equipment. 5 Basic Capability to gather network configuration information automatically and each
network device must be capable of invoking regular updates of configuration information.
6 Basic Capability to customize the network map, enabling the creation of hierarchical network maps on a hub and floor basis.
7 Basic Browsability of configuration information using a GUI. 8 Additional Capability to display the results of past configuration modifications, as
changes before and after a modification. 9 Basic Capability to display configuration information in the way most suited to each
hub and section. 10 Basic Capability of a screen-by-screen display of the different types of configuration
information. 11 Additional Capability to display types of configuration information based on the VLAN
route. 12 Basic Capability to distinguish the state (normal/failed) of devices and line
conditions on the screen – for example, by the changing of icon colors. 13 Basic Capability to locate an operational bottleneck (CPU of a network
device/server, memory, etc.), which requires tracking of changes in the business throughput and load.
14 Additional Capability to maintain continued operational monitoring – without any delay associated with device switching – even in the cases of device failure in the operational management server.
15 Basic Capability to restrict types of operations allowed to the operator and administrator: a measure to prevent network problems caused by inadvertent operations.
Non-functional Requirements (description provided only when relevant requirements given) Availability Basic The servers and client PCs must be able to perform non-networking
tasks even while the network is down. Performance Basic Capability to manage multiple PCs (several hundred thousand) and
servers (several hundred) simultaneously. Extendability Basic Extendability of the range of controllable PCs (up to several hundred
thousand) and servers (up to several hundred).
176
Security Basic Capability to assign the authority of accessing the gathered configuration information of monitored devices only to qualified persons.
Related technologies Network management protocol
SNMP (Simple Network Management Protocol) In a TCP/IP network, this protocol is used to monitor/control the networked communication devices (routers, computers, terminals, etc.) through the network. The devices to be controlled have a management information database, called MIB, and the controlling device configures the target devices appropriately based on MIB. (Specifications) http://www.ietf.org/rfc/rfc2570.txt?number=2570 (Link & information portal) http://www.simpleweb.org/
MIB MIB (Management Information Base) MIB is the management information contained in a SNMP-controlled device. Two versions are currently available (MIB1 defined by RFC 1156 and MIB2 defined by RFC 1213), of which the latter has become more prevalent. The specifications for this database are standardized by the IETF. (Specification) http://www.faqs.org/rfcs/rfc1213.html
5.9.4.2. Traffic management
Traffic management provides methods to control the traffic over the network.
Functional Requirements 1 Basic Capability to measure and gather traffic information in real time. 2 Basic Capability to define a threshold on the measured traffic information and to notify
the person in charge automatically in case the actual traffic exceeds it. 3 Basic Capability to monitor the traffic passing through the network, and to perform fine
bandwidth management (i.e. control of bandwidth and transmission delay) conforming to the policy defined by the user. The locations from where the monitoring/management operation is performed are stated separately.
Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Business services must be provided continuously and flawlessly
regardless of the running status (on/off) of the traffic management functions.
5.9.4.3. Fault control
Fault control provides methods to control network faults.
Functional Requirements 1 Basic Capability to monitor if a node/link is down in network devices, as well as to
monitor node status using ICMP-echo. 2 Basic Provision of automatic notification and filtering of the events to be monitored. 3 Additional Provision of automatic classification (filtering) for the events to be monitored. 4 Basic Capability of a forced remote-controlled shutdown of the link of connection
ports incorporated in central/local node switches.
177
5 Basic Capability of centralized control (e.g. powering On/Off, restart) of network devices located in external hubs (this requirement applies to the network devices capable of remote powering On/Off and restart).
6 Basic Capability to remotely control network devices even in the case of network failure (assuming that communication to those network devices is still available).
7 Basic Capability of historical management of failures, including search function using a keyword.
Non-functional Requirements (description provided only when relevant requirements given) Extendability Additional Data saving functions must be compatible with various types of
databases and OSs. Availability Basic Provision of multiple notification methods (e.g. alarm light, mail,
etc.). These monitoring methods must operate concurrently to guarantee secure notification to the management server.
Availability Additional Capability of monitoring and archiving the management of Syslog output from the network devices.
5.9.4.4. Others Functional Requirements 1 Additional Capability to record an operations log performed in relation to network
management, and the log information must be browsable.
5.9.5. Functional/ non-functional requirements for storage management 5.9.5.1. Storage configuration management
Storage configuration management provides functions to display/notify information regarding
storage devices such as the attributes, logical disk configuration, and connection status.
Functional Requirements 1 Basic Provision of configuration information gathering functions applicable to storage
devices. 2 Basic Provision of an automatic detection function of connected storage devices. 3 Basic Provision of a function to create a map of the connected storage devices. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic The servers and client PCs connected to the storage management
server/storage must remain operative without interruption even while the storage is down.
Security Basic Access authority to the gathered storage configuration information must be assigned only to qualified operators.
5.9.5.2. Performance management
Performance management provides functions to monitor and display the performance status in real
time, detecting symptoms, and preventing performance degradation.
178
Functional Requirements 1 Basic Capability to gather and monitor storage devices’ performance information such
as Read/Write frequency, data transfer time, average response time, and disk usage rate.
2 Basic Capability to gather and monitor performance information between the server and storage (SAN switch performance, etc.).
3 Basic Provision of a function to monitor the threshold assigned to performance information for storage devices and server-storage operations, and to automatically notify the person in charge.
4 Basic Provision of a graphic display and file output function for performance information. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Failure in performance management functions shall not hinder
continuous operation of storage devices. 5.9.5.3. Resource (capacity) management
Resource (capacity) management provides functions to display and notify the usage status (used
and free space) in each disk and logical group.
Functional Requirements 1 Basic Capability to gather and save the resource (capacity) information of each
server connected to the storage (capability to grasp the amount of used and free space in each device, volume and server is required).
2 Basic Provision of a function to monitor the disk usage threshold and to automatically notify the person in charge.
3 Basic Provision of a graphic display and file output function. 4 Additional Capability to grasp current disk usage information (used and free space) for
each folder and user. 5 Basic Provision of a function to calculate billing data for each section based on its
usage. 6 Basic Capability to accommodate additions of new disks. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Resource (capacity) management shall not have an effect on the
performance of storage devices. 5.9.5.4. Fault control
Fault control provides functions to monitor and display the status of storage devices, and to issue
messages when failure occurs.
Functional Requirements 1 Basic Provision of a function to provide automatic notification of the occurrence of
monitored events. 2 Basic Provision of a filtering function, which enables automatic classification of the
monitored events.
179
3 Additional Capability to remotely operate the storage devices in the event of a storage failure (centralized control of powering On/Off and restart).
4 Basic Capability to gather information such as the operation/console log, event log, and configuration.
5 Basic Capability to forcefully shutdown connection port links in SAN switches from a remote location. This functionality is required, for example, to perform stepwise disconnection prior to starting maintenance operations.
Non-functional Requirements (description provided only when relevant requirements given) Extendability Basic Compatibility with various types of databases and OSs. Availability Basic Provision of multiple notification methods (e.g. alarm light, mail, etc.).
These monitoring methods must operate concurrently to guarantee secure notification to the management server.
5.9.5.5. Backup management
Backup management provides controlling methods against data destruction that may be caused by
disasters or storage failures (including human errors).
Functional Requirements 1 Basic Provision of functions that enable performance of backup operations without the
use of the LAN or servers (*). 2 Basic Provision of functions to support remote backup and disaster recovery operations
among the hubs. (*) LAN-free backup: a method to backup data by way of SAN, and not by way of LAN.
Server-less backup: a backup method that does not use the LAN, and does not put load on the
server.
Non-functional Requirements (description provided only when relevant requirements given) Security Basic Authority to make a reference to the backup media must be strictly
limited only to the authorized operators. 5.9.5.6. Others Functional Requirements 1 Basic Capability to record an operations log performed to the storage, and the
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.
180
2 Basic Capability to automatically notify the operator in charge of inquiries, and to register them for storage in database.
3 Basic Capability to attach a file, as auxiliary information, to trouble tickets, problem sheets, and modification management forms.
4 Basic Capability to browse and search past inquiries through the use of a GUI. 5 Basic Provision of an escalation function. 6 Basic Capability to automatically register failure information that was detected by other
management functions through a well coordinated linkage between them. 7 Basic Capability to integrate all information system related application contacts to the
service desk. Non-functional Requirements (description provided only when relevant requirements given) Extendability Additional Provision of an interface that enables coordinated operation with
server monitoring and network monitoring functions. Availability Basic No software restriction shall be placed on the maximum number of
management-related inquiries (extendability must be incorporated).
5.9.6.2. Others Functional Requirements 1 Basic Capability to record an operations log performed to the service desk, and the
information must be browsable.
181
5.9.7. Functional and Non-Functional Requirements for Security 5.9.7.1. Virus protection function
Virus protection provides function to detect malicious or infected programs to protect servers and
terminals (PCs) from becoming infected with those harmful agents.
Functional Requirements 1 Basic Provision of anti-virus/vaccine software that is compatible with the proposed
OS. 2 Basic Capability of automatic shutdown of PCs following the completion of a virus
scan (if the user plans to shutdown the PC after the virus-scan), or automatic re-execution of the virus scan at the subsequent restart of the PC.
3 Basic Capability of automatically updating the virus definition pattern file, which involves scheduled access to the server of the pattern file provider through the Internet.
4 Additional Capability to execute an update of the virus definition pattern file without the need to restart the system.
5 Basic Capability to detect infected/malicious programs in real time, and to isolate the malicious program or cleanse viruses.
6 Basic Provision of functions that enable centralized management of pattern files in a server, and to distribute them to terminals.
Non-functional Requirements (description provided only when relevant requirements given) Availability Additional Abnormality in vaccine software must not cause the stoppage of
servers and terminals (PC). Availability Basic Stoppage of the distribution server that distributes virus definition
patterns and other information shall not bring the detection function to a stop.
Availability Basic Latest pattern files for virus-checking shall be distributed. Security Basic Provision of protective measures against inadvertent distribution
of spurious virus definition pattern files. Security Basic Inability of the end users to stop the running vaccine software, or
uninstall it. Performance Additional Virus scan and pattern file distribution shall not cause excessive
delay in other normal operation programs. Extendability Basic Provision of scalability to cope with the increased variety of
objects to be distributed (i.e. pattern files and other related files). - The content of this section corresponds to the following items in the Standards for Information
Security Measures for the Central Government Computer Systems: 2.1.1.4, 2.1.2
- The content of this section corresponds to the following segments in the physical configuration
model: S0, S1
182
5.9.7.2. Internet Content Filtering Function
The Internet contents filtering function provides methods to block access to harmful information on
the Web (Internet)
Functional Requirements 1 Basic Introduction of a function to block access from the targeted internal network
to a set of specified Internet URLs. 2 Basic Capability to automatically update the banned URL database by means of
accessing database provider’s servers, such as PICS, via the Internet. 3 Basic Capability to specify the interval to check if there are any updates in the
banned URL database. 4 Basic Capability to allow access authority to URLs only to the specified users. 5 Basic Capability to monitor accesses to the banned URLs. 6 Basic Provision of enough banned URL data within and outside of the country. 7 Basic Capability to classify the banned and allowed URLs into detailed categories. 8 Basic Capability to apply a particular filtering policy on a unit-by-unit, or
user-by-user basis. 9 Basic Capability of centralized user management in coordination with the directory
service. 10 Basic Capability to synchronize multiple servers, even in a load-balancing
environment consisting of a number of servers, by setting and applying a single rule.
11 Basic Provision of flexible rule settings, including such rules as “Browsing allowed & transmission prohibited” and “Filtering after checking its contents.”
12 Basic Capability of category-by-category and user-by-user graphic display access situation.
13 Basic Capability to extract required information (e.g. user name, group name, blocking situation, etc) from the access log.
14 Basic Capability to apply filtering functions to the cache of a search engine and translation functions provided by a translation site. Block log and POST log must be browsable from the management screen or by using report software.
15 Additional Provision of a virus detection capability by analyzing Web contents. 16 Additional Provision of an ICAP client function, or its equivalent within the chassis. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Abnormality in contents filtering functions shall not cause the
stoppage of servers and terminals (PC). Availability Basic Stoppage of the distribution server that distributes pattern files for
contents filtering shall not bring the detection function to a stop. Availability Basic Failures in content filtering functions shall not place any obstacles in
the flawless continuation of network communication, and this must not require user intervention (setting modifications, etc).
Security Basic Provision of a method to check the source of pattern file distribution (e.g. server certificate), enabling confirmation of the legitimacy of the pattern file.
183
Security Basic Inability of the end users to stop the running contents filter, or uninstall it.
Performance Basic Running of the contents filter and distribution of pattern files shall not cause excessive delay in other normal system operations.
Extendability Basic Provision of scalability to cope with the increased number of terminals to be checked by the contents filter.
Related technologies Contents control standard
PICS (Platform for Internet Content Selection) Technical specifications for implementing selective reception of Web contents in accordance with the levels defines by the user. This standard was established by W3C. (Standard) http://www.w3.org/PICS/
- The content of this section corresponds to the following items in the Standards for Information
Security Measures for the Central Government Computer Systems: 2.1.1.2, 2.1.1.4, 2.2.3.2
- 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.
184
Non-functional Requirements (description provided only when relevant requirements given) Availability Additional Abnormality in anti-spam functions shall not cause the stoppage
of servers or terminals (PC). Availability Basic Stoppage of the distribution server that delivers anti-spam mail
measures (e.g. pattern file) shall not cause a halt in anti-spam mail functions.
Availability Basic Provision of measures to avoid adverse effects on normal operations (mail traffic, etc.) even in the case of functional failures and stoppage of the anti-spam mail server.
Security Basic Provision of protective measures against inadvertent distribution of spurious anti-spam pattern files.
Security Basic Inability of the end users to stop the running anti-spam functions, or uninstall them.
Performance Basic Checking of spam mails and distribution of pattern files shall not cause excessive delay in other normal operation programs.
Extendability Basic Provision of scalability to cope with the increased variety of objects to be distributed (anti-spam mail pattern files, etc.).
Performance Additional Enough capacity to handle reception processing of a large number of spam-mails.
- 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).
185
Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of a multi-device redundant configuration that enables
continued operation even in a case of failure and stoppage of one firewall function.
Performance Basic Capability to continue normal processing even when the system receives a large number of packets.
Security Basic Provision of a function to deny the access of suspicious packets in coordination with IDS.
- 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
186
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.
7 Basic Provision of a function to analyze and summarize information regarding the number of connected terminals and the security status for each of them during a designated period, and output a report in text format.
Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of redundancy in network connection monitoring functions,
which guarantees continued operation even when the network devices (e.g. server) with network monitoring capability fail.
Availability Basic Capability to isolate/stop the network connection monitoring function with ease if any trouble occurs in it. That is, such a situation shall not take place in which no PC – with connection authority given by the network connection monitoring function – is connected to the network.
Extendability Basic Capability to connect more than one terminal. Related technologies
187
IEEE802.1x Authentication
Institute of Electrical and Electronic Engineers 802 シリーズ A standard that stipulates the user authentication method at access points: defined by IEEE (Institute of Electrical and Electronics Engineers) LAN standardization committee (802 committee). (Specifications) http://www.ieee802.org/1/pages/802.1x.html
- 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.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.
188
3 Basic Capability to perform encrypted communication without the need of encoding/decoding operations.
Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of the above described procedures shall not cause
significant delays in normal business operations. Related technologies Encryption Standard
AES(Advanced Encryption Standard) The U.S. Government’s next generation standard for encryption methods, adopted by the National Information System for Science and Technology (NIST). The new standard was established in March 2001 (FIPS PUB197) to replace DES (established in 1977) due to the concerns about insufficient security. (FIPS PUB197) http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
Encryption Standard
3DES(Triple - Data Encryption Standard) An encryption method developed by IBM. A higher level of security has been achieved by the triple application of DES (a secret key cryptosystem developed by IBM).
Electronic Certificate
X.509 Certificate. A standard for open key certificate established by ITU-T (one of X500
directory series included in ISO/IEC international standards). The latest version published in 1997 (X.509v3) added an extension area in
the certificate for arbitrary functional enhancement. X.509v3 was revised in 2000 to bring higher clarity to the quick method of expired information notification to the user and attribute certificate definitions.
- 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)
189
3 Basic Capability for use with several different Web browsers. 4 Basic Capability to apply the SSL server and client authentication technique when data
of special importance is processed (e.g. uploading). 5 Basic Authentication history and HTTP communication log after authentication shall be
recorded and stored for a specified period. 6 Basic As an alternative to the management method of the communication log stated in
the previous item, the trail management function may be used. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of above described procedures shall not cause significant
delays in normal business operations. Performance Basic In case an attempt is due to incorporate TSL in an HTTP server that
suffers heavily concentrated access, an introduction of a dedicated TSL server shall be considered.
Availability Basic In case a dedicated TLS server is already in place, stoppage of the server (due to failure, hazard, etc.) shall not affect operations of HTTP servers.
Related technologies Security Protocol
TLS (Transport Layer Security) A protocol that provides encryption functions for communication requiring security. It is implemented as a wrapper for TCP communication, thus it is independent of the upper level protocols. (TSL1.1/RFC4346)http://tools.ietf.org/html/rfc4346
- 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.
190
7 Basic Provision of simple and easy file encryption methods in preparation for storage in external media.
8 Basic Provision of a function to block taking information out of the ministries without encryption – for example, by disconnecting external media (USB memory, MO, FD, external HDD, etc.) out of the terminals installed within the ministry.
9 Basic Capability of automatic data encryption to be performed when the data is transferred for storage to the external devices (e.g. USB memory, MO, FD, external HDD, etc.) connected to the terminals installed in the ministry.
10 Basic Capability to decode encrypted files that were transferred from the devices within the ministry to those in places out of the ministry without relying on a specially-installed encryption software installed on the latter (password entry for authentication may be a required step).
Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of the above described procedures shall not cause
significant delays in normal business operations. Backup Basic Provision of a fail-safe mechanism that enables decoding of an
encrypted file even if the terminal in which the encryption were performed fails – for example, through the use of a backed-up decoding key.
- 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.
191
Non-functional Requirements (description provided only when relevant requirements given) Security Basic Provision of a function to protect the gathered log information against
any attempt of tampering. Security Basic Provision of appropriate measures – access control, encryption,
anti-tampering and tampering detection etc. - to protect trail logs against fraudulent use by third parties.
Extendability Basic Capability to handle OS logs (normal/error log of the system and applications) in the same fashion as above.
Performance Basic Execution of log gathering operations shall not cause significant delays in log output functions.
Backup Basic Provisions of appropriate measures (e.g. making a backup) to protect the trail log against file corruption and deletion.
- 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.
192
5.9.9. Compatibility with virtualization Functional Requirements (compatibility with virtual environment) 1 Basic Capability to deploy an equivalent set of software to achieve the same level of
performance in a virtual environment as in the physical server environment. The virtual environment consists of such elements as a virtual guest server, virtual storage, and a virtual network realized through the use of virtualization mechanisms.
193
5.10. EIP
5.10.1. Definition EIP represents the “Enterprise Information Portal” that provides functions conducive to perform
effective IT-system based business operations, including the function to control information and
applications centrally for delivery to Web browsers running on the terminals. It delivers an assortment
of views on a screen linked to contents and applications appropriately assigned to the user depending
on his/her role in the portal site.
EIP Functions & Services Function & Service Definition Portal Site function Functions to create an integrated view as a Web page (portal site)
comprising of multiple applications – business applications, groupware applications, information contents (documents, images, animations, etc.) – capable of transmitting/receiving information to/from other Web browsers.
Personalize function A function to identify each portal site user and his/her role, and create a combination of contents and applications most suited to him/her, enabling delivery of it in a unified screen or view.
Application integration function
A mechanism to achieve on-portal site integration of the job-related roles of a portal site user and applications, thus enabling close linkage among them. The target applications include such business packages as groupware, business intelligence (BI), customer relationship management (CRM), and enterprise resource planning (ERP), as well as XML Web service applications.
Management An EIP related management function. It includes user management, contents management, auditing, other various management functions and backup.
5.10.2. Portal Site Function Functional Requirements 1 Basic Capability to perform user authentication/authorization on a portal site basis, and
the capability to perform these tasks in coordination with other directory services external to the server.
2 Basic Customization: allowance to freely change the combination of information contents and applications incorporated in the portal site, and to rearrange the screen layout.
3 Basic Search: a function to search, by entering a keyword to a search field on the portal site screen or a search application, the objective through the information contents and application data accumulated on the portal site, and report the search result information on the site’s screen.
4 Basic The portal site shall have a capability to respond to accesses from the Web browser installed on such devices as PC, PDA, and mobile phones.
194
Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of system configuration that has multiplexed portal sites
over a plural of server hardware systems, which ensures uninterrupted system operation even in the case of failure in one server utilizing other servers.
Load balancing
Basic Provision of system configuration with its portal site servers multiplexed over a set of plural server hardware systems, which enables to balance the load of access request to the site.
Performance Basic Provision of enough performance capacity that enables to process the amount of user access requests arriving at the portal site simultaneously.
5.10.3. Personalize function Functional Requirements 1 Basic Customize function: customizing capability to combine the required contents
information and applications, and to define/edit the screen layout depending on the user’s role in business operation.
2 Basic Personalize function: capability to change the set of information (selection of views and applications) in accordance with the attribute information of the logged on user.
5.10.4. Application integration function Functional Requirements 1 Basic Portlet collaboration: capability to link/integrate portlets – those within the
user’s server, as well as remote portlets that are openly released as Web services – to facilitate operating applications and contents placed on other servers.
2 Basic External connection: capability to link business systems, business applications, and databases that are connected to the network and operating within and outside of the common infrastructure.
3 Basic Web service collaboration: capability to perform linkage/integration operations on the screen of the portal site in coordination with the applications provided as a Web service.
Related technologies Directory service protocol LDAP (Lightweight Directory Access Protocol)
195
4 Basic Provision of functions to integrate the following types of groupware applications on the portal site screen. 1) Scheduling function 2) Meeting room, bulletin board 3) Electric mail 4) Workflow of routine tasks (attendance management, expense calculations, etc.) 5) Database searching 6) Document management
5 Additional Application collaboration: provision of a function to perform integration/linkage operations on the screen of the portal site in coordination with application package products (business intelligence (BI), customer relationship management (CRM), and enterprise resource planning (ERP)).
5.10.5. Management Functional Requirements 1 Basic User management: capability to manage (register/edit/delete) the user ID
and personal information of the users that have access authority to the portal site.
2 Basic Audit: capability to browse the access history (log) to the contents and applications within the portal site. The access history shall include such information as: date and time, information to identify the computer accessed, and the access result (success/failure).
3 Additional Single sign-on: Provision of a function to authenticate and authorize the user automatically, to access desired contents/applications with a single action (i.e. entry of user ID and password) done by the user when he/she tries to login to the portal site. This involves contents and application management in association with the user ID and password for user authentication and authorization.
Non-Functional Requirements (description provided only when relevant requirements given) Backup Additional Provision of a system configuration that enables backing up the
information contents and management data contained in the portal site.
Related technologies Web service related protocols SOAP
WSDL
196
5.11. Open Web Server
5.11.1. Definition The Open Web Server distributes information content through the Internet, and its primary use is
as a tool to disclose information to the general public as well as to enterprises. Because it operates
24 hours a day and 7 days a week embracing a variety of access from unspecified clients, it is under
constant threat from all sorts of possible malicious attacks (data tampering, denial of service,
information tapping, unauthorized promotion/denial of access authority, etc.). Therefore, measures
must be adopted to protect assets from those attacks, and to prevent security events/accidents from
occurring. These measures are implemented in a high-security segment with firewall isolation, or
DMZ (DeMilitarized Zone), which lies in between the external network (the Internet) and internal
network.
In light of possible IPv4 address depletion problem, previous considerations must be due for proper
coexistence and parallel usage of IPv4 and IPv6. This involves careful implementation of
operation/management/monitoring/maintenance methods, at the design stage as well as in the
purchase of equipment, and security measures for running various devices used on open Web server
devices.
Mail server
Communication within the Cabinet Office and Ministries
Internet
General user (citizens, enterprises)
Load balancer (load balancing
equipment)
DMZ
External f irewall
CMS equipmentInternal Proxy
serverInternal DNS server
Internal f irewall
Intranet
Mobile access server
Open DNS server
DMZ
Open Web server
External Proxy server
Figure 5.11-1 Open Web Server Configuration
197
Functions and services provided by the Open Web Server Function & Service Definition WWW service Refers to the contents distribution services utilizing HTTP
protocol - documents, images, and other data - conducive to information disclosure to the general public and enterprises.
FTP service Refers to the services utilizing FTP protocol that enables file transfer (upload and download) between the terminals located outside the ministries and the open Web server. The services shall be mainly used for distributing/uploading large size files, or frequently updated files.
Content management system (CMS)
The Content Management System (CMS) provides services such as production and management of Web-based digital content – released/distributed from the WWW services running on the open Web server – and performs distribution/review/maintenance services for the open Web server. CMS shall include functions that assume due considerations for compatibility with the internal control and accessibility.
-Assumed users/usages-Site (information distribution)
managerAllocation and authority settings of information
distribution
-Assumed users/usages-Server manager
Server management/audit-Assumed users/usages-
Internet connection usersWeb site browsing
File upload/download
WWW service
Operating system
Access log
Open Web server
Web browser
Operation management tool/audit toolGUI/CUI
WAF(Web Application Firewall)
FTP service
Load balancer (load balancing equipment)
FTP client
Figure 5.11-2 Schematic Overview of Open Web Server
198
5.11.2. WWW Service Functional requirements 1 Basic This function returns contents stored in the Web server responding to
requests from users (e.g. Web browser clients). It shall include such additional capabilities as: running server-side script language (SSI, etc.) embedded in the content to convert and send data (HTML, etc.), and running external programs on the server that dynamically format and send data (HTML, XML, images, etc.).
2 Basic User authentication/authorization: provision of a function to identify the user, when an access is made to an open site, and gives authentication accordingly – i.e. allows access to, and usage of the site only for those who already have been authorized, and denies access to others. It also shall be able to set the access range and operation limit for each user within the open Web site, and to grant authorization accordingly. Additionally, the authentication/authorization procedures shall be capable of performing in coordination with external directory services.
3 Basic WAF (Web application firewall): Provision of the capability to detect improper data indicative of malicious attacks (such as SQL injection and cross-site scripting) and block these accesses, which requires rigorous inspection of transmitted/received information to/from the applications and Web pages on the open Web site.
4 Additional Server certificate and path encryption: Provision of a function to install a server certificate (server’s open key and server information), and to encrypt transfer data using SSL protocol. The encryption method shall have encryption strength compatible with those code languages listed in the e-Government recommendations.
5 Basic File format management for delivery: Capability to define a set of file formats for use in file delivery from a Web site, and inhibit those that are not included in that set from being used in file transfer.
6 Basic Allocation of delivery file: Capability given to the Web administrator to allocate contents and set access authority for delivering information through the intra-net and open Web site, and execute quick check/test on the latest update information of the contents.
7 Basic Access log record: Capability to record an access log for the accumulation of access history files (who, when, what, and the last access to the information, etc.). The log information shall be recorded in a way that allows selection/specification of type and order of information to meet the requirements of HTTP communication, and should be capable of outputting in either W3C extended log file format or NCSA common log file format.
8 Additional Audit: Capability to compile an auditing report from the stored stock of access logs in different perspectives (for each audit event, for different time windows, for each user,…).
199
9 Additional Efficiency measurement: Provision of the capability to measure the work load on a WWW site (number of concurrent connections, average request frequency, etc.), processing efficiency (HTTP process throughput, response time, etc.), and resource usage status (CPU utilization ratio, etc.).
10 Basic Session management: Provision of a function to issue a session ID needed for the Web application to perform safe session management, and to maintain the session information.
11 Basic Management interface: Provision of GUI (Graphical User Interface) or CUI (Character-based User Interface) tools to help perform various management operations (add/edit/delete a user account, setting of site authority, setting of file types for delivery, auditing, performance monitoring, etc.) from the management terminal installed in the internal network. Provision of a set of API‘s (Application Program Interface), used to invoke management tasks for programs, is also required.
200
Non-functional Requirements (description provided only when relevant requirements are given) Performance Basic Provision of sufficient processing capacity - in terms of the number
of concurrent connections, SPECweb value, etc. - to meet the client’s (mainly Web browser) requirements.
Availability Basic Provision of a system configuration (clustering, etc.) that enables continued processing of subsequent request even after a failure in server hardware or middleware.
Upgradability of processing performance
Basic Capability to secure sufficient processing capacity – through increasing/decreasing server resources, and additional installation or removal of servers – to meet the changing load requirements (number of concurrent connections, increasing/decreasing number of accesses) without needing to stop services.
Upgradability of SSL performance
Basic Provision of a system configuration that enables the addition of performance enhancement mechanisms for SSL protocol (for higher encryption and decoding performance, e.g. SSL accelerator).
Regular delivery of security patch information to middleware and OS
Basic Delivery of vulnerability and security patch information to the server administrator regularly (for example, once a month). This service shall be included in the information delivery target software provided by the information security service vendor, and may require affiliation to some kind of information delivery service.
Application of security patch to middleware and OS
Basic Capability to perform the following procedures: application, test and verification, and situation-dependent cancelling (deletion) of security patches to the operating system and middleware distributed by Web page.
Service delivery time zone
Basic Capability of service delivery on a “24 hours a day / 7 days a week” basis.
Backup, restoration
Basic Capability to backup data on the open Web site (distributed contents and server configuration information) without needing to stop Web site operations, and to restore the site quickly using the backup data.
Remote management
Basic Provision of a system configuration that enables the performing of management tasks targeted at an open Web site from the administrator terminal implemented in the internal network.
Load balancing Basic Provision of a load balancing function (a device) implemented on the front side of the open Web server, and the capability to realize a load-balanceable configuration using it.
201
Related technology Web server's client-to-client (Web browser)communication protocol
HTTP (Hyper Text Transfer Protocol)
Web page description language HTML (Hyper Text Markup Language) This markup language has been standardized as HTML 4.01specifications (W3C recommendation, 24 Dec.1999).
CSS (Cascading Style Sheets) This style sheet has been standardized as CSS2.1 specifications (W3C recommendation, 9 Sep. 2009).
Technology to run external program on the server
CGI (Common Gateway Interface) CGI has been standardized as RFC3875.
Java Servlet ASP.NET (Active Server Pages for .NET)
Server-side script language SSI (Server Side Include) PHP (Hypertext Preprocessor) JSP (Java Server Pages)
Unit for Web processing efficiency measurement
SPECweb
Authentication scheme Basic Authorization Digest Authorization
Directory service protocol LDAP (Lightweight Directory Access Protocol) Path encryption protocol SSL(Secure Socket Layer) Standard for sending/receiving various types of files as e-mail, or using HTML protocol
MIME(Multipurpose Internet Mail Extension)
Log file format W3C extended log file format NCSA common log file format
Monitoring, Control Mechanism/Protocol
SNMP (Simple Network Management Protocol) WBEM (Web-Based Enterprise Management)
202
5.11.3. FTP Service Functional requirements 1 Basic Capability to provide server-side file transmission/reception services for file
transfer practice between the client PC and the open Web server. 2 Basic User authentication/authorization: Provision of a mechanism to identify the
user, and authorize/deny the user the ability to perform specified operations and access to the targeted files and folders based on the authority given to him/her. These authentication/authorization procedures shall be capable of performing in liaison with the OS’s access control functions and external directory services.
3 Basic Transmission/reception data encryption: The encryption method shall have the encryption strength compatible with those methods listed in the e-Government recommendations.
4 Basic User separation: Capability to separate the area (folder) for uploading/downloading on an user-by-user basis, and isolate it from those used by other users. Capability to create a user folder in accordance with the structure specified, and to define the folder capacity and maximum file size allowed for transfer on a user-by-user basis.
5 Basic Access log record: Capability to record and accumulate operation history as a series of log files (who, when, what, and the types of operation). The log information shall be recorded in the way that allows for the selection/specification of the type and order of information to meet the requirements of FTP communication, and should be capable of outputting in either W3C extended log file format or NCSA common log file format.
6 Basic Audit: Capability to compile an report serviceable for auditing from the stored stock of usage status logs in different perspectives (for each audit event, for different time windows, for each access user,…).
7 Basic Client access: Capability to access an FTP site from a client PC utilizing a Web browser or CUI (Character-based User Interface).
8 Additional Efficiency measurement: Provision of a capability to measure processing requests (number of concurrent connections, etc.), processing efficiency (transfer rate, etc.), and resource usage status (CPU utilization ratio, waiting status of I/O queue, etc.).
9 Basic Management interface: Provision of methods to perform various management operations - add/edit/delete a user account, setting of site authority, setting of file types for delivery, auditing, performance monitoring, etc. - from the management terminal located on the internal network. If the management method involves the use of a GUI (Graphical User Interface) or CUI (Character-based User Interface), a set of APIs ((Application Program Interface) shall be provided for the programs to access management tasks.
203
Non-functional Requirements (description provided only when relevant requirements are given) Performance Basic Provision of sufficient performance capacity to the process
uploading/downloading load of files (number of concurrent connections, data transfer capability, etc.).
Data storage capacity
Basic Provision of sufficient disk area capacity for the secure storage of uploaded/downloaded files.
Availability Basic Provision of a system configuration that allows for continuous normal processing of subsequent requests by surviving servers even after a failure in a single server hardware, OS, and middleware.
Expansibility of disk area
Basic Capability to expand free space for storage of uploaded/downloaded files within a given period of time (this may be required when capacity shortage is imminent).
Upgradability of processing performance
Basic Capability to secure sufficient processing capacity – through increasing/decreasing server resources, and additional installation or removal of servers – to meet the changing load requirements (number of concurrent connections, increasing/decreasing number of data transfer requests) without needing to stop services.
Regular delivery of security patch information to middleware and OS
Basic Delivery of vulnerability and security patch information to the server administrator regularly (for example, once a month). This service shall be included in the information delivery target software provided by the information security service vendor, and may require affiliation to some kind of information delivery service.
Application of security patch to middleware and OS
Basic Capability to perform the following procedures: application, test and verification, and situation-dependent cancelling (deletion) of security patches to the operating system and FTP service middleware.
Service delivery time zone
Basic Capability of delivery on a “24 hours a day / 7 days a week” basis.
Backup, restoration
Basic Capability to backup data on the file storage area of an FTP site without needing to stop services, and to restore the site quickly using backup data.
Remote management
Basic Provision of a system configuration that enables the performing of management tasks targeted at an open FTP site from the administrator terminal implemented in the internal network.
Load balancing Additional Provision of a system configuration that enables balancing of file transfer load among the servers: i.e. capability to construct an FTP site by combining multiple servers and allocating a larger load to the server with the minimum track record in terms of the volume of data communication.
204
Related technology File transfer protocol FTP (File Transfer Protocol) Directory service protocol LDAP (Lightweight Directory Access Protocol) Data encryption protocol in file transfer
FTPS (File Transfer Protocol over SSL/TLS) SFTP (Secure File Transfer Protocol)
Log file format W3C extended log file format NCSA common log file format
Monitoring, control mechanism/protocol
SNMP (Simple Network Management Protocol) WBEM (Web-Based Enterprise Management)
205
5.11.4. Content Management System (CMS) Functional requirements 1 Additional Capability to utilize/include content from existing Web sites in an content
production effort. 2 Additional Capability to search and list various contents (text, images, etc.) for
browsing/referencing to facilitate content production. 3 Additional Capability to easily produce and control contents, that have standardized and
unified page design for controlled accessibility throughout the site, by utilizing templates (such as Web page prototypes).
4 Basic Capability to update contents by editing HTML files. 5 Additional Capability to handle various data formats (PDF, Flash, text, Microsoft Office
documents, etc.) for content files. 6 Additional Provision of an authority management function (including authentication and
authorization) to assign to specified users or to user groups, the authority to operate on contents. The authentication and authorization functions shall operate in conjunction with other directory services.
7 Basic Capability to register pre-release content files on the Web page, enabling the ability to preview the expected image after release.
8 Additional Provision of a function to automatically carry forward the approval and release process for new content, or a workflow that promotes this process.
9 Additional Provision of a function to automatically release a new content on the open Web server on the scheduled day (the content and release schedule must be defined in advance).
10 Additional Capability to perform such operations as: reference to revision history of content, review older images of content, and rewind the display back to one of the older versions.
11 Additional Capability to browse past actions done by the persons in charge of production/maintenance/presentation of content (who, when, and which operation).
12 Additional Capability to deliver update information for a Web page using one of the update information distribution technologies (RSS feed, ATOM feed, etc.).
Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Capability to continue content delivery using WWW services
even in the event of CMS stoppage. Backup, restoration
Additional Capability to save backup copies of Web contents even while they are under production or in the process of being delivered. A function shall be provided to rewind the Web content to an older state by restoring from the backup.
Related technology Web accessibility criteria JIS X 8341-3
W3C WCAG (Web Content Accessibility Guidelines) 1.0/2.0 Directory service protocol LDAP (Lightweight Directory Access Protocol)
206
5.12. Groupware, File Server, and Mail Server
5.12.1. Definition of groupware, file server, and mail Server
The groupware, file server, and mail server are accepted as productivity enhancing mechanisms
for organizations as they realize sharing and exchange information among the information system
users. These mechanisms provide such facilities as electronic mail, electronic bulletin board,
electronic conference room, scheduling, conference room booking, and file sharing. The objective of
these facilities is to achieve smoother communication among the users, and thus support information
sharing for well-informed policy planning.
Figure 5.12-1 Functions and services provided by groupware, file server, and mail server
The groupware, file server, and mail server typically provide the following six functions/services.
1) Groupware
2) Electronic mail
3) File sharing
4) Instant messaging
5) Full-text search
6) Web conference
207
Functions and services provided by groupware, file server, and mail server
Function & Service Definition Groupware Groupware provides facilities for information sharing among
users, and thus contributes to achieving smoother communication. The users can exchange their opinions and information using the electronic bulletin board and electronic conference. Such functions as user schedule management, facility management (e.g. conference room), and To-Do list contribute to enhance routine task efficiency for the users. The groupware also provides functions for managing attribute information (e.g. user ID assigned to each user, and the group he/she belongs), allowing it to be used as an employee directory.
Electronic mail Electronic mail provides the users with the means to send/receive an e-mail within the ministry or with external organizations. Standardized protocol for sending and receiving mails is employed, and communication requests from the terminals shall be compatible with SMTP (for transmission) and POP, IMAP (for reception). In light of the need to exchange highly confidential e-mails, this function shall be compatible with encryption and electronic signature. To avoid virus infection via e-mail communication, it shall perform anti-virus functions by checking attached files. Note that the e-mail communication may be provided as a function of groupware.
File sharing Refers to the practice of shared use of storage resources among the terminals, making cross-user information sharing easier and quicker. This mechanism includes the shared use of storage areas under the control of file server, enabling file sharing according to the user’s affiliation and authority. Rigorous access control shall be implemented in the file sharing mechanism, and access history shall be recorded in the audit log.
Instant messaging Refers to the provision of a real-time message exchange function, whereby the usage status of the users is checked in advance. This function shall not only be able to identify if the user is on-line or off-line, it provides further on-line status information (i.e. enabled/disabled to respond, at/away-from-desk, at conference, etc.), enabling to select the contact method most suited to the situation (telephone/e-mail, instant messaging).
Full-text search Refers to the functions to search for a given string among the document database provided by groupware and the stock of document files stored on the file server. The user shall be able to use combined criteria – single of multiple keyword, and logical conditions connecting them (AND, OR, etc.) – and only
208
the allowed range of the search results shall be presented to the user depending on his authority level.
Web conference Refers to the functions that allow a plurality of users on the network to have a conference, sharing a common screen and using voice/video communication. It also provides functions to share office documents, and shared use of a virtual whiteboard to which the conference participants are able to write sentences and figures. A Web interface is also provided for booking and managing a Web conference.
209
5.12.2. Functional/Non-Functional Requirements and Standard Technology of Groupware Functional requirements 1 Basic Capability of the user to register/modify/delete the documents posted to
electronic bulletin board. 2 Basic Capability to add a link to the posed document (link to a file, table, image,
document, etc.). 3 Basic Capability to classify the posted documents based on the information
displayed on the document list screen – for each author, for each category, etc. Capability to perform search among the posted documents based on “keywords or other information.”
4 Basic Capability given to the system administrator to define the users with authority to access the bulletin board, and restrict the range of their usage authority.
5 Basic Capability given to the system administrator to delete a document from electronic bulletin board if the document is considered inadequate for public view.
6 Basic Provision of functions to support electronic conferences, where multiple users can post/exchange their opinions on a specific theme.
7 Basic Provision of functions to create multiple electronic conference rooms for each discussion theme, and users’ opinion (posting) shall be recorded as electronic data.
8 Additional Capability to display the series of postings on a specific theme in a hierarchical structure for easy viewing as a single thread.
9 Basic Capability of schedule management on a user-by-user basis. Capability to define and manage the range of users whose schedules will be put on view for others.
10 Basic Capability to browse schedules of multiple of users that belong to the same organization/group, and to search their vacant times.
11 Basic Capability to register repetitive schedules (weekly, monthly, …), with an authority to accept/reject the request for schedule registration.
12 Additional Capability to identify an overlapped portion of a schedule (if any) by means of a symbol or marking.
13 Basic Capability given to the user to refer to the booking status of facilities (e.g. conference room).
14 Basic Capability given to the administrator to manage registration/update/deletion of facilities. The administrator shall be able to assign access authority on facility-by-facility basis.
15 Basic When a user tries to reserve a conference room, he/she shall be able to search for a vacant time zone for the room. The user shall also be able to search for an available room at a specified time window.
16 Basic In synchronization with the booking of a conference room, a notification message shall be sent to those involved by e-mail or other means.
17 Basic Capability to manage To-Do lists created by users. 18 Basic Capability to manage the progress status of tasks (work) registered in the
To-Do list, which necessitates the capability to assign the start date, terminal date, and priority information for each task.
210
19 Basic Provision of an electronic telephone directory function as well as the directory for the centralized management of the users. Search capability - based on such information as the name, affiliation, telephone number, mail address, etc. - shall be provided as well.
20 Basic Authentication of a user, when he/she tries to use groupware, shall be performed using the user ID and password assigned to each user.
21 Basic Provision of a graphical user interface (GUI) for easy access for users. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced
availability, by employing such technologies as redundant servers, clustered software, and replication.
Security Basic Capability to exercise rigorous control on each of the functions provided by groupware - e.g. electronic bulletin board, electronic conference room, schedule, facility booking, To-Do list, and electronic telephone directory.
Additional Capability to encrypt communication to ensure security. Performance Basic The system design shall assume {approximately 50 thousand}
users, and the system configuration shall provide sufficient processing capacity to meet the stated performance requirements.
Extendability Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades.
Backup Basic Capability to save backup copies of contents created by the user (posting, schedule, booking, tasks, etc.) along with the configuration information.
Related technology Directory service protocol
LDAP (Lightweight Directory Access Protocol) is a standard protocol used for connection with the directory service. LDAP V3 has been established.
Directory exchange format
LDIF (LDAP Data Interchange Format) defines the file formats used to exchange LDAP account information.
Supplementary note: Groupware, in the broad sense of the term, may include such functions as
electronic mail, instant messaging, and Web conferencing. An appropriate specification description
shall be adopted in view of the purchase range.
211
5.12.3. Functional/Non-Functional Requirements and Standard Technology of Electronic Mail Functional requirements 1 Basic Provision of a web mailing function, and the capability to create, transmit,
and receive mails from electronic mail clients. Requests from electronic mail clients shall conform with SMTP (transmission) and POP, IMAP (reception). Web mail shall conform with HTTP/HTTPS.
2 Basic Mail format shall support an HTML format as well as a simple text format. 3 Basic Functions to sort the mails – based on such criteria as destination and
content - shall be provided. The folders used to sort the mail shall be allowed to have a hierarchical structure, enabling easy search by specifying conditions.
4 Basic Provision of an automatic sorting function to given folders based on such information as the sender and the keyword included in the subject. The user shall be able to assign multiple addresses and keywords for sorting mail.
5 Basic The address book shall provide functions compatible with Japanese names and Japanese organization names.
6 Basic Capability to encrypt the body text of a mail and attached files for exchange of
e-mails with a high level of confidentiality. Provision of functions for sender
authentication, and to give/check an electronic signature. The encryption
method and electronic signature shall be compatible with S/MIME. 7 Additional Capability to send a notice of absence to the sender if the receiver is absent. 8 Basic Electronic mail clients shall have the capability to read and create a mail
even when the network is offline. 9 Additional Provision of the mechanism given to the electronic mail clients to avoid
erroneous transfer and diverted use of the mail (through copy & paste and printing).
10 Basic Capability to restrict the size of mail boxes provided to the users. 11 Basic Provision of functions to link with groupware’s schedule management and
facility booking functions (e.g. automatic mail transmission to members when a schedule is registered).
12 Additional Provision of an option to confirm if the mail has been read. 13 Additional Capability to perform a virus check of the files attached to a mail on the mail
server using anti-virus software. For encrypted mails – as it is difficult to for check viruses on the mail server – methods shall be provided to run virus checking on other locations (e.g. terminal).
14 Additional Capability to save archived mails for auditing: this is a measure to avoid unauthorized use of mails and information leaks.
15 Additional Provision of settings that prevent external leakage of ministerial physical information to the outside world (e.g. the IP address of ministry mail server may be leaked by being attached to a mail header).
212
16 Additional The request to send from electronic mail clients shall be authenticated and compatible with SMTP over SSL/TLS, and the request to receive shall be compatible with POP over SSL/TLS, or IMAP over SSL/TLS.
Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced
availability by employing such technologies as redundant servers, clustered software, and replication.
Security Additional Capability to verify electronic mails using sender domain authentication to detect malicious mails (avoidance of tampering and spoofing of electronic mails).
Additional Provision of mechanisms to prevent erroneous mail transmission: for example, placement of a wait before mail delivery and cancels sending if an error in the destination description is found.
Additional Provision of a mechanism to send only the mails authorized by the approver: this applies when handling highly confidential mails.
Performance Basic The system design shall assume {approximately 50 thousand} users. Performance specifications shall be made clear in advance, for creation of the system with sufficient processing capacity.
Additional The size of the mail box per user shall be at least {100MB}. Extendability Additional In view of a possible increase in the number of users, the system
configuration shall assume enough flexibility to allow future performance upgrades.
Backup Basic Capability to store backups of mails transmitted and received by the user, as well as the setting information.
Related technology Mail transmission protocol
SMTP (Simple Mail Transfer Protocol) is a standard protocol used to send an electronic mail. It is used when a user sends an electronic mail to the mail server, and the electronic mail is transferred between mail servers.
Mail reception protocol
POP3 (Post Office Protocol) is a protocol used to receive a mail from the server where electronic mails are stored. It is used when a user tries to receive an electronic mail from the mail server. The mails are stored and managed on a terminal. IMAP4 (Internet Message Access Protocol) is a protocol used to receive a mail from the server where electronic mails are stored. It is used when a user tries to receive an electronic mail from the mail server. The mails are stored and managed on the mail server.
Mail encryption method
S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard method used to encrypt an electronic mail, and to create an electronic signature. It is utilized by the user to encrypt an electronic mail and create an electronic signature.
Supplementary note: In terms of the effective use of electronic mails, the configuration of the
mechanism to be procured may differ from case to case: for example, intra-ministerial mail exchange
and external communication – with external organizations, and mail exchange via the Internet – may
213
require different configurations (e.g. implementation of a mail gateway). Therefore, the procurement
planning requires clear specifications regarding the range of the mail exchange (within the ministry,
with external organizations, or via the Internet).
(Example)
[In this procurement, the scope of mail exchange is intended only for intra-ministerial
communications.]
[In this procurement, the scope of mail exchange includes, not only within the ministry, but also
extra-ministerial mail traffic with other ministries and local governments via the Kasumigaseki WAN
and the LGWAN.]
[In this procurement, the scope of mail exchange includes traffic with private sectors via the Internet,
as well as within the ministry and with other ministries.]
214
5.12.4. Functional/Non-Functional Requirements and Standard Technology of File Sharing Functional requirements 1 Basic Provision of file sharing functions among the users. 2 Basic OS standard file management software and Web browser shall be given an
access capability to shared resources. 3 Basic Capability to control access by setting graded access privileges to the users
depending on the user’s authority. The access control shall have the authority to manage creation, reference, modification, and deletion of files and folders.
4 Basic Capability to record an access log to the shared resources, and output information for the analysis of unauthorized accesses.
5 Basic Capability to encrypt data to be stored on the file server. 6 Basic Capability to create a backup on a regular basis: required for easy
restoration in case of data loss by user’s inadvertent operation. 7 Basic Capability to limit available disk capacity for each user, and for each shared
drive (management of the used space of disks). 8 Additional Capability to perform a full-text search on all the files stored in the file server. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of system configuration that provides enhanced
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 Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity.
Additional Capability to process accesses from {300 terminals} simultaneously.
Additional The file server shall have an effective capacity equal to, or larger than {100 TB}.
Extendability Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion.
Backup Basic Capability to save backup copies of data on the shared disks, along with the configuration information.
215
Related technology File sharing protocol
CIFS (Common Internet File System) is a standard protocol used to share files on a TCP/IP network.
216
5.12.5. Functional/Non-Functional Requirements and Standard Technology of Instant Messaging Functional requirements 1 Basic Provision of a real-time message exchange mechanism, whereby the usage
status of the users on the terminal are checked in advance. 2 Basic Capability to manage users by grouping: a contact list (persons on the end of
line) specific to each user shall be compiled for message exchange. 3 Basic Capability to display if the persons on the contact list are present or absent by
online/offline identification. 4 Basic The status indicators used to show that the person is on-line shall be
user-selectable: “ready to respond,” “unable to respond,” “absent from the desk,” and “at conference,” etc.
5 Basic Capability to display user’s attribute information (telephone number, mail address, etc) as well as his presence/absence status.
6 Basic Capability to save the message exchange history (sorted on person-by-person basis on the other end of the line).
7 Basic Capability to exchange messages among three or more users, as well as conduct one-to-one communication.
8 Basic Capability to automatically change, even while in the “on-line” state, the status indicator to “absent from desk” if the user does not operate the terminal longer than a given period of time.
9 Basic This function shall be able to exchange files using the same mechanism as the message exchange, without the need to attach the file to a mail.
10 Basic Authentication of a user, when trying to use instant messaging, shall be performed using the user ID and password assigned to each user.
11 Basic Provision of a graphical user interface (GUI) for easy access for the users. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of system configuration that provides enhanced
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.
217
5.12.6. Functional/Non-Functional Requirements and Standard Technology of Full-Text Search Functional requirements 1 Basic Capability to search for contents within the Cabinet Office and Ministries that
contain the keyword entered by the user. The user shall be able to specify a combined search criteria – single or multiple keywords, and logical conditions connecting them (AND, OR, etc.).
2 Basic Capability to restrict the scope of a user’s search: a user shall be allowed to search only the contents within the Cabinet Office and Ministries on which he/she has the access authority.
3 Basic The targets of search shall include: documents created by office applications installed on the server (word processors, spread sheets, presentation tools, and others), document database for groupware (postings on electronic bulletin board, etc.), and XML/HTL files on Web sites.
4 Basic Capability to limit or select the scope of target information – e.g. only the data stored on the file server.
5 Basic Capability to perform synonym search (search using a word similar to the keyword given). Data shall be provided for synonym search, and the dictionary shall be maintained by the administrator.
6 Basic Capability to display the search result information as a list, and the user can select an information item from the list for display and then save the relevant information.
7 Additional Capability to collect data that may be used as target information for searching, by accessing the file servers, groupware, and Web site within the Cabinet Office and Ministries on a regular basis.
8 Additional Capability to extract texts for analysis from the collected resources such as text/HTML/XML files and documents created by office applications.
9 Additional Capability to compile a search information index based on the results of analysis, which can accelerate searching.
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.
Additional Provision of a tolerance against the attacks from the users that threaten security (e.g. SQL injection).
Performance Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity.
218
Extendability Additional In view of possible the increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion.
Backup Basic Capability to save backup copies of data (index, etc.) along with the configuration information.
219
5.12.7. Functional/Non-Functional Requirements and Standard Technology for Web conference Functional requirements 1 Basic Capability given to multiple of participants on the network to have a Web
conference sharing a common screen on the browser. 2 Additional Capability to have voice conversations and video conferences through the
use of microphones, speakers, and Web cameras available on the terminal. 3 Basic Capability to confirm, on the screen, the list of the users participating in the
Web conference. 4 Basic Capability given to all participants to share the terminal screen designated by
the presenter. 5 Basic The mode of screen sharing shall allow selections depending on the
presenter’s convenience – full-screen sharing and partial screen sharing (i.e. only the screen of a specific application is shared).
6 Basic Provision of a virtual whiteboard to which any of the participants can freely write characters and figures: it is shared by the participants to help develop a discussion.
7 Basic Provision of a mechanism to book Web conferences from the browser, and send an electronic notification mail to the user who will chair the conference.
8 Basic Provision of a function to define a password required to log on to the conference. The user shall be able to define it when booking the Web conference, as well as the conference name, date and time, and the number of participants.
9 Basic Capability to book a series of repetitive Web conferences at one time, on an “every day,” “every week,” “every month,” and “every year” basis.
10 Basic Provision of a function to display the lists of Web conferences for easy reference: on-going Web conferences, those that have already closed, and those reserved.
11 Basic Capability, given to the user who will chair a conference, to see the list of his Web conferences and detailed information thereof.
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
220
sufficient capacity.
Additional The system shall assume that {approximately 500 users} will participate in a Web conference simultaneously.
Extendability Additional In view of the possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion.
Backup Basic Capability to save backup copies of information related to the Web conference (configuration information and others).
Related technology Distributed file system protocol
WebDAV (Web-based Distributed Authoring and Versioning) – a file management protocol (an extended version of HTTP) for use in a Web-based distributed file system. IETF RFC 2518.
221
5.13. Integrated Account Management, Authentication, Authorization (Access Control)
5.13.1. Definition of Integrated Account Management, Authentication, Authorization (Access Control)
Integrated Account Management, Authentication, and Authorization (Access Control) provides a
mechanism to manage information system users in an integrated and uniform fashion. It confirms the
identity of a user (to authenticate him with his ID), and controls his/her access to resources according
to the level of authority given to him/her.
Figure 5.13-1 Functions and services provided by Integrated Account Management,
Authentication, Authorization (Access Control)
Integrated Account Management, Authentication, and Authorization (Access Control) typically
provides the following five functions/services.
1) Integrated account management
222
2) Directory linkage
3) Web single sign-on
4) Desktop single sign-on
5) OS access control
These functions and services constitute a mechanism to manage account information in an
integrated fashion, and realize a single sign-on environment that contributes to the enhanced
convenience for users. The integrated directory information may further find its applications in the
electronic telephone directory within the organization, a shared address book for the mail system, and
a destination address search for instant messaging.
Functions and services provided by Integrated Account Management, Authentication, Authorization (Access Control) Function & Service Definition Integrated account management
Refers to the provision of functions to manage user authentication information (user ID, password) and attribute information (group, affiliation) in an integrated fashion. The account information, under integrated control, is provided – automatically or manually - to the related systems and directories based on the pre-defined policies (provisioning function). It also provides a workflow function that supports various management tasks (i.e. tasks related to account management).
Directory linkage In an environment where account information is stored in multiple of directories in different formats (RDB, LDAP, CSV file), a Directory Linkage realizes coordination among these directories by providing connector functions (used for connection with various directories and databases) and through attribute conversion (data conversion/mapping).
Web single sign-on Refers to the provision of methods to manage the authentication process of multiple Web applications and access control in an integrated fashion, thus realizes single sign-on. The user has to only log in to the Web once with a single sign-on: this enables the user to utilize all the accessible Web applications without the need to log in to each, one by one. It also provides functions such as: access history log to Web applications, generation of re-authentication request when a time-out occurs.
Desktop single sign-on Refers to the functions that enable the user to log in to various applications – the OS running on the terminal, groupware, Web applications, and C/S type applications – by performing a single log in procedure (i.e. single sign-on). The user only has to log in to the desktop once through a single sign-on: this enables the user to utilize all the accessible applications that run on the terminal without the need to log in to each, one by one.
223
OS access control Refer to the functions to execute access control procedures over the OS resources (files, network, user, etc.) in accordance with the pre-defined access control policies. The access control policies are managed in an integrated fashion, and are applied collectively to each of the systems to be managed. It also collects and stores access history information - when, who, to what resource, and success/failure – as an audit log. The access control policies may be applied, as well as to the ordinary users, to those with privileges (so called administrator users) in accordance with this type of work.
224
5.13.2. Functional/Non-Functional Requirements and Standard Technology of Integrated Account Management Functional requirements 1 Basic Provision of a function to register/modify/delete account information in an
integrated fashion. 2 Basic Capability to automate the life cycle management of account information by
utilizing pre-defined policies to register/modify/delete account information. 3 Basic Provision of a mechanism to automatically provide the changes in one
system (user registration, attribute etc.) to the systems in destination address (provisioning function), whereby the changes are provided based on the defined policies.
4 Basic Capability to restrict the scope of available user IDs based on given restrictions (e.g. naming rules, period of validity, etc.). In terms of passwords, this function shall also place restrictions on the length of the string, types of characters, and period of validity.
5 Basic Provision of a mechanism to apply proposed changes in account information (registration, modification, deletion, etc.) to various OSs and directories after obtaining approvals through the workflow.
6 Basic Capability to place usage control on a user’s ID: suspension (deactivation) and resumption (activation).
7 Basic The user shall be authorized to change or reset his own password (self-care).
8 Basic Essential operations – addition, modification, deletion in account information and policy – shall be recorded in the audit log.
9 Additional Capability to display the content of audit logs in an easy-to-read report format.
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.
225
Extendability Additional As the targeted system expands and the user population grows, the number of accounts is also expected to increase. The system configuration shall assume enough flexibility to allow future performance upgrades.
Backup Basic Capability to save backup copies of account information and policies.
Related technology Directory service access protocol
LDAP (Lightweight Directory Access Protocol) – a standard protocol used to connect to directory services. LDAP V3 has been established.
Directory service interchange format
LDIF (LDAP Data Interchange Format) – a file format used to exchange LDAP’s account information.
Provisioning information exchange language
SPML (Service Provisioning Markup Language) – a standard protocol used for ID provisioning. SPML V2 has been established.
- 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
226
5.13.3. Functional/Non-Functional Requirements and Standard Technology of Directory Linkage Functional requirements 1 Basic Provision of a function to coordinate multiple directories for synchronizing the
account information in these directories. 2 Basic Provision of a connector (data communication) function. This function shall
enable the delivering of account information to dissimilar distributed directories (RDB, LDAP, CSV file, etc.).
3 Basic Provision of a matching engine function (data conversion/matching). This function shall be able to perform data type conversion/matching at the time of account information delivery, so that the account information becomes compatible with the destination directory environment.
4 Basic Provision of tools (GUI, SDK, etc.) used to configure data conversion/mapping operations.
5 Basic Capability to incorporate logical operations freely while data is being processed – for example, combining and processing data obtained from different directories.
6 Basic Provision of a mechanism to synchronize the passwords stored in an integrated directory.
7 Basic Provision of a mechanism to check the validity of account information stored in a directory (discrepancies, addition of unauthorized account, etc.).
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 service access protocol
LDAP (Lightweight Directory Access Protocol) – a standard protocol used to connect to directory services. LDAP V3 has been established.
Database connection API
JDBC (Java Database Connectivity) – a set of APIs used by Java programs to access RDB. Use of these APIs is assumed in case the directory is RDB.
227
- 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
228
5.13.4. Functional/Non-Functional Requirements and Standard Technology of Web Single Sign-on Functional requirements 1 Basic Provision of two control functions targeted at Web applications:
authentication using the specified authentication schemes (user ID, password, etc.), and a URL-based access control function.
2 Basic Capability given to the user that, once the user logs in to the system, he/she can utilize all the accessible Web applications without the need to log in to each, one by one (single sign-on).
3 Basic Centralized management of access control policies, enabling application to multiple authentication proxies and agents simultaneously.
4 Basic Provision of a mechanism to transfer the account information of the logged-in users (user ID, affiliation, etc.) to Web applications.
5 Basic Capability to lock (disable) an account automatically if it failed log-in procedures repeatedly more than the specified number of times.
6 Basic Capability to create and accumulate audit logs from account authentication history.
7 Additional Capability to combine the authentication mechanism with other powerful methods such as token authentication (one-time password), IC card authentication, and biometric authentication.
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 Basic The system assumes {approximately 50 thousand} accounts. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity.
Extendability Additional In view of a possible increase in the number of Web applications and users, the system configuration shall assume enough flexibility to allow future performance upgrades.
Backup Basic Capability to save backup copies of settings information (of access control policies, etc.) and audit logs.
Related technology Directory service access protocol
LDAP (Lightweight Directory Access Protocol) – a standard protocol used to connect to directory services.
- 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
229
- The content of this section corresponds to the following segments in the physical configuration
model: S1 - S6
230
5.13.5. Functional/Non-Functional Requirements and Standard Technology of Desktop Single Sign-on Functional requirements 1 Basic Provision of an agent running on the terminal whose function is to perform,
by executing user authentication steps in place of the user, to automatically log in to various applications – Web applications, groupware, C/S type applications – thus, realizing a single sign-on.
2 Basic The user shall be able to utilize all available applications on the terminal by only performing a log on to the desktop one time, saving the time and effort of logging in to each application. A single sign-on shall be realized through the adoption of applications that run in conjunction with the log-on authentication on desktop OS, or through the action of an agent that automatically enters authentication information, which matches the information (user ID, password) pre-registered to the relevant application.
3 Basic The system administrator shall be able to manage all the single sign-on applications in an integrated fashion, along with the automatically entered user IDs and passwords. Terminal settings shall also be managed in an integrated fashion.
4 Additional In view of the possibility that the user has lost the log in password for the desktop agent for single sign-on, the system shall provide a function to cope with this situation (e.g. password reminder function).
5 Additional Capability to combine the authentication mechanism with other powerful methods such as token authentication (one-time password), IC card authentication, and biometric authentication.
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
231
5.13.6. Functional/Non-Functional Requirements and Standard Technology of OS Access Control
This section describes only the aspects of access control - functional and non-functional
requirements - directly linked to the OS. With the advancement of Internet technologies in recent
years, several mechanisms for access control and authority management, that are not limited in their
scope to one OS, have been standardized (e.g. RBAC, XACML) as a part of identity management.
These OS-independent schemes distribute information regarding access control to resources in
accordance with the pre-defined access control policies. The access control policies are managed in
an integrated fashion, and provide functions for auditing (creation/modification/deletion) and life cycle
management. Access control allows both role-based and rule-based definitions, and enables
incorporation of independent logic.
Functional requirements 1 Basic Capability to monitor accesses to OS resources (files, network, users, etc.),
and allow only those accesses permitted by the pre-defined access control policy.
2 Basic Capability to apply access control – access to system operations, files, and programs - even to those account with OS administrator authority.
3 Basic Capability to manage the access control policies in an integrated fashion, and apply them to multiple targeted servers.
4 Basic Capability to detect and block tampering attempts to critical data and programs.
5 Basic Capability to give notice to the monitoring console at the time when a policy violation is detected (e.g. unauthorized access).
6 Additional Audit log that records accesses to OS resources (files, network, users, etc.) shall include such information as: date and time, user name, resource name, details of access and results.
7 Additional Capability to analyze a policy violation event, such as an unauthorized access, if such an instance is detected. The analysis shall be based on the information recorded in the audit log (date and time of unauthorized access, user name, resource name, details of access and its results, etc.).
8 Basic Provision of a mechanism to collect audit logs gathered by the managed servers, and manage and store them in an integrated fashion.
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.
232
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 systems and users, the system configuration shall assume enough flexibility to allow future upgrades of process performance.
Backup Basic Setting information (e.g. access control policy) and audit log shall be backed up.
Related technology Access control
RBAC (Role Based Access Control) – a role-based approach to implement access control. The administrator achieves proper authority allocation by managing the role assignment of users or groups (UA: User Role Assignment) and permission assignment to the roles (PA: Permission Role Assignment).
Access control description language
XACML (eXtensible Access Control Markup Language) – a set of specifications to define a XML-based access control description language. It enables complex conditional settings to the resources. International standard: ITU-T Recommendation X.1142
- 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
233
5.14. Integrated Directory
5.14.1. Definition of Integrated Directory
The integrated directory provides master database functions that cover the collected account
information separately maintained in each ministry. It maintains the master account information data
in coordination with the data stored in the human resource/payroll account information system and
GIMA (Government Identity Management for Authentication) - an inter-ministerial common system.
The account information stored in the integrated directory is distributed to each relevant directory
within the Cabinet Office and Ministries via the integrated account management functions and
directory linkage functions.
Figure 14-1 Relation between the Integrated Directory and GIMA (Government Identity
Management for Authentication)
234
Functions and Services Provided by Integrated Directory Functions and Services
Definition
Integrated directory The integrated directory provides master database functions that control the collection of account information constructed by the Cabinet Office and Ministries. It provides a common platform to unify the management of account information used for running Web applications and groupware, as well as to enable the staff member search of the staff member directory. As it stores the master data for account information to be saved in a variety of directories, it needs to be updated for the latest organization/personnel information, in close coordination with the human resource/payroll account system and GIMA (Government Identity Management for Authentication, when personnel shuffling is implemented. [Reference] Human resources/payroll account systems have two variants: those constructed by the initiative of the Cabinet Office or each Ministry, and those constructed through common agreement among these organizations based on the Business System Optimization Plan. Currently, the former individual systems are in the process of shifting into the latter common system. Therefore, depending on the transition status in each ministry, the system to be linked with the integrated directory should be selected accordingly. The Government Identity Management for Authentication (GIMA) manages account information required to utilize the business applications used within the Cabinet Office and in common with Ministries, as well as those used in each ministry independently, and also provides functions for authentication, authorization, and acquisition of audit logs. ■Functions provided by Government Identity Management for Authentication (GIMA) 1) Management and provision of account information 2) Principal authentication and authorization function 3) Recording and provision of access trail information (log information of 1) and 2) above)
235
The Government Identity Management for Authentication (GIMA) performs an on-line acquisition of personnel information from the human resources/payroll account system to streamline account information related to administrative tasks in business applications. In the Cabinet Office and Ministries where they already have the mechanism for the unified management of account information within the organization, they shall utilize the established mechanisms as a user authentication platform within the cabinet office and ministries that delivers the equivalent functionality of GIMA. Linkage specifications documents for effective data linkage with GIMA are provided: they should be consulted as the need arises.
236
5.14.2. Functional /Non-Functional Requirements of Integrated Directory Functional requirements (use of a password is assumed as authentication information) 1 Basic Realization of a mechanism to manage account information in an
integrated fashion in close linkage with the integrated account management function and directory linkage function.
2 Basic Provision of a repository (data storage) function used to store and manage account information in an integrated fashion. The repository shall have the capacity to store the following information items for the user.
- Identifier : ID (user ID, etc.) for user identification - Credential : Data used for authentication (password,
etc.) - Common Profile : Data about the user (affiliation,
government post, etc.) 3 Additional The repository shall have the capacity to store the following
information items for the user. - Application Profile : Data used by applications
4 Additional Capability to take data linkage with the human resources/payroll management systems in each ministry independently.
5 Basic Provision of a function to import/export account information. 6 Basic Provision of an interface for data linkage with external systems. 7 Basic Capability to record operations performed on account information in
an audit log. 8 Additional Capability to display the content of an audit log in an easy-to-read
report format. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional
Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication.
Security Basic Provision of a mechanism to allow access to account information only to authorized administrators.
Basic Capability to protect account information by setting appropriate levels of access authority according to the roles of the administrator and his/her scope of management objectives.
Basic Intensive application of access control on the acquired audit log records to prevent information from tampering.
Additional
Capability to encrypt communications.
Performance Basic The system will manage “approximately 50 thousand” accounts, and in a period of personnel changes, is required to update a large number of user attribute modifications in a short period of time. The performance requirements shall be
237
defined clearly in advance to achieve a configuration with sufficient processing capacity.
Extendability Additional
As the targeted system expands and the user population grows, the number of user IDs is also expected to increase. The system configuration shall assume enough flexibility to allow future performance upgrades.
Backup Basic Data of account information stored in the repository shall be backed up.
Related technologies Directory service access protocol
LDAP: LDAP (Lightweight Directory Access Protocol) is a standard protocol used for connection with the directory service. LDAP V3 has been established.
Directory service data exchange format
LDIF: LDIF (LDAP Data Interchange Format) defines the file formats used to exchange LDAP account information.
Database access technology
JDBC: JDBC (Java Database Connectivity) represents a set of APIs used by Java programs to access RDB. Use of these APIs is assumed in the case where the directory is RDB.
- 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
238
5.15. WAN, Ministerial LAN, DNS/DHCP/Proxy, Remote Access
The IPv4 global address, required for connections to the Internet, has now almost depleted its
inventory available for new assignments (IPv6 will be used for newly assigned global addresses).
Therefore, new installation of servers with IPv4 global address, and construction of a new DMZ
will be ruled out in advance under normal conditions. In addition, as IPv6 does not hold
compatibility with IPv4, the networks and servers using IPv6 defy simple connection with those
using IPv4. To cope with the problem of new address assignment and connection, some
measures will be needed to achieve coexistence and combined use of both the IPv6
environment and the existing IPv4 environment.
To accomplish flawless coexistence and combined use of IPv4 and IPv6, careful
considerations should be exercised in advance on the equipment (server, PC, etc.) at the design
and procurement stages, as well as on the operational practices such as the content of
operation/management/monitoring/maintenance and security measures.
This section mainly provides description from the viewpoint of IPv4 requirements. When
planning to introduce IPv6, due considerations should be exercised at both the design and
implementation stages.
5.15.1. LAN
LAN is an infrastructure network through which a variety of services are provided within
Cabinet Office and Ministries as shown in the figure below.
LAN LAN
WAN
Remote access
XX Ministry XX Ministry
Sw
itchS
witch
Sw
itchS
witch
Router, etc.
Router, etc.
Figure 5.15-1 Positioning of LAN in the network
239
Definitions of the functions and services provided by LAN are as follows.
Functions and Services
Definition
Layer-3 switch Layer-3 switches shall be deployed in the locations where multiple of networks (segments) are linked together. This switch assumes the role of the core switch (center switch) of the LAN within the Cabinet Office and Ministries.
Layer-2 switch Layer-2 switches shall be deployed in the locations where network devices within the same network (a segment) are linked together. This switch assumes the role of the floor switch (edge switch, access switch) of the LAN within the Cabinet Office and Ministries.
Secure wireless LAN
Wireless LAN refers to the LAN system that transmits/receives data through wireless communication. The secure wireless LAN is a variant of this characterized by an enhanced level of security.
5.15.1.1. Layer-3 Switch
Functional requirements 1 Basic Capability to communicate using DIX Ethernet Ver.2 frame. Or, if
the system uses IEEE802.3 frame, capability to communicate using IEEE802.3 frame.
2 Basic Provision of a routing function (Static, RIPv1/v2, OSPFv2/v3, etc.)
3 Basic Provision of multicast routing functions (PIM-SM/DM, IGMP, etc.) are required if services are to be provided utilizing multicast within the Cabinet Office and Ministries.
4 Basic Provision of functions to enable access control for packets that are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list function, filtering function, etc.
5 Basic Provision of a priority control function (QoS, etc.) that enables identification of packets – those transmitted/received by a specific system provided within the Cabinet Office and Ministries - and to prioritize them for relaying.
6 Basic Provision of VLAN functions compatible with IEEE802.1Q. 7 Basic Provision of link aggregation functions compatible with
IEEE802.3ad. 8 Basic Provision of spanning tree protocol functions compatible with
IEEE802.1D, IEEE802.1w, or IEEE802.1s.
240
9 Basic Provision of network authentication functions (IEEE802.1X authentication, Web authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries.
10 Basic Provision of correct cables (category 5, etc.) that fit the ports. 11 Additional Provision of a IEEE802.3af compatible power receiving
capability (POE) is required if the layer-3 switch is to be connected, or planned to be connected, for a power supply from a secure wireless LAN using the IEEE802.3af scheme.
Non-functional requirements Performance
Basic Provision of the required number of the correct types of ports for connections with the servers and network devices within the Cabinet Office and Ministries (e.g. 10/100BASE-TX, 10/100/1000BASE-T, 1000BASE-SX, 1000BASE-LX, 10GBASE-SR, 10GBASE-LR, etc.)
Basic Provision of a sufficient performance capacity (backplane performance, switching performance, etc.) to meet the required service throughput provided for the Cabinet Office and Ministries.
Reliability Basic Provision of functions (e.g. VRRP and others) required to enable, in case of trouble, redundant operation of the network, utilizing a hot standby system. This scheme includes sharing the same default gateway address by two or more layer-3 switches
Basic Provision of backup ports in preparation for physical port failures – the number of them should not be so large that they adversely affect normal system operation.
Basic Provision of a dual power supply, and measures to enhance the reliability of power supply (such as the use of UPS)
Security Basic Provision of an identity authentication function that enables selective endowment of administrative authority
Basic Provision of functions required to enable the administrator to define settings (e.g. ACL), and to monitor (audit) the system through the review of modification records
Operational maintenance
Basic Provision of a console port that can be used to track modifications of setting information and check operational status.
Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable remote maintenance from the operation management terminal.
Basic Provision of functions (FTP, TFIP, etc.) that enable saving of a backup copy of configuration definition information.
241
Basic Provision of functions (SNMP, RMON, etc.) required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries.
Basic Provision of a function (NTP or SNTP) that enables the system to maintain the time settings of the layer-3 switch in a normal state at all times.
Basic Provision of a function (port mirroring, etc.) that enables traffic analysis over the layer-3 switch.
Basic Provision of a function to transfer logs (Syslog and others) to the server.
Basic Mountability in a 19-inch rack.
Related technologies Routing protocol RIP (Routing Information Protocol) is a routing protocol used to
perform path exchanges dynamically with layer-3 switches or routers. RIPv1:RFC1058, RIPv2:RFC2453 OSPF (Open Shortest Path First) is a routing protocol used to perform path exchanges dynamically with layer-3 switches or routers. With improvements in some of the problems inherent in RIP, routing protocol has become applicable to large scale networks. OSPFv2/v3: RFC2328/RFC2740
File transfer protocol
FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. RFC1350
Multicast protocol
PIM-SM (Protocol Independent Multicast- Sparse Mode) is a routing protocol to create the path information required to relay multicasting packets. RFC2362 PIM- DM (Protocol Independent Multicast- Dense Mode) is a routing protocol to create the path information required to relay multicasting packets. IGMP (Internet Group Management Protocol) is a protocol to control the multicast group configured to receive multicasting packets. IGMPv1: RFC1112, IGMPv2: RFC2236, IGMPv3:RFC3376
Network time protocol
NTP (Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state at all times through time synchronization with external servers. NTPv3:RFC1305 SNTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state at all times through its capability to synchronize with external servers. RFC1361
Network SNMP (Simple Network Management Protocol) is a protocol
242
management protocol
used to monitor/control network devices through networks based on a MIB (Management Information Base). The devices generally support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. RMON (Remote network Monitoring) is an MIB (Management Information Base) used to monitor the communication status – traffic situation, errors, etc.- of the network devices installed in remote locations. RFC1757. Generally, four groups of MIB (Ethernet Statistic, Ethernet History, Alarm, Event) are implemented in the devices. MIB (Management Information Base) is management information, standardized in terms of its structure and identification method, for use in network management protocols. RFC1213. Both standard definitions and vendor definitions exist.
Communication protocol
TELNET is a protocol that provides general purpose bidirectional communication and virtual terminals. RFC854
Encrypted communication protocol
SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819 SFTP (SSH File Transfer Protocol) is a file transfer protocol that utilizes SSH.
router redundancy protocol
VRRP (Virtual Router Redundancy Protocol) is a protocol that enables redundant configurations in the system consisting of layer-3 switches and routers. RFC2338
Log message transfer protocol
Syslog is a protocol for transferring log messages of the network devices to external servers via the IP network.
Link aggregation protocol
Link Aggregation is a protocol that enables enhancement for path redundancy and secures wide bandwidth through logical aggregation of a plurality of physical ports into one. IEEE802.3ad
Virtual network VLAN (Virtual LAN) is a function that enables division of one switch into a plurality of networks. VLAN includes such schemes as Port LAN, Tag VLAN, and Protocol VLAN. IEEE802.1Q
Loop-free protocol
STP (Spanning Tree Protocol) is a protocol that enables construction of redundant configurations in layer-2. STP includes such variants as RSTP and MSTP. IEEE802.1D, IEEE802.1w, IEEE802.1s
Ethernet communication standard
Standard specifications for Ethernet ports implemented in network devices. 10BASE-T: IEEE802.3, 100BASE-TX: IEEE802.3u, 1000BASE-T: IEEE802.3ab, 1000BASE-SX, 1000BASE-LX: IEEE802.3z, 10GBASE-SR, 10GBASE-LR: IEEE802.3ae
243
Electricity Supply Standard
POE (Power Over Ethernet) is a method to supply power to network devices - wireless LAN access points, IP telephones, etc. – utilizing LAN cables. IEEE802.3af
Authentication standard
IEEE802.1X
5.15.1.2. Layer-2 switch
Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX
Ethernet Ver2 frame. 2 Additional Provision of functions to enable access control for packets that
are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list function, filtering function, etc.
3 Basic Provision of a priority control function (QoS, etc.) that enables identification of packets – those transmitted/received by a specific system within the Cabinet Office and Ministries - and to prioritize them for relaying.
4 Basic Provision of VLAN function compatible with IEEE802.1Q. 5 Basic Provision of a link aggregation function compatible with
IEEE802.3ad. 6 Basic Provision of spanning tree protocol functions compatible with
IEEE802.1D, IEEE802.1w, or IEEE802.1s. 7 Basic Provision of a network authentication function (IEEE802.1X
authentication, Web authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries.
8 Additional Provision of a IEEE802.3af compatible power receiving capability (POE) is required if the switch is to be connected, or planned to be connected, to a secure wireless LAN (this requirement shall apply when power is received from a switch using the IEEE802.3af scheme).
9 Basic Provision of correct cables (category 5, etc.) that fit with the ports.
244
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 maintenance
Basic Provision of a console port that can be used to track modifications of setting information and check operational status.
Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable 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.
245
Related technologies File transfer protocol
FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. RFC1350
Network time protocol
NTP (Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in in a normal state through time synchronization with external servers. NTPv3:RFC1305 SNTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state at all times through its capability to synchronize with external servers. RFC1361
Network management protocol
SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). The devices generally support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. RMON (Remote network Monitoring) is a MIB (Management Information Base) used to monitor the communication status – traffic situation, errors, etc.- of the network devices installed in remote locations. RFC1757. Generally, four groups of MIB (Ethernet Statistic, Ethernet History, Alarm, Event) are implemented in the devices. MIB (Management Information Base) is management information, standardized in terms of its structure and identification method, for use in network management protocols. RFC1213. Both standard definitions and vendor definitions exist.
Communication protocol
TELNET is a protocol that provides general purpose bidirectional communication and virtual terminals. RFC854
Encrypted communication protocol
SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819 SFTP (SSH File Transfer Protocol) is a file transfer protocol that utilizes SSH.
Log message transfer protocol
Syslog is a protocol for transferring log messages of the network devices to external servers via the IP network.
Link aggregation protocol
Link Aggregation is a protocol that enables enhancement of path redundancy and the securing of wide bandwidth through logical aggregation of a plurality of physical ports into one. IEEE802.3ad
Virtual network VLAN (Virtual LAN) is a function that enables division of one switch into a plurality of networks. VLAN includes such schemes as Port LAN, Tag VLAN, and Protocol VLAN. IEEE802.1Q
246
Loop free protocol
STP (Spanning Tree Protocol) is a protocol that enables construction of redundant configurations in layer-2 routers. STP includes such variants as RSTP and MSTP. IEEE802.1D, IEEE802.1w, IEEE802.1s
Electricity Supply Standard
POE (Power Over Ethernet) is a method to supply power to network devices - wireless LAN access points, IP telephones, etc. – utilizing LAN cables. IEEE802.3af
Authentication standard
IEEE802.1X
247
5.15.1.3. Secure Wireless LAN
If the system plans to introduce a secure wireless LAN, due deliberation should be exercised on its
security strength.
Functional requirements 1 Basic Communication capability using TCP/IP, UDP/IP shall be provided. 2 Basic Both the access point (AP) and client shall support IEEE802.11g,
IEEE802.11a (W52,W53,W56) as the transmission scheme. 3 Additional Both the AP and the client shall support IEEE802.11n as the
transmission scheme. 4 Basic Both the AP and client shall support IEEE802.11n as the
transmission scheme. Note, however, that the clients are allowed to use a supplicant. The encryption method shall have encryption strength compatible with those method listed in the e-Government recommendations.
5 Basic Both the AP and client shall support WPA2, IEEE802.1x (EAP-FAST/TLS/TTLS/PEAP, etc.) as the authentication scheme. Note, however, the clients are allowed to use a supplicant. They shall support, when in a connected state, authentication using the MAC address of the terminal.
6 Basic The AP shall support ESS-ID stealth function. 7 Basic In the system where VoWLAN is implemented, the capability to limit
the number of terminals connected to an AP is required. 8 Basic The system shall support both AC source and IEEE802.3af scheme
to receive electric power or a power injector with the matching capacity may be used instead (in which case, matching shall be made with the switch’s power supplying capacity).
9 Additional Provision of a DHCP function, or DHCP relay function.
Non-functional requirements Reliability Basic Capability to do maintenance of the AP settings from remote
terminals via the network. Security Basic Capability to perform wireless access point setting and
identity authentication for audit record administrator. Basic Capability to acquire security-related audit logs – start/end
of access point usage, access logs, and others. Operational maintenance
Basic Capability to manage the AP using SNMP. Basic Link capability with the Syslog server.
248
Related technologies Wireless LAN standard
IEEE802.11a (W52,W53,W56), IEEE802.11b/g,n
Wireless LAN authentication method
WPA (Wi-Fi Protected Access) is a standard used for wireless LAN authentication. IEEE802.11i WPA2 (Wi-Fi Protected Access 2) is a standard used for wireless LAN authentication. This is a new version of the WPA standard, published in 2002, compatible with the upgraded AES encryption. IEEE802.11i
Encryption standard
AES (Advanced Encryption Standard) is a symmetric-key cryptography scheme standardized as the new U.S. encryption method. FIPS PUB 197 PEAP (Protected Extensible Authentication Protocol) is one of extended variants of PPP (Point to Point Protocol) with an added feature for authentication functions, which is characterized by two-way authentication between the server and clients. IEEE802.1x
Security protocol
TLS (Transport Layer Security) is characterized by combined security technologies – public- and private-key cryptography, digital certificates, hush functions, etc. - and is capable of preventing tapping and tampering of data and spoofing. IEEE802.1x TTLS (Tunneled Transport Layer Security) is a variant of TLS (Transport Layer Security, a EPA authentication protocol utilized in PPP authentication schemes), and performs authentication using the user name/password protected by a key encryption method. IEEE802.1x. EAP-FAST is a generally available EAP (Extensible Authentication Protocol) pursuant to IEEE 802.1x, and implements tunneling through authentication process using a symmetrical key algorithm. It is compatible both with IEEE 802.1x and EEE 802.11i.
Avoidance of wireless LAN detection
ESS-ID stealth is a function to conceal a part of the “beacon signal” train (i.e. transmission of ESS-ID, network identification, at a regular interval to external world). IEEE 802.11
Electricity Supply Standard
POE (Power Over Ethernet) is a method to supply power to network devices - wireless LAN access points, IP telephones, etc. – utilizing LAN cables. IEEE802.3af
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 management protocol
SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). The devices generally
249
support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3.
Log message transfer protocol
Syslog is a protocol for transferring log messages of the network devices to external servers via the IP network.
250
5.15.2. WAN
It represents a communication scheme in which a set of computers installed in remote locations –
home ministry and its regional offices, and other ministries – exchange data through telephone lines
and other dedicated lines.
Sw
itchS
witch
Sw
itchS
witch
Router, etc.
Router, etc.
LAN LAN
WAN
Remote access
XX Ministry XX Ministry
Figure 5.15-2 Positioning of WAN in the network
Definitions of the functions and services provided by a WAN are as follows.
Functions and Services
Definition
Router A router is a piece of equipment that relays the data flowing within a network to other networks.
Line service (Inter-hub network)
Line service (inter-hub service) represents a “Wide Area Network.” It represents a communication scheme in which a set of computers installed in remote locations – home ministry and its regional offices, and other ministries – exchange data through telephone lines and other dedicated lines. Representative examples of WAN include IP-VPN – a carrier network that is shared among user enterprises, and a virtual LAN is constructed on it - and wide-area Ethernet.
Line service (Internet connection)
Line service (Internet connection) represents a set of computer networks mutually interconnected using the Internet Protocol technology. It realizes data communication with the computers on the
Internet via telephone lines, dedicated lines, and Internet service providers (ISP).
251
5.15.2.1. Router and other devices
Functional requirements 1 Basic Capability to communicate using DIX Ethernet Ver.2 frame, or if
the system uses the IEEE802.3 frame, the capability to communicate using IEEE802.3 frame.
2 Basic Provision of a routing function (Static, RIPv1/v2, etc.). Additional Provision of a routing function (OSPFv2/v3, BGP, etc.).
3 Basic In cases where the system has network connections in locations exterior to the Cabinet Office and Ministries, or it uses internet VPN connections: Router: The router shall support IPsec (main mode/aggressive mode).
Additional In other cases than above: The device shall support IPsec (main mode/aggressive mode).
4 Basic The routers In the system that have network connections and internet VPN connections in locations exterior to the Cabinet Office and Ministries: If the list of encryption methods included in the e-Government recommendations have been released, a router with encryption strength matching with those listed shall be applied to the IPsec encryption algorithm for mutual connection among the hubs.
Additional In other cases than above: If the list of encryption methods included in the e-Government recommendations have been released, a router with encryption strength matching with those listed shall be able to apply.
5 Basic Router: The router shall have a shaping function.
Additional SW: The SW shall have a shaping function.
6 Basic Provision of a priority control function (QoS, etc.) that enables identification of the packets – those transmitted/received by a specific system provided within the Cabinet Office and Ministries - and to prioritize them for relaying.
7 Additional In cases where the router is connected to a network with overlapping network addresses, provision of an NAT, NAPT function is required.
8 Basic Provision of functions to enable access control of packets that are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list functions, filtering functions, etc.
9 Basic Provision of correct cables (category 5, etc.) that fit with the ports.
252
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 maintenance
Basic Provision of a console port that can be used to track modifications of setting information and check operational status.
Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable 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
253
OSPF (Open Shortest Path First) is a routing protocol used to perform path exchanges dynamically with the layer-3 switches or routers. With improvements in some of the problems inherent in RIP, routing protocol has become applicable to large scale networks. OSPFv2/v3: RFC2328/RFC2740
File transfer protocol
FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. FC1350
Time synchronization protocol
NTP (Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state through time synchronization with external servers. NTPv3:RFC1305 NTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state through its capability to synchronize with external servers. RFC1361
Network management protocol
SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). 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.
Communication protocol
TELNET is a protocol that provides general purpose bidirectional communication and virtual terminals. RFC854
Encrypted communication protocol
SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819 SFTP (SSH File Transfer Protocol) is a file transfer protocol that utilizes SSH.
Log message transfer protocol
Syslog is a protocol for transferring log messages of the network devices on the IP network to external servers.
Ethernet communication standard
Standard specifications for Ethernet ports of network devices.. 10BASE-T: IEEE802.3, 100BASE-TX: IEEE802.3u, 1000BASE-T: IEEE802.3ab, 1000BASE-SX, 1000BASE-LX: IEEE802.3z, 10GBASE-SR, 10GBASE-LR: EEE802.3ae
254
Encrypted communication standard
IPsec is the standard for the use of encrypted communication. RFC2401(Security Architecture for the Internet Protocol), RFC2406(IP Encapsulating Security Payload [ESP])
Key exchange standard
IKE is the standard used for key exchange. RFC2407 (The Internet IP Security Domain of Interpretation for ISAKMP), RFC2408 (Internet Security Association and Key Management Protocol (ISAKMP)), RFC2409 (The Internet Key Exchange (IKE))
Network address conversion standard
NAT and NAPT are the standards for address conversion. FC1631 (The IP Network Address Translator (NAT))
5.15.2.2. Line Service (inter-hub network)
Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX Ethernet
Ver2 frame. 2 Basic Support of the following schemes as the access method (access line) to
the backbone: exclusive line, ATM, Ethernet, xDLS, and FTTH. 3 Basic Provision of [QoS (priority control) or other functions] to reduce the
effect caused by inter-system traffic to a minimum. 4 Basic Secured isolation of the line services from the external world, ensuring
a complete shut out of access from external networks. 5 Basic Capability to provide router monitoring as a part of the services. 6 Basic Capability to provide a remote access function as a part of the services.
255
Non-functional requirements Performance Basic Capability to allocate sufficient throughput (bandwidth)
needed to render services delivered within the Cabinet Office and Ministries.
Reliability Basic Provision of a network capable of constructing optimum (such as redundant) configuration to cope with unexpected system stops (circuit failure, router failure, etc.)
Basic The main line and backup line shall use different regional lines – each of which provided by different telecommunication carriers – to upgrade fault tolerance. The backbone shall also be a multi-carrier-capable (i.e. capability to construct a multi-carrier redundant configuration). Switching between the main line and backup line shall be performed automatically.
Operational maintenance
Basic Provision of a contact for inquiries in case of troubles that may occur in the backbone line, regional lines (access lines), and terminal devices.
Basic Capability to monitor, do maintenance, and respond to troubles on the line (notification of trouble occurrence, tracking down and separation of the cause of the failure, failure reporting, etc.)
Basic Capability of on-site troubleshooting, in terms of device repair and replacement.
Basic On-request provision of traffic data for each line after the introduction of the system.
256
5.15.2.3. Line Service (Internet connection)
Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX Ethernet
Ver2 frame. 2 Basic The provider’s backbone switch shall have the capability of IPv6
connection. 3 Basic The access line to the Internet (the communication line from the
Internet connection point to the ISP) shall support an exclusive line, ATM, Ethernet, and FTTH.
4 Basic The ISP backbone shall have the capability to connect directly, or by way of a transit carrier, to a domestic/overseas major IX and overseas major ISP. Sufficient bandwidth – wider than that given to the access line - shall be secured to the ISP backbone.
5 Basic Provision capability of the required number of global IP addresses. 6 Basic Provision capability of a DNS server as a part of the internet connection
services.
Non-functional requirements Performance Basic Capability to allocate sufficient throughput (bandwidth)
needed to render services delivered within the Cabinet Office and Ministries.
Reliability Basic Provision of a network capable of constructing optimum (such as redundant) configuration to cope with unexpected system stops (circuit failure, router failure, etc.).
Basic The main line and backup line shall use different regional lines – each of which provided by different telecommunication carriers – to upgrade fault tolerance. Switching between the main line and backup line shall be performed automatically.
Basic Capability to, when needs arise, to achieve a redundant configuration using path exchange protocol (dynamic routing protocol: BGP).
Operational maintenance
Basic Provision of a contact for inquiries in case of troubles that may occur in the ISP access line and terminal devices.
Basic Capability to monitor, do maintenance, and respond to troubles on the line (notification of trouble occurrence, tracking down and separation of the cause of the failure, failure reporting, etc.)
Basic Capability of on-site troubleshooting, in terms of device repair and replacement.
Related technologies Path exchange BGP (Boarder Gateway Protocol) is a routing protocol used to
257
protocol perform path exchanges dynamically with the layer-3 switches or routers. RFC4271
258
5.15.3. Remote Access
Remote access represents a mode of connection from the external networks to the internal network
(or computers) via telephone line, dedicated line, or the Internet.
XX Ministry
Sw
itchS
witch
Router/FW
Remote access device
Internet
Figure 5.15-3 Remote access device configuration in a network
Functions, services, and definitions of remote access are as follows.
Functions and Services
Definition
Remote access device
Refers to the devices that terminate accesses from the external networks to the internal network (or computers) via telephone line, dedicated line, or the Internet.
5.15.3.1. Remote access device
Functional requirements 1 Basic Capability to communicate using the IEEE802.3 frame and DIX
Ethernet Ver2 frame. 2 Basic Provision of an authentication function to prevent connection from an
unauthorized terminal. 3 Basic Linkage capability with the authentication server. 4 Basic Provision of an encrypted communication function using SSL or IPsec
to secure a sufficient level of security. If the list of encryption methods included in the e-Government recommendations has been released, a device with the encryption strength matching with those listed shall be applied.
5 Basic Definition capability of the maximum number of simultaneously accessible users.
259
6 Basic Web applications shall be operational while the remote access devices are being connected using SSL and other schemes.
7 Basic Capability to configure settings for each user/group, and the provision of easy procedures for security policy settings and maintenance.
Non-functional requirements Performance Basic Provision of a response capability to the requests from
clients located within the range of service delivery (reconnection of disconnected communication, etc.).
Reliability Basic Capability to achieve a redundant configuration of devices. Operational maintenance
Basic Capability of being operated by way of Web-browser and CLI.
Basic Provision of maintenance functions from remote locations using [TELNET, FTP, SSH, etc.]
Basic Provision of functions [SNMP, etc.] required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries.
Basic Mountability in a 19-inch rack.
Related technologies Encrypted communication standard
IPsec is the standard for the use of encrypted communication. RFC2401 (Security Architecture for the Internet Protocol), RFC2406(IP Encapsulating Security Payload [ESP])
Communication protocol
TELNET is a protocol that provides general purpose bidirectional communication and virtual terminals. RFC854
File transfer protocol
FTP (File Transfer Protocol) is a protocol to transfer files. RFC959
Encrypted communication protocol
SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819
Network management protocol
SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). Devices generally support one or more of the three versions: SNMPv1, SNMPv2c, SNMPv3.
260
5.15.4. DNS/DHCP/Proxy
DNS is a function to manage relations between IP addresses and domain names, or host names.
DHCP is a function to distribute the IP addresses and subnet masks to be used to the clients, and
notify the IP addresses of the servers (gateway server, DNS server, etc.) to be used to the clients.
Proxy is a function to communicate with the external networks, in place of the computers located in
the internal network and are incapable to perform direct communication with the external networks.
XX Ministry XX Ministry
Sw
itchS
witch
Sw
itchS
witch
Router, etc.
Router, etc.
DNS/DHCP/Proxy serverDNS/DHCP/Proxy server
Figure 5.15-4 DNS/DHCP/Proxy server configuration in a network
The definitions of DNS/DHCP/Proxy are as follows.
Functions and Services
Definition
DNS server A DNS server manages relations between IP addresses and domain names, or host names.
DHCP server A DHCP server distributes the IP addresses and subnet masks to be used by the clients, and notifies the IP addresses of the servers (gateway server, DNS server, etc.) to be used to the clients.
Proxy server A Proxy server communicates with the external networks, in place of the computers located on the internal network and are incapable of performing direct communication with external networks.
261
5.15.4.1. DNS Server
Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic Provision of a name (address) resolution function for IP addresses,
domain names, and host names associated with the use of DNS protocol.
3 Basic The name resolution function shall be compatible both with forward and reverse lookup.
4 Basic Provision of linking capability with the upper, or lower DNS server.
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 maintenance
Basic Capability to clear the cache. Basic Capability of being maintained from remote devices. Basic Mountability in a 19-inch rack, or compatibility with floor
mounting.
Related technologies Domain name system
DNS (Domain Name System) manages correspondence between the IP address and other items such as a host name on the Internet and a domain name used in e-mail. RFC1034, RFC1035
5.15.4.2. DHCP Server
Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic Capability to provide the IP addresses required for the use of DHCP
protocol. or Capability to provide IP addresses through the use of DHCP protocol.
3 Basic Capability to specify the range of IP addresses to be allocated.
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 maintenance
Basic Capability of being maintained from remote devices. Basic Mountability in a 19-inch rack, or compatibility with floor
262
mounting.
Related technologies DHCP DHCP (Dynamic Host Configuration Protocol) is the protocol
used to assign a computer with the information, such as an IP address, required to establish a temporary connection to the Internet..RFC2131, RFC2132
263
5.15.4.3. Proxy Server
Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic The Proxy server shall be able to relay access to the Internet and Web
within the ministry. 3 Basic Provision of an HTTP request relaying function compatible with
HTTP1.1. 4 Basic Provision of a caching function of HTML contents.
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 maintenance
Basic Capability of being maintained from remote devices. Basic Mountability in a 19-inch rack, or compatibility with floor
mounting.
Related technologies Proxy server A Proxy server is situated in an interface between the Internet
and the internal network of an enterprise or other entities, and provides an internet connection as a “proxy” for the computers within the internal computers that are not capable of direct connection.
Hypertext transfer protocol
HTTP (Hyper Text Transfer Protocol) 1.1. RFC2068
Web page description language
HTML (HyperText Markup Language) is a markup language used to describe a Web page.
264
5.15.5. VoIP VoIP is a platform on which various telephone services within the Cabinet Office and Ministries are
provided utilizing the IP network as shown in the diagram below.
IDCLAN
XX Ministry
WAN Sw
itchS
witch
Sw
itchS
witch
Router, etc.
Router, etc.
LANOperational VoIP server, VoIP gateway
Standby VoIP server, VoIP gateway
IPtelephone
Figure 5.15-5 VoIP server/gateway configuration in a network
Functions, services, and definitions of VoIP are as follows.
Functions and Services
Definition
VoIP server, VoIP gateway
A combination of VoIP servers and/or VoIP gateways are arranged to work with a layer-3 switch bundling a plurality of networks (segments) within the Cabinet Office and Ministries. VoIP server and/or VoIP gateway assumes a role to provide various types of telephone services within the Cabinet Office and Ministries.
5.15.5.1.VoIP Server, VoIP Gateway Functional requirements 1 Basic Provision of an extension interconnection function within the Cabinet
Office and Ministries, and an external connection function with the general public networks and IP public networks.
2 Basic Provision of call hold, call redirection, and call pickup functions. 3 Basic Provision of a function to define the call notification number (transmitted
when an external call is made) for each extension number. 4 Basic Provision of a function to connect with mobile terminals (wireless LAN
telephone terminal, PHS, etc.). 5 Basic Provision of optimum path selection (ARS, etc.) to reduce the cost of
external calls.
265
6 Basic Provision of a function to gather external calling charge (deemed charge) information for each extension number and department within the Cabinet Office and Ministries, and output reports thereof.
7 Basic Provision of network authentication functions for IP telephone transceivers (IEEE802.1x authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries.
8 Basic The control protocol used in the IP telephone transceivers shall conform to SIP (IETF RFC3261).
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 maintenance
Basic Provision of a log that can be used to track modifications of setting information and check operational status.
Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable 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 telephone and others
SIP (Session Initiation Protocol) is a control protocol for IP telephone and others. IETF RFC3261
Authentication IEEE802.1X
266
standard File transfer protocol
FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. RFC1350
Log message transfer protocol
Syslog is a protocol for transferring log messages of the network devices to external servers via the IP network.
267
5.16. Workflow, BAM
5.16.1. Definition of workflow and BAM
Workflow describes a series of work patterns - each of which have high chances of repetition -
found in a part or the whole of a business process, which enables a smooth handover of business
activities (document, information, tasks, etc.) from one person in charge to the next, following the
established steps of business practices. A workflow is often represented as a business flow chart or
other presentation tools, after careful examination of each work’s content and sequence.
The software specifically designed to define, create, and operate the workflow on an IT system is
called a workflow management system. The system enables such practices as execution controls
(automatic allocation and ordering of work for each person in charge), management and transfer of
information/data associated with the workflow, and monitoring of situation progress.
The use of a workflow management system enables efficient processing and is expected to speed
up business operations. This is achieved through the creation of electronic data from a variety of work
papers (application form, request for approval, payment bill for transportation, request for vacation,
notification of residence removal, etc.) that have traditionally required moving through a series of
approval steps by the persons in charge, dispersed throughout the sections within the ministry. This
processing is done by implementing such practices as parallel circulation of documents and requests
for final decision making from a business trip destination utilizing a hand-held PC.
BAM (Business Activity Monitoring) represents a suite of technologies and processes that monitors
the implementation status and past record of business processes in real time, and issues an alert
when an irregular value or some other sign of degradation is detected. The administrator and persons
in charge can utilize this information, as a trigger for the call to next action, leading to decisions being
made and swift handling of the problem. BAM also monitors the selected business processes directly
related to the organization’s KPI (Key Performance Indicators), and display a visualized summary of
execution state and KPI on the dashboard screen.
The alert information reported from monitoring enables quicker response to the chances of
problems taking place in business processes, leading to upgraded efficiency. This is the objective of
BAM. Monitoring data thus measured and accumulated will also provide useful information for the
review and redesign of business processes.
268
5.17. Common Elements in Domains
5.17.1. Definition The common elements in domains represent an assembly of requirements common to a plurality of
technical domains such as communication protocol, data formats, and character codes. This section
defines only the related technologies, and does not provide functional, and non-functional
requirements. Functional and non-functional requirements are designated in the sections that
describe the related technologies.
Related technologies Communication protocol
IP: IETF RFC 791 TCP: IETF RFC 793 UDP: IETF RFC 968 HTTP 1.1: IETF RFC 2616 HTTP over TLS: IETF RFC 2818 TLS: IETF RFC 4243 FTP: IETF RFC 959 FTPS: IETF RFC 2229 SSH: IETF RFC 4250, 4251, 4252, 4253, 4254, 4255, 4256
Universal Multiple-octet Coded Character Set
Unicode: ISO/IEC 10646
Graphic format JPEG: ISO/IEC 15444-1, -2, -3 PNG: ISO/IEC 15948
269
6. Procurement of services
This Chapter organizes “services” to be procured in information system procurement in accordance
with procurement specifications issued by ministries and explains the method of creating
specifications. Please refer to Chapter 5 for procurement of “goods” which is not covered by this
Chapter.
This Chapter classifies services related to information systems by information system phase.
Figure 6-1 Classification of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
270
Table 6-1 Explanation of services
Service Service operation 6.1 Support for master plan
formulation Planning the systematization initiative and creating a systematization plan
6.2 Support for procurement Supporting service for ministerial procurements: e.g. implementation of requirements definition, deciding on procurement policies/procedures, creation of procurement specifications, request for comments, evaluation of contractors, and project management.
6.3 System integration (design/development)
Service operations concerning information system integration: e.g. design, development, migration, operation, operation/maintenance, design of information systems.
6.4 Operation Service operations concerning information systems (“6.5 Helpdesk” may be considered as part of the operations of 6.4; however, it is separately described in this Chapter)
6.5 Helpdesk Service operations concerning helpdesk to respond to inquiries from users on system operation
6.6 Maintenance Service operations of information system maintenance: e.g. correction of information system faults, modification of system/software products after delivery and adaptation to changed environments
6.7 Tasks incidental to procurement of devices
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)
6.8 Tasks incidental to procurement of iDC equipment
Service operations such as installation and configuration of various equipment in facilities (data center) prepared by the procurers, and operation monitoring of relevant systems (and incidental operations)
6.9 Network procurement Services related to construction of local networks, such as LAN and WAN (Wide Area Network), and service operations incidental to service procurement, such as WAN service and internet service.
6.10 Cloud service Service operations using cloud system services 6.11 Cloud construction Service operations to construct cloud systems 6.12 Security This section describes security cautions in procurement
of services and security approaches during construction of information systems
6.13 Other (to be created) Service operations not included in 6.1 – 6.12, such as procurement of business package software.
271
6.1.Support for master plan formulation
6.1.1. Definition of procurement area “Support for master plan formulation” refers to support provided by contractors to procurers in
formulating master plans concerning system integration/operations.
If reforms are being considered in the business process/system/organization for the formulation of
master plans, such considerations shall be conducted during this process.
Figure 6.1-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等)
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.) 6.1 Support
for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
272
6.1.2 Services to be listed in specifications 6.1.2.1. Typical service operations The following table shows services to be included in specifications. The corresponding
SLCP-20071 activities are also given. For actual procurement, correspondence to SLCP activities
should be examined so as not to omit necessary information. To write specifications, a draft of
procurement specifications should be prepared by selecting appropriate items while coordinating with
the corresponding Program Management Office (PMO).
Service operations Outline of service operations SLCP-2007
activity
Chapter/section corresponding to
Basic Guidelines for Procurement2 (and
its title) 1. Systematization initiative
Extracting issues on existing systems(* for existing systems) Study on demand for systematization Study on technological trends Formulating systematization initiative, etc.
1.4.2 Systematization initiative
-
2. Systematization plan
Considering system outline Formulation of schedule of design/development/migration/ operation Implementation of rough estimates Formulating systematization plan , etc.
1.4.3 Systemization plan
-
1 Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 2 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf
273
6.1.2.2. Explanations and examples of descriptions in specifications concerning services 1. Systematization initiative
Item Description Outline of services Prior to system integration, systemization initiative shall be
formulated by conducting studies on demand for systematization
and studies on technological trends, etc. If there is an existing
system, issues in the system shall be identified.
Suggested input
(Prepared by the
procurer)
Requirements definition document and design document for
existing systems (*for existing system)
Demands from procurers for systematization
Set of relevant materials in cases where there are materials
concerning the previous optimization plan
Product
(Prepared by the
contractor)
Systematization initiative document
Matters to be described
in specifications
Requirements for systematization initiative shall be described
[1. Basic requirements to be listed] ・ Study of demand for systematization
・ Study of technological trends
・ Formulation of systematization initiative, etc.
[2. Requirements to be added depending on type/characteristics of project] ●For existing systems
・ Identify issues on existing systems
Example/explanation of
a description in
specifications
[1. Basic requirements to be listed] (1)Studies on demand for systematization
A study of demand for systematization shall be conducted by
interviewing persons concerned.
(2) Study of technological trends
Applicability shall be examined and issues involved in
application shall be organized through the study of trends of
the most advanced technologies both in Japan and overseas.
(3)Formulation a systematization initiative
A systematization initiative document shall be formulated to
clarify the entire structure of new system, system integration
policies, estimated costs, outline of suggested effects, etc.
[2. Requirements to be added depending on type/characteristics of project]
274
●For existing systems
(1) Identifying issues on existing systems
Problems in existing system shall be identified through
interviews with users and organizing issues to be resolved.
Notes on characteristics
of projects/information
systems
-
Notes on security In the case of information systems that deal with critical
information, security policies shall be included in the
systematization initiative
275
2. Systematization plan
Item Description Outline of service
operations
Upon giving shape to the future image of the system and making
rough estimates, design/development/operation schedule shall be
formulated based on the systematization initiative document and
estimates. These descriptions shall be compiled into a
systematization plan.
Suggested input
(Prepared by the
procurer)
Requirements definition document and design document of existing
systems (*for existing systems)
Demand from procurer for systematization
Product
(Prepared by the
contractor)
Systematization plan
Optimization plan (*for systems subject to optimization)
Matters to be
described in
specifications
Enter requirements for systematization plans
[1. Basic requirements to be listed] ・ System outline shall be examined.
・ Design/development/operation schedule shall be formulated.
・ Rough estimates shall be made.
・ Systemization plans shall be prepared.
[2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization
・Optimization plan shall be prepared.
Example/explanation
of a description in
specifications
[1. Basic requirements to be listed] (1) Consideration of system overview
System function diagram shall be created upon defining and
organizing basic requirements for functions to be mounted on the
system.
Hardware diagram, software diagram, network diagram shall be
created upon considering rough system configuration.
(2)Formulation of design/development/operation schedule
Overall schedule for system development/operation shall be
formulated upon considering the period required for system
integration.
(3) Implementation of rough estimates
Rough estimates of costs required for system integration shall be
made.
(4) Formulation of systematization plan
276
The following documents shall be created: a systematization plan
that includes a future image of the system,
design/development/operation schedule, and the result of rough
estimates. A systematization plan shall define the framework and
roles of procurers and contractors, constraints and prerequisites and
standard management guidelines to be observed.
[2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization
(1) Formulation of optimization plans
An “optimization plan Shall be created, which defines overview of
target business/system, details of implementation of optimization,
optimization process table, existing and future systems, and list of
index of optimization effect/service index, based on the Guidelines
for Business/System Optimization Plan.
Notes on
characteristics of
projects/information
systems
Optimization plans for systems subject to business/system
optimization shall be created, as defined in the Guidelines for
Business/System Optimization Plan.
Notes on security In cases of information systems that deal with critical information,
systemization plans shall include considerations for security.
277
6.1.3. Deliverable product and timing of delivery The table below lists typical deliverable products and timing of delivery. The official name of each
product and its delivery deadline needs to be entered in accordance with the actual situation.
Service Deliverable product Delivery deadline
1.Systematization initiative Systematization initiative At the completion of the project
2. Systematization plan Systematization plan
Optimization plan
At the completion of the project
6.1.4. Suggested input
The following table shows input and timing to be presented to a procurer (proposer) in advance.
The official name of each product and its delivery deadline need to be entered in accordance with the
actual situation.
Service Input Timing for presenting input
1. Systematization
initiative
Requirements definition
document and design document
of existing system, etc.
At the time of tender publishing
Demand from the procurer for
systematization
At the time of tender publishing
2. Systematization plan Concept of systematization At the time of tender publishing
Requirements definition
document and design document
of existing system, etc.
At the time of tender publishing
Demand from procurer for
systematization
At the time of tender publishing
6.1.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related
procurement and the relevant procurement should be clarified in accordance with the scope of
separated orders and the ministerial policies and presented at the time of tender publishing.
When considering procurement, services to be realized in the entire procurement should be
identified. A clear division of roles and services should be specified and a table of the division of roles
should be compiled so that the concerned parties can agree that there are no omissions/errors in
services/roles in the breakout procurement.
278
6.2. Support for procurement
6.2.1. Definition of procurement area Support for procurement refers to support for operations of procurers at the time of
design/development. This document covers two services: namely, “6.2.2 Support for procurement in
requirements definition phase” and “6.2.3 Support for procurement in design/development phase,
such as project management.”
Figure 6.2-1 Classification of services in support for procurement
Service classification Applicable service operations
6.2.2 Support for procurement in
requirements definition phase
The contractor shall provide support for operations, such as
implementation of requirements and procurement of goods and
services (support for determining procurement
policies/procurement method, support for creation of
procurement specifications, and support for request for
comments and evaluation of contractors).
6.2.3 Support for procurement following
design/development, such as project
management
The contractor shall provide support for service operations, such
as project management concerning system development and
procurement of goods and services (support for determining
procurement policies/procurement method, support for creation
of procurement specifications, and support for request for
comments and evaluation of contractors).
Requirements definition
Basic design
Detailed design
Development /test /migration
Operation /maintenance
Support for requirements definition Support for
procurement following basic design (creation of specifications, creation of assessment criteria, etc.)
Support for project management (formulation of project plan, progress management, issue management, change management, quality management, risk management, etc.)
Support for procurement (creation of specifications, creation of assessment criteria, etc.)
Support for other operations (product management, operation of conferences, etc.)
Major services
By TRM classification
6.2.2 Support for procurement in the requirements definition phase
6.2.3 Support of procurement following design/development, such as project management
279
6.2.2. Support for procurement in the requirements definition phase 6.2.2.1. Definition of procurement area “Support for procurement in requirements definition phase” refers to support operations in
requirements definition phase, such as support for requirements definition and support for creation of
procurement specifications for system design/development based on the definition (See Figure 6.2-1
and Figure 6.2-2). Please refer to 6.2.3 for procurement support operations concerning projects
following the design/development operations (system integration operations), since it is not included
in this section.
Figure 6.2-2 Scope of the applicable services in the process of information system
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
280
6.2.2.2. Services to be included in specifications 6.2.2.2.1. Typical services The following table shows services to be included in the specifications. Corresponding SLCP-20073
activities are also given. For actual procurement, the correspondence to SLCP activities should be
checked so as not to omit necessary information.. Items corresponding to the Basic Guidelines on
Procurement (BGP)4 are also listed. To write specifications, a draft of procurement specifications
should be prepared by selecting appropriate items while coordinating with the corresponding
Program Management Office (PMO).
Service operations Outline of service operations Activities of SLCP-2007
Chapter and section of
specifications corresponding to
BGP (and its title)
1. Confirmation/evaluation/ improvement/estimation of effects of the optimization plan
Support for confirmation/ evaluation/improvement/ estimation of effects of the optimization plan
1.4.3 Systematization plan
3.Infromation system requirements 4.Requirements for scale/performance 5. Requirements for reliability, etc. 6.Requreiments for information security 7.Information operation environment 8. Requirements definition for tests 9. Requirements definition for migration 10. Requirements definition for operation 11. Requirements definition for maintenance
2. Support for requirements definition
Support for the following requirements definition ・ Definition of schedule ・ Requirements definition for
business/functions ・ Requirements definition for system
architecture ・ Requirements definition for
information/data ・ Requirements definition for user
interfaces ・ Requirements definition for external
interfaces ・ Requirements definition for networks ・ Requirements definition for software ・ Requirements definition for
hardware ・ Requirements definition for
information security ・ Requirements definition for
design/development ・ Requirements definition for tests ・ Requirements definition for
migration ・ Requirements definition for
operation/maintenance
1.5.2.4 Definition of function requirements 1.5.2.5 Definition of non-function requirements 1.6.2 Definition of system requirements 1.5.2.6 Requirements definition concerning schedule
3.Estimation of system cost Construction of system/estimation of operation cost based on requirements definition implemented in Section 2.
1.5.2.5 Definition of non-function requirements
4.Support for procurement operations
Support for procurement-related operations, such as the creation of a procurement plan, creation of procurement specifications, response to request for comments and evaluations from contractors, etc.
1.1.2 Preparation of presentation request 1.1.3 Preparation and renewal of contract
3 Software Life Cycle Processes-Japan Common Frame-2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 4 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf
281
6.2.2.2.2. Explanation on services and examples of descriptions in specifications 1. Confirmation/evaluation/improvement/estimation of effects of optimization plans
Item Description Outline of Service
operations
To confirm and evaluate the optimization plan, and make
improvements as necessary.
To provide support for estimation of optimization effects.
Suggested input
(Prepared by the
procurer)
・ Optimization plan
Product
(Prepared by the
contractor)
・ Report on the optimation plan in terms of the confirmation/evaluation/improvement/estimation of effects
Matters to be
described in
specifications
[1. Basic requirements to be listed] ・ Confirmation/evaluation/improvement proposals for optimization
plans
・ Estimation of the effects at the time of implementing the plan
Example/explanation
of a description in
specifications
○The contractor shall make proposals for
confirmation/evaluation/improvement proposals of an optimization
plan.
The contractor shall make confirmation/evaluation and improvement
proposals to check if an optimization plan presented by the Ministry is
in conformity with “the Basic Guidelines for Government Procurement
Related to Information Systems,” “Business/System Optimization
Guidelines” and the “Information Network (Common System)
Optimization Plan of the Ministry of ___.”
○The contractor shall make estimation of effects at the time of
implementing the plan, shall confirm details estimated in the
optimization plan with respect to the effects of the realization of the
plan, such as a reduction of costs and/or a reduction of operation
processing time, and shall make revisions when necessary.
Notes on
characteristics of a
project/information
system
This operation becomes necessary only when an optimization plan is
created in “6.1 Support for formulating master plan”
Notes on security -
282
2. Support for requirements definition
Item Description Outline of Service
operations
Support for requirements definition concerning system and business
procurement.
Suggested input
(Prepared by the
procurer)
・ Systemization plan
・ Optimization plan (* when there is an optimization plan)
・ Requirements definition document/design document of existing system, etc. (* when there is an optimization plan)
・ Other information to be provided as needed by contractor
Product
(Prepared by the
contractor)
・ Requirements definition document
Matters to be
described in
specifications
[1. Basic requirements to be listed]
Support for requirements definition with respect to the following
items:
・ Definition of schedule
・ Requirements definition for business/functions
・ Requirements definition for system architecture
・ Requirements definition for information/data
・ Requirements definition for user interfaces
・ Requirements definition for external interfaces
・ Requirements definition for networks
・ Requirements definition for software
・ Requirements definition for hardware
・ Requirements definition for information security
・ Requirements definition for design/development
・ Requirements definition for tests
・ Requirements definition for migration
・ Requirements definition for operation/maintenance
Example/explanation
of a description in
specifications
○Implementation of requirements definition
The following requirements shall be defined and requirements
definition documents shall be compiled, based on the “Draft
Optimization Plan” prepared by the Ministry, guidelines separately
presented by the Ministry and consultation with the Ministry.
A) Definition of schedule
B) Requirements definition for business/functions
C) Requirements definition for system architecture
D) Requirements definition for information/data
E) Requirements definition for user interfaces
283
Item Description F) Requirements definition for external interfaces
G) Requirements definition for networks
H) Requirements definition for software
I) Requirements definition for hardware
J) Requirements definition for information security
K) Requirements definition for design/development
L) Requirements definition for tests
M) Requirements definition for migration
N) Requirements definition for operation/maintenance
Notes on
characteristics of
projects/information
systems
If organizational change happens, its effects shall be discussed in the
requirements definition.
Notes on security Procurers and creators of specifications shall define information
security requirements in conformity with the “Standards for
Information Security Measures for the Central Government Computer
Systems” and the information security policies of ministries. The
definition of the following requirements shall be specifically clarified
since they are required to be stated in specifications by the “Basic
Guidelines for Government Procurement Related to Information
Systems”:
(1) Definition of authority, and
(2) Definition of security measures
284
3. Estimation of system cost
Item Description Outline of Service
operations
To estimate the cost for system integration/operation from the results
of requirements definition
Suggested input
(Prepared by the
procurer)
・ Requirements definition document (for product stated in Section 2)
Product
(Prepared by the
contractor)
・ Estimated cost of system integration (draft)
・ Estimated cost of operations (draft)
Matters to be
described in
specifications
[1. Basic requirements to be listed]
・ Cost estimation and creation of cost estimation document
Example/explanation
of a description in
specifications
○Cost estimation and creation of estimated cost document
・ The contractor shall estimate the cost of defined functions and services, system integration and operation expenditure based on
the requirement definition document, and shall compile an
estimated cost document.
・ Approval of a relevant officer shall be obtained with respect to calculation items, calculation method and calculation type.
Notes on
characteristics of
projects/information
systems
-
Notes on security -
285
4. Support for procurement operations
Item Description Outline of Service operations
Support for operations related to the procurement of design/development, such creation of a procurement plan, creation of procurement specifications, request for comments, and evaluations of contractors, etc.
Suggested input (Prepared by the procurer)
・ Optimization plan (* if there is an optimization plan) ・ Requirements definition document (for product listed in Section
2) Product (Prepared by the contractor)
・ Procurement plan document (draft) ・ Procurement specifications (draft) ・ Outline for creating bid materials (draft) ・ Evaluation procedures (draft) ・ List of evaluation items (draft) ・ Evaluation criteria document (draft) ・ Table of scores (draft) ・ Table of responses to request for comments ・ Explanations on bid announcement (draft) ・ Budget justification materials needed after bid announcement
(draft) Matters to be described in specifications
[1. Basic requirements to be listed] ・ Support for formulating procurement method/procedures ・ Support for creating materials related to procurement
procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc.
・ Support for request for comments ・ Support for evaluation of bidders [2. Requirements to be added depending on type/characteristics of project] (Project falling under the category of a specific information system) (project with an estimated price of design/development exceeding ¥0.5 billion) ・ Support for creating a procurement plan document (draft) ・ Support for responding to remarks from a government-level
Project Management Office and ministerial-level Project Management Offices.
Example/explanation of a description in specifications
[1. Basic requirements to be listed] ○Support for creating procurement method/procedures ・ The contractor shall examine and propose the best procurement
method in accordance with the scale and characteristics of the project.
○Support for creating materials concerning procurement procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc. ・ The contractor shall support the creation of procurement
specifications (draft) and outlines for creating bid materials (draft), shall support the procurement of design/development contractors, based on the requirements definition document. Procurement specifications (draft) shall be created from a fair and
286
Item Description neutral perspective, without making assumptions on specific technology or devices/tools.
・ The contractor shall support the creation of materials (evaluation procedures/list of evaluation items/certificate of confirmation, etc.) necessary for selection of contractors in accordance with the procurement method.
○Support for response to request for comments ・ The contractor shall provide support for creating responses to the
opinions and inquiries received, when comments are requested, ・ The contractor shall present the revision and finalization of
procurement specifications (draft) when necessary, based on the results of request for comments.
○Support for evaluation on bidders ・ The contractor shall provide support for technical review and
present evaluation reports for the Ministry. The contractor shall examine whether every item of proposals and certificates of confirmation presented by bidders are meeting requirements, and compile items with unclear descriptions or not meeting requirements into a list and present the list to the Ministry.
[2. Requirements to be added depending on type/characteristics of project] ●Projects under the category of specific information systems ○The contractor shall provide support for creating a procurement plan (draft). The contractor shall create a procurement plan document (draft) based on the “Basic Guidelines for Government Procurement Related to Information Systems.” ○The contractor shall provide support for responding to remarks made by a government-level Project Management Office and ministerial-level Project Management Offices. The contractor shall provide support for creating materials and shall give explanations on created products when remarks or inquiries are made by a government-level Project Management Office and ministerial-level Project Management Offices.
Notes on characteristics of projects/information systems
The “Basic Guidelines for Government Procurement Related to Information Systems” requires creation of a procurement plan in the cases of specific information systems (projects with estimated price of design/development exceeding ¥0.5 billion).
Notes on security -
287
6.2.2.3. Deliverable product and timing of delivery The following table shows the deliverable product and delivery timing. The official names and
delivery timing of each product should be listed in accordance with the actual situation.
Service operations Deliverable product Delivery timing
1.
Confirmation/evaluation/
improvement proposal
for optimization plan
and estimation of effects
Report on confirmation
evaluation/improvement proposals for
optimization plans and estimation of effects
After conclusion of contract
(example of a 6-month project:
around 1.5 months after the
conclusion of contract)
2.Support for
requirements definition
Requirements definition document After conclusion of contract
(example of a 6-month project:
around 2.5 months after the
conclusion of contract)
3.Estimation of system
cost
Estimation of cost of system integration
Estimation of operation cost
After implementation of
requirements definition
4.Support for
procurement
operations
Procurement plan document (draft)
Procurement specifications (draft)
Outline for creating bid materials (draft)
Evaluation procedures (draft)
List of evaluation items (draft)
Evaluation criteria document (draft)
Table of scores (draft)
Table of responses to request for
comments
Explanations on bid announcement (draft)
Budget justification materials needed after
bid announcement (draft)
Date designated by
ministries/agencies
288
6.2.2.4. Suggested input The following table shows the input and timing to be presented to procurers (or proposers) in
advance. The official names and delivery timing of each input should be listed in accordance with the
actual situation.
Service operations Input Timing to present input
1. Confirmation/evaluation/
improvement proposal for
optimization plan and estimation of
effects
Optimization plan At the time of formulation for the
optimization plan
2.Support for requirements
definition
Systematization plan
Optimization plan
(reflecting Section 1)
At the time of release of
specifications
Date designated by
ministries/agencies
3.Estimation of system cost Requirements definition document
(product in Section 2)
After implementation of
requirements definition
4.Support for procurement
operations
Optimization plan
Requirements definition document
(product stated in Section 2)
After operations of requirements
definition
(*A set of support operations, such as requirements specifications for next-term infrastructure
information system of the Ministry of ___, 2010)
Figure 6.2-3 Example of table of overall schedule
Fiscal Year 2010
Dec
embe
r
July
Aug
ust
Sept
embe
r
Oct
ober
Nov
embe
r
Mar
ch
Janu
ary
Febr
uary
Confirmation/evaluation/improvement proposal for optimization plan and estimation of effects
Creation of next-term system procurement plan Specifications for request for comment, etc. (Creation of rough
draft) (Creation of final draft
Estimation of system cost based on the draft of specifications for request for comment (requirements definition)
(Creation of draft) (Creation of estimation)
Creation of draft of WBS items related to support for technical review, etc.
(Reference)
Revision of optimization plan (Draft creation) (Intra-ministerial coordination/approval
procedure)
Next-term system requirements specifications (Intra-ministerial
coordination/coordination with MIC)
(Creation of specification)
289
6.2.3. Support for procurement following design/development, such as project management. 6.2.3.1. Definition of procurement area “Support for procurement following design/development, such as project management” in this
section refers to procurement support operations, etc., such as project management after the
design/development phase. (See Figure 6.2-1 and Figure 6.2-4).
Figure 6.2-4 Scope of applicable services in the process of information system
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用
6.3 ハードウェア更改 6.3
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
6.2.3 Support for procurement (Project management, etc.)
290
6.2.3.2. Services to be stated in specifications 6.2.3.2.1. Typical services The following table shows services to be included in specifications. The corresponding
SLCP-200753 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
Activities of SLCP-2007 Outline of service operations
Activities of SLCP-2007
Chapter and section of
specifications corresponding to BGP (and its
title) 1.Project management Creation of a project plan, progress
management, issue management, change management, quality management, risk management
1.2.4 Planning 1.2.5 Implementation and management
―
2.Support for procurement
Support for procurement related operations, such as creation of a procurement plan document, creation of procurement specifications, response to request for comments, evaluation of contractors, etc.
3.Support for other operations
Product management, Operation of conferences
5 Software Life Cycle Processes-Japan Common Fram-2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 6 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf
291
6.2.3.2.2. Explanation on services and examples of descriptions in specifications 1. Project management
Item Description Outline of service
operations
Formulate project plans and define the method of project
management, etc.
Implement various types of management, such as progress
management, issue management, change management, quality
management, and risk management
Suggested input
(Prepared by the
procurer)
・ Systematization initiative
・ Systematization plan
・ Optimization plan
・ Requirements definition document
Product
(Prepared by the
contractor)
・ Project management plan
・ Report on project management
Matters to be
described in
specifications
[1. Basic requirements to be listed] ・ Formulation of project plan
・ Progress management
・ Issue management
・ Change management
・ Quality management
・ Risk management
[2. Requirements to be added depending on type/characteristics of project] ・ Progress management by EVM
Example/explanation
of description of
specifications
[1. Basic requirements to be listed] ○Formulation of project plan
A project plan shall be formulated, which prescribes the promotional
method of project management operations and index for
management, etc.
When doing so, roles of project participants, contact list of concerned
parties, and conferences, etc. shall be clarified in the project plan.
○Progress management
Instructions shall be given to system developers to present WBS and
other necessary materials that are needed for progress
management. Requirements for the relevant documents shall be
presented to contractors.
The progress of work of the development contractor shall be
periodically checked, and if there is a delay in schedule, support for
292
measures for recovery from the delay shall be provided upon
identifying the causes and impacts, etc.
○Issue management
Issues that may influence the progress of the project shall be
appropriately managed, and the division of roles shall be considered
to resolve the issues and support shall be given for managing
resolution deadlines and for consideration of solutions.
○Change management
Importance/target/implementation period of various specifications
shall be examined and managed at the time of change in system
specifications.
○Quality management
Details of product and materials presented by the development
contractor shall be confirmed and inquiries shall be made to indicate
defects, etc., for the purpose of improving the quality of product, etc.
○Risk management
Possible risks shall be identified, which may influence the progress of
a project and measures for risk reduction/aversion or resolution shall
be presented. [2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization
○Progress management by EVM
Quantitative progress management by EVM (Earned Value
Management) shall be performed and reported, based on the WBS
consulted and agreed between the procurer and the operation
contractor for system development.
Notes on
characteristics of
projects/information
systems
-
Notes on security -
293
2. Support for procurement
Item Description Outline of service operations
Support for operations related to the procurement of design/development, such as creation of a procurement plan, creation of procurement specifications, response to request for comments, and evaluation of contractors, etc.
Suggested input (Prepared by the procurer)
・ Optimization plan (* only when there is one) ・ Requirements definition document
Product (Prepared by the contractor)
・ Procurement plan document (draft) ・ Procurement specifications (draft) ・ Outline for creating bid materials (draft) ・ Evaluation procedures (draft) ・ List of evaluation items (draft) ・ Evaluation criteria document (draft) ・ Table of scores (draft) ・ Table of responses to request for comments ・ Explanations on bid announcement( draft) ・ Budget justification materials needed after bid announcement
(draft) Matters to be described in specifications
[1. Basic requirements to be listed] ・ Support for procurement methods/procedures ・ Creation of materials concerning procurement procedures, such
as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc.
・ Support for response to request for comments ・ Support for evaluation of bidders [2. Requirements to be added depending on type/characteristics of project] (Projects falling under the category of specific information system) ・ Creation of procurement plan (draft) ・ Support for responding to remarks made by a government-level
Project Management Office and ministerial-level Project Management Offices.
Example/explanation of a description in specifications
[1. Basic requirements to be listed] ○Support for procurement methods/procedures ・ The contractor shall examine and propose the best procurement
procedures based on the size and characteristics of the project ○The contractor shall create materials related to procurement procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures and list of evaluation items, etc. ・ The contractor shall create procurement specifications (draft) and
outline for creating bid materials (draft), based on the requirements definition, for the procurement of design/development contractor. Procurement specifications (draft) shall be created from a fair and neutral perspective, without making assumptions on specific technology or devices/tools.
294
Item Description ・ The contractor shall create materials (evaluation procedures/list
of evaluation items/certificate of confirmation, etc.) necessary for the selection of contractors in accordance with the method of procurement.
○Support for response to request for comments ・ The contractor shall support responses to opinions and inquiries
received, when comments are requested, ・ The contractor shall provide support for the revision and
finalization of procurement specifications (draft) when necessary, based on the results of request for comments.
○Support for evaluation of bidders ・ The contractor shall provide support for technical review and
report evaluation results to the Ministry. The contractor shall also examine whether every item of proposals and certificates of confirmation presented by bidders is meeting requirements, and shall compile items with unclear descriptions or not meeting requirements into a list and present the list to the Ministry.
[2. Requirements to be added depending on type/characteristics of project] ●Projects falling under the category of specific information systems ○The contractor shall create a procurement plan document (draft) based on guidelines and the “Basic Guidelines for Government Procurement Related to Information Systems.” ○The contractor shall provide support for responding to remarks made by a government-level Project Management Office and ministerial-level Project Management Offices. ・The contractor shall provide support for the creation of materials and shall give explanations on the created products when remarks or inquiries are made by a government-level Project Management Office and ministerial-level Project Management Offices.
Notes on characteristics of projects/information systems
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 -
295
3. Support for other operations
Item Description Outline of service
operations
Support for operations of the procurer, such as product management
and conference operations, etc.
Suggested input
(Prepared by the
procurer)
-
Product
(Prepared by the
contractor)
・ Product management plan (draft) (*)
・ Communication management plan (draft) (*)
・ Conference minutes (draft) (*) Not necessary if it is defined in the project management plan
Matters to be
described in
specifications
[1. Basic requirements to be listed] ・ Product management
・ Operation of conferences
Example/explanation
of a description in
specifications
[1. Basic requirements to be listed] ○Product management
・ The contractor shall support acceptance by the procurers by confirming that the deliverable products of the development
contractor is complete and its quality is satisfactory.
・ The contractor shall support version management of delivered products.
○ Operation of conferences
・ The contractor shall support in project defining conferences and shall clarify participants and operating body, etc.
・ With respect to conferences operated by contractors of the business in question, the contractor shall create and present the
minutes (draft) within __ business days after the relevant
conference.
・ With respect to conferences hosted by procurers, the contractor shall provide support for creation of conference materials when
necessary.
Notes on
characteristics of
projects/information
systems
-
Notes on security -
296
6.2.3.3. Deliverable product and timing of delivery The table below lists typical deliverable products and timing of delivery. The official name of each
product and its delivery deadline should be entered in accordance with the actual situation.
Service Deliverable product Delivery deadline
1.Project management Project plan Report on project management
Project plan: within one month after conclusion of a contract Report on project management: monthly
2.Support for procurement
Procurement plan (draft) Procurement specifications (draft) Outline for creating bid materials (draft) Evaluation procedures (draft) List of evaluation items (draft) Evaluation criteria document (draft) Table of scores (draft) Table of responses to request for comments Explanations on bid announcement (draft) Budget justification materials needed after bid announcement (draft)
Date designated by ministries/agencies
3.Support for other operations
Minutes Within __ business days after conference
6.2.3.4. Suggested input The following table shows input and timing to be presented to procurers (proposers) in advance.
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 Requirements definition document
After implementation of 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.
297
6.3. System Integration (Design/Development)
This Chapter covers services related to construction of information systems, including design,
development, migration and operational design.
Table 6.3-1 Items corresponding to the classification of procurement of services
6.3.1. Definition of procurement areas Services in system integration (design/development) are classified into four groups in accordance
with the situation in which information systems are developed: namely, new development, system
renewal, hardware renewal, and function addition.
The definition of each group is described below.
Service Definition New development Referring to a system development project to develop a new information
system for services in which no information system currently exists.
System renewal Referring to a system development project due to changes in laws and
operations, such as full-fledged application renewal and system
integration.
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
298
Hardware
renewal
Referring to a system development project for application migration due
to hardware renewal.
Function addition Referring to a function addition project at a subsystem level, design of
existing system and a system improvement projects outside the contract
to be executed by the development contractor/maintenance contractor.
Please refer to “6.3.3 Application maintenance” for additions lower than
subsystem level.
6.3.2 Services to be included in specifications 6.3.2.1. Typical service operations The following table shows services to be included in specifications. The corresponding SLCP-20077
activities are also given. For actual procurement, correspondence to SLCP activities should be
examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on
Procurement (BGP)8 are also listed. To write specifications, a draft of procurement specifications
should be prepared by selecting appropriate items while coordinating with the corresponding
Program Management Office (PMO).
Service operations Outline of service operations Activities of SLCP-2007
Chapter and section of specifications corresponding to
BGP 1.Preparation for development environment
Securing devices (hardware, development tools, etc.), and work site for development
1.6.1 Preparation for process initiation
Chapter II (5.1) Description of work Chapter XII (2) Method of development
2.Creation of the development plan
Creating design/development plans (schedule, framework, division of roles, work details, development environment, development tools, product, etc.)
1.6.1 Preparation for process initiation
Chapter II (5.1) Description of work Chapter XII (2) Method of development
3.Basic design Function design (business function, etc.,), data design (conceptual model/logical model), screen design, form design, system architecture design, external interface design and information security design, which are based on the requirements definition. * The above is partially applied to function addition.
1.6.2 Definition of system requirements 1.6.3 System architecture design 1.6.4 Definition of software requirements 1.6.5 Software architecture design
Chapter II (5.1) Description of work Chapter XII (2) Method of development
4.Detailed design Program design (list of development programs and definition of specifications, etc.), data design (physical model), screen design, form
1.6.6 Detailed software design
Chapter II (5.1) Description of work Chapter XII (2) Method of development
7 Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 8 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf
299
Service operations Outline of service operations Activities of SLCP-2007 Chapter and section
of specifications corresponding to
BGP design, system architecture design, external interface design and information security design, which are based on the basic design
5.Unit test,, integration test, system test, connectivity test with other systems
Creating source code based on detailed design Creating test plans and gaining approval from the relevant sections Preparing for test devices/tools Implementing tests and response to detected faults Creating test result report
1.6.7 Creation of software code and test 1.6.8 Software integration 1.6.9 Software qualification test 1.6.10 System integration 1.6.11 System qualification test
Chapter II (5.1) Description of work Chapter VIII Definition of test requirements Chapter XII (2) Development method
6.Acceptence test support
Support for acceptance tests carried out by procurer, such as creation of drafts of acceptance test procedures, implementation of investigation on and countermeasures against faults and implementation of operation tests
1.6.13 Software acceptance support
Chapter II(5.1) Description of work Chapter XII(2) Development method
7.Migration Migrating data necessary for operations and inputting initial data Migration form development to the live environment
1.8.5Migration Chapter II (5.1) Description of work Chapter IX (1) Requirements concerning migration Chapter XII (2) Development method
8.User education Creating education plans and system usage manuals Implementing training for government officials
1.6.13 Software acceptance support
Chapter II (5.1) Description of work Chapter IX (2) Requirements concerning education
9.Transfer to operation/maintenance contractors
Operation design Transfer to operation /maintenance contractors
1.7.1 Preparation for process initiation 1.8.1 Preparation for process initiation
Chapter II (5) Description of operations/ Deliverable product
10.Project management Implementing project management for design/development operations, including progress management, document management, information security management, issue/problem management, change management and configuration management
3.1.2 Planning 3.1.4 Implementation and management
Chapter II (5.1) Description of work Chapter XII (2) Development method
11.Acceptance Delivering necessary products, and making corrections if deemed necessary
1.2.7 Delivery and completion
Chapter II (5) Description of work/deliverable product
300
6.3.2.2. Explanation on services and examples of descriptions in specifications Many services mentioned in the preceding section are common to all service types, whether it is new
development, system renewal, hardware renewal, or function addition. Therefore, items in this
section are applied to all service types unless otherwise stated, and a specific service type is
indicated when necessary.
1. Preparation for development environment
Item Description Outline of service
operations
Securing of necessary development devices and work site
Suggested input
(Prepared by
procurer)
Outline of new system infrastructure (scheduled)
Operating environment
Operating conditions
Requirements definition document
Product
(Prepared by
contractor)
-
Matters to be stated in
specifications
[1. Basic requirements to be listed] ・ Construction of system design and development environment
(work site, devices and expendables)
・ Management of development environment
Example/explanation
of descriptions in
specifications
Examples of descriptions in specifications ・ System design and development devices shall be prepared and
borne by the contractor.
・ Sufficient security measures for development environment (devices/work site, etc.) shall be taken.
Notes on
characteristics of
projects/information
systems
If development environment cannot be prepared on site, there is
room for considering creating a development repository.
Notes on security Security measures for development environments
・ When a contractor prepares development environment (devices, work site, etc.), it shall take sufficient information security
measures for the environments.
301
2. Creation of development plan
Item Description Outline of service operations
Creation of design/development plan
Suggested input (Prepared by procurer)
・ Requirements definition document ・ List of major operations ・ Relationship between contractor and related contractors ・ Outline of operations of concerned contractors ・ Operation schedule ・ Table of division of roles ・ Document standards of the government
Product (Prepared by contractor)
・ Project plan ・ Design/development plan
Matters to be stated in specifications
[1. Basic requirements to be listed] ・ Contractor shall create a design/development plan in
accordance with the central government’s standards, such as optimization guidelines, and shall finalize the plan upon coordination with ministries.
・ The project plan shall be created, including WBS (Work Breakdown Structure), critical path and milestones.
[2. Requirements to be listed when necessary] ・ The contractor shall define documentation standards and
development rules, and implementation of reviews to confirm that the development is being conducted accordingly.
Example/explanation of descriptions in specifications
Examples of descriptions in specifications ○Project plan Contractor shall create a project plan. The following operations shall be implemented when creating the project plan. ・ Prior to the creation, necessary operations for the full-fledged
operation of this system shall be organized and WBS documents shall be compiled. Details of operations and deliverable product, commencement and completion conditions shall be clarified by each task. Tasks shall be detailed as much as possible before the commencement so that actual progress and actual cost (AC) can be measured.
・ A dependence relationship of tasks and critical paths (group of tasks that cannot be delayed to avoid delay of the completion of project as a whole) shall be clarified and dates of commencement and completion and interim milestones for each task shall be established.
○Design/development plan ・ Prior to systematization, a document defining work the schedule
related to the product, description of operations, personnel in charge, review plan, check-points, conditions for commencement/completion, and work process of the project shall be complied into a “Project Plan,” which shall be approved
302
by the Ministry upon consultation. Actual design/development operations shall be implemented based on the relevant “Project Plan.”
○Schedule ・ Creation of a schedule including an overall schedule and major
milestones. ○Project framework ・ Entry of the necessary information of the project participants,
such as the leaders and personnel in charge of each organization, and contact list, etc.
・ Clarification of assignments of management responsibility in the entire project and details of management.
○Division of roles ・ Clarification of roles of each project participant so that each can
be aware of its own roles in the entire project. Notes on characteristics of projects/information systems
Some ministries require submission of documents separately. It is desirable to conform to procurement policies/guidelines stipulated by each ministry. In the case of considering the possibility of additional projects or correction projects, it is necessary to mention in the specifications that creation of estimates and calculation of the necessary number of processes may become necessary. Two types of documents describing tasks and schedules may be prepared: one for external use and another for internal management use. It is desirable to create the one for internal management use which contains the status of progress in the WBS. It is desirable to define the tasks of any responsible persons other than a contractor, such as compete relevant ministries, in addition to the tasks of the contractor. When defining the tasks of responsible persons other than a contractor, coordination becomes necessary. Thus, consultation with relevant ministries is necessary when making a rough draft.
Notes on security -
303
3. Basic design
Item Description Outline of service
operations
Function design, data design, screen design, form design, system
architecture design, external interface design, information security
design, which are based on requirements definition.
Suggested input
(Prepared by
procurer)
・ Requirements definition document
・ Basic design document for existing systems (excluding new development)
・ Security policies prescribed by each ministry
・ Standards for Information Security Measures for the Central Government Computer Systems
Product
(Prepared by
contractor)
・ Basic design document (Function design document, data design document, screen design document, form design document,
system architecture design document and external interface
design document may be separately published)
Matters to be stated in
specifications
[1. Basic requirements to be listed] ・ Items in the basic design document.
・ Design environment and work site are prepared by a contractor at the responsibility and expense of the contractor.
・ Response when there are changes in design due to a law amendment.
・ Cooperation with other contractors concerning the system to be procured.
・ Design of test environment and maintenance environment.
[2. Requirements to be listed when necessary] ・ When developing a design mainly for a generic package, it is
necessary to describe the process of the project and a fit and
gap analysis to see if there are any gaps between the processes
described in the requirements definition document and those of
the package (excluding function addition).
Example/explanation
of descriptions in
specifications
Examples of descriptions in specifications ○ Items in the basic design document.
・ Function design (design for business function, exception handling design and operational function, etc.).
・ Data design (design of conceptual model and logical model using E-R diagram).
・ Screen sign.
・ Form design.
304
・ System architecture design (technical design basis for software configuration and hardware configuration, etc.)
・ External interface design
・ Information security design
○Common requirements for design
・ Design of a live environment where this system runs, in addition to test environment and maintenance environment.
・ Design of environment (hardware and middleware for design and design tools, etc.) and work site, etc. shall be prepared by a
constructor at the responsibity and expense of the constructor.
・ Management based on the Guidelines for Management of Configuration/Change stipulated in the project plan.
・ Work shall be implemented in cooperation with a process management contractor, project partners of this system and
contractors concerning other system, which are to be procured
separately.
○Design mainly for generic packages
・ Since this system will be developed under the premise of using generic packaged software, it is necessary to carry out a fit/gap
analysis to determine the degree of fitness between the
business requirements in the specifications and the introduced
generic packaged software.
Notes on
characteristics of
projects/information
systems
Depending on a project, one contractor may carry out both the
requirements definition and design/development. Please refer to
“6.2.1 Requirements definition” for descriptions concerning the
requirements definition.
Notes on security Information security design
・ Information security design in conformity with the Standards for Information Security Measures for the Central Government
Computer Systems and information security policies of each
ministry.
305
4. Detailed design
Item Description Outline of service operations
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.
Suggested input (Prepared by procurer)
・ Detailed design of the existing system and program source (excluding new development)
Product (Prepared by contractor)
・ 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.)
Matters to be stated in specifications
[1. Basic requirements to be listed] ・ Output items of detailed design [2. Requirements to be listed when necessary] ・ Cooperation for related contractors
Example/explanation of descriptions in specifications
Examples of descriptions in specifications ○ Output items of detailed design ・ Program design (the list of programs to be developed, of
specifications, etc.) ・ Data design (physical model) ・ Screen/form design (design based on development tools to be
used) ・ System architecture design (design based on the
software/hardware to be used) ・ Information security design (design based on the
software/hardware to be used) ○Related contractors ・ Design materials shall be presented to related contractors and
questions and inquiries shall be answered when necessary. Notes on characteristics of projects/information systems
-
Notes on security Information security design ・ Information security design shall be carried out in conformity with
the Standards for Information Security Measures for the Central Government Computer Systems and information security policies of each ministry.
306
5. Unite test, integration test, system test, and connectivity test with other systems
Item Description Outline of service
operations
Creation of source code based on detailed design
Creation of test plans and gaining approval from relevant section
Preparation for test devices and tools
Implementation of each test and response to detected faults
Creation of test results report
Suggested input
(Prepared by
procurer)
-
Product
(Prepared by
contractor)
The following data and documents are related to unit tests,
integration tests and system tests:
・ Test data
・ Test plan
・ Test procedures (test specifications)
・ Test result/quality assessment report
Matters to be stated in
specifications
[1. Basic requirements to be listed] ・ Creation of test plans
・ Creation of test procedures
・ Creation of test data
・ Outline of unit tests, integration tests and system tests
・ Handling of fault correction and investigation of causes
・ Creation of test results/quality assessment report
Example/explanation
of descriptions in
specifications
Examples of descriptions in specifications ○Creation of test plans
The contractor shall submit test plans describing test policies, test
procedures and the reason for tests for each test: unit test,
integration test and system test.
Below are the items to be listed in the test plan
(1) Framework of implementation and roles of contractors
(2) Detailed tasks and test schedule
(3) Test environment (lines and equipment structure in test, and test
coverage)
(4) Test tools
(5) Test data
(6) Assessment criteria
○Creation of test procedures
307
Preparing test procedures by organizing a series of test cases (input
and output and test criteria), test scenario and test data and
procedures.
○Creation of test data
(a) A contractor shall basically prepare the test data
(b) Describe types of test data in the test plan by each test
process
○Outline of unit test, integration test, and system test
(1) Unit test
To test if a program can properly work by the unit of the developed
module.
(2) Integration test
The contractor shall verify the integrity of the software through tests
in which the system is integrated in a stepwise manner to see
programs or modules can function in the entire system.
(3) System test
(a) To see if this system is constructed as required.
(b) To confirm that this system is deliverable.
(c) To implement tests upon setting up assessment criteria to
confirm that the software complies with specifications and is
usable in the live environment.
(d) Performance and stress tests are to confirm that the system
works properly by putting it under stress similar to that of the
live environment.
(e) To confirm the following items:
(i) Functionality
・ Both normal and abnormal system functions can operate according to the specifications.
・ Business coordination processing with other systems can function normally.
・ Meeting information security requirements. (ii) Reliability
・ Meeting reliability requirements.
・ Appropriate recovery processing at the time of failure. (iii) Operability
・ The system operates in accordance with the requirements and instruction and is easy to use.
308
(iv) Performance
・ Appropriate online processing, response time of batch processing and through-put.
・ The system works normally under limiting conditions (data volume, processing volume).
○Handling of fault correction, investigation of causes
・ When a correction is made, confirm that the relevant correction will not negatively affect other programs
In addition to investigating the causes, such as mistakes in
programing or design defect, investigation and analysis shall be
performed with respect to the personnel in charge (for instance, if
faults occur often in modules or components designed/developed
by a specific staff member, investigation shall be focused on other
modules and components designed/developed by the relevant
staff member.)
○Test results/quality assessment report
Report the number of test cases in proportion to program size,
total number of detected faults, rate of detected faults in proportion
to program size, number of completed tests/number of planned
tests and actual number of faults/ estimated faults.
Notes on
characteristics of
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.
309
6. Acceptance test support
Item Description Outline of service operations
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)
・ Acceptance test procedures ・ Report on acceptance tests
Matters to be stated in specifications
[1. Basic requirements to be listed] ・ Creation of acceptance test procedures ・ Securing support staff for acceptance tests ・ Creation of the environment for an acceptance test ・ Preparation of acceptance test data ・ Analysis of faults and presentation of countermeasures ・ Implementation of program modification in line with the
countermeasures prescribed by ministries Example/explanation of descriptions in specifications
Examples of descriptions in specifications ○Creation of acceptance test procedures ・ To create acceptance test procedures including specific
procedures taken by acceptance testers and its results. It should be easy to understand for any person who is not familiar with system operations.
○Securing support staff for acceptance test ・ Acceptance test is led by the Ministry: however, support staff
shall be employed when required. ○Creation of the environment for an acceptance test ・ Prepare an environment for an acceptance test as close to the
actual live environment as possible. ○Preparation of acceptance test data ・ Prepare test data necessary for acceptance test ○Analysis of faults and presentation of countermeasures ・ Analyze faults detected in acceptance tests and gain the
approval of the Ministry on countermeasures ○Implementation of program correction in line with the countermeasures prescribed by ministries ・ Correction based on the approved countermeasures
Notes on characteristics of projects/information systems
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.
Notes on security -
310
7. Migration
Item Description Outline of service operations
Creation of various plans and procedures related to migration operations System migration rehearsal the under live environment and migration to the live environment
Suggested input (Prepared by procurer)
・ Input target data ・ Diagram of migration operations
Product (Prepared by contractor)
・ Migration plan ・ Migration procedures ・ Migration rehearsal specifications/quality assessment report ・ Migration program ・ Migration data ・ Report on migration results
Matters to be stated in specifications
[1. Basic requirements to be listed] New development ・ The contractor shall help the procurer determine the
specifications of migration data and coordinate with concerned parties. The contractor shall develop migration tools and programs when required
・ Data entry from paper-medium materials and data extraction/migration operations from the existing system
The following shall be entered only for migration from the development environment to the live environment in the case of new development, and are compulsory in cases of other service types. ・ Creation of migration plan ・ Creation of migration procedures ・ Creation of migration rehearsal specifications ・ Implementation of migration rehearsal under the live
environment ・ Creation of migration rehearsal results/quality assessment report ・ Implementation of migration to the live environment ・ Creation of migration result report
Example/explanation of descriptions in specifications
Examples of descriptions in specifications ○New development ・ The contractor shall confirm in advance contents and formats of
data and implement migration operations upon confirming with responsible officers of the Ministry of ___ with respect to the method of migration (how to handle white space, sections without data and difference in data format, etc.). The contractor shall develop migration tools and/or programs to carry out migration, on as needed basis.
・ Migration operations include creation and registration of master data necessary for use of this system and conversion and installation of past data. Thus, migration framework shall be developed upon clarifying the roles of ministries related to the division of work necessary for migration. Migration operations
311
shall be carried out in accordance with the following procedures: (1) Organize migration target data upon consultation with the
supervising section, (2) Determine data format for migration to this system and
create tools to integrate the data into this system from that format when necessary,
(3) Create migration data by newly inputting data in accordance with the data format or converging the existing data,
(4) Integrate data into this system using a migration tool, etc., (5) Examine if migrated data is correctly integrated, and (6) Correct data and reconfirm that the data are properly
corrected. ○Migration ・ Contractor shall implement various operations for migration,
such as design/development of migration programs to the database of this system, migration operations and validation confirmation of migrated data, when necessary, presuming that existing data is provided.
・ Data shall be migrated into the live environment after installation in accordance with migration plan. At the time of migrating data, a preliminary rehearsal shall be carried out in accordance with migration plan.
Explanation ・ Migration plan
This document shall describe interested parties and roles, detailed schedule for migration, migration environments, migration methods and methods of preparing migration tools, etc.
・ Migration procedures This document shall describe the following in connection with migration to the production environment: detailed operations, verification methods, verification criteria, contingency plans and time schedules, etc.
・ Migration rehearsal specifications This document shall describe the following in connection with the migration rehearsal: detailed operations, verification methods, verification criteria, contingency plans and time schedules, etc.
Notes on characteristics of projects/information systems
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
Notes on security -
312
8. User education
Item Description Outline of service
operations
Creation of an education plan and operation manual
Holding training for ministry officers
Suggested input
(Prepared by
procurer)
・ Target, venue and period of educational training
・ Operation manual (existing) (excluding new development)
Product
(Prepared by
contractor)
・ Education plan
・ Training text
・ Operation manual
Matters to be stated in
specifications
[1. Basic requirements to be listed] ・ Creation of an operation manual
・ Requirements for holding training for system users (size and period, etc.)
[2. Requirements to be listed when necessary] When a system is large in terms of the number of users and
locations, the following operations are stated to offer an effective
educational environment.
・ Creation of an education plan
・ Provision for an e-Learning function
Example/explanation
of descriptions in
specifications
・ Examples of descriptions in specifications ○Creation of the operation manual
・ Create operation manual containing the method of operation of devices and usage of this system.
○Requirements for holding training for system users (size and period)
・ Implement group training of this system for system users. Create self-learning materials and compile a training guidebook,
including methods of education and training and usage of
teaching materials.
・ Create a training text upon consultation with the Ministry. When creating the text, care must be taken in the method of
explanation and wordings, so that users can acquire the
operation skills of this system in a short period of time. The
contractor shall also give care to make the text understandable
so that users can sufficiently understand by reading it through.
○Creation of the education plan
・ Create the education plan, including education and training
313
environment and the method of education and training, etc.
・ The contractor shall provide an e-Learning function so that learners can easily understand how to use this system in training
conducted by trainees of the central training; and take necessary
measures, such as providing videos of the central training as an
additional training material, when necessary. When distributing
teaching materials, the contractor shall prepare the necessary
number of copies.
Notes on
characteristics of
projects/information
systems
-
Notes on security User education
・ Education on information security shall be offered to system users.
314
9. Transfer to operation/maintenance contractors
Item Description Outline of service
operations
Operation design
Transfer to operation management contractor and maintenance
contractor
Suggested input
(Prepared by
procurer)
(Excluding new development)
・ Operation design (existing system)
・ Operation manual (existing system)
Product
(Prepared by
contractor)
・ Operational design
・ Operation manual
・ Table of maintenance framework (draft)
・ Transfer plan
・ Transfer report
Matters to be stated in
specifications
[1. Basic requirements to be listed] ・ Operation design for operational systems and applications to be
developed
・ Creation of operation manuals
・ Creation of transfer plans and transfer reports
・ Transfer to operation contractor and maintenance contractor prior to the full-fledged operation of a new system
・ Answering to questions and handle requests for amendments regarding operation manuals during the term of the contract
Example/explanation
of descriptions in
specifications
Examples of descriptions in specifications ○Operation design
・ Carry out operation design for operational systems and applications to be developed. Identifying operation works as
“works necessary for safe and stable operations of business and
applications,” the system shall be designed by defining
necessary work requirements in a systematic and
comprehensive manner.
○Operation manual
・ Create an operation manual for the operation of this system
○Transfer plan
Contractor shall create a transfer plan, including transfer
framework/roles in transfer, detailed tasks and schedules, methods of
transfer, assessment methods/criteria for transfer results.
315
The contractor shall handover in accordance with the transfer plan.
After completing transfer, the contractor shall write transfer reports.
○Transfer to maintenance contractor
Operations of software maintenance contractor concerning System ,
which is to be separately procured, will commence from Month,
Fiscal Year N, contractor shall consult with relevant officer and
implement content transfer of this Transfer software at the
responsibility and expense of the contractor by the end of Month,
Year, after selecting a maintenance contractor.
○Transfer to operation contractor
・ In order to contribute to the smooth implementation of operation works of the operation contractor after the start of full-fledged
operations in Fiscal Year N, contractor shall develop, create and
provide necessary documents for the operations of this system,
which is followed by the provision of necessary training for the
operation contractor by establishing a training period.
Notes on
characteristics of
projects/information
systems
Operation tools and procedure manual shall be provided when
necessary.
Notes on security -
316
10. Project management
Item Description Outline of service
operations
Implement project management for design/development operations,
such as progress management, document management, information
and security management, issue/problem management, change
management, configuration management, etc.
Suggested input
(Prepared by
procurer)
-
Product
(Prepared by
contractor)
・ Materials for progress management
・ Table of task management
Matters to be stated in
specifications
[1. Basic requirements to be listed] ・ Progress management
・ Document management
・ Issue/problem management
・ Configuration management
・ Change management
・ Information security management
Example/explanation
of descriptions in
specifications
Explanation ○Progress management
・ Based on progress management materials, the status of progress shall be quantitatively analyzed and operation statuses
shall be reported. Conference/information transmission plans by
each operation process shall be created, and periodical reviews
shall be implemented. When a delay occurs, operation
modification plans, such as addition of workers and revision of
the framework, shall be presented.
○Document management
・ When a contractor makes a correction/renewal of the result of the basic design, it must follow the guidelines for standard
management for the “Plan of Design/Development Phase”
(essentials for document management, essentials for change
management), prepared by the Ministry of XXX.
○Issue/problem management
・ To manage operational issues in a unified manner, establish a
317
process of issue awareness, consideration of countermeasures,
solution and reporting.
○Configuration management
・ To maintain consistency in the development of this software and establish traceability of changes in the project environment.
○Change management
・ When changes to matters listed in the procurement specifications and requirements definition document are
necessary, approval from the relevant ministry shall be gained at
an early stage, after confirmation of the location of change,
description, reason, affected area and the magnitude of
influence, etc.
○Information security management
・ Accident and fault in security systems shall be prevented in advance in each operational stage. Any damage shall be
minimized when it occurs.
Notes on
characteristics of
projects/information
systems
This section describes project management services for the
design/development contractor.
Please refer to “6.2.3 Project management” for project management
services concerning the entire information system procurement.
Carry out EVM progress management in the case of a large-scale
project.
When EVM is conducted by the procurement support service
contractor (process management), the procurement specifications for
the design/development need to include the information to be
reported for progress management.
Notes on security Information security management
・ Accident and fault in security system shall be prevented in advance in each operation stage. Any damage shall be
minimized when it occurs, after promptly reporting to procurer.
318
11. Acceptance
Item Description Outline of service
operations
Make necessary product delivery and carry out repair if deemed
necessary
Suggested input
(Prepared by
procurer)
-
Product
(Prepared by
contractor)
・ Report of project completion
・ Each document
・ Set of programs, including source code, implementation module, etc.
Matters to be stated in
specifications
[1. Basic requirements to be listed] ・ Report of project completion
・ Delivery based on the requirements listed as “deliverable product” in the specifications
・ Making corrections if the deliverables are deemed to need correction
Example/explanation
of descriptions in
specifications
Examples of descriptions in specifications ・ Deliver deliverable product based on the requirements described
in the specifications
・ When the Ministry decides that all or part of the deliverables need corrections, the contractor shall take back the deliverables
immediately, conduct the necessary changes, and provide the
deliverables to which the corrections have been made by the
designated date and time.
Notes on
characteristics of
projects/information
systems
-
Notes on security -
319
6.3.3. Timing of delivery of deliverable product The following table shows the deliverable product and delivery timing information. It is necessary to
list the official name and delivery timing of each product in accordance with the actual situation. The
delivery timing shall be set in expectation of an inspection and correction period.
Service operations Deliverable product Delivery timing
1.Preparation for development environment
-
2.Creation of development plan Project plan Design/development plan
Within two weeks after receipt of order (ARO)
3.Basic design Basic design At the completion of basic design
4.Detailed design Detailed design At the completion of detailed design
5.Unit test, integration test, system test, connectivity test with other system
The following data and documents concerning unit test, integration test, and system test: Test data Test plan Test essentials (test specifications) Test result/quality assessment report
Two weeks prior to each test Two weeks prior to each test Two weeks prior to each test At the completion of each test
6.Acceptance test support Draft of acceptance test procedures Report of acceptance test
Two weeks prior to the test At the completion of the test
7.Migration Migration plan Migration procedures Migration rehearsal specifications Migration rehearsal result/quality assessment report Migration program Migration data Migration result report
Prior to migration Prior to migration Prior to migration At the completion of the project At the completion of the project At the completion of the project At the completion of the project
8.User education Education plan Training text Operation manual
At the completion of the project
9. Transfer to operation and maintenance contractors
Operational design Operation manual Table of maintenance framework (draft) Transfer plan Transfer report
At the completion of the project
10.Project management Progress management material Table of issue management
On as needed basis On as needed basis
11.Acceptance Project completion report Each document Set of programs, such as source code, implementation module
At the completion of the project
320
6.3.4.Suggested input The following table shows the input and timing to be presented to procurers (or proposers) in
advance. It is necessary to list the official name and delivery timing of each input in accordance with
the actual situation.
Service operations Input Timing to present input
1.Preparation for development environment
Outline of new system infrastructure (tentative) Operation environment Operating conditions Requirements definition document
To be included in procurement specifications and appendices at the time of tender publishing
2.Creation of development plan
Requirements definition document List of major operations Relations between procurer and concerned contractors Outline of operations of concerned contractors Operation schedule Tale of division of roles Document standards in ministries
To be included in procurement specifications and appendices at the time of tender publishing
3.Basic design Requirements definition document Basic design document for existing system (excluding new development) Security guidelines stipulated by each ministry Standards for Information Security Measures for the Central Government Computer Systems
To be included in procurement specifications and appendices at the time of tender publishing
4.Detailed design Detailed design for existing system, program source (excluding new development)
At the time of commencement of detailed design
5.Unit test, integration test, system test, connectivity test with other system
- -
6.Ascceptance test support - - 7.Migration Input target data
Diagram of migration installation operations
To be included in procurement specifications and appendices at the time of tender publishing
8.User education Target, venue and period of education (existing) Operation manual (excluding new development)
To be included in procurement specifications and appendices at the time of tender publishing
9.Transfer to operation/maintenance contractors
(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
10.Project management - - 11.Acceptance - -
321
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
Main operations Procurement section
Supporter of process
management
Common infrastructure
contractor
Individual function
contractor
Hardware delivery
contractor, etc.
Operation contractor
Software maintenance
contractor Project management/promotion
Formulation of project plan (revision)
Creation of project scope ◎ ◆ □
Establishment of project framework ◎ ◆ □
Creation of method of operating conferences ◎ ◆ □
Setting up schedule and major milestone ◎ ◆ □
Setting up common WBS ◎ ◆ □
Creation of standard management essentials ◎ ◆ □
Creation of project standards ◎ ◆ □
Project promotion (implementation of project management)
Document management ◎□ ◆□ ○□ □ □ □ □ Guidelines for information security measures ◎□ ◆□ ○□ □ □ □ □ Progress management
Progress management for common infrastructure system
◎ ◆ ○□ △
Progress management for individual function system
◎ ◆ △ □
Progress management in integrated operations
◎ ◆ ○□ △ △ △ △
Quality management
Quality management for common infrastructure system
◎ ◆ ○□ △
Quality management for individual function system
◎ ◆ △ □
Quality management in integrated operations ◎ ◆ ○□ △ △ △ △ Issue/problem management
Issue/problem management for common infrastructure system
◎□ ◆ ○□ △
Issue/problem management for individual function system
◎□ ◆ △ □
Issue/problem management in integrated
operations ◎ ◆□ ○□ △
△ △ △
Change management ◎□ ◆□ ○□ □ □ □ □ Configuration management ◎ ◆ ○□ □ □ □ □ Creation of procurement plan and implementation of
procurement
Example ◎:Approval or confirmation ◆:Support for verification ○:Request for cooperation and coordination □:Implementation △:Support Blank:Participation on as needed basis
322
Main operations Procurement section
Supporter of process
management
Common infrastructure
contractor
Individual function
contractor
Hardware delivery
contractor, etc.
Operation contractor
Software maintenance
contractor Revision of procurement plan ◎□ □ △
Creating of procurement specifications and implementation of procurement
Procurement of production control support service
◎□
Procurement of common infrastructure service ◎□ ◆□
Procurement of individual function service ◎□ ◆□ □△
Procurement of hardware, etc. ◎□ ◆□ △ △
Procurement of operation service ◎□ ◆□ △ △
Procurement of software maintenance service ◎□ ◆□ △ △
Design/development operations
Organizing basic items ◎ ◆ □
Design/development operation for common infrastructure system
◎ ◆ □
△
Design/development operations for individual function system
◎ ◆ △ □
Implementation of integrated operations ◎ ◆ ○□ □ □ □ □ Promotion of works implemented in cooperation of all participants
Integration test ◎ ◆ ○□ □ △ System test ◎ ◆ ○□ □ △ □
Acceptance test ◎□ ◆□ △ △ △ △ △ Creation of various manuals
・Operation manual ◎ ◆ ○□ □ △ △ △ ・User manual ◎ ◆ ○□ □ △ △
Training ◎ ◆ ○□ □ △ △
Construction and operation of test environment ◎ ◆ ○□ □ □ △ △
Construction of live operation environment ◎ ◆ ○□ □ □ △ △
Operations concerning migration ◎ ◆ ○□ □ △ △ △
Creation of Service Level Agreement (SLA) ◎ ◆ ○□ △ △ □ △
Transfer to operation contractor ◎ ◆ ○□ □ △ □
Transfer to software maintenance contractor ◎ ◆ ○□ □ □
・・・・・・
323
6.4. Operation
6.4.1. Definition of procurement area The term “Operation” in this Section refers to service procurement to carry out operation services
for information systems. The Helpdesk may be considered as part of the procurement of operation
services (in some cases, the helpdesk is handled independently), but this Section (6.4 Operation)
does not include specifics regarding helpdesk services.
If concomitant procurement of helpdesk operations is necessary at the time of the procurement of
operation services, it is desirable to create specifications referring to the Section “6.5 Helpdesk,” in
addition to this Section.
Figure 6.4-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
324
6.4.2. Services to be listed in specifications 6.4.2.1 Typical service operations
The following table shows services to be included in specifications. The corresponding SLCP-2007
activities are also given. For actual procurement, correspondence to SLCP activities should be
examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on
Procurement (BGP) are also listed. To write specifications, a draft for procurement specifications
should be prepared by selecting the appropriate items while - coordinating with the corresponding
Program Management Office (PMO).
Service operations Outline of service operations Activities of SLCP-2007
Chapter and section of
specifications
corresponding to BGP
(and its title)
1.Formulation of
operation plan
Formulation of implementation
plan of operation and creation of
operation plan.
Receiving approval from
competent officers.
1.7.1.1
Creation of operation process
plan
10.Requirements
definition of operation
2.Transfer for
operation
Receiving explanations and
documents from system
developers, operators of existing
systems (in the case of existing
systems), installer, etc.
1.7.1.2
Transfer of assets for operation
9.Requirements definition
of migration
(1) Requirements
concerning migration
3.Construction of
operation
environment
Procurement and installation of
utensils to be prepared by the
contractor required for system
operation
3.3.3 Construction of
environment
10.Requirements
definition of operation
4.Education for
operators
Training for system operators. In
the case of transfer, receiving
training/education from the
existing operator. Implementation
of contingency/security training.
1.7.2.4 Training for system
operation
9. Requirements
definition of migration
(2) Requirements
concerning education
5.System
operation
Implementation of operation
services necessary for system
operation.
・System operation monitoring
・Server device monitoring
・Network monitoring
・Job monitoring
1.7.4.1 System operation
1.7.4.2
Monitoring operation and
collection of operation data,
identifying problems, recording
and finding solutions,
improvement of operation
10.Requirements
definition of operation
325
・Log monitoring
・Resource distribution
・Backup and restore
・Media management,
expendables management
・Incident management
・Problem management
・Change management
・Release management
・Configuration management
・Capacity management
・IT service continuity
management
・Availability management
・Response to inquiries
environment
1.7.4.3 Identifying and
improving problems
1.7.4.4 Improvement of
operation environment
6.Service level
operation
Report, improvement at a service
level
1.7.7 Assessment of system
operation
10. Requirements
definition of operation
7.Holding
operation
conferences
Business report at regular
conferences. Consideration for
issues and resolutions when
necessary (monthly, weekly,
annual, immediate reporting, to
ministries)
1.2.6 Review and assessment 10. Requirements
definition of operation
326
6.4.2.2. Explanation on services and examples of descriptions in specifications 1. Operation plan
Item Description Outline of service operations
To receive approval from the officer of a competent authority after formulating operation implementation plans and creating operation plans.
Suggested input (Prepared by the procurer)
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.
Product (Prepared by the contractor)
Operation plan document Organizational chart, etc. (Some ministries require separate submission of installation plans and organizational chart, etc. It is then desirable to comply with procurement policies/guidelines issued by each ministry/agency)
Matters to be described in specifications
To formulate an operation implementation plan, which includes the following items, after coordination with design/development entities and the current operator. [1. Basic requirements to be listed] ・Tasks to be implemented ・Role-sharing table, chain of instruction and command system in implementation framework ・Designation of work hours and work place, etc. and constraints ・Requirements for personnel in charge (skill/ experience/qualification) ・Notification of personnel in charge, compliance with rules when changed, etc. [2. Requirements to be added depending on type/characteristics of project] ・Plan of relevant tasks when contingency tasks are generated, such as construction of operation environments, etc.
Example/explanation on a description in specifications
Examples of descriptions in specifications ○Implementation framework, etc. (1) The contractor shall create an operation plan document (including schedule, implementation framework, etc.) within seven days after a successful bid, and submit it to the supervising section and receive approval. (2) Prior to implementation of the operation, the contractor prepares
327
implementation framework assigning at least two operation support personnel who are engaged in relevant tasks and at least two assistants who assist the operation support personnel, and provide relevant officials with an organizational chart, which includes affiliation/title/name/contact number of the operation support personnel and their assistants. (3) Operation support personnel and assistants shall be stationed at ___ Section and carry out the relevant tasks. (4) When operation support personnel and assistants are to be changed due to circumstances of the contractor, the contractor shall consult with personnel in charge by at least two weeks prior to the change. (5) When changing operation support personnel or assistants, the contractor shall create a transfer document and carry out sufficient transfer and training so as to avoid any disruption to business.
Notes on characteristics of project/information system
(1) There are cases where a design/development contractor formulates operation plans. In such cases, it is necessary to finalize the plan after coordinating with the design/development contractor. (2) If coordination with the existing operator and cooperation/ coordination with the existing operation plan, such as continuity and additional procurement, are needed, a statement to that effect shall be included. (3) When the work place is more than one or re-commissioning is necessary, a statement to that effect shall be included and roles to be shared and a responsibility matrix shall be clarified.
Notes on security (1) When personal information is included in organizational charts, etc., such documents shall be treated in conformity to the degree of significance pursuant to regulations.
328
2. Transfer for operation
Item Description Outline of service operations
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.
Suggested input (Prepared by the procurer)
A transfer plan document from predecessors (system constructor in the case of new system integration; hereinafter the same shall apply) Transfer materials from predecessors
Product (Prepared by the contractor)
○ When receiving a transfer of operation Report on implementation of operation transfer ○When conducting transfer Transfer plan (draft) and transfer materials (to successor)
Matters to be described in specifications
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.
Example/explanation on a description in specifications
Examples of descriptions in specifications ○When receiving transfer of operation (Coordination with concerned contractors and creation of a transfer plan) (1) The contractor of the relevant procurement shall consult with concerned contractors in order to collect the necessary information for the execution of the operation tasks of the operation system and shall create a “transfer plan” in consideration for “operation procedures” issued by the Ministry of ___. (Response to training, etc.) (1) The contractor of the relevant procurement shall receive training for personnel in charge of system operations, read thoroughly the user manual for system operators and develop operation framework before the commencement of operation tests. ○When conducting transfer (1) Operators after Fiscal Year ___ will be separately procured. Thus, if the successor after Fiscal Year ___ (hereinafter referred to as “next winning bidder”) is different from the current winning bidder, the current one shall steadily carry out the transfer to the next winning bidder for smooth operation tasks, under the burden and
329
responsibility of the current winning bidder within contract period of service. The following points shall be observed during transfer. (a) Reporting to the authority concerned in advance on personnel in charge of transfer and details of transfer, etc. and to receive approval before transfer. (b) Creating “Statement of Transfer” which includes an outline of tasks implemented during the contract period, and carry out the transfer to the next winning bidder using the said “Statement of Transfer” after receiving approval from the authority concerned. Details and progress of project tasks, which will not be completed by March 31, ____, shall be appended separately in the “Statement of Transfer.” (c) Based on the transfer plan, approval of the authority concerned shall be gained with respect to the result of the transfer. If approval is not gained, operations shall be carried out by extending the contract period so as not to interfere with operations under the responsibility and burden of the winning bidder.
Notes on characteristics of project/information system
(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.
Notes on security -
330
3. Construction of operation environment
Item Description Outline of service operations
Procurement/installation of utensils necessary for system operation to be prepared by the contractor
Suggested input (Prepared by the procurer)
List of utensils to be prepared (when utensils to be prepared by the contractor in charge of the operation have been defined)
Product (Prepared by the contractor)
Task report (environment construction)
Matters to be described in specifications
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.
Example/explanation on a description in specifications
Examples of descriptions in specifications ○Selection of appropriate utensils/software in accordance with requirements specifications (1) Utensils deemed to be necessary shall be prepared by the contractor on its burden. Examples for such utensils include desks, chairs, shelves, copiers, fax machines, hardware and software necessary for information management, telephone lines, and internet lines, etc. When installing internet lines, it is prohibited to connect to the intra-ministerial LAN. (a) The contractor shall file applications for delivery and installation of utensils (b) The contractor shall conduct preliminary studies for the delivery/installation of utensils (c) The contractor shall prepare components necessary for delivery/installation (d) The contractor shall remove and dispose the packaging of utensils, tools used for delivery and other unnecessary materials as soon as installation is completed. Considering the impact on the environment, efforts shall be made to minimize waste materials as
331
much as possible. (e) The contractor shall basically carry out delivery/installation within business hours on weekdays. Details shall be separately instructed by the Ministry of ___.
Notes on characteristics of project/information system
(1) It is necessary to clarify the roles to be shared by preparation/installation contractors of utensils to be procured, etc.
Notes on security -
332
4. Education of operational workers
Item Description Outline of service operations
Operation staff shall receive education from the current operator or system constructor (design/development).
Suggested input (Prepared by the procurer)
Operational procedures manual
Product (Prepared by the contractor)
Operational procedures manual (revised version) Work report (staff education)
Matters to be described in specifications
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.
Example/explanation on a description in specifications
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.)
Notes on characteristics of project/information system
(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.
Notes on security -
333
5. System operation
Item Description Outline of service operations
To carry out necessary operations, using an operation outline, operation procedures manual and operation tools that have been handed down from the design/development entity or from the existing operator.
Suggested input (Prepared by the procurer)
Operation design document Operation outline Operation procedures manual Documents for application/management concerning tasks (change/release) Security policies issued by ministries/agencies, etc.
Product (Prepared by the contractor)
Operation report Work report (operational tasks) Operation procedures manual (additions and revisions made), etc.
Matters to be described in specifications
To carry out operations necessary for system operation. To extract tasks necessary for the contractor from the operation requirements for the relevant information system and to extract the roles of the procurer and to list them in the specifications. To indicate the timing of implementation of each task. When implementing each task, security policies of each ministry/agency are expected to be observed. ・System operation monitoring ・Server device monitoring ・Network monitoring ・Job monitoring ・Lob monitoring ・Distribution of materials ・Backup and restore ・Media management, expendables management ・Incident management ・Problem management ・Change management ・Release management ・Configuration management ・Capacity management ・IT services continuity management ・Availability management ・Response to inquiries (*Details of services of helpdesk are described in 6.5 Helpdesk), etc.
Example/explanation on a description in specifications
Examples of descriptions in specifications ○ Actual operations
334
The relevant contractor shall carry out the following items in accordance with the regulations stipulated in the operation procedures manual: (A) Monitoring of operation of each system (1) The relevant contractor shall monitor the online status and batch processing. (2) At the time of regular maintenance/scheduled shutdown, each system shall be shut down and started up again. (B) Server device monitoring (1) The relevant contractor shall monitor operations of server devices installed in the iCD and the Ministry concerned, etc. (2) At the time of regular maintenance/scheduled shutdowns, each system shall be shut down and started up again. (C) Network monitoring (1) The relevant contractor shall monitor the operational status of LAN/WAN networks in the Ministry of ___, as well as networks constructed in the iCD and each center (the Ministry concerned and local branches). (D) Job monitoring (1) The relevant contractor shall monitor the job execution of each system. (2) The relevant contractor shall confirm that batch processing has been properly carried out. (3) The relevant contractor shall carry out a batch job that requires manual startup in accordance with the startup instructions. (4) In cases of abnormal processing, the relevant contractor shall re-run, analyze the failure/recover from failure in accordance with the operation procedures manual, or contact the personnel in charge. (E) Log management (1) The relevant contractor shall manage the log of each system. (2)The relevant contractor shall collect log data on unauthorized use, detection of unauthorized intrusions, information leakage, availability/reliability/confidentiality, hardware breakdown, software breakdown, etc. and shall offer cooperation when an officer of the Ministry of ___ performs a log analysis. (F) Distribution of resources (1) Program files, etc. are automatically distributed to servers and clients’ network computers. If it becomes necessary to distribute
335
resources manually due to extraordinary distribution or failure of automatic distribution, etc., the relevant contractor shall do so in accordance with instructions. (G) Backup and restore (1) An automatic backup system is in place. If a restore (reinstating data) becomes necessary for temporal backup operations or recovery, the relevant contractor shall perform the restore in accordance with instructions. (H) Media management and expendables management (1)The relevant contractor shall store media and keep records for information on the media/date of storage, in accordance with the prescribed method of storage. (I) Incident management (1) To uniformly manage incidents detected by the service desk or system monitoring (system failure, device breakdown, generation of error/warning messages, etc.). (2) To implement responses and solutions, if there are any applicable events through searching for incidents in the past. (3)To upgrade the incident to problem management, considering urgency, priority and the scope of impact, if there are no applicable events through searching for incidents in the past. (J) Problem management ・Separation of failure (1) To uniformly manage incidents those have been upgraded from incident management as problems. (2) To separate problems in accordance with the boundary of responsibility among concerned business entities. (3) To convene an extraordinary conference by instructing concerned parties to carry out investigations, on an as needed basis. ・Investigation of/recovery from failure (1) Following the separation of failure, to instruct the concerned contractor in charge of the relevant failure to identify the root cause and to carry out recovery tasks. (2) To supervise the work until recovery and to confirm recovery. (3) To organize a series of responses to failure. (4) To take temporary measures if the problem cannot be fundamentally solved in the short term. To formulate and request the concerned business entity to formulate a permanent solution. (K) Change Management
336
(1) To receive and uniformly manage requests for change presented by a supervising officer from the Ministry of ___ or problem management. (2)To clarify impacts and risks that may be generated by the change and to formulate a change plan in accordance with the request for change. To confirm the change plan with the supervising officer from the Ministry of ___. (3)To judge propriety of the release after a verification test if a program modification is required, following the confirmation of the change plan.
(L) Release management (1) To receive and uniformly manage requests for the release of new hardware, new software and new versions of software those are listed in the activities of change management. (2)To formulate release plans and to implement release. Upon consultation with supervision officer from the Ministry of ___, to implement renewal of a pattern file for antivirus measures and patch application for operating system and middleware, etc. (3)When related business entities are in operation, such as a change in hardware devices, etc., the relevant contractor shall observe the work and confirm the result of the work. (M) Configuration management (1)To record and sort information on the network/hardware/ software/facility which comprises a system, and keep it in the most recent and complete form at all times. (N) Service delivery To respond to plans and improvement on mid- and long-term system operations management: specifically, to carry out the following tasks: (1) Capacity management To monitor, measure, collect data and record performance of resources and report these matters in order to prevent problems such as degradation of performance or lack of resources. (2) To make efforts to maintain appropriate processing capacity, number of servers and network bandwidth, keeping an eye on the trends of usage.
(O) IT service continuity management (1) To implement backups and store backup data in preparation for large scale disasters or data loss. To provide support for discussions on recovery plans and alternative means to be prepared by supervising ministries and related business
337
entities. (P) Availability management (1)To support strengthening quality and security for the stable supply of services.
Notes on characteristics of project/information system
(1) Please also refer to 6.5 Helpdesk if it is necessary to set up a helpdesk serving as an information resource in response to inquiries from users.
Notes on security -
338
6. Service level management
Item Description Outline of service operations
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)
Service level items/definition document Service Level Agreement (SLA)
Product (Prepared by the contractor)
Service level report
Matters to be described in specifications
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
Example/explanation on a description in specifications
Examples of descriptions in specifications ○ Service level items (1) Service level management To report on attainments of service level, based on the concluded “Service Level Evaluation Items and Requirement Standards” and “Evaluation Method for Service Level.” To make specific proposals as a “Service Improvement Plan,” when service level is unattained. ○ Examples of descriptions concerning the conclusion of a Service Level Agreement (SLA) When implementing the relevant tasks, a Service Level Agreement (SLA) shall be concluded between the concerned authority and the winning bidder. Service level evaluation items and required standards will be decided upon during consultation between the concerned authority and the winning bidder after the concluding of an SLA, based on the following requirements: It is necessary to make specific proposals as a basis for the consultation with respect to the “Service Level Evaluation Items and Required Standards,” “Service Level Evaluation Method” and “Service Improvement Plan for Unattained Items.” 1. Normal operation (1) No occurrence of an event that cannot ensure completeness of business data concerning ___ business (such as data falsification). Events attributable to the winning bidder are counted in the number of occurrences, excluding events attributable to other business contractors or events where business has not been affected by implementing recovery measures. (2)Availability of each system is at least 99.9%. However, this is not applied to the period of system shutdown caused by reasons not attributable to the winning bidder.
339
(3) Annual service availability of the support service office (proportion of cases in which appropriate responses have been taken to the total number of inquiries: for example, recording the frequency of inappropriate responses due to inadequate design of management framework or response manual, etc.) is at least 99.9%. 2. Quality of services (1) When implementing the relevant tasks, to make efforts to gain understanding of ___business and the function of ___system, while seeking coordination with the contractors in charge of system development/maintenance, at the expense of the winning bidder. (2) Winning bidder, at their own expense, shall make efforts to understand the product, while seeking coordination with the business entities which deliver hardware and software products to be installed. (3) The winning bidder shall make efforts to understand the entire network configuration, including the next system and peripheral systems, and be aware that the relevant system should work in association with peripheral systems. (4) The winning bidder shall take responsive measures, at their expense and responsibility, in cases where the winning bidder has failed to provide the transfer operations and normal operations at the time of implementation of the relevant business, or exerted influence or troubles to the system of ___ business data. (5) The relevant authority will lend documents necessary for the execution of the relevant operations of a winning bidder, on an as needed basis. Documents lent out shall be returned to the authority when requested or after expiration of the execution period. <<omission>> (9)The winning bidder shall address problems while reporting the situation to and seeking advice from the relevant authority whenever necessary for operations. (10) In the event of violating the provisions stated above, submissions of a report shall be requested and an SLA point may be added.
Notes on characteristics of project/information system
○ Matters to be noted at the time of concluding a Service Level Agreement (SLA) (1) Since operation procurement is in the purchase of services, it is necessary to conclude Service Level Agreement (SLA) as an evaluation index. Non-availability of systems may often be caused by procured hardware/software, and not always attributable to the operation. Shortening of non-available time due to activation of backup operations at the time of system failure may be different depending on architecture. It is therefore necessary to set and evaluate service level values as an index for evaluation of operations with due considerations to these facts. (2)It is also desirable to evaluate the quality of operation report and monitoring. (3) There is an approach of imposing a penalty in accordance with
340
the attainment of service level items. Based on the concept of a contingency fee as part of the “amount of payment (winning bid) = basic rate + contingency fee,” the amount of payment shall be determined in accordance with the attainment of service level items agreed between the procurer and winning bidder. In general, in cases where winning bidder infringes conditions agreed with the procurer, winning bidder’s liability for the damage may be seen as an obligation under socially accepted conventions; however, the most important wish of the procurer is the provision of high quality services from the winning bidder, and the concept of reward should be determined for that purpose. It is not meant to impose unfairly severe conditions on winning bidder. Example of condition (1) The ratio of the basic rate of a contingency fee shall be 9:1. Example of condition (2) The proportion of contingency fee shall be as follows: (2-1) 10% (full amount): Prescribed conditions attained in all service level requirements (2-2) 5%: Unattained prescribed conditions account for less than 5% of total conditions.
(2-3) 2%: Unattained prescribe conditions account for more than 5% and less than 10%. (2-4) 0%: Unattained prescribed conditions account for more than 10% of total conditions.
Notes on security -
341
7. Holding an operation conference
Item Description Outline of service operations
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.).
Suggested input (Prepared by the procurer)
Date of operation for conference (draft)
Product (Prepared by the contractor)
Daily report Weekly report Monthly report Report on an extraordinary conference Operation report Minutes of an operation conference
Matters to be described in specifications
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
Example/explanation on a description in specifications
Examples of descriptions in specifications ○Holding of operation conference The relevant contractor shall hold the following conferences and create reports for each conference. When necessary, the relevant contractor may apply for the participation of related business entities upon confirming with competent an officer of the Ministry of ___. (1) Daily operation conference ・Participant: Relevant contractor ・Date of conference: Open days of government offices and when working on holidays for inspection, etc. ・Name of the report: Daily report ・Details of the report -Occurrence of incidents and failures on the preceding day and its response (number of occurrences/devices/completion) -Response of the helpdesk on the preceding day (number of inquiries) -Operation status of systems on the preceding day (start and closing time of service, details/time/personnel in charge/confirmer of operations) - Schedule of operations work on the relevant day, etc.
342
(2) Weekly operation conference ・Participants: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: Weekly ・Name of the report: Weekly report ・Description: Details of the report - Weekly occurrence of incidents and failures and its responses (Number of occurrences/devices/completion, progress) - Weekly responses of the helpdesk (total number of inquiries, tendency, distribution) - Outline of system operations for the week - Schedule and plan of operations on the following week, etc. (3) Monthly conference ・Participant: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: Monthly ・Name of the report: Monthly report ・Details of the report: - Monthly occurrence of incidents and failures and its responses (Number of occurrences/devices/completion, progress) - Monthly responses of the helpdesk (total number of inquiries, tendency, distribution) -Outline of system operations of the month (status of problems, changes) - Attainment of service level for the month - Results of performance monitoring for the month - Usage of resources for the month - Security status for the month (number of detected unauthorized accesses, number of detected viruses, number of detected falsifications, number of detected unauthorized e-mails, changes in the number of users, number of account locks, new information on vulnerability) - Schedule and plan of operations on the relevant month, etc. (4) Briefing session on inventory status of configuration management ・Participants: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: semiannually ・Name of the report: Configuration management inventory table ・Details of the report: Result of system configuration results, such as server devices and software, etc. (5) Extraordinary conference ・Participant: Competent officers of the Ministry of ___ and relevant contractors
343
・Date of conference: On an as needed basis (in cases where an emergency event occurs) ・Name of the report: Extraordinary conference report ・Details of the report: Report, confirmation, analysis and
consideration for the event or problem. Notes on characteristics of project/information system
-
Notes on security -
344
6.4.3. Deliverable product and timing of submission The table below lists deliverable products and timing of delivery. The official name of each product
and its delivery deadline need to be entered in accordance with the actual situation. Service Deliverable product Delivery deadline 1.Creation of operation plan
Operation plan document Organizational chart
Within the designated date after the conclusion of an agreement. If changed, on an as needed basis
2.Business transfer for operation
○Transferee Operation transfer
implementation report
○Transferor
Transfer plan (Draft), Transfer
materials
(to transferee)
Within one week after the completion of a transfer
Prior to transfer
3.Construction of operation environment
Task report (Environmental construction)
Prior to installation of devices At the time of environmental construction
At the completion of environmental construction
work 4.Education of operation staff
Operation procedures manual (Revised version) Task report (Staff education)
After training
After training 5.system operation Operation report
Task report (Operational tasks)
Operation procedures manual
(Revised)
Daily, weekly, monthly, annually On an as needed basis
Submission after revision 6.Service level management
Service level report Designated date
7.Holding of operation conference
Daily report Weekly report
Monthly report
Report on an extraordinary
conference
Operation report
Conference minutes
Daily Weekly
Monthly
On an as needed basis
Designated date, at the time of final delivery
Within designated days following the conference
345
6.4.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance.
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.Creation of operation plan
Overall schedule Operation outline Operation design document Organizational chart (related business entities and contractors of the relevant systems, the procurers) Role-sharing table (related business entities and contractors of the relevant systems, the procurers) Outline of system subject to operation Configuration information of system subject to operation Details of relevant operations /requirements, such as volume of work
At the time of tender publishing/during the tender period During the tender period At the time of tender publishing
2.Transfer for operation Transfer plan from the predecessor (system constructor in the case of new system integration; hereinafter the same shall apply) Transfer materials from the predecessor
After conclusion of an agreement
3.Construction of operation environment
Utensils subject to preparation, etc. At the time of tender publishing
4.Education of operation staff
Operation procedures manual Disclosed to expected bidders during the tender period. Lent to contractors after conclusion of an agreement. After conclusion of an agreement
5.System operation Operation design document Operation outline Operation procedures manual Documents on the application/management of tasks (change/release) Security policies prescribed by ministries
Disclosed to expected bidders during the tender period. Lent to contractors after conclusion of an agreement.
6.Service level management
Service level items/Definition document Service Level Agreement
At the time of tender publishing At the time of conclusion of an agreement
7.Holding of operation conference
Schedule of operation conference (draft)
At the time of tender publishing
346
Item number Service level item Details of regulation Unit
1 Period of operation service provision
Period of implementing operation services Period
2
Method of reporting operation service provision status/ Time interval
Method of reporting operation status and operation plan/time interval
Time
3 Batch processing time Time spent on batch processing Time
4 Frequency of monitoring physical resources
Frequency of monitoring physical resources, such as performance
Time/day
5 Failure notification process/duration until notification
Presence or non-presence of communication process at the time of an occurrence of operation failure and duration until notification
Presence/non-presence Time
6 Acquisition of backup Details/methods/frequency the of acquisition of backup
Presence/non-presence
7 Backup time Time necessary for backup Time
8 Storing period of backup data
Storing period of backup media Time
9 Backup recovery time Time spent from system shutdown to data recovery
Time
10 Acquisition of log Details/methods/frequency of acquisition of logs that can be provided to users
Presence/non-presence
11 Storing period of log Storing period of media storing logs Period 12 Failure recovery System recovery/support system for failure Presence/non-presence
13 Developing operation environment/removal time
Time necessary for developing environments for implementation of operation services/time for removing operation environment
Time
14
Staff education time Time spent on various education programs for operation staff At the time of commencement of business, regular training, etc.
Time
15 Report Regular report Item
Table 6.4-2 Examples of service level items
347
6.4.5. Division of roles In this Section, examples of roles divided among the relevant contractor, authorities and contractors
of other operations are described.
In separated/breakout procurement, the division of roles among procured services, related
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
Tasks Supervisory
section Operator Succeeding
operator *1
Related business entity
*2 1.Creation of operation plan △ ○ △ 2.Transfer for operation ○ △ 3.Construction of operation environment ○ △
4.Education of operation staff ○ △ 5.System operation ○ △ 6.Service level management △ ○ △ 7.Holding of operation conferences △ ○ △
*1 Succeeding operator: Transferee of operation or business entity conducting operation transfer
*2 Related business entity: Business entity working in corporation with operators, including
maintenance (hardware, software) business entities, iDC business entities, and helpdesk business
entities.
348
6.5. Helpdesk
6.5.1. Definition of procurement area Procurement of helpdesks refers to the procurement of services to construct and operate helpdesk
environments enabling appropriate responses to users’ inquiries in the operation of information
systems (primary response, secondary escalation, data registration, FAQ management, etc.).
In procurement of helpdesk services, helpdesk contractors that manage overall operation services
should be procured separately. There are two cases: one in which the helpdesk is procured
independently and the other in which the operation contractor provides helpdesk services
comprehensively as part of their operation services. This Chapter applies to helpdesk services of the
latter case, and it is necessary to refer to “6.4 Operation” for other operation services.
Independent procurement of a helpdesk is for a large-scale system in most cases. In most of
small-scale system projects, it is procured as part of operations.
In the classification of procurement of services, it is one of the procurement areas in
operation/maintenance phase as shown in the figure below.
Figure 6.5-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
349
6.5.2 Services to be listed in specifications 6.5.2.1 Typical service operations
The following table shows services to be included in the specifications. The corresponding
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 Outline of service operations Activities of SLCP-2007
Chapter and section of specifications
corresponding to BGP (and its title)
1.Creation of operation plan
To create an implementation plan, installation plan and business operation plan for helpdesk operations and submit them as plan documents to the supervisory section of ministries for approval. To implement periodical reviews or revision of plans if necessary for the progress of works.
1.7.1.1 Creation of operation process plans
Chapter X Requirements definition of operation (and outline shall be listed in Chapter II (5) Work description/Deliverable product)
2.Business transfer for operation
To receive explanations and necessary documents from general managers and helpdesk operators from the previous fiscal year. To create transfer plans and materials to be handed to transferees. To implement transfer.
1.7.1.2 Transfer of assets for operation
3.Development of working environment
To prepare telephone, fax, PBX, CTI, servers and software and wiring that are necessary for helpdesk operations.
-
4.Service level management
To conclude SLA and report service levels in preparation for helpdesk operations.
1.7.1.9 Setting operation assessment criteria
5.Helpdesk operation Primary reception, primary response, escalation. To record and analyze details of inquiries. To extract and renew matters posted on FAQ. Remote control of user’s terminal server, etc.
1.7.6.1 Business operation 1.7.6.2 User support
Chapter X Requirements definition of operation (and outline shall be listed in Chapter II (5) Work description/Deliverable product)
6.Survey on user Survey and report on system -
9 Software Life Cycle Processes-Japan Common Fram-2007 (SLCP-JCF 2007), Information-technology Promotion
Agency, Japan (in Japanese) 10 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of
Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf
350
Service operations Outline of service operations Activities of SLCP-2007
Chapter and section of specifications
corresponding to BGP (and its title)
satisfaction users’ satisfaction 7.Helpdesk operation conference
To report on operation of helpdesk operations at regular conferences. To create conference minutes. To discuss issues and solutions when necessary (monthly, weekly, annually, extraordinary briefing session, etc.). To create and submit a helpdesk operations manual and other reports.
1.2.6 Review and assessment 1.7.1.5 Establishment of procedures for system operation 2.1 Documentation process
351
6.5.2.1. Explanation on services and examples of descriptions in specifications 1. Creation of operation plan
Item Description Outline of service operations
To create implementation plans, installation plans and business operation plans for helpdesk operations and submit them as plan documents to competent sections of ministries for approval. To implement periodical reviews or revision of plans if necessary for the progress of works.
Suggested input (Prepared by the procurer)
・Expected installation and rough estimates of the number of users ・Statement of Work ・Overall schedule (draft) ・Organizational chart (draft) ・Operational framework (draft)
Product (Prepared by the contractor)
・Implementation plan ・Helpdesk environmental construction diagram ・Installation plan ・Operation plan, outline of operation implementation (Some ministries require separate submission of documents, such as installation plans and organizational charts, etc. Procurement policies/guidelines issued by each ministry should be followed.)
Matters to be described in specifications
To state the following requirements in specifications, which will be necessary for the judgment of validity of plans by ministries Other materials requiring submission in advance as project plan documents shall be listed as requirements. [1.Basic requirements to be listed] ・Formulation of business implementation plans ・Formulation of installation plans ・Formulation of business operation plans ・Operation management [2. Requirements to be added depending on type/characteristics of project] ・In the case of separate procurement for operations, it is necessary to clarify the consistency with the operation plan of the operator.
Example/explanation on a description in specifications
Examples of descriptions in specifications ○Formulation of business implementation plans The contractor shall, in advance, create a helpdesk business operation plan as a part of formulation the of business implementation plan (hereinafter referred to as the “business implementation plan document”) and gain approval of the supervisory department of the Ministry of ___. The following are the details of the business implementation plan (1) Overall schedule
352
Item Description (2) Product (3) Procedures for revision of plan and procedures for change management ○Formulation of installation plan The contractor shall, following the formulation of a business implementation plan, create a helpdesk business installation plan, which describes work plans during the installation period, (hereinafter referred to as the “implementation plan document”) and obtain approval from the supervisory department of the Ministry of ___. The following are the details of the installation plan. (1) Installation schedule (2) Environment development plan for helpdesk operations (3) Education plan for helpdesk staff (4) Implementation framework (5) Conferences (6)Staffing plan (during installation period) ○Formulation of business operation plan (1) Formulation of business operation plan The contractor shall, prior to the commencement of the relevant service, create a helpdesk business operation plan, which describes helpdesk operations after the start of the service, (hereinafter referred to as the “business operation plan document”) and obtain approval from the supervisory department of the Ministry of ___. The following are the details of creating a business operation plan. (i) Helpdesk business operation plan (ii) Implementation framework (iii) Conferences (iv) Staffing plan (during the period of service provision) (v) Procedures for revision of plans and procedures for change management (2) Formulation of the outline of business operation implementation The contractor shall, prior to the commencement of the relevant service, create an outline of helpdesk business implementation, which describes helpdesk operations after the start of the service, (hereinafter referred to as the “business operation implementation outline”), based on the “Outline of Operation and Maintenance of Information Operation Center Related to ___ operations) (Day__ Month__ Year__) (hereinafter referred to as the “Operation/Maintenance Management Outline”) and obtain approval from the supervisory department of the Ministry of ___. For the formulation of the business operation implementation outline, the contractor shall seek coordination with the general manager and
353
Item Description personnel in charge of operation services. Flow, communication means and details of escalation shall also be reflected on the business operation implementation outline upon consultation with the manager and personnel in charge of operation services. The following are the business operation implementation outlines to be created. If the prepared business operation implementation outline is not sufficient, a decision shall be made upon consultation with supervisory department of the Ministry of ___ after contract is made. (i) Outline of document management (ii) Outline of service index management (iii) Outline of issue/problem management (iv) Outline of communications management ○Operation management The contractor shall carry out operation management of the relevant business, based on the business implementation plan, installation plan and business operation plan, mentioned above.
Notes on characteristics of project/information system
When a helpdesk is procured together with an operation, it is necessary to add the details of a formulating service operations plan prescribed in 6.4 Operation, in addition to the relevant matters listed here.
Notes on security Compliance with the outline of implementing information security measures
354
2. Business transfer for operations
Item Description Outline of service operations
To receive explanations and documents from the general manager and former helpdesk operator, etc. To create transfer plans and materials for transferee and implement the transfer.
Suggested input (Prepared by the procurer)
・Transfer plan from predecessors (system constructor, in the case of new system integration; hereinafter the same shall apply). ・Training on transfer materials, business details, operational tasks, and security etc. from predecessors.
Product (Prepared by The contractor)
・Transfer plan to successors ・Transfer materials to successors ・Report on transfer
Matters to be described in specifications
[1. Basic requirements to be listed] ・Transfer requirements from predecessors ・Creation of transfer plan and transfer materials to the successors [2. Requirements to be added depending on type/characteristics of project] ・To state requirements for data transfer in cases where data, such as data on FAQ, are to be transferred.
Example/explanation on a description in specifications
Examples of descriptions in specifications ○Transfer from predecessors The contractor shall receive necessary matters for the tasks of relevant operations, such as know-how in helpdesk operations from the integrated operation monitoring (under transition) company. The contractor shall hand over data related to the relevant systems. The contractor shall create transfer plans and report the completion of transfer. (1) Transfer works from predecessors (i) Predecessors shall create a “transfer plan” in accordance with the instructions of the integrated operational monitoring contractor (under transition). Predecessors shall also create a “report on completion of transfer” when the transfer work has been completed. The overall schedule shall be listed in the “preparation and transfer of the integrated operational monitoring.” (ii) The contractor shall receive the transfer from the integrated operational monitoring (under transition) contractor and prepare the environment, while the integrated operational monitoring (under transition) contractor implements the actual integrated operational monitoring work. The contractor must not cause delays in operational work of the integrated operational monitoring (under transition) contractor.
355
Item Description (iii) The contractor shall initiate the transfer. The transfer shall be carried out in consideration to the following matters.
(a) To proactively acquire system configuration and operation details from the design document and documents related to operation, etc.
(b) When making inquiries to the integrated operational monitoring (under transition) contractor, such inquiries shall be made upon gaining the full understanding of the design document and documents related to operations, etc.
(c)Upon consulting with the integrated operational monitoring (under transition) contractor, the method of making questions and inquiries shall be selected so as not to interfere with the operations of the integrated operational monitoring (under transition) contractor.
(iv) Data transfer The contractor shall receive all the following data concerning the relevant system from the integrated operational monitoring (under transition) contractor. The contractor shall make efforts to understand the transferred data. ・Business data ・Operation related data (indent management data, FAQ data of the helpdesk, configuration management data, etc.) ・All the data filed in the library management system (design documents, procedures manuals, definition files, etc.) ・All data in the registry (Backup tape registry, iCD visitor registry, etc.) ・Other data (paper data, data stored in external media, etc.) ○Transfer to successors Training on business details, operational tasks and security, etc. shall be carried out promptly after the conclusion of an agreement with the successor. Transfer work is planned under the assumption of actual operation. (1) The contractor shall carry out the transfer to the successors with respect to the tasks and operation results, before termination of the contract. (2) The contractor shall enable successors to receive system maintenance and expansions without depending on specific product/technology, when implementing the transfer. (3) The contractor shall formulate transfer plans, create transfer materials, and obtain approval from the office of ____. (4) The contractor shall follow the instructions of the office of ___ with respect to transfer period and deadlines, etc. (5) The contractor shall answer questions from the successors when
356
Item Description there is an omission in transfer materials, etc. even after the termination of the contract.
Notes on characteristics of project/information system
In the case of new development, it is desirable to receive the transfer from the design/development business entity. It is also desirable to receive the transfer from the supervisory section if it is difficult to carry out transfer from predecessors.
Notes on security -
357
3. Development of work environments
Item Description Outline of services To prepare telephone, fax, PBX, CTI, servers and software and
wiring, which are necessary for helpdesk operations.
Suggested input (Prepared by the procurer)
・Constraints on wiring ・Details of system reform and system improvements that are needed for the revision of the helpdesk operations manual
Product (Prepared by the contractor)
・Helpdesk educational materials ・Helpdesk manual ・Telephone lines for the helpdesk ・Telephone line installation diagram for the helpdesk ・Telephone lines for an Interactive Voice Response (IVR) server ・Telephone line installation diagram for the IVR server
Matters to be described in specifications
[1. Basic requirements to be listed] ・Construction of the helpdesk environment ・Wiring [2. Requirements to be added depending on type/characteristics of project] ・Organizing helpdesk tasks ・Creation of the helpdesk manual ・Education for helpdesk staff ・Report on the helpdesk installation status ・Revision of the manual due to organizational changes and system improvements.
Example/explanation on a description in specifications
Examples of descriptions in specifications [1. Basic requirements to be listed] ・Construction of the helpdesk environment (preparing telephone, fax, PBS, CIT, servers and software) (1) Preparation of utensils necessary for operations (i) The contractor shall prepare utensils deemed necessary for operations at its own expense. Utensils include desks, chairs, shelves, media storage cabinets, copiers, fax machines, hardware and software for information management, internet connections, and telephone lines, etc. When installing an internet line, it is prohibited to connect to the intra-ministerial LAN. (ii) When the contractor concludes that the number of helpdesk terminals and operation management terminals is not enough, the contractor shall prepare the similar terminals as those prepared by Bureau of ___, on an as needed basis. (iii) The contractor shall file an application for delivery and installation
358
Item Description of utensils. (iv) The contractor shall conduct a preliminary study for delivery and installation of utensils. (v) The contractor shall prepare the necessary components for delivery and installation. (vi) The contractor shall remove and dispose of the packaging of utensils and tools used for delivery and other unnecessary materials as soon as installation is completed. Considering the impact on environment, efforts shall be made to minimize waste materials as much as possible. (vii) The contractor shall basically carry out delivery/installation within business hours on weekdays. Details shall be separately instructed by the Bureau of ___. (2)Construction of the helpdesk environment The contractor shall construct the helpdesk installation place and environment. When implementing remote monitoring, the contractor shall develop an environment which enables remote monitoring. The contractor shall also prepare lines connecting with the office of ___. ○Requirements concerning wiring (1) The contractor shall perform an on-site study on wiring: specifically, confirmation of pathway of optical fiber and LAN cables, etc. (under the floor, on the floor, vertical pipeline, in-ceiling piping, etc.) is required. (2) The contractor shall gain the approval of the Bureau of XXX for a wiring pathway. (3) The contractor shall carry out wiring operations. (4) The place of operations in the data center should not be wired. The contractor shall secure communication means in other places at its own expense. [2. Requirements to be added depending on type/characteristics of project] ○Organizing helpdesk operations As a preparation for helpdesk operations, the contractor shall implement the following operations. The contractor shall also be responsible for any other necessary operations. (1) Preparation for access to FAQ information In ___ system, FAQ information will be disclosed via the Kasumigaseki WAN to system users. Since the contractor cannot refer to this FAQ information, it shall prepare its own environment for reference for helpdesk operators, etc. by receiving initial FAQ
359
Item Description information from the supervisory department of the Ministry of ___. Refer to “Response to FAQ information for system users” for details of operations concerning FAQ information. (2) Creation of an operations manual The contractor shall, by the commencement of the relevant business, create a helpdesk operations manual concerning the duties of telephone operators and operation procedures of the helpdesk system(note) (hereinafter referred to as the “operations manual”), based on the business operation plan and the business operation implementation outline. (Note) It refers to the environment in which the contractor in charge of operation services and the one in charge of the helpdesk confirm the operations of ___ system, allowing the operation of the same business applications with ___ system by registering pseudo data. ○Education for helpdesk staff In order to make smooth implementation of the relevant operation, the contractor shall, at its responsibility, provide education necessary for helpdesk staff, including operators, before the commencement of service. When providing education for helpdesk staff, the contractor shall make effective use of FAQ contents and simulations (mock environment) and create educational materials, such as education manuals, thus providing efficient and effective education within the contractor’s capacity. The following are details of education for helpdesk staff and support of the Ministry of ___. (1) Education The contractor shall carry out efficient and effective education with respect to the following educational contents: (i) Details of the overall operations of ___. (ii) Function and operations of the ___ system (iii) Details of the operation implementation outline (iv) Details of the operations manual (v) Information security measures (vi) Other necessary education
○Report on helpdesk installation status Status of helpdesk installation operations shall be reported to the supervisory department of the Ministry of ___ on the occasions of the following conferences. The contractor shall convene meetings when necessary to confirm the installation status, in an attempt to grasp the situation.
360
Item Description In the event of an emergency or a serious problem that may disrupt the commencement of a relevant service, the contractor shall immediately report to the supervisory department of the Ministry of ___ ○ Responses through organizational changes and improvements of ___ system, etc. When the revision of documents, including the business operation plan document, business operation implementation outline, and manuals, etc., becomes necessary along with organizational changes and/or system improvements, the contractor shall promptly revise the relevant documents upon consultation with the supervisory department of the Ministry of ___. When necessary, the contractor shall receive information from the design/development contractor with respect to the details of improvements in the ___ system necessary for the revision. Efforts shall also be made not to interfere with the execution of the relevant operation through information sharing and thorough education and information provision to employees engaged in operations.
Notes on 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.
361
4. Service level management
Item Description Outline of service operations
To conclude a SLA necessary for helpdesk operations and provide report on the service level.
Suggested input (Prepared by the procurer)
・Service level items/definition document
Product (Prepared by the contractor)
・Service Level Agreement (SLA) ・Service level report
Matters to be described in specifications
*When a helpdesk is procured together with an operation, it is necessary to add the details of service works for the formulating plan prescribed in 6.4 Operation. “6.5.4 Suggested input” lists service level items in the examples of specifications for independent procurement of helpdesk operations. [1. Basic requirements to be listed] ・Service level items (operation ratio, abandon rate, backlog rate, call back rate, target response time, response time adherence rate, target support time, support time adherence rate, etc.) ・Creation of an SLA ・Support when the service level has not been achieved
Example/explanation on description in specifications
Examples of descriptions in specifications ○Service level items Requirements for the relevant category are as follows: (1) Index for service level By assessing the status of achievement of each item of service level in the following table on a monthly basis, the contractor shall report its three months’ result to the Ministry of ___. The degree of achievement of service level during the relevant period shall be confirmed based on the consultation between the contractor and the Ministry of___, by adding some elements, such as an improvement plan, to the monthly status of service level achievement reported by the contractor every month. Table: Index of the degree of service level achievement Achievement level Conditions A: Achieved designated conditions in every service level item B: The number of unachieved service level items accounts for less
than 5% of the total number of service level items in the preceding three months
C: The number of unachieved service level items accounts for more than 5% and less than 10% of the total number of service level items in the preceding three months
D: The number of unachieved service level items accounts for more
362
Item Description than 10% of the total number of service level items in the preceding three months
(2) Measures for improving the service level achievement rate When unachieved service level items are attributable to the contractor, the contractor shall make efforts to improve the achievement rate through the following measures: (i) Free response When the SLA has not been consummated for reasons attributable to the contractor, the contractor shall consider and implement its own improvement measures (revision of procedure, installation of framework/tools, tests/inspections, etc.,) and the necessary operations shall be provided for free at the expense of the contractor. (ii) Revision of organization/appointment of full time chief supervisor In the cases of “achievement level C” or lower, the contractor shall not make the chief supervisor (manager of assistant manager) be engaged in other works than those cited in the relevant agreement. (3) Measures for the cases in which the achievement of service level continues to be difficult When the quality of service is extremely abysmal for reasons attributable to the contractor and prospect of improvement is low, the reward may be reduced. ○ Creation of an SLA and conclusion of a Service Level Agreement. The contractor, based on the definition of service level, shall create a service level agreement (SLA) (draft) clarifying the items of service level to be provided, to the supervisory department of the Ministry of ___ and their index before one month of the commencement of services and conclude the Service Level Agreement (hereinafter referred to as “SLA”) with the supervisory department of the Ministry of ___. The contractor shall comply with the concluded SLA. ○ Response when service level has not been achieved. SLA shall prescribe responses to the cases where the service level has not been achieved, which includes revision of service index and review of the contents of agreement, etc.
Notes on characteristics of project/information system
-
Notes on security
-
363
5. Helpdesk operations
Item Description Outline of services Primary reception, primary response, escalation
Recording and analysis of inquiries Extraction and renewal of matters to be posted on the FAQ Remote control or users’ terminal, etc.
Suggested input (Prepared by the procurer)
-
Product (Prepared by the contractor)
・FAQ information ・Report on availability status ・Information on history of inquiries and responses ・Daily report ・Weekly report ・Monthly report
Matters to be described in specifications
[1. Basic requirements to be listed] ・Primary reception, primary response, escalation -Reception time -Unitary support -Escalation -Primary response -Inquiries handled at the helpdesk ・Recording and analysis of inquiries, extraction and renewal data posted on the FAQ: ・Requirements for completion of inquiries
Example/explanation on a description in specifications
Examples of descriptions in specifications ○Primary reception, primary response, escalation (1) In principle, operator services shall be available between 9:00 and 18:00 excluding holidays (days stipulated in Article 1 of the Act on Holidays of Administrative Organs). Inquiries by fax and telephone calls shall be accepted 24 hours a day. If operator services are to be shortened or closed for several days, the contractor shall notify the Ministry of ___ to that effect in advance, and the restricted time zone mentioned above can be lifted only when the Ministry of ___ has approved of it. (2) Inquiries from officers of the Ministry of ___ by fax, telephone calls or e-mail shall be handled in a unified manner. (3) Decisions shall be made on whether an inquiry can be answered at the helpdesk. If it is solvable at the helpdesk, a primary response shall be made. If not, the inquiry shall be shifted to the secondary level. (4) Prepare responses to inquires that are deemed to be solvable at
364
Item Description the helpdesk and provide answers to users. (5) Inquiries to be handled at the helpdesk shall be as follows: ・Breakdown of a network computer and/or printer of a client ・Matters related to functions of the business system ・Operating procedures of software and/or devices ・Other matters related to the overall system, etc. ○ Recording and analysis of inquiries, extraction and renewal of data posted on the FAQ (1) To record user information and details of inquires with respect to all the inquires in the helpdesk system (2) To record details of answers in the helpdesk system after the answers have been made. (3) To select and post frequently asked questions and answers in the FAQ
Notes on characteristics of project/information system
-
Notes on security -
365
6. Survey on user satisfaction
Item Description Outline of service operations
Implementation of survey on system user satisfaction and report of the results
Suggested input (Prepared by the procurer
Questionnaire survey
Product (Prepared by the contractor)
Report on the survey on user satisfaction
Matters to be described in specifications
[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
Example/explanation on a description in specifications
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 -
366
7. Helpdesk operation conference
Item Description Outline of service operations
To report on helpdesk operations at regular conferences, etc. To discuss issues and solutions when necessary (monthly, weekly, annually, special briefing session, etc.). To create and submit reports on conferences.
Suggested input (Prepared by the procurer)
・List of deliverable products ・Implementation schedule (draft) [Dates of operation conferences (draft)]
Product (Prepared by the contractor)
・Monthly report ・Minutes
Matters to be described in specifications
To select written documents to be reported and submitted and indicated to that effect. Review and approval process shall be conducted at an appropriate timing. [1. Basic requirements to be listed] ・Creation and review of reports ・Outline, frequency and participants of conferences that require reporting and approval processes.
Example/explanation on a description in specifications
Examples of descriptions in specifications ○Creation and review of reports The contractor shall report to the supervisory department of the Ministry of ___ with respect to the status of helpdesk operations in the following conferences. The contractor shall make efforts to understand the status by holding conferences to confirm availability status, on an as needs basis, and prepare reports. In the event of an emergency or serious problem that may interfere with the relevant business, a report shall be made immediately for the consideration of countermeasures, without waiting for a regular conference. ○Outline, frequency and participants of conferences that require reporting and approval processes The contractor shall participate in the following conferences that are held by the entire operation center. Operational briefing sessions and annual assessment conferences shall be held at a venue (scheduled to be in Tokyo) designated by the supervisory department of the Ministry of ____. The venue of individual coordination conference shall be coordinated among concerned parties, when necessary. Details of conferences shall be determined after the conclusion of an agreement, based upon
367
Item Description consultation with the supervisory department of the Ministry of ___. (i) Conference on installation reports To report on the progress of developing the helpdesk environment and staff education, etc., during the period of helpdesk installation. Frequency: Every other week Participant ・Secretariat of ___ system ・General manager ・Helpdesk management contractor (ii) Operation briefing session To report to the Secretariat of ___ system on the operational status and service level index. Frequency: Once a month Participant ・Secretariat of ___ system ・General manager ・Operation service contractor ・Helpdesk management contractor ・Application maintenance service contractor ・Hardware maintenance service contractor (iii) Annual assessment conference To report on the performance of services and responses from the preceding year and make assessments of the validity of the service level index. Frequency: Once a year Participant ・Secretariat of ___ system ・General manager ・Operation service contractor ・Helpdesk management contractor ・Application maintenance service contractor ・Hardware maintenance service contractor (iv) Individual coordination conference To be held whenever coordination is separately needed. Frequency: On an as needed basis Participant: To be arranged on an as needed basis
Notes on characteristics of project/information system
-
Notes on security -
368
6.5.3. Deliverable products and timing of delivery The table below lists typical deliverable products and the timing of delivery. The official name of
each product and its delivery deadline need to be entered in accordance with the actual situation.
Service Deliverable product Delivery deadline
1.Creation of operation plan
Implementation plan document Helpdesk environmental construction diagram Establishment plan document Operation plan document, outline of operation implementation
Within two weeks after the conclusion of an agreement Within two weeks after the conclusion of an agreement Within one month after the conclusion of an agreement Before commencement of service
2.Business transfer for operation
Transfer plan document to successors Transfer materials to successors
One month prior to transfer
3.Development of operation environment
Helpdesk education materials Helpdesk operations manual Telephone lines for the helpdesk Installation diagram of telephone lines the for helpdesk Telephone lines for IVR server Installation diagram of telephone lines for IVR server
Before commencement of service
4.Service level management
SLA Service level report
Before commencement of service Monthly
5.Helpdesk operations
FAQ information Report on operation status Information on inquires/responses
Monthly Information on inquires/responses: at the time of the completion of a task
6.Survey on user satisfaction
Report on the results of the survey on user satisfaction
By designated date
7.Helpdesk operation conference
Monthly report Report on completion Minutes
Monthly By designated date
369
6.5.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance.
the official name of each product and its delivery deadline need to be entered in accordance with the
actual situation.
Service Input Timing for presenting input
1.Creation of operation plan Planned establishment and estimated number of users Table of division of roles Overall schedule Organizational chart Operational framework
To be listed in specifications and appendix at the time of tender publishing
2.Business transfer for operation
Transfer documents from predecessors (system constructor in the case of new system integration) Transfer materials, operational procedures, operational tasks, and training on security, etc. from predecessors
To be listed in specifications and appendix at the time of tender publishing
3.Development of work environment
Restrictions on installation of lines 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
4.Service level management Service level items/definition document
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
370
Examples of service level items Number. Service level item Regulations Unit
1
Open hours of helpdesk (response to failures)
Open hours of the helpdesk dealing with faults From hour to hour
2
Open hours of helpdesk (regular inquiries)
Open hours of the helpdesk for regular inquiries
3 Average response time Time spent on resolving problems Hour(s)
4 Primary response time Time spent by operator from receiving failure report to providing primary response
Hour(s)
5 Number of inquiries to helpdesk
Average number of inquiries per day Case/day
6
Call busy rate Call abandonment rate
Call busy rate: Calls failed to be connected Call abandonment rate: Calls failed to be answered
%
7 Rate of problems solved at helpdesk (time)
Percentage of problems solved (closed) within the designated period of time
%
8 Hour/times of helpdesk escalations
Percentage of time spent and frequency until escalation %・number of times
9 Helpdesk backlog rate Percentage of unsolved problems at the end of the day %
10 Helpdesk call back rate Percentage of call backs for inquiries once completely answered or fixed
%
11
Service hours for the application of use related to service desk information system
Application for intranet/internet use (application for the use of common ID management system (LDAP)), application for e-mail use and application for mobile use, etc.
From hour to hour
12 Date of service desk application process Time (days) to process various applications for use
Day
13 Report Regular report Item
14 To make reception status available on the website, enabling understanding of the inquiry status, in cases of changes in the business system
Item
371
6.5.5. Division of roles In this Section, examples of roles divided among helpdesk operators, authorities and contractors of
other services are described.
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
Task Supervisory section
System constructor
HW maintenance contractor
SW maintenance contractor
AP maintenance contractor
Operation contractor
iDC contractor
Helpdesk contractor
Creation of operation plan ○ △ - - - △ △ ○
Business transfer for operation
○ ○ △ △ △ △ △ ○
Development of work environment
△ - - - - △ △ ○
Service level management ○ - - - - △ - ○
Helpdesk operations △ - △ △ △ △ △ ○
Survey on user satisfaction ○ - - - - - - ○
Helpdesk operations conference (report)
○ - △ △ △ ○ △ ○
Helpdesk operations conference (assessment)
○ - ○ ○ ○ ○ ○ ○
* System constructor applies only in the cases where new system integration and transfer for
operations are to be carried out.
372
6.6. Maintenance
Maintenance operations are services to repair errors that occurred after the start of information
system operations and to respond to requests for minor modification of functions in the system.
Services in this phase include regular maintenance (regular inspection) carried out to prevent faults
and problems, emergency maintenance in the event of a problem or fault, and support for system
users and the supervisory sections, etc.
Since the details of services in this phase are formulated in the preceding phase of
“design/development,” the product of maintenance design is the input in this phase.
Details of four services implemented in maintenance are shown in Table 6.6.1.
Classification of detailed services Definition
6.6.1. Hardware maintenance HW maintenance, (server, storage, common network computer, office printer, network function: router, switch, etc.) (including software installed in hardware)
6.6.2. Software maintenance Maintenance of commercial OS, commercial middleware, and commercial application software(excluding OS, middleware, business software of OSS)
6.6.3. Application maintenance Maintenance of business application software, excluding commercial OS and commercial package software (including OS, middleware and business software of OSS)
6.6.4. System infrastructure maintenance Maintenance of “EIP,” “open webservers, “groupware, fileserver, mail server,” “integrated account management, authentication, authorization (access control),” “integrated directory,” “WAN, intra-ministerial LAN, DNS/DHCP/Proxy, remote access,” and “network lines,” which are listed in “Chapter V: Description of Technical Domain” of technology reference model.
Table 6.6.1 Classification of detailed services and definition of maintenance
373
6.6.1. Hardware maintenance 6.6.1.1. Definition of procurement areas
Hardware maintenance is the maintenance service for hardware (server, network computer, printer,
storage, office printer, network functions: router and switch, etc.).
In service procurement concerning hardware maintenance, goods (provision of devices),
installation/coordination of devices, and development of environment may be procured under the
same agreement. However, this section exclusively describes services concerning hardware
maintenance.
Table 6.6.1-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
374
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 Activities of SLCP-2007
Chapter and section of specifications
corresponding to BGP (and its title)
1.Formulation of hardware maintenance plan
Formulation of the hardware maintenance plan (maintenance work plan, work framework, etc.)
1.8.1.2 Creation of plan and procedures
Chapter VI (2) Requirements for hardware maintenance (and outline shall be listed in Chapter II (5) Work description/ deliverable product)
2.Service level management
Concluding an SLA and recording work status in relation to service the level management index, when ensuring the quality (level) of service is necessary.
-
3.Regular maintenance/regular inspection
Preventative inspection and changing of expendables to be carried out once or more times per year, pursuant to the requirements for maintenance, etc.
1.8.2.1 Problem report or analysis of request for modification
4.Fault support On-site support for hardware faults 1.8.3.1 Analysis and decision on modification part 1.8.3.2 Implementation of modification
5.Support for version upgrade
Providing release information, such as firmware, etc., and upgrading work
1.8.3.2 Implementation of modification
6. Technical support Technical support based on requests made by the supervisory section or operation support contractor, etc.
1.7.6.2 User support 1.8.2.2 Replay or inspection of problems
375
6.6.1.2.2. Explanation on services and examples of descriptions in specifications 1. Formulation of hardware maintenance plans
Item Description Outline of service operations
To formulate hardware maintenance plans (including maintenance work plans and organizational charts listing emergency and non-emergency contact numbers, etc.)
Suggested input (Prepared by the procurer)
・Maintenance outline ・Maintenance procedures ・Maintenance plan (draft) ・SLA (draft) ・Statement of Work (concerned business entities and the procurer of the relevant system)
Product (Prepared by the contractor)
・Hardware maintenance plan documents (including progress chart, emergency/non-emergency contact list, maintenance organizational chart, etc.)
Matters to be described in specifications
To indicate requirements for the formulation of a maintenance plan [1. Basic requirements to be listed] ・Maintenance time ・Details to be included in the plan (work schedule, emergency contact list, list of maintenance centers, etc.) ・Deadline for submission of the plan ・Roles of concerned parties in maintenance work (refer to 6.6.1.5 for an example of division of roles) [2. Requirements to be added depending on type/characteristics of project] ・Compliance with the SLA
Example/explanation on a description in specifications
Examples of descriptions in specifications [1. Basic requirements to be listed] (i) Hours of on-site maintenance work shall be from 9:00 to 18:00 excluding days public offices are closed (including holidays and national holidays). However, if hardware failure may cause serious impact on business, maintenance and inspections involving system shutdown shall be available outside of the above hours. (ii) The contractor shall create a maintenance plan for regular inspections, hardware maintenance work and a maintenance organizational chart for emergency/non-emergency cases, which shall be submitted and approved by the supervisory section within 14 days of receiving the order. (iii) When formulating a maintenance work plan, the contractor shall be fully careful not to interfere with business by (for example) avoiding system shutdowns (service suspension). The contractor shall be
376
Item Description prepared to work on holidays if the maintenance work may influence business, based upon consultation with the supervisory section with respect to the dates of work. The contractor shall create a maintenance plan by arranging workdays and time tables in consideration for minimizing system shutdown time/maintenance time, while coordinating the work schedule of regular inspections/regular maintenance with operation/maintenance-related companies. (iv) The contractor shall establish a helpdesk to be able to respond quickly to inquiries during regular service hours in the event of fault of devices as well as when requests are made from the supervisory section, and gain approval from the supervisory section. Maintenance staff shall be engineers with sufficient knowledge and experience on devices covered by maintenance. [2. Requirements to be added depending on type/characteristics of project] (v) The contractor shall conclude an SLA, based on specifications and proposals submitted at the time of procurement by the contractor. The contractor shall also create a maintenance plan giving due consideration to the maintenance framework for preventive maintenance and trouble-shooting that are necessary for attaining the index for service level management.
Notes on characteristics of project/information system
-
Notes on security -
377
2. Service level management
Item Description Outline of service operations
To manage service level by setting a service level index and target values when it is necessary to ensure the quality (level) of services associated with hardware maintenance.
Suggested input (Prepared by the procurer)
・SLA (Draft) (including service level management index)
Product (Prepared by the contractor)
・SLA (including service level management index) ・Service level management plan ・Service level report
Matters to be described in specifications
To be specifically stated in service level management index and the SLA. Such documents as the service level management index and SLA are drafted by the contractor and shall state to the effect that an agreement (contract) will be concluded upon consultation between the two parties and may change after consultation. If strict compliance with an SLA is demanded, the documents shall mention periodical reviews on the performance of the service index as well as the improvement process or penalties for cases of non-compliance. Since service level management is not a compulsory requirement, full discussions shall be conducted on whether an SLA needs to be applied to a given procurement project. [2. Requirements to be added depending on type/characteristics of project] ・Service level management index (draft) ・Implementation of consultation prior to concluding an SLA ・Concept of surcharge and penalty ・Measurement of performance of the service level management index and periodical reviews on SLA attainment ・Requirements in the case of non-compliance with the SLA (approaches to responses and improvements for free)
378
Item Description Example/explanation on a description in specifications
Examples of descriptions in specifications [1. Basic requirements to be listed] (i) In the relevant procurement, a Service Level Agreement (SLA) shall be concluded upon consultation with the contractor for the purpose of verifying that the quality of maintenance provided by the contractor is kept high. The contractor shall formulate the draft of the service level agreement contributing to maintenance and improvement of service level, based on the draft of service level management index described in the relevant specifications, and shall present the draft in the form of a proposal.
No Service level management index
Specifics Index value
1 Mean Time To Repair (MTTR)
Mean Time To Repair is the monthly average time that a device took to recover from any failure, during service operation. Time of occurrence of failure is the time when a failure has been detected or recognized by notice. Recovery from failure is the state in which causes of failure of the device has been removed, normal operation has been observed and the device is available for use.
Within 6 hours
(ii) Based on the Service Level Agreement concluded with the supervisory section, the contractor shall measure the implementation status by the service level management index every month, and report the attainment status at the service level briefing sessions to be held every three months. [2. Requirements to be added depending on type/characteristics of project] (iii) Consultation between the contractor and the supervisory section shall be held based on the report of service level attainment status
379
Item Description submitted by the contractor, to determine the degree of attainment of the SLA during the relevant period. When non-attained SLA items accounts for less than 90%, the contractor shall make an improvement proposal at its own expense and implement countermeasures upon gaining approval of the supervisory section.
Notes on characteristics of project/information system
Service level management is not a compulsory requirement, but is the requirement to be set when the quality of maintenance service is emphasized. One should be careful because setting a service level index and objectives and adding excess requirements may raise commission fees.
Notes on security -
Degree of attainment
Percentage of payment
Conditions
A 100%(full) Attained prescribed conditions in all SAL
items.
B 97% Percentage of non-attained SLA items
accounts for less than 5% of total SLA items.
C 94% Percentage of non-attained SLA items
accounts for more than 5% and less than 10% of total SLA items.
D 90% Percentage of non-attained SLA items
accounts for more than 10% of total SLA items.
380
3. Regular maintenance/regular inspection
Item Description Outline of service operations
To implement regular inspections more than once per year and carry out expendable changes and device adjustments, based on the maintenance outline, etc.
Suggested input (Prepared by the procurer)
Maintenance outline Maintenance procedures
Product (Prepared by the contractor)
・Report on regular maintenance
Matters to be described in specifications
[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 on a description in specifications
Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall carry out maintenance/inspections once a year, based on the “maintenance plan,” “maintenance outline,” and “maintenance procedures,” etc. (ii) The contractor shall give due consideration to the impact on business associated with the relevant system shutdown. If a regular inspection causes system shutdown, the contractor shall consult with the supervisory section in advance, and gain approval. (iii) Every time the contractor implements maintenance work based on the “maintenance plan,” the contractor shall create a “post-maintenance report” and gain approval of the work result from the supervisory section. (iv) The contractor shall formulate response plans against detected failures/troubles as a result of maintenance/inspections, and gain the approval of the supervisory section. In the cases where countermeasures have been taken during a regular inspection, a “post-maintenance report” may serve as a substitute.
Notes on characteristics of project/information system
-
Notes on security
381
4. Fault support
Item Description Outline of service operations
To receive hardware fault notices and carry out on-site support for fault recovery.
Suggested input (Prepared by the procurer)
・Maintenance outline ・Maintenance procedures ・Fault separation procedures
Product (Prepared by the contractor)
・Fault report
Matters to be described in specifications
[1. Basic requirements to be listed] ・Definition of the date/time of support service when a hardware fault occurs ・Creation of a fault repair work report [2. Requirements to be added depending on type/characteristics of project] ・To erase data completely at the time of disposal/change of a hard disk due to physical breakdown. ・Devices applicable for send-back maintenance services, the hardware maintenance contractor shall prepare an alternate device in advance, and carry out the replacement promptly when a fault occurs.
Example/explanation on description in specifications
Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall dispatch maintenance staff in response to fault notifications of devices or requests made from the supervisory section. However, in the event of an emergency, maintenance work shall be carried out outside maintenance hours upon consultation with the supervisory section. (ii) The contractor shall promptly carry out procurement, replacement and repair of parts and make efforts for early recovery of devices. (iii) When re-installation and data recovery are necessary due to hard disk change, the contractor shall request the application maintenance contractor and system maintenance contractor to carry out the work through the supervisory section. [2. Requirements to be added depending on type/characteristics of project] (iv) When external memory media, such as hard disks and /or tape media, are broken, which are then taken away from the installation site, data stored in the external memory media shall be completely erased or physically destroyed and taken away from the venue upon gaining approval from the supervisory section. (v) When the relevant device is subject to send-back service alone, the contractor shall, in advance, prepare an alternative device, and promptly replace the relevant device when a fault occurs.
Notes on Since fault support shall be carried out in cooperation among the
382
Item Description characteristics of project/information system
operation contractor, software maintenance contractor, application maintenance contractor, system infrastructure maintenance contractor and related system contractor, etc., it is necessary to clarity the roles with the concerned parties and the scope of responsibility of each contractor.
Notes on security -
383
5. Support for version upgrade
Item Description Outline of service operations
To acquire release information on firmware, etc., and provide the information to the supervisory section. To carry out the upgrading of firmware, etc., upon consultation with the supervisory section.
Suggested input (Prepared by the procurer)
・Maintenance outline ・Maintenance procedures
Product (Prepared by the contractor)
・Task report
Matters to be described in specifications
[1. Basic requirements to be listed] ・Report and provision of patch updates ・Time spent from release to report of patch updates ・Type of submitted files, etc. ・Change operations, such as environment settings associated with firmware renewal, etc.
Example/explanation on a description in specifications
Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall acquire information on firmware updates for devices from manufactures/agents of the relevant devices, and report to the supervisory section within seven days after the disclosure of the update information. (ii) The contractor shall apply the update information to the relevant devices, when such information is deemed to be necessary, upon gaining approval from the supervisory section within one month after the approval of ministries. (iii) Upon approval of the supervisory section, the version upgrade of firmware, etc. shall be carried out with due consideration to work schedule and time so as not to cause an impact on system operations. When configuration change is necessary along with a firmware upgrade, such change shall be carried out at the time of the upgrading work.
Notes on 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.
384
6. Technical support
Item Description Outline of service operations
To implement technical support in response to requests made by the supervisory section or operator.
Suggested input (Prepared by the procurer)
Maintenance procedures Maintenance outline Affiliation/number (expected) of the source of inquiry
Product (Prepared by the contractor)
・Technical support implementation report
Matters to be described in specifications
[1. Basic requirements to be listed] Time of receiving request for support Response to technical inquiries Support for separating trouble [2. Requirements to be added depending on type/characteristics of project] Deadline of response to inquiry Submit implementation result report to the supervisory section and operation support company
Example/explanation on a description in specifications
Examples of descriptions in specifications [1. Basic requirements to be listed] The contractor shall promptly answer and give advice to inquiries made by the supervisory section or the operator. The contractor shall dispatch maintenance staff to the site in response to an escalation notice from the supervisory section/operator, and provide support for solutions in cooperation with concerned parties (such as the supervisory section, operator, or other maintenance companies, etc.). The contractor shall carry out a hardware log analysis, confirmation/provision of hardware configuration information when necessary, to solve problems. When the cause of the problem is stemmed in the hardware, the contractor shall promptly offer recovery service. Inquiries are accepted, in principle, from 9:00 to 18:00 on days excluding the holidays of public offices (days stipulated in Article 1, paragraph 1 of the Act on Holidays of Administrative Organs (law no. 91, 1988). The contractor shall report to the supervisory section on work results immediately after the problem has been solved or recovery work has been completed. [2. Requirements to be added depending on type/characteristics of project] The contractor shall report on response and analysis results within two days after receiving an inquiry [excluding the holidays of public offices
385
Item Description (days stipulated in Article 1, paragraph 1 of the Act on Holidays of Administrative Organs (law no. 91, 1988))]. When response cannot be presented within the deadline, the contractor shall inform the source of inquiry about progress and the expected date of response. The contractor shall provide the supervisory section and operation support company with a work report immediately after the completion of support work.
Notes on characteristics of project/information system
When a comprehensive inquiry reception desk, such as an integrated helpdesk, is established, specifications shall be added to enable escalation from the reception desk.
Notes on security -
386
6.6.1.3. Deliverable products and timing of submission The table below lists typical deliverable products and the timing of delivery with respect to hardware
maintenance services. The official name of each product and its delivery deadline need to be entered
in accordance with the actual situation.
Service Deliverable product Delivery deadline
1.Formulation of hardware maintenance plan
Hardware maintenance plan Maintenance outline/ maintenance procedures (revised version)
Within 14 business days after conclusion of the agreement
2.Service level management SLA Service level management plan
Within 14 business days after conclusion of the agreement
Report on the results of service level management
On the designated date, every time service level is measured
3.Regular maintenance/ regular inspection
Regular maintenance reports Within seven days after completion of work
4.Fault support Fault report Within seven days after completion of work
5.Support for version upgrade Work report Within seven days after completion of work
6.Technical support Inquiry management table Designated date Work plan (for request for support) Fourteen days prior to implementation of
work Report on the implementation of support work
Within seven days after completion of work
6.6.1.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance.
The official name of each product and its delivery deadline should be entered in accordance with the
actual situation.
Service Input Timing for presenting input
1.Formulation of hardware maintenance plan
Maintenance plan (draft) Service level items/definition SLA Statement of Work (SOW)
Included in procurement specifications or as attachment
Maintenance outline Maintenance procedures
During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor
2.Service level management
Service level items / definition SLA
Included in procurement specifications or as attachment
3.Regular maintenance/ regular inspection
Maintenance outline Maintenance procedures
During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor
4.Fault support Maintenance outline Maintenance procedures
During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor
5.Support for version upgrade
Maintenance outline Maintenance procedures
During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor
6.Technical support Maintenance outline Maintenance procedures
During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor
387
6.6.1.5. Division of roles Examples of roles divided among the hardware maintenance contractor, authorities and contractors
of other works are described below.
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
Tasks Supervisory section
HW maintenance contractor
SW maintenance contractor
AP maintenance contractor
Operation contractor
iDC contractor
Helpdesk contractor
Planning and procurement of operation maintenance plan for hardware, packaged software, and network, etc.
○ △ △ △ △ -
On-site support for hardware - ○ - - △ △ -
Provision of packaged software in batches and implementation of off-site support
- - ○ - △ △ -
On-site support for networks - - - - ○ △ -
Daily system operation - - - - ○ △ -
System and network monitoring - - - - ○ △ -
Security monitoring - - - - ○ △ -
Handling inquiries from users ○ - - - - - ○ Response to inquiries from the supervisory section and escalation from the joint Helpdesk
- ○ ○ ○ ○ ○ ○
Primary separation in the event of problems △ △ △ △ ○ △ -
Secondary response to the problem (hardware fault) △ ○ △ △ △ △ -
Secondary response to the problem (software/application software fault)
△ △ △ ○ △ △ -
Secondary response to the problem (iDC equipment fault)
△ △ △ △ △ ○ -
System recovery process in the event of faults △ △ - ○ ○ - -
Maintenance of application software △ - - ○ - - -
Collection, analysis, report, suggestions concerning operation management information
△ △ - △ ○ △ -
Expendables management - - - - ○ - -
Table 6.6.1.5.1 Table of Division of Roles for Operation/Maintenance Contractor (example)
388
6.6.2. Software maintenance 6.6.2.1. Definition of procurement area Software maintenance includes the maintenance services for products, including commercial OSs,
middleware and application software, etc.; any software other than commercial products, such as
newly developed software or open software (OSS), is not included in this category.
Software maintenance is often procured together with hardware maintenance; however, this section
exclusively deals with the services related to software maintenance.
Figure 6.6.2-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
389
6.6.2.2. Services to be listed in specifications 6.6.2.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding
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 Activities of SLCP-2007
Chapter and section of specifications corresponding
to BGP 1.Formulation of
software maintenance plan
Formulation of software maintenance plan containing details of maintenance services for various products and emergency/non-emergency contact list, etc.
1.8.1.2 Creating of plan and procedures
Chapter XI (1) Requirements for software maintenance (and the abstract shall be included in Chapter II (5) Details of work/deliverable products)
2. Provision of correction (patch) file and version upgrade program
Provision of release information on correction (patch) file, etc., and correction file
1.8.1.2 Creation of plan and procedures 1.8.3.1 Analyzing and deciding on the parts to be corrected 1.8.3.3 Implementation of correction of purchased package
3.Technical support Provision of technical support (off-site support) for software products covered by maintenance
1.7.6.2 User support
390
6.6.2.2.2. Explanations and examples of descriptions in specifications concerning services 1. Formulation of software maintenance plan
Item Description Outline of service operations
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
Suggested input (Prepared by the procurer)
・Maintenance outline ・List of software products covered by maintenance
Product (Prepared by the contractor)
・Maintenance plan (including progress chart, emergency/non-emergency contact list, and maintenance organizational chart, etc.)
Matters to be described in specifications
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)
Example/explanation of a description in specifications
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.
Notes on characteristics of project/information system
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.
Notes on security -
391
2. Provision of correction (patch) files and version upgrade program
Item Description Outline of service operations
To provide correction (patch) files and version upgrade programs of software products covered by maintenance, as well as release information on the said programs.
Suggested input (Prepared by the procurer)
・List of software products covered by maintenance
Product (Prepared by the contractor)
・Maintenance status report
Matters to be described in specifications
[1. Basic requirements to be listed] To promptly provide correction program and version upgrade information The subcontracting agreement shall be concluded with a software copyright holder when necessary to give the procurer the applied right to the correction (patch) file and version upgrade program.
Examples of a descriptions in specifications
Examples of descriptions in specifications (i) When version upgrade programs responding to the function enhancement of software products covered by maintenance and minor version upgrade programs to respond to the correction of faults are released, the contractor shall immediately notify the supervisory section. The contractor shall also provide a license for version upgrade and minor version upgrade programs that have been released during the maintenance period. (ii) For the provision of the said program and license, the contractor shall conclude a contract and carry out coordination with the license provider of the relevant software product, when necessary, and this shall be the responsibility of the contractor.
Notes on characteristics of project/information system
The right to upgrade some software products, in the case of major version upgrades, etc., may not be exercised due to the license regulations of the relevant software product.
Notes on security The contractor should inform the application maintenance contractor or the mainboard maintenance contractor about information pertaining to software bugs, patch and version upgrades, etc., immediately after such information becomes available and instruct the application maintenance contractor or the mainboard maintenance contractor to a conduct preliminary assessment of the possibility of patch application. In order to make early decisions on the possibility of patch application, there is a way to include the application maintenance contractor and the mainboard maintenance contractor in the list of recipients of information on software version upgrades provided by the software maintenance contractor.
392
3. Technical support
Item Description Outline of service operations
Response to technical inquiries concerning software products covered by maintenance
Suggested input (Prepared by the procurer)
・List of software products covered by maintenance
Product (Prepared by the contractor)
・Solutions to inquiries
Matters to be described in specifications
[1. Basic requirements to be listed] ・Establishment of software technical support desk
Examples of a descriptions in specifications
An example of a description in specifications ・ To establish a support desk for inquiries about software products covered by maintenance and to provide support for the relevant software
Notes on characteristics of project/information system
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.
Notes on security -
393
6.6.2.3. Deliverable products and timing of submission The table below lists deliverable products and timing of delivery with respect to software maintenance
services. The official name of each product and its delivery deadline need to be entered in
accordance with the actual situation.
Service Deliverable product Delivery deadline
1.Formulation of maintenance plan
Maintenance plan Within two weeks after conclusion of the agreement
2. Provision of correction (patch) files and version upgrade programs
Correction (patch) file and version upgrade program
At the time of patch release or update program release
3.Technical support Solution to inquiry At the time of inquiry (on an as needed basis)
394
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 Timing for presenting input
1.Formulation of maintenance plan
List of software products covered by maintenance
Included in procurement specifications or as an attachment at the time of tender publishing
2.Provision of correction (patch) files and version upgrade programs
List of software products covered by maintenance
Included in procurement specifications or as an attachment at the time of tender publishing
3.Technical support List of software products covered by maintenance
Included in procurement specifications or as an attachment at the time of tender publishing
395
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 Supervisory section
HW maintenance contractor
SW maintenance contractor
AP maintenance contractor
Operation contractor
iDC contractor
Helpdesk contractor
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 - - - - ○ △ -
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)
396
6.6.3. Application maintenance 6.6.3.1. Definition of procurement area Application maintenance is the maintenance services for operational applications developed from
scratch and customized packaged software (the customized part or the entire packaged software
including customized part).
This Section includes OSS (OS, middleware, business software) to which there is no fixed-style of
maintenance service or maintenance services that have not been provided by distributors, etc.
Figure 6.6.3-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
397
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 Activities of SLCP-2007
Chapter and section of specifications
corresponding to BGP (and its title)
1. Transfer from designers/developers
Transfer from designers/developers
Chapter XI (1) Requirements for software maintenance (and the abstract shall be included in Chapter II (5) Details of work/deliverable products)
2. Formulation of application maintenance plan
Formulation of application maintenance plan (including maintenance work plan and organizational charts with non-emergency/emergency contact lists, etc.)
1.8.1.2 Creation of plan and procedures
3.Service level management
Conclusion of SLA Report on the compliance status of the service level management index
-
4.Fault support On-site support for system failure
1.8.2.1 Problem report or analysis of request for modification 1.8.2.2 Replay or inspection of problems
5.Program modification
Partial modification and function addition for programs, development for bug fixes, tests, release in production environments, system impact analysis before patch applications, preliminary evaluations, and patch applications in operational environments
1.6.6 Detailed software design 1.6.7 Creation of software code and test 1.6.8 Software integration 1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance
6.Technical support Implementation of technical support in response to requests made by the supervisory section and operators
1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance
398
6.6.3.2.2.Explanation on services and examples of descriptions in specifications 1. Transfer from designers/developers Item Description Outline of Service operations
Transfer from design/development contractor
Suggested input [Products related to operation and maintenance created by the design/development contractor] ・ Maintenance plan (draft) ・ Maintenance design ・ Maintenance procedures ・ Maintenance tools ・ Transfer implementation plan
(Prepared by procurer)
・ Transfer implementation report ・ Maintenance plan ・ Organizational charts
Matters to be described in specifications
[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
Example/explanation of a description in specifications
○Transfer from designers/developers, etc. ・ The contractor shall consult with the relevant officer immediately
after the completion of a contract, and shall receive transfer of the details and maintenance work for the software covered by the maintenance contract from designers/developers.
・ The contractor shall develop a maintenance framework and a maintenance plan, based on the transfer concerning maintenance.
Notes on characteristics of a project/information system
-
Notes on security -
399
2. Formulation of application maintenance plan
Item Description Outline of service operations
To formulate application maintenance plans (including maintenance work plans and organizational charts with non-emergency/emergency contact lists, etc.)
Suggested input (Prepared by the procurer)
・Maintenance outline ・Maintenance procedures ・Service level management index (draft) ・Table of the division of roles (contractors involved in the relevant systems and the procurers)
Product (Prepared by the contractor)
・Implementation plan, etc.
Matters to be described in specifications
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.
Example/explanation of a description in specifications
Examples of descriptions in specifications (1) The contractor shall create and deliver a maintenance plan, based on the “relevant procurement specifications,” as well as the “maintenance design” and “maintenance procedures” (issued separately), etc., and receive the approval of the supervisory section. (2) The maintenance work plan shall give sufficient consideration not to interfere with business, such as avoidance of system (service) shutdowns. Any work that may have an impact on business may be done on holidays, etc. through schedule coordination. (3) The contractor shall establish a framework that enables a rapid maintenance response during regular maintenance hours in preparation for faults of devices covered by the maintenance contract and/or response to requests made from the supervisory section, and shall gain the understanding of the supervisory section. Maintenance staff shall be engineers with sufficient knowledge and experience on the application software products covered by the maintenance and
400
Item Description the entire system covered by that maintenance, including the relevant application systems.
Notes on characteristics of a project/information system
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.
Notes on security -
401
3. Service level management
Item Description Outline of service operations
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.
Suggested input (Prepared by the procurer)
・Service level management index (draft) ・Service level management plan
Product (Prepared by the contractor)
・Service level report
Matters to be described in specifications
[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 of a description in specifications
Example of a description in specifications [2. Requirements to be added depending on type/characteristics of project] (1) In this procurement, the contractor shall conclude the Service Level Agreement (SLA) upon consultation with the procurer, shall formulate the SLA plan that will contribute to the maintenance and improvement of service level, based on the service level management index described in this specifications document, in order to ensure that the quality of maintenance provided by the contractor is kept high, and shall present it in the form of a written proposal.
No Service level management index
Explanation
1 Modification of application software
Whether response had been completed within a month after an application defect had been detected
402
Item Description 2 Security
maintenance Whether the preliminary evaluation and application to the operational environment have been completed within a month after the release of patches, such as the operating system (OS) of the system equipped with the application software covered by the maintenance contract and middleware, etc.
(2) The contractor shall measure the performance status of each service level management index on a monthly basis, based on the SLA concluded with the supervisory section, and shall report the attainment status at the service level briefing session to be held every three months. (3) Based on the report on the service level attainment status from the contractor, the contractor and the supervisory section shall hold discussions to assess the attainment level of the SLA during the relevant period. The payment of the fee for the commissioned business shall be determined in accordance with the attainment level of the SLA. If the unattained SLA items accounts for less than 90%, the contractor shall make a proposal for improvements under its own responsibility, and implement the measures upon receiving approval from the supervisory section. Attainment Level
Percentage of payment
Conditions
A 100% (full amount)
Attained prescribed conditions in all SLA items
B 97% The number of unattained SLA items
accounts for less than 5% of all SLA items.
C 94% The number of unattained SLA items
accounts for more than 5% and less than 10% of all SLA items.
D 90% The number of unattained SLA items
accounts for more than 10% of all SLA items.
Notes on characteristics of a project/information system
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.
Notes on security -
403
4. Fault support
Item Description Outline of service operations
To conduct on-site support for the escalation 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)
・Fault report
Matters to be described in specifications
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
Example/explanation of a description in specifications
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.
Notes on characteristics of a project/information system
-
Notes on security -
404
5. Program modification
Item Description Outline of service operations
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
Suggested input (Prepared by the procurer)
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
Product (Prepared by the contractor)
[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
Matters to be described in specifications
[1. Basic requirements to be listed] ・Modification of application software in response to problems detected after the commencement of operation ・Patch applicability assessment for the maintenance of application software generated after the commencement of operation ・Partial and slight improvement of application software and function addition associated with system change, etc. (including incidental tasks, such as revision of design documents, program modification, tests and, migration) [2. Requirements to be added depending on type/characteristics of project] ・Modification of application software in order to respond to performance problems originating in the application software
405
Item Description Example/explanation of a description in specifications
Example of a description in specifications [1. Basic requirements to be listed] (1) The contractor shall implement modification of defects in application software covered by the maintenance contract based on the incident management document issued by the supervisory section or operations management contractor, in accordance with the design/development process of this system. However, this shall not apply to the warranty period of the designers/developers. (2) The contractor shall implement light function addition/modification described in the appendix of the specifications, in accordance with the design/development process of this system. (3) When a patch file is released for an operating system (OS) and middleware used for the system in which application software covered by the maintenance contract is installed, the contractor shall implement a preliminary evaluation of the application within one month after the release of the relevant patch file. The preliminary evaluation shall be carried out under the maintenance environment controlled by the supervisory section and the result of the preliminary evaluation and path application procedures shall be promptly presented to the supervisory section in written form. [2. Requirements to be added depending on type/characteristics of project] (4) Application of patch files, such as an evaluated operating system (OS) and middleware, into the operation environment shall be promptly carried out in accordance with the design/development process of the relevant system, upon consultation with the supervisory section.
Notes on characteristics of a project/information system
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 -
406
6. Technical support
Item Description Outline of service operations
・To implement technical support in response to requests made by the supervisory section or operator.
Suggested input (Prepared by the procurer)
・Design documents and maintenance procedures of systems covered by the maintenance contract
Product (Prepared by the contractor)
・Report on the implementation of support tasks
Matters to be described in specifications
[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/explanation of a description in specifications
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.
Notes on characteristics of a project/information system
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
Notes on security -
407
6.6.3.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to application
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. Transfer from design/development contractor
Transfer implementation report Within one week after the completion of transfer
2. Formulation of maintenance plan
Implementation plan Within two weeks after the conclusion of contract
3.Service level management
SLA Service level management plan
Within 14 business days after the conclusion of contract
Report on the results of service level management
On the designated date, every time service level is measured
4.Fault support Fault report Fault support Within one week after the completion of fault support
5.Program modification Work implementation plan Fourteen days prior to the commencement of work
[Revised version] Procedures (maintenance procedures, operation procedures) [Revised version] design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.)
[Revised version] Source code, etc. Program files Test specifications (various specifications, including unit test, integration test, system test, acceptance test) Report on test results Release plan Release procedures Report on release results
On an as needed basis (within 14 days after the completion of the release or at the time of collating)
6.Technical support Report on support work implementation
Within one week after the completion of work
408
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 Input Timing of presenting input
1. Transfer from design/development contractors
Maintenance plan (draft), maintenance design, maintenance procedures, maintenance tools, transfer implementation plan (draft)
At the time of transfer from the designers/developers
2. Formulation of maintenance plan
Maintenance plan (draft) SLA (draft) Service level management index (draft) Table of the division of roles (SOW) (Statement of Work)
Included in procurement specifications or as an attachment
Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.)
During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor
3.Service level management
SLA (draft) Service level management index (draft)
Included in procurement specifications or as an attachment
4.Fault support Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code
During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor
5.Program modification Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code
During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor
6.Technical support Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code Information indicating the volume of maintenance work
During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor
409
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
Tasks Supervisory section
HW maintenance contractor
SW maintenance contractor
AP maintenance contractor
Operation contractor
iDC contractor
Helpdesk contractor
Planning and procurement of operation maintenance plan for hardware, packaged software and network, etc.
○ △ △ △ △ -
On-site support for hardware - ○ - - △ △ -
Provision of packaged software in batches and implementation of off-site support
- - ○ - △ △ -
On-site support for networks - - - - ○ △ -
Daily system operation - - - - ○ △ -
System and network monitoring - - - - ○ △ -
Security monitoring - - - - ○ △ -
Handling inquiries from users ○ - - - - - ○ Response to inquiries from the supervisory section and escalation from the joint Helpdesk
- ○ ○ ○ ○ ○ ○
Primary separation in the event of problems △ △ △ △ ○ △ -
Secondary response to the problem (hardware fault) △ ○ △ △ △ △ -
Secondary response to the problem (software/application software fault)
△ △ △ ○ △ △ -
Secondary response to the problem (iDC equipment fault)
△ △ △ △ △ ○ -
System recovery process in the event of 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)
410
6.6.4. Maintenance of system infrastructure 6.6.4.1. Definition of procurement areas Maintenance of system infrastructure is the maintenance services for technologies included in
“Chapter V: Explanations on Technical Domain” of the technical reference model, such as “EIP,”
“open web server,” “groupware, file server, mail server,” “integrated account
management/authentication/authorization (access control),” “integrated directory,” “WAN/ministerial
LAN, DNS/DHCP/Proxy, remote access,” and “network lines.”
There are cases where procurement of these maintenance services is made under the same contract
as the installation of devices, introduction of setup devices and development of the environment.
However, this section describes only the services related to maintenance.
Figure 6.6.4-1 Items corresponding to the classification of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
411
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
Chapter/section corresponding to
Basic Guidelines for Procurement
1. Transfer from designers/developers
Transfer from designers/developers
1.8.1.1 Transfer from development process
Chapter XI Requirements for maintenance (however, not applicable to either (1) or (2))
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.)
1.8.1 Preparation for process initiation (maintenance process)
3.Service level management
Concluding SLA, recording SLA index and improving non-attained SLA items
-
4.Fault support Provision of fault support in cooperation with the hardware maintenance contractor, software maintenance contractor and operator to resolve a system fault which cannot be solved by the operator
1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance
5.Updating basic software Software maintenance tasks necessary for the sustainable provision of services
1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance
6.Technical support Each task of system engineers necessary for system operation
1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance
412
6.6.4.2.2. Explanations and examples of descriptions in specifications concerning services 1. Transfer from designers/developers
Item Description Outline of service operations
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
Product (Prepared by the contractor)
・ Transfer implementation report ・ Maintenance plan ・ Organizational chart
Matters to be described in specifications
[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
Example/explanation of a description in specifications
○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.
Notes on characteristics of project/information system
-
Notes on security -
413
2. Formulation of maintenance plans for system infrastructure Item Description Outline of service operations
Submit the maintenance plan for system infrastructure (including a maintenance work plan and an organizational chart with a non-emergency/emergency contact list, etc.) to the supervisory section and gain the approval of the supervisory section
Suggested input (Prepared by the procurer)
[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)
Product (Prepared by the contractor)
・Maintenance plan for system infrastructure
Matters to be described in specifications
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/explanation of a description in specifications
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.
Notes on characteristics of project/information system
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.
Notes on security -
414
3. Service level management
Item Description Outline of service operations
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.
Suggested input (Prepared by the procurer)
・Service level management index (draft) ・SLA (draft)
Product (Prepared by the contractor)
・SLA ・Maintenance report ・Service level report
Matters to be described in specifications
[1. Basic requirements to be listed] None [2. Requirements to be added depending on type/characteristics of project] To include requirements for SLA to be concluded between the procurer and the contractor and state to the effect that both parties may discuss issues about the service level management index. When demanding strict compliance with the SLA, periodical reviews and task requirements for non-compliance shall be specified. ・Implementation of discussions on the service level management index between ministries and the maintenance contractor ・Definition and explanatory notes on SLA items, such as frequency of version upgrades and fault support hours ・ Implementing periodical reviews on the results of compliance with the SLA ・Requirements for responses in the event of non-compliance with the SAL (for free response and approaches to improvements)
415
Item Description Example/explanation of a description in specifications
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 Service level management index
Explanation
1 Modification of application software
Whether countermeasures have been completed within a month after the application defect had been detected
2 Security maintenance Whether the preliminary evaluation and application to the operational environment have been completed within a month after the release of patches, such as an operating system (OS) equipped with application software covered by maintenance contract and middleware, etc.
(2) The contractor shall measure the performance status of each service level management index on a monthly basis, based on the SLA concluded with the supervisory section and shall report the attainment status at the service level briefing session to be held every three months. (3) Based on the report on the service level attainment status from the contractor, the contractor and the supervisory section shall hold discussions to assess the attainment level of the SLA during the relevant period. The payment of the fee for the commissioned business shall be determined in accordance with the attainment level of the SLA. If the unattained SLA items accounts for less than 90%, the contractor shall make a proposal for improvements under its responsibility, and implement the measures upon receiving approval from the supervisory section.
416
Item Description
Notes on characteristics of project/information system
-
Notes on security -
Attainment level
Percentage of payment
Conditions
A 100%(full amount)
Attained prescribed conditions in all SLA items
B 97% The number of unattained SLA items
accounts for less than 5% of all SLA items.
C 94% The number of unattained SLA items
accounts for more than 5% and less than 10% of all SLA items.
D 90% The number of unattained SLA items
accounts for more than 10% of all SLA items.
417
4. Fault support
Item Description Outline of service operations
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)
・Fault report
Matters to be described in specifications
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
Example/explanation of a description in specifications
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.
Notes on characteristics of project/information system
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.
Notes on security -
418
5. Updating system infrastructure software
Item Description Outline of service operations
To update system infrastructure software and perform patch applications for function improvements and countermeasures against defects and vulnerabilities of the system infrastructure software etc.
Suggested input (Prepared by the procurer)
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.
Product (Prepared by the contractor)
[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.
Matters to be described in specifications
[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/explanation of a description in specifications
Example of a description in specifications [1. Basic requirements to be listed] (1) The contractor shall update system infrastructure software based on defect information, vulnerability information and incidence management slips presented by the supervisory section concerning the system infrastructure and its software covered by maintenance contract. Before implementing the update operations, the contractor shall perform preliminary evaluations in a maintenance environment and gain approval from the supervisory section. (2) At the time of update verification, the contractor shall carry out the operation verification for systems/software that will operate on the system infrastructure or in coordination with the system infrastructure. (3) When implementing update operations, the contractor shall use the revised design/procedures, in accordance with the configuration management process of this project.
Notes on characteristics of
419
Item Description project/information system Notes on security Provision of information and application of security patches
Information pertaining to technical problems, security holes, software bugs, patches, and version upgrades of the information system shall be immediately reported to ministries. The contractor shall also carry out such works as application verification work, patch application, and provision of technical advice on software, in response to requests from ministries.
420
6. Technical support
Item Description Outline of service operations
・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.
Suggested input (Prepared by the procurer)
・Design documents for systems covered by the maintenance contract and maintenance procedures
Product (Prepared by the contractor)
[Revised version] Source code, etc., program files, test specifications, test results, release plans, release procedures, reports on the results of release works
Matters to be described in specifications
[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/explanation of a description in specifications
Example of a description in specifications [1. Basic requirements to be listed] When security patches and updates concerning the OS and middleware, on which the system infrastructure software covered by maintenance contract is operated become available, the contractor shall consider the necessity of its application. When the application is deemed to be necessary, the contract shall conduct a preliminary evaluation under the maintenance environment to ascertain that patch application will not cause defects, and then carry out the application to the operation environment upon reporting to the supervisory section.
421
Item Description [2. Requirements to be added depending on type/characteristics of project] [Matters associated with EIP] The contractor shall register the applications requested by the supervisory section so that the application can be integrated into the portal. The contractor shall implement maintenance works on data to be registered in the EIP. [Matters associated with open web servers] ・ Carrying out regular reviews on security settings so as to keep
the security level of the open web server high, by occasionally checking on vulnerability information, etc.
[Matters associated with groupware, file servers, mail servers] ・ Appropriately carrying out authority settings for groupware, file
servers and mail servers associated with the hiring, leaving and changing of employees, etc.
[Maters associated with integrated account management, authentication, and authorization (access control)] ・ Appropriately carrying out the addition, change, and deletion of
user accounts associated with the hiring, leaving and changing of employees, etc.
[Matters associated with the integration directory] ・ Solidly carrying out integration directory settings associated with
the addition, change, and deletion of ministerial systems [Matters associated with WAN/ministerial LAN, DNS/SHCP/Proxy, remote access] ・ Carrying out changes in settings of the WAN/ministerial LAN,
DNS/DHCP/Proxy, etc. associated with the addition, renewal or abolition of ministerial systems.
Notes on characteristics of project/information system
Notes on security -
422
6.6.4.3. Deliverable products and timing of submission The table below lists typical deliverable products and their timing of delivery with respect to maintenance services for system infrastructure. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation.
Service Deliverable product Delivery deadline 1. Transfer from
design/development contractor
Transfer report Within one week after the completion of transfer
2. Formulation of maintenance plan
Maintenance implementation plan
Within two weeks from the conclusion of a contract
3.Service level management SLA Service level management plan
Within 14 business days after the conclusion of a contract
Report on the results of service level management
On the designated date at every measurement of the service level
4.Fault support Maintenance report Service level report (*Fault support, in the cases where fault support is included in the SLA)
Maintenance report: Monthly Service level report: At the time of collating or quarterly
5. Updating system infrastructure software
Work implementation plan At least 14 business days before the implementation of work
[Revised version] Procedures (Maintenance procedures, Operation procedures). [Revised version] Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) [Revised version] Source code, etc., program files, test specifications, report of test results, release plan, release procedures, report on results on release works
On an as needs basis (within 14 days after the completion of the release or at the time of collating)
6.Technical support Work implementation plan At least 14 business days before the implementation of work
[Revised version] Sources code, etc., program files, test specifications (specifications of various tests, such as unit test, integration test, system test and acceptance test) report on test results, release plan, release procedures, report on results of release work
Within seven business days after the implementation of work
423
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 Input Timing for presenting input
1. Transfer from design/ development contractor
Maintenance plan (draft), Maintenance design, Maintenance procedures, Maintenance tools, Transfer implementation plan (draft)
At the time of implementation of transfer from designers/developers
2. Formulation of maintenance plan
Maintenance plan (draft) SLA (draft) Service level management index (draft) Statement of work
Included in procurement specifications or as an attachment
Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.)
During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor agreement.
3.Service level management
SLA (draft) Service level management index (draft)
Included in procurement specifications or as attachment
4.Fault support Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, definition of system environment, etc.) Source code
During tender period: Disclosed to bidders After conclusion of agreement: Lent to contractor
5.Update of system infrastructure software
Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, definition of system environment, etc.) Source code
During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor
6.Technical support Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) Information indicating the volume of maintenance work Source code, etc.
During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor
424
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
Tasks Supervisory section
HW maintenance contractor
SW maintenance contractor
AP maintenance contractor
Operation contractor
iDC contractor
Helpdesk contractor
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 - - - - ○ - -
Table 6.6.4.5.1 Division of roles among operation and maintenance contractor (example)
425
6.7. Tasks incidental to procurement of devices
6.7.1. Definition of procurement area The term “tasks incidental to procurement of devices” refers to services incidental to devices
(including ready-made software for OSs inseparable from hardware) that are necessary to implement
information systems (see Figure 6.7.1.).
There are cases where procurement of the subsequent maintenance services is made under the
same contract in addition to the installation of devices such as deployment and setting, and
arrangement of the environment. However, this section describes only the services related to
installation.
Figure 6.7-1 Items corresponding to the classification of procurement of services
6.7.2. Services to be listed in specifications 6.7.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding
SLCP-200711 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)
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System construction (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
426
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 Outline of service operations Activities of SLCP-2007
Chapter and section of specifications
corresponding to BGP (and its title)
1.Master plan formulation Formulation of work details, schedule, process, implementation framework (division of roles), Creation of implementation plan Progress management, reviews to the persons in charge
1.2.4: Planning 1.2.5: Implementation and management 1.2.6: Review and assessment
Chapter XII Framework and method of work (1)Framework of work (3) Introduction
2.Prior explanation/coordination with concerned parties
Prior explanation to and coordination with concerned contractors and ministries
3.2.2: Environment construction process
Chapter XII Framework and method of work (3)Introduction
3.On-site investigation/design
On-site investigation of the site where devices are to be installed Creation of on-site investigation report and working drawing Creation of on-site work plan Creation and submission of diagrams such as device installation layout, rack layout, network diagram (if network is included), and design documents such as security design and network design documents
3.2.2 Environment construction process 3.2.1 Preparation for process initiation(environment development process)
Chapter XII Framework and method of work (3)Introduction
4.Device installation Work on power source and ventilation Emplacement/installation of devices
3.2.2 Environment construction process
Chapter XII Work framework and method (3)Introduction
5.Device setup Network installation in accordance with the design document (if a network is included), Installation and setting up of software, and connection with other systems
1.6.12 Software installation process
Chapter XII Work framework and method (3)Introduction
6.Operation verification/test
Carrying out verification tests on installed hardware, software and the network (if a network is included) Support for tests performed by system development contractors
2.4.1 Preparation for process initiation 2.4.2 Validation, 2.5.1 Preparation for process initiation 2.5.2 Confirmation of validity
Chapter VIII Definition of requirements for tests
7.Migration Migration of data, system, and business from the existing system or support for that work
1.8.5 Migration Chapter IX Definition of requirements for migration (1) Migration-related
requirements 8.Information provision to Provision of information to 1.6.13 Chapter IX
12 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of
Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf
427
Service operations Outline of service operations Activities of SLCP-2007
Chapter and section of specifications
corresponding to BGP (and its title)
operation/maintenance contractors
operation/maintenance contractors, such as setting information for devices and software, and operation procedures
Software acceptance support
Definition of requirements for migration (2) Education-related
requirements
9. Information provision and training to users
Training of system operation procedures for end users and persons in charge of the system (if end users use the system)
1.6.13 Software acceptance support
Chapter IX Definition of requirements for migration (2) Education-related requirements
10. Acceptance Preparation/delivery of a set of the necessary deliverables Support for acceptance tests by ministries
1.2.7 Delivery and completion
Chapter XII Framework and method of work (3) Introduction
428
6.7.2.2. Explanations and examples of descriptions in specifications concerning services 1. Master plan formulation
Item Description Outline of service operations
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)
・ Master plan
Matters to be described in specifications
[1. Basic requirements to be listed] ・ Tasks to be included in the plan ・ Roles of persons in charge ・ Organizational structure ・ Designation and constraints concerning working hours, locations,
etc. [2. Requirements to be added depending on type/characteristics of project] ・ Required qualifications for workers ・ Requirements for the contractors, such as job experience ・ Detailed rules regarding work hours/locations ・ If conditions differ among locations, such as work days and hours,
work plans for locations shall be submitted accordingly. Example/explanation of a description in specifications
○Creation of an implementation plan The contractor shall create an “implementation plan” that includes work descriptions, a framework and a schedule of work, etc., prior to the installation of devices. (1) Creation of an implementation plan
・ The “implementation plan” shall include all the operations listed in the “Table __. Division of roles in installation work.”
・ If coordination is necessary for the cooperation with external parties in creating the “implementation plan,” the contractor shall consult with the relevant Ministry. In addition, the contractor shall provide support for the necessary coordination.
(2) Working hours The emplacement and installation should be within business hours on weekdays.
Notes on characteristics of project/information system
・ Some ministries require separate submission of introduction plans and organization charts. The specifications should state that such matters shall be done in accordance with the procurement policies/guidelines of the ministry.
・ When a project requires specific experience or skills, detailed requirements for the personnel in charge shall be stated.
・ In case that the installation is carried out at many places, the
429
specifications should state that the contractor shall submit a list of persons in charge at each location, contact information and the like, and a general guideline for operation carried out on site.
Notes on security -
430
2. Prior explanation/coordination for concerned parties
Item Description Outline of service operations
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)
・ Documents for prior coordination/explanation and minutes (drafts in case of support)
Matters to be described in specifications
[1. Basic requirements to be listed] ・ Prior coordination shall be carried out. ・ Matters needs to be coordinated beforehand (the statements
should be described in concrete terms.) ・ Concerned parties to participate in prior coordination (the
expected number of participants shall be given.) [2. Requirements to be added depending on type/characteristics of project] ・ The contractor shall convene or participate in conferences such
as a meeting for prior explanation, if required. ・ Participants and subjects of explanations of conferences such as
a meeting for prior explanation shall be described. Example/explanation of a description in specifications
○ Prerequisite operation prior to delivery (A) The contractor shall take part in on-site explanatory meeting prior
to delivery to give details of deliverable devices, delivery schedule, and other necessary explanations.
(B) The contractor shall identify matters to be consulted with persons in charge on site, such as installation locations of existing products and preparation of power supplies, etc.
(C) The contractor shall conduct prior coordination on the matters mentioned in the previous clause.
Notes on characteristics of project/information system
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 -
431
3. On-site investigation/design
Item Description Outline of service operations
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
Suggested input (Prepared by the procurer)
・ 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
Product (Prepared by the contractor)
・ On-site investigation plan ・ Report on on-site investigation ・ Design documents, such as working diagrams, layout diagrams for
device installation, rack installation diagrams, and wiring diagrams Matters to be described in specifications
[1. Basic requirements to be listed] ・ Selection of appropriate devices/software based on the
requirements in the specifications ・ Necessary on-site investigations ・ Results of on-site investigations, design ・ Outputs, such as diagrams to be created ・ Implementation of on-site investigations and timing of the
submission of outputs ・ Constraints on the implementation of on-site investigations [2. Requirements to be added depending on type/characteristics of project] ・ Definition of security requirements in conformity with the standard
security policies of the central government, etc. ・ “Definition of security requirements/design” shall be included in the
requirements if a design should be tailored. Example/explanation of a description in specifications
Example of a description in specifications (1) As for the location of installation, “layout diagram for device
installation” and a “rack installation diagram” should be created- after conducting studies, etc.
(2) On-site investigations necessary for the installation of a power source and LAN cables shall be conducted. The on-site and other studies shall be conducted in accordance with the “system switching work plan” presented by the relevant authority to the relevant site.
Notes on characteristics of project/information system
If connecting to systems operated by other ministries is necessary, the contractor shall state to the effect that the network design will be formulated upon coordination with the relevant bureau of said ministries. In that case, the concerned parties shall be clearly specified for the coordination..
Notes on security Security design The contractor shall create a security design following the Standards for Information Security Measures for the Central Government Computer Systems and information security policies issued by each ministry. The contractor shall also take information security measures based on the security design.
432
4. Device installation work
Item Description Outline of service operations
To implement work on power source/ventilation work and emplacement/installation of devices
Suggested input (Prepared by the procurer)
・ Working diagram, layout diagram for device installation, rack installation diagram, wiring diagram, and various other design documents concerning the existing system
・ Materials concerning power source usage Product (Prepared by the contractor)
・ Change documents concerning the result of works, including the working diagram, layout diagram for device installation, rack installation diagram, wiring diagram, and various other design documents
Matters to be described in specifications
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/explanation of a description in specifications
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
Notes on characteristics of project/information system
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.
Notes on security -
433
5. Device setup
Item Description Outline of service operations
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.
Suggested input (Prepared by the procurer)
・ Requirements for hardware, requirements for software, requirements for networks and requirements for operation and maintenance
Product (Prepared by the contractor)
・ Definition of environment
Matters to be described in specifications
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/explanation of a description in specifications
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.
Notes on characteristics of project/information system
In the case of a large-scale separated procurement project, the responsibility demarcation for the installation/connection of devices, etc. may become unclear. Thus, the responsibility should be clarified in advance by, for example, creating a table of the division of roles (see 6.7.5).
434
Notes on security Security settings/adjustment To carry out environment settings and adjustment work necessary for this system, using the procedures for the existing system, the installation procedures and the prepared security design documents.
Updating of virus definition file Virus software/virus definition files shall be updated to the newest version.
435
6. Operation verification/test
Item Description Outline of service operations
To perform operation verification tests on installed hardware, software and the network and provide support for tests performed by system developers.
Suggested input (Prepared by the procurer)
・ List of items subject to operation verification ・ Information necessary to perform tests, such as coordination
policies with other functions
Product (Prepared by the contractor)
・ Test specifications ・ Report on test results (Operation test report)
Matters to be described in specifications
To list inspections to be implemented as operation verification for installed devices and software and their requirements and targets. Documents to be presented by the procurer shall be specified, as well as any documents to be reported in response to the test results. [1. Basic requirements to be listed] ・ Subjects of the operation verification/test ・ Implementation and validation of the operation verification/test ・ Response to generated problems ・ Cooperation with concerned parties ・ Report on the operation verification/test [2. Requirements to be added depending on type/characteristics of project] ・ Tests to be performed (and details of support) and application in
case that the project requires integration with the existing system ・ To specifically clarify the division of roles with the operation
contractor, etc. Example/explanation of a description in specifications
Example of a description in specifications ○Operation/connection verification test
・ The contractor shall perform an operation verification test and connection verification test for devices of this system to verify the compliance with the specifications
・ The contractor shall perform system test of the relevant system in cooperation with the renewal contractor, after the introduction of devices for this system and the renewal of ___system separately procured by the relevant ministry. When defects attributable to this procurement are found in system test, the contractor shall analyze the cause and carry out the change in environment settings, and other necessary tasks until the system works properly.
Notes on characteristics of project/information system
Since items subject to operation verification and its details are different depending on the scale and system subject to connection, test requirements should be clarified in advance. When testing, cooperation with the application construction contractor may at times become necessary. Thus, the division of roles should be clarified beforehand.
436
Notes on security -
437
7. Migration
Item Description Outline of service operations
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.
Suggested input (Prepared by the procurer)
・ Outline of the types/volume and location of migrated data ・ Migration plan
Product (Prepared by the contractor)
・ Migration design ・ Report on the results of migration data validation
Matters to be described in specifications
When the contractor carries out data migration, conditions for data transfer, etc. shall be described. When a system developer carries out data migration, service requirements for migration support shall be described. [1. Basic requirements to be listed] ・ Items subject to migration ・ Details of migration work ・ Details of support for migration work ・ Prerequisites for migration work ・ Conditions for migration work (possible working hours, possible
period of implementation, migration method, etc.) Example/explanation of a description in specifications
Example of a description in specifications ○Requirements for data migration The contractor shall implement migration work of data held in the existing system (A) The following make up the outline of the migration data. The
details will be presented by the Ministry after the conclusion of the contract.
(The rest is omitted.) (B) Following the migration, data verification shall be performed to
ensure the integrity of the migrated data and the results shall be reported as the “report on the results of migration data verification.”
Notes on characteristics of project/information system
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.
Notes on security -
438
8. Information provision to operation/maintenance contractors
Item Description Outline of service operations
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.
Suggested input (Prepared by the procurer)
・ Specifications for device management information exchange file
Product (Prepared by the contractor)
・ Device management information ・ Setting information ・ Manual
Matters to be described in specifications
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
Example/explanation of a description in specifications
○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.
Notes on characteristics of project/information system
All the information necessary for the operation/maintenance contractor should be handed over.
Notes on security -
439
9. Information provision and training to users
Item Description Outline of service operations
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)
・ Training schedule ・ procedure documents ・ Textbook(s)
Matters to be described in specifications
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/explanation of a description in specifications
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.
Notes on characteristics of project/information system
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.).
Notes on security -
440
10. Acceptance
Item Description Outline of service operations
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)
・ A set of documents designated as deliverable products
Matters to be described in specifications
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/explanation of a description in specifications
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.
Notes on characteristics of project/information system
Reviews should be set up on an appropriate timing to prevent rejections at the time of acceptance.
Notes on security -
441
6.7.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to deliverable
products. The official name of each product and its delivery deadline need to be listed in accordance
with the actual situation.
Service Deliverable product Delivery deadline
1. Master plan formulation Implementation plan Prior to the commencement of introduction work
2. Prior explanation /coordination with concerned parties
Materials for preliminary coordination/information session and minutes (draft in the case of support)
Prior to each work on an as needed basis
3. On-site investigation/design On-site investigation plan Prior to the commencement of on-site investigation
On-site investigation report Working diagram Layout diagram for device installation Rack installation diagram Wiring diagram Other design documents
Prior to the commencement of work at the introduction site
4. Device installation work Change documents for working documents for hardware and a set of software, layout diagram for device installation, rack installation diagram, wiring diagram, and other design documents
Until the date designated in the specifications
5. Device setup Environment definition After the setup of devices
6. Operation verification/test Test specifications Prior to the commencement of operation verification/test
Report on test results
After the implementation of operation verification/test
7. Migration Migration design Prior to the implementation of migration
Report on the results of migration data validation
After the implementation of migration
8. Provision of information/training for operator/maintenance contractor
Device management information Setting information Manual
Until the completion of the introduction work
9. Information provision and training to users
Training schedule A range of procedure documents Textbook(s)
-
10. Acceptance A set of designated deliverable products
Date of acceptance
442
6.7.4. Suggested input The following table shows input and timing to be presented to the contractor (proposer) in advance.
The official name of each deliverable and its delivery deadline need to be listed in accordance with
the actual situation.
Service Input Timing for presenting input
1. Master plan formulation Overall schedule Table of the division of roles
Included in procurement specifications or as an attachment at the time of tender publishing
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
Included in procurement specifications or as an attachment at the time of tender publishing
3. On-site investigation/design
Security guidelines prescribed by each ministry
Disclosed on the website, or during tender period
Working diagram Layout diagram for device installation Rack installation diagram Wiring diagram Other design documents (The above applies to the existing system)
During tender period
4. Device installation work
5. Device setup Requirements for hardware, requirements for software, requirements for networks, requirements for operation/maintenance
After the conclusion of a contract
6. Operation verification/test List of items to be verified Information necessary for the implementation of tests, such as coordination policies with other sets of devices
Included in procurement specifications or as an attachment at the time of tender publishing
7. Migration Outline of type, volume and location of migration data Migration plan
After the completion of a contract
8. Provision of information/training for operator/maintenance contractor
Specifications for device management information exchange file
Included in procurement specifications or as an attachment at the time of tender publishing
9. Information provision and training to users
Possible dates/locations of training Included in procurement specifications or as an attachment at the time of tender publishing
10. Acceptance List of deliverable products Included in procurement specifications or as an attachment at the time of tender publishing
443
6.7.5. Division of roles
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 ◎: Accountability
○: Responsibility for implementation
△: Confirmation
Ministry
Operator
Contractor
Developer
1. Master plan formulation ◎ ○ 2. Prior explanation/coordination with concerned parties
◎ ○
3. Onsite investigation/design ◎ ○ 4. Device installation work ◎ ○ 5. Device setup ◎ ○ 6. Operation verification/test ◎ ○ 7. Migration ◎ ○ 8. Information provision to operator/maintenance contractors
△ ◎ ○
9. Information provision and training to users
◎ ○
10. Acceptance ◎ △ ○ △
444
6.8. Tasks incidental to procurement of iDC equipment
6.8.1. Definition of procurement area “Tasks incidental to procurement of iDC equipment” refers to the installation of various devices
prepared by the contractor in the facility to make them usable via the network environment, such as
cables and lines, and to the implementation of system operation monitoring and incidental services.
It corresponds to the one defined as operation technology in the procurement area and the main
tasks are planning, operation and maintenance, etc. Please refer to “5.3 iDC/Equipment” for
requirements/specifications for the functions/services of iDC equipment.
This section excludes services to procure equipment necessary for the operation of information
system devices (racks and cooling systems, etc.) since they are included in the procurement of
devices.
Figure 6.8-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
445
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-200713 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 Outline of service operations Activities of SLCP-2007
Service items corresponding to
Guidelines for Information Disclosure concerning Data Center Security and Reliability
(1st ed.) by MIC
Chapter/section corresponding to Basic Guidelines for Procurement
(and its title)
1.Work plan Creation of implementation plan Scope of procurement Work flow Schedule, etc.
2.3.1 Preparation for initiation of quality assurance process
62.-68.Access control (requirements for building)
Chapter II (4) / (5) Chapter IV Chapter V Chapter VI
2.Implementation of work Work at the Data Center Cable lines-related work (when necessary)
3.2.2 Construction of environment
- Chapter X, Chapter XI, Chapter XII Chapter V (5) 3.Preparation for initiation
of operation /maintenance
Creation of system operation Monitoring procedures Procedures for monitoring potential attacks Procedures for security diagnosis Formats of reports Formats of management registers Service requirements for SLA
3.2.1 (Environmental improvement) Preparation for process initiation
99. SLA
4.Operatation/ maintenance (daily)
Daily tasks (operations management, and maintenance management) Creation of daily report
1.7.4.1 System operation 1.7.4.2 Operation monitoring and collection of operation data, identification, recording and resolution of problems, improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation 1.8.2 Comprehension and correction/analysis of problems 1.8.3 Correction
60. 24hours×7days/weekly monitoring 105.-109. Service notice/report 110.-112.Support service
5. Operation/ maintenance (weekly)
Weekly tasks (database backup, etc.)
Creation of weekly report 6. Operation/ maintenance (monthly)
Monthly tasks (security diagnosis, etc.) Creation of monthly report
7. Operation/ maintenance (irregularly)
The following services with respect to the work generated irregularly Details of work Creation of report
69.-70.Media storage
13 Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 14 The “Basic Guidelines for Government Procurement Related to Information Systems,” March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf
446
6.8.2.2. Explanations and examples of descriptions in specifications concerning services 1. Work plan
Item Description Outline of service operations
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
Product (Prepared by the contractor)
Implementation plan
Matters to be described in specifications
To specify requirements for creating an implementation plan [1. Basic requirements to be listed] ・ Scope of procurement ・ Implementation framework ・ Work schedule, etc.
Example/explanation of a description in specifications
Examples of descriptions in specifications ○ Scope of procurement
The objective of the information systematization is to introduce professional services by installing server devices in the information system of the Ministry of ___, which includes power sources, ventilation system, anti-seismic measures and the prevention of physical intrusion, etc. for the safe operation of devices in the Ministry of ___. The scope of the procurement in this project shall be limited to the preparation for power equipment associated with device installation, anchoring devices for anti-seismic purposes, physical security measures for devices, and operations at the installation site, and shall exclude the following requirements.
(i) Procurement of goods such as server devices used by the Ministry of ___ and the incidental setup work
(ii) Monitoring of the information system on which the server devices used by the Ministry of ___ are operated.
○Implementation framework The following are the requirements in this section:
(i) The contractor shall establish an implementation framework to carry out this project.
(ii) Details of the implementation framework shall be clearly specified in terms of the roles of each team, division of work, and timing of team formation, etc.
(iii) The personnel in charge of the relevant services shall have qualifications related to project management or have equivalent knowledge, such as a Project Management
447
Professional (PMP). Qualification/knowledge necessary for the position shall be pursuant to the Basic Guidelines for Government Procurement Related to Information Systems of MIC.
(iv) The contractor shall formulate a schedule/organizational plan based on the necessary volume of work by selecting necessary items from work requirements stipulated in this specifications document, create the Work Breakdown Structure (WBS) and clarify the orders and dependency of work flows. The WBS is a table showing the entire project being divided into tasks.
○Work schedule (Schedule of implementation for commissioned work)
(i) Date M/D/Y: Completion of preparation for the Data Center (scheduled for installing devices)
(ii) Date M/D/Y: Commencement of test operations (iii) Date M/D/Y: Commencement of production operations (iv) Date M/D/Y: Completion of the relevant contract
Notes on characteristics of project/information system
(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 -
448
2. Implementation of work
Item Description Outline of service operations
To carry out work at the Data Center (preparation for equipment, installation of devices). To carry out wiring-related work, etc. when necessary.
Suggested input (Prepared by the procurer)
List of devices, network diagram (Details of device information to be installed, details of the types of cables/lines to be wired in the iDC and server/provider)
Products (Prepared by the contractor)
Report on the completion of work
Matters to be described in specifications
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/explanation of a description in specifications
Example of a description in specifications ○Preparation/coordination for the equipment in the Data Center (1) Function composition
Among requirements listed in Chapter III, the procurement in this project applies to the “conditions for location, conditions for facility, conditions for machine rooms, conditions for power sources /ventilation, conditions for security, and conditions for operations” in the “iDC/equipment.” Other items shall be procured under a separate contract.
(2) Scale requirements The following is the number of devices requested by the Ministry of ___.
Information system devices, such as server, etc.: __ units Network devices, such as router and switch, etc.: __ units Racks: __ units
An operation room for the operators[ ___ persons (or __m2)] shall also be procured (the operation room and network wiring with the server shall be included in the scope of procurement)
Computer terminal desks: __ units Lockable cabinets: __ units
(3) Procurement work (i) Installation layout design(including rack installation)
A layout of the installation site for the information system devices to be installed in the Data Center shall be designed. When renting racks owned by the Data Center, a rack installation diagram shall be created based on the presented list of devices.
(ii) Power source connection design
449
With respect to the power source connection, the contractor shall create a “power/line connection diagram,” indicating the allocation and breaker, etc. When redundancy of power sources is necessary, the contractor shall consider the redundancy including a distribution board by, for example, supplying the distribution board in a separate system.
(iii) Equipment preparation The contractor shall prepare equipment based on the results of the “layout/power connection design,” such as anchoring devices for anti-seismic purposes/power source preparation work associated with rack installation.
(4) Requirements for implementation of work (i) The contractor shall manage the project management using the
WBS-based management method. (ii) The contractor shall propose a progress management method to the
relevant official of the Ministry of ___, with due consideration to the details of the work. The contractor shall also promote and manage the work in accordance with the progress management method verified by the relevant official of the Ministry of ___.
(iii) The contractor shall hold regular progress report sessions to give a briefing on the work status (plan, performance and the gap between them).
(iv) Consultation with the relevant official of the Ministry of ___ shall be conducted in Japanese and information materials and deliverable documents shall be written in Japanese.
(v) When changing the implementation framework, the contractor shall file a report to that effect to the relevant official of the Ministry of ___ and obtain confirmation.
○Support for device installation (cable connection, etc.)
(i) On-site presence when carrying in devices To secure a carrying-in route leading to the device installation site in the server room
(ii) Support for power source connection To give power connection instructions to and manage the installation contractor with respect to the connection of the distribution board to the power distribution unit (PDU) and the connection of the rack power distribution unit to the power cables of the devices.
(iii) Support for installation and connection of cables To prepare protective ducts/trays associated with the installation of LAN cables, fiber cables, and lines for external connections, etc.
○Requirements for implementation of wiring-related work (basic requirements)
(i) The contractor shall provide line-terminating devices. Routers and switches shall be brought in and installed by a hardware contractor which is separately procured.
450
(ii) Piping and power source work with respect to wiring into the administrative building ___ shall fall under the scope of the procurement.
(iii) The date of commencement of the use of the lines shall be on M/D/Y. Notes on characteristics of project/information system
(i) The installation work may change depending on whether the lines have already installed or not. With respect to the descriptions, in addition to specifying requirements for the work as described above, there is an option of having the contractor define the work items, instead of describing the elements, except for technical requirements. (ii) In the power connection design, devices requiring redundancy of power sources should be specified in the list of devices and instructions should be given to make sure that power will be supplied from a different distribution board. (iii) With respect to the installation of cables, there may be a risk of communications interruption due to mutual interference in an environment where a number of power cables and communication-related cables are run together. Thus, preparation for piping and trays to prevent interference should be requested. (iv) With respect to the piping and power source work in relation to wiring in the administrative building ____, the decision shall be made whether it is included in the scope of procurement depending on the condition of the installation site in the building (location under the contract, etc.).
Notes on security -
451
3. Preparation for initiation of operation/maintenance
Item Description Outline of service operations
To create a procedure manual for system operation monitoring to be carried out by the operation contractor
Suggested input (Prepared by the procurer)
List of system operation monitoring items
Product (Prepared by the contractor)
Procedures for system operation monitoring Report formats Communication flow chart
Matters to be described in specifications
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,
452
event, etc.), reporting timing (daily, monthly, etc.), method of reporting (printed matter, electric data, such as email, etc.) and the recipient of report, based on the system operation monitoring items.
(ii) Creation of formats The contractor shall create a request form for emergency work and a form for reporting the items determined in (1). The report format to be created is roughly described as follows, which shall be further detailed depending on monitoring items: (a) Request for and report on emergency work, (b) System operation daily report, (c) System operation weekly report, (d) Attack status report (monthly), (e) Incident (abnormality)report, (f) System operation monthly report, and (g) Security diagnosis report (monthly).
○Creation of management register
The contractor shall create management registers concerning the matters to be installed, operated and managed in the iDC, in cooperation with the Ministry of ___.
(i) Management register (a) Hardware configuration management register (b) Network supply management register (c) Document management register (d) Backup media management register (e) Communication flow chart (f) Policies for measures against large-scale disaster/communication
structure ○ Services related to SLA
The contractor shall evaluate the status of achievement of SLA items on a monthly basis, and to report three-month results at the “service level briefing session” held every three months.
Notes on characteristics of project/information system
(i) When there is no existing network or ministerial system accommodated in the Data Center, cooperation with other contractors in charge of the existing network or system is deemed to be unnecessary for the creation of plans. However, the above examples are cited since there are existing systems in many procurement projects. (ii) The operation manual assumes the use of the equipment possessed by the iDC contractor for internet connection and firewall, etc. as a precondition. However, when the equipment is prepared separately by a related contractor, such as a network contractor, the items shall be defined in accordance with the consigned items. (iii) Response policies of the iDC contractor and a communication flow with the relevant official of the Ministry of ___ in the event of a large-scale
453
disaster shall be clarified. (iv) The frequency of Service Level Management (SLM) (evaluation items, reporting and review cycle, etc. regarding SLA) shall be determined with consideration to the level of importance of the system, although it is specified to be every three months in the “example/explanation of a description in specifications.” This is because the necessary costs for SLM may grow significantly if the number of items and frequencies is increased.
Notes on security
454
4. Operation/maintenance (daily)
Item Description Outline of service operations
Operations and maintenance tasks to be implemented and reported on a daily basis
Suggested input (Prepared by the procurer)
Operation manual Procedures for monitoring security status
Product (Prepared by the contractor)
System operation daily report Incident (abnormality) report (only when an incident occurs)
Points to be described in specifications
To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be described] ・Daily tasks
(Equipment maintenance management, monitoring of system operation status, maintenance management, matters related to reporting)
・Creation of a system operation daily report Example/explanation of a description in specifications
Example of a description in specifications ○Daily tasks (i) Equipment maintenance management
The contractor shall monitor power source/ventilation equipment, disaster detection devices (smoke sensor, etc.), and surveillance cameras, etc. that have been provided as iDC equipment. The contractor shall conduct maintenance management of security devices for the access to the room and access control of visitors.
(ii) Operation status management The contractor shall monitor the items stipulated in “3. Preparation for initiation of operation/maintenance” in accordance with the operation manual (Examples of monitoring items)
Live monitoring of the system Process monitoring Event/message monitoring Capacity monitoring (The rest are omitted.)
(iii) Maintenance management The contractor shall carry out visual confirmation of lamps [LED (status display lamp), indicator display and device status display, etc.] by regular patrolling and monitoring the status of devices.
(iv) Matters related to reporting The contractor shall carry out reporting based on the prescribed communication/response method if defects are detected or
455
concerns outside the scope of the procedures are noticed during the daily operations.
○Creation of a system operation daily report To record the status of the above mentioned (i) and (ii) in the system operation daily report.
Notes on characteristics of project/information system
(i) When the daily report is deemed unnecessary due to the importance of the system accommodated in the Data Center, etc., this section may not be required. However, reporting on monthly basis is regarded as mandatory.
Notes on security Security monitoring The contractor shall report the security monitoring status (careful investigation of the firewall logs, monitoring of unauthorized access, etc.) and the monitoring results shall be periodically reported to the relevant official of the ministries.
456
5. Operation/maintenance (weekly)
Item Description Outline of service operations
Operations and maintenance tasks to be implemented and reported on a weekly basis
Weekly tasks (database backup, etc.) Creation of weekly report
Suggested input (Prepared by the procurer)
Operation manual
Product (Prepared by the contractor)
System operation weekly report
Points to be described in specifications
To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be listed] ・Weekly tasks ・Creation of a system operation weekly report
Example/explanation of a description in specifications
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.
Notes on characteristics of project/information system
(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.
Notes on security -
457
6. Operation/maintenance (monthly)
Item Description Outline of service operations
Operations and maintenance tasks to be implemented and reported on a monthly basis
Monthly tasks (security diagnostics, etc.) Creation of a monthly report
Suggested input (Prepared by the procurer)
Operation manual Procedures for security diagnosis
Product (Prepared by the contractor)
System operation monthly report Report on security diagnosis
Matters to be described in specifications
To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be described] ・Monthly tasks ・Creation of a monthly report
Example/explanation of a description in specifications
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.
Notes on characteristics of project/information system
(i) It is assumed that the SLA items shall, in principle, be specified; however, the SLA performance need not be reported if SLA is not specified, depending on the importance of the system, etc.
Notes on security Security diagnosis and reporting The contractor shall carry out periodical diagnosis on vulnerability and report its result (situation, impact, response method) to the relevant official of the ministry.
458
7. Operation/ maintenance (irregularly)
Item Description Outline of service operations
Operations and maintenance tasks to be implemented and reported on an irregular basis
Suggested input (Prepared by the procurer)
Operation manual Request for and report on emergency work (section of request)
Product (Prepared by the contractor)
Request for and report on emergency work (section of report) Other reports on work results (no fixed format, etc.)
Matters to be described in specifications
To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be listed] ・Details of work ・Creation of a report
Example/explanation of a description in specifications
Examples of descriptions in specifications ○Details of work
(1) Maintenance management (i) Regular maintenance
The contractor shall implement the reception and on-site presence of SE/CE for the regular maintenance of operations of installed devices, etc., necessary tasks prior to and after the work (server shutdown, restart), and confirmation of the completion of the maintenance work, etc.
(ii) Response to defects The contractor shall implement reporting for lap status confirmation/monitoring status and log data collection, at the time of occurrence of a defect, etc.
(2) Storage management The contractor shall implement the system change and system full backups after the maintenance / alteration work.
(3) Expendables management (i) Hardware management
The contractor shall perform acceptance operations/ renewal of management register in response to hardware addition/change
(ii) Media management The contractor shall receive new media from the concerned contractor, change to the new media, and renew the management register when replacement becomes necessary due to damage/degradation of the media
(4) Other (i) The contractor shall implement the reception of visitors to
the Data Center (leading visitors into the server room),
459
implement reception of other business operators, such as relevant officials of the ministry and the developer (guiding them to the place where racks are installed, etc.).
(ii) Sending and receiving of goods (consumables, etc.) The contractor shall handle the reception of goods sent from the relevant administrative officials, related contractors, and the external business operators concerning the system, or the shipment of goods.
(iii) Audit management The constructor shall implement audit acceptance/ response to inquiry slips when iDC becomes subject to various audits, including those of external organizations
(iv) Removal of devices When removing installed devices and racks or moving the Data Center, the contractor shall implement removal work in cooperation with concerned contractors, such as device procurement vendors; such work includes the removal of devices, unfastening of the fixed racks, retracting of the power cables and transfer of operation procedures.
(5) Response to references, etc. The contractor shall implement a lamp status confirmation, hardware installation status and response to inquiries/requests for information provision concerning iDC equipment/operation, such as inquiries about the Data Center equipment.
(6) Creation of report The contractor shall create a “request for and report on irregular work” with respect to the work result in accordance with the document of “request for and report on irregular work.” When other tasks are implemented, a report (no fixed format) shall be created on the result of the work.
Notes on characteristics of project/information system
(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 -
460
6.8.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware
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.Work plan Implementation plan By five days prior to the commencement of work after the conclusion of the contract
2.Implementation of work Report on completion of work Within five days after the completion of work
3.Preparation for initiation of operation/maintenance
System operation monitoring procedures Communications-related documents Communication flow chart
At the time of formulating pre-operation documents (by the commencement of operation training)
4.Operation/maintenance (daily)
System operation daily report Incident (abnormality) report (only in the event of incident)
Every day after the commencement of operation
5.Operation/maintenance (weekly)
System operation weekly report Every week after the commencement of operation
6.Operation/maintenance (monthly)
System operation monthly report Security diagnosis report
Every month after the commencement of operation
7.Operation/maintenance (irregularly)
Request for and report on irregular work (section of request)
Within five days after the completion of work
6.8.4. Suggested input
The following table shows input and timing to be presented to the procurer (proposer) in advance.
The official name of each product and its delivery deadline should be entered in accordance with the
actual situation. Service Input Timing for presenting input
1.Work plan
Establishment of Date Center and list of devices subject to operations management
Included in procurement specifications or as an attachment at the time of tender publishing
Requirements for the of installation site
Included in procurement specifications or as an attachment at the time of tender publishing
System integration schedule Included in procurement specifications or as an attachment at the time of tender publishing
2.Implementation of work List of devices and network diagram
Included in procurement specifications or as an attachment at the time of tender publishing
3.Preparation for initiation of operation/maintenance
List of monitoring items of system operation
Included in procurement specifications or as an attachment at the time of tender publishing
4.Operation/maintenance (daily)
Operation manual Security status monitoring procedures
―
5.Operation/maintenance (weekly)
Operation manual ―
6.Operation/maintenance (monthly)
Operation manual Security diagnosis procedures ―
7.Operation/maintenance (irregularly)
Request for and report on irregular work (section of report) ―
The following show the examples of suggested service level settings in iDC equipment. Items and
values should be used as a reference and should be determined in accordance with the importance
of individual projects and systems. The contractor should clearly prescribe the level of the quality of
services to be provided by setting the SLA, which is the result of consensus between the procurer
(the Ministry of ___) and the provider (iDC contractor), and carry out maintenance and management
461
of the service level in accordance with the SLM. The SLA has two approaches: guaranteed-goal
oriented approach and effort-oriented approach, either of which should be applied to each item.
Examples of service level settings for iCD equipment are listed below. Items and values should be
used as a reference and should be determined in accordance with the importance of individual
projects and systems.
Item
number Classification Service level
items Details of regulations Unit Example of service level settings
1-1 Availability Service hours Hours in which iDC equipment is provided
Time Defining service hours (set by the type of service) Examples of the service type:
・Power supply ・Operation service ・Operation monitoring
Examples of time setting ・24 hours×7 days/week
(Excluding planned shutdown plan/ regular maintenance)
・9:00-17:00 Notice of a service shutdown (when a shutdown occurs during service hours, time of planned shutdown shall be set by the provider on an individual case basis, and a prior announcement of the planned shutdown shall be stipulated.)
1-2
Service availability
Availability (power supply) - weld time/service time
Availability To manage continuity of power supply to installed devices. At least 99.8% availability, etc. However, if redundant power source is installed, a judgment basis for supply disruption should be defined.
1-3 Availability (installation environment) - provision time within management range/ service time
Availability By setting server room management temperature and humidity (24ºC±4ºC), the temperature and humidity shall be controlled within the range. The operations shall be carried out within the management range. Example of the setting: To be controlled between an upper limit and a lower limit at a 99.5% level of confidence.
1-4 Availability (network) - network operating time/scheduled network operating time (service time)
Availability To define availability concerning the network procured as iDC equipment. At least 99.9% availability, etc.
1-5 Availability - monitoring service provision time/scheduled monitoring service provision time (service time)
Availability To define system availability concerning various monitoring environments procured as iDC environment. At least 99.5% availability, etc.
2-1 Reliability Number of operator staff
Number of staff engaged in the relevant system
Staff number
To define the number of staff when constructing operation system exclusive for the system to be procured
2-1 Accuracy Error rate per operator (operation other than procedures)
Error rate (%)
To define the number of operation errors and typographical errors, etc. with respect to the details of the statement of operation procedures. Setting the parameter should be careful when defining the error rate, instead of defining the frequency.
2-3 Operator staff Number of training sessions for operator
Number of training sessions
To define the number of training sessions for operators about ISO-related matters and security policies: for example, 8 hours every 6 months.
462
Item
number Classification Service level items Details of regulations Unit Example of service level settings
2-4 Reliability Defect notification process/ notification time
Setting a communication process at the time of occurrence of a defect (recipient of notification/method/path) and time spent on notification to prescribed recipients based on the communication process ・Method of notification - phone call, e-mail, website ・Example of recipient of notification - procurer receiving the provision of services -Owner of services (in cases where services are outsourced)
Presence or absence
Time
・To contact designated emergency contact persons by e-mail/phone call and post notification on the website ・To set notification time suitable for the recipient of notification ・Settings suitable for the service level within/outside of business hours To implement the SLA settings taking the three points above into account. The following are the possible cases: Case 1 Notification of defect within business hours to procurers who receive service provision or service owner by phone call or e-mail (e.g. within one minute in the case of automatic notification system. within five minutes in the case of person to person contact) Case 2 Notification of defect outside of business hours to procurers who receive service provision or service owner by phone call or e-mail (e.g. within one minute in the case of automatic notification system. within 10 minutes in the case of person to person contact) Case 3 Defect occurrence report on the website for the procurers who receive service provision and target posting time (posting the time of occurrence, and expected time of recovery on the website within 30 minutes after the defect occurrence)
2-5 Defect monitoring interval
Collection of defect incidents/interval of aggregation (Frequency of confirmation of operation status of devices)
Time There are cases where settings are different between within and outside of business hours. Within one minute (core business) Fifteen minutes (other than the above)
463
6.8.5. Division of roles This section introduces an example of the division of roles between the hardware maintenance
contractor, ministries and procurement contractors of other operations.
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
464
contractor shall also make necessary adjustments and coordination.
(3) Division of roles
The following are the examples of a division of roles in installation work (1. Work plan – 3.
Preparation for initiation of operation /maintenance) and product operation (4. Operation/
maintenance (daily) – 6. Operation Maintenance (irregularly), removal work (7. Removal work).
A. Installation work
○: Main operator in charge, △: Support, advice Work item Supervisory
section Maintenance contractor
Operator Network contractor
iDC contractor
System integration contractor
Device procurement contractor
Development/presentation of input information ○ △ △ △ △
Creation of WBS concerning iDC equipment ○
Regular briefing session △ ○ Creation of layout of server room installation ○
Creation of rack installation diagram (*1) ○
Creation of power connection diagram ○
Anti-seismic rack anchoring work (standard rack preparation (*1))
○
Power source preparation work ○
Device emplacement work ○ Presence at the emplacement site (instruction of installation locations)
○
Preparation for equipment related to cables (*2) ○
Device installation ○ Cable connection work ○ ○ Support for connection work (instruction on connection targets, FA under-floor work, etc.)
○
Preparation for operation monitoring environment (*3) ○
Creation of operation monitoring procedures (*3) ○
Operation acceptance training △ ○
Guidance on acceptance training ○ ○
*1: Division of roles when using racks provided by the iDC contractor is described.
In cases where a device procurement contractor is supposed to prepare racks, the procurement
contractor must create and prepare the racks.
*2: “Equipment related to cables” refers to preparation for rosette for metallic cables, protection duct
for optical lines, and protection duct (or tray) for LAN cable, etc.
*3: “Preparation for operation monitoring environment” refers to the division of work in the case of
using an operation monitoring environment for the iDC. When the monitoring environment is to be
constructed by the related contractor, such as system by a development vendor, etc., the division
of work should be further detailed separately.
465
B. Operation work
○: Main operator in charge, △: Support, advice Work item Supervisory
section Maintenance contractor
Operator Helpdesk contractor
Network contractor
iDC contractor
Device procurement contractor
Development/presentation of input information ○ △ △ △ △
Operations (daily, weekly, monthly, irregularly) *On-site work
△ ○
Operations ○ △ Creation of a report ○ Defect detection/ report △ △ △ △ ○ Implementation of countermeasures against defect
○ ○ ○ ○
Handling of visitors, such as maintenance vendor ○
Media management ○ Maintenance management of equipment (power sources/ventilation, etc.)
○
Server room monitoring *Surveillance cameras,,
access control devices, etc.
○
Reporting abnormality in the server room △ ○
Inquiries from users ○
466
6.9. Network procurement
6.9.1. Definition of procurement area Services of network procurement refer to (1) services related to network construction for LAN
and WAN, etc.(services associated with network construction) or (2) services related to the procurement of such services as a wide area network or internet connection, etc., including WAN (services associated with communication service procurement).
In terms of procurement pattern from the viewpoint of the technical domain, both network
construction and network service procurement correspond to the category defined as WAN design /
construction and ministerial LAN design/construction, covering such services as planning, design,
work, operation and maintenance, etc. On the other hand, in the actual procurement, network
procurement is often carried out concomitantly with server and software procurement of groupware
and file sharing applications; however, this section does not deal with procurement of applications.
Figure 6.9-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
467
6.9.2. Services associated with network construction 6.9.2.1. Services to be listed in specifications 6.9.2.1.1. Typical service operations The following table shows services to be included in the specifications. The corresponding
SLCP-200715 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 Outline of service operations Activities of SLCP-2007 Chapter and section
of specifications corresponding to
BGP 1.Design/development plan
To create a draft plan equivalent to the “Plan of design/development phase” in the Guidelines for Business/System Optimization” To create design/development implementation framework and roles, detailed work and schedule
1.6.1 Preparation for process initiation
Chapter II (4), (5) Chapter IV Chapter V Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI Chapter XII Chapter XIII
2.Design/development Network design, development, work, and unit test (excluding hardware procurement for network devices)
1.6.1 Preparation for process initiation 1.6.3System architecture design 3.2.2Environment construction
3.Migration plan Planning of work necessary for migration of the existing users to the newly constructed network
1.7.3.2 Documentation and validation of migration plan 1.7.3.3 Notification of the migration plan to all the concerned parties
Chapter II (4), (5) Chapter IV Chapter V Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI Chapter XII (2). (4) Chapter XIII
4.Suppor for test and migration judgment
Implementation of tests before handing the system over to the user to verify that the new network will operate as designed
1.6.13 Software acceptance test 1.7.1.8 Formulation of an operation test plan 1.7.2 Operation test
5.Migration Implementation of migration
1.7.3.5 Notification of migration to all the concerned parties 1.7.3.6 Review for migration assessment
6.Operation/maintenance plan
Institutionalization for operation/ maintenance, operation design and organization of documents
1.7.1.3 Establishment of problem management procedures 1.7.1.4 Preliminary coordination for system operation and establishment of work procedures
Chapter II (4), (5) Chapter V (5) Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI
15 Software Life Cycle Process-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 16 The “Basic Guidelines for Government Procurement Related to Information Systems,” March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf
468
Service operations Outline of service operations Activities of SLCP-2007 Chapter and section
of specifications corresponding to
BGP 1.7.1.8 Establishment of work procedures for business operation 1.8.1.2 Creation of a plan and procedures
Chapter XII (3). (4) Chapter XIII
7.Operation/maintenance work
Implementation of operation/maintenance and reporting of operation status in response to the result of the operation/ maintenance plan
1.7.4 System operation 1.7.4.1 System operation 1.7.4.2 Operation monitoring and collection of operation data, identification, recording and resolution of problems, improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation 1.8.2 Problem identification and modification analysis
469
6.9.2.1.2. Explanations and examples of descriptions in specifications concerning services 1. Design/development plan
Item Description Outline of service operations
To support creation of a document equivalent to the “plan for design /development phase” in the Guidelines for Business/System Optimization
Suggested input (Prepared by the procurer)
・ Development schedule ・ Views of ministries through interviews, etc. ・ Ministerial security policies ・ User organizations (centers) in which the systems are deployed.
Product (Prepared by the contractor)
・ Documents pertaining to support for the formulation of a design development plan
Matters to be described in specifications
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]
Example/explanation of a description in specifications
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.
Notes on characteristics of a project/information system
The plan for the design/development phase designated as a deliverable product in this service is equivalent to the “plan for the design/development phase” in the optimization guideline. Although the optimization guideline does not require a creation of the relevant product at the time of expansion, the relevant product should still be created in the case of a large-scale expansion due to the necessity of reaching consensus among concerned parties.
There may be cases where further detailing of definition requirements is outsourced at the design phase. Please see “6.2.2. Support for the definition of requirements phase” for the details.
Notes on security Information security measures in accordance with the importance and risks involved in the information assets shall be specifically defined pursuant to the information security policies of each ministry based on the Standards for Information Security Measures for the Central Government Computer Systems.
470
2. Design/development
Item Description Outline of service operations
In charge of design, architecture, construction, unit tests of the network
Suggested input (Prepared by the procurer)
・ Basic requirements for input data references, implementation framework and project management policies, communications with key personnel, boundary of responsibility with concerned parties, etc. that are necessary for design/development.
・ User organizations (centers) in which the system are deployed ・ Existing environment (network diagram, etc.) ・ Network information of superior organizations to be connected (if
necessary) ・ Physical prerequisites of the locations where devices are to be installed ・ Technical requirements necessary for network design/development ・ Definition of service level items (if necessary)
Product(Prepared by the contractor)
・ Implementation plan for design/development ・ Basic design
・Physical design ・Logical design ・Reliability design ・Line design/external connection design ・Security design
・ Detailed design ・ Work diagram and device installation diagram ・ Connection specifications ・ Setting document
Matters to be described in specifications
To specify matters to be carried out by the contractor with respect to network design/construction [1.Basic requirements to be listed] ○Details of an implementation plan for design/development ○Requirements to be met by the design/development contractor (skills,
etc.) (if necessary) ○Details of designs (basic design, detailed design, connection design)
-To include items to be discussed (detailed setting items. LAN/WAN connection design items, items to be coordinated with individual systems, etc.)
○Details of development -To include notes and requirements for implementing development
work -To include requirements for performing tests
[2. Requirements to be added depending on type/characteristics of project] ○If there are matters to be coordinated with LAN/WAN connection design or
individual systems, etc., the details of procurement of such work shall be specified.
○If removal/disposal of existing equipment and devices is necessary, requirements for such work shall be included.
471
Item Description Example/explanation of a description in specifications
Example of descriptions of basic requirements to be specified ○Details of implementation plan for design/development (1) The contractor shall create an implementation plan for
design/development which includes an implementation framework of design/development and roles, detailed definition of work and schedule, development environment, development method and development tools, etc., while seeking coordination with the Ministry of ___.
(2) The contractor shall carry out design/development work in line with the implementation plan for design/development and shall report the results.
○Requirements to be met by design/construction contractor The manager of design/construction work in this procurement shall meet the following requirements. 《Note: The following describes the requirements for experience in services equivalent to the relevant service, a list of qualifications for an individual or person having a capacity equivalent to the qualifications, and the qualification requirements for an organization. If only persons with qualifications can work due to legal reasons, participation of a qualified person is mandatory whether or not such description is given. Specific details are omitted.》 ○Details of designing (1) Basic design
The contractor shall describe the logical configuration and physical configuration, etc. in the basic design after determining specific network services and devices following the final confirmation of requirements for this procurement. Equipment in the center necessary for operation/ maintenance shall also be designed. When designing, the contents shall be consistent throughout the entire network to avoid inconsistency with the existing network which will continue to be used. The following are matters described in the basic design. (Details are omitted.)
A. Equipment design (designation of target range) B. Design of IP address (domain design) C. Routing design D. Physical configuration design (designation of target range) E. Logical configuration design (network topology, etc.) F. Line configuration design (backbone line, interchange circuit, access
line) G. Design based on the security policy (encryption, FW, IDS/IPS,
quarantine) H. Encryption design (encryption specifications, encryption method,
encryption algorithm) I. Bandwidth reservation design (bandwidth control specifications,
bandwidth control method)
472
Item Description J. Quarantine system design (quarantine specifications, quarantine
method) (2) Detailed design
The details of setting and setting policies and reasons shall be described in the detailed design with respect to major setting items of devices operated in the relevant network based on the basic design. The following are matters implemented in the detailed design. Items related to server, etc. which is operated together with the network are also described here. (Please also refer to “6.7 Tasks incidental to procurement of devices.”) (Details are omitted.)
A. Parameter design for network monitoring (network monitoring parameters, server monitoring parameters)
B. Parameter design for network devices (setting values for routers, switches, etc.)
C. Detailed design for server devices (configuration of server (redundancy configuration, etc.), storage configuration, software functions (OS, middleware, etc.) and parameter design
D. Parameter design for security services (quarantine, etc.) (3) Connection design
Physical configuration and setting conditions, etc. shall be clarified in the connection design for the connection with concerned departments, equipment and concerned systems. The following are items to be determined in the connection design. (Details are omitted.) i) Information center
A. A method of acceptance for provided services of the existing network operated by the existing operation and maintenance contractor, which will continue to be used.
B. Interface specifications C. IP address (domain, etc.) D. Routing design E. Security policy design (filtering conditions) F. Encryption design (encryption range): introduction of encryption with
appropriate level of strength based on the government’s guidelines G. Equipment specifications concerning installation and operation
ii) ___ System A. The method of the provision of services B. Interface specifications C. IP address (domain, etc.) D. Routing design (allocation of communication paths to the
business-oriented network and the information-oriented network) E. Quarantine system design (presence or absence of the quarantine
application, scope of quarantine, information on devices subject to quarantine)
F. Firewall/IDS/IPS design G. Equipment specifications concerning the network connection of this
473
Item Description system
○Details of development
The contractor shall carry out specific construction work based on the applicable design contents. The contractor shall also compile these contents into the products concerning design/construction.
The following are matters implemented in the development work. (Details are omitted.) (1) Items of construction work
A. Line installation B. Device emplacement/fitting C. Equipment adjustment (unit test) D. Device setting/construction
(2) Line installation, device emplacement/fitting The contractor shall carry out line installation, device emplacement,
installation and operation verification at the user organization’s location to which the network is connected. The contractor shall provide support for inquires about verification tests conducted by the user after the completion of migration.
Examples of requirements to be added depending on type / characteristics of project ○ Examples of listing LAN/WAN connection design and adjustment with individual systems, etc. (1) Existing system user organizations There will be in principle no installation work in the existing system user organization since the speed of the existing line will be increased (instead of installing a new line). (2) Newly connected system user organizations 《Note: Prerequisites and conditions for design and construction shall be specified with respect to the following items, etc.》 ・Securing of site, securing of power source equipment ・Implementation of preparation, installation, securing of power source, and installation of cables running in conduits and devices, etc. ・Coordination with the managers of user organizations and management companies of the relevant LAN ・Prerequisites
The following are the physical prerequisites for the installation of devices in each user organization. In the case of user organizations, etc. which cannot adopt the following conditions, the contractor shall carry out the installation upon coordination with the relevant personnel and user organization in accordance with the actual situation of the user organization, etc.
(1) Power source conditions -omitted (2) Ventilation conditions -omitted
474
Item Description (3) Installation conditions -omitted
・Specifications of network requirements (Details are omitted.) The area shall be divided into the WAN environment and the center connection environment and detailed requirements for specifications shall be presented based on the network configuration described here (with configuration diagram).
(1) WAN environment ・ Communications protocol and routing method ・ Bandwidth reservation ・ Security requirements
The contractor shall take measures in line with the “information security policies of the Ministry of ___.” (2) Center connection environment (an environment that connects the new and existing centers via WAN cables, such as wide area Ethernet) ・ Communications protocol and routing system ・ Security requirements If there are matters to be cooperated specifically with the existing operation and maintenance contractor, etc. (method of sharing security information, test methods, emergency measures, etc.), such cooperation shall be described.
○Examples of requirements for removal and disposal of devices (1). Removal and displacement work (details are omitted.)
Details of work shall be presented. ・ Removal of unnecessary devices ・ Removal of related cables and lines ・ Clarification of objects not to be removed ・ Concept of bearing expenditures necessary for removal,
displacement and disposal (including protective materials, equipment and vehicles, etc.)
・ Creation of a work schedule concerning the dates and frequency of removal/displacement
・ Implementation of necessary protective work (2). Data deletion
A. The contractor shall carry out coordination, etc. concerning data deletion upon gaining approval of the relevant official.
B. Data shall be completely deleted so as not to be restored by a third party by using data restoration software, etc., once unnecessary devices have been removed and displaced.
C. The contractor shall, at its expense and responsibility, prepare places and devices necessary for the data deletion. The contractor shall take strict security measures to prevent information leakage from the unnecessary devices throughout the process, from the removal and displacement of the unnecessary devices to the deletion of data. However, this does not apply if the work is carried out within the
475
Item Description Ministry.
D. Following the completion of data deletion, the contractor shall submit certification of data deletion to the relevant official.
(3). Disposal (Details are omitted.) The contractor shall present the details of work and methods.
A. The contractor shall observe disposal-related laws and regulations. The work may be re-entrusted (only with notification and approval of the relevant ministry in advance).
B. The contractor shall submit the certificate of the completion of disposal after the completion of disposal.
C. In the case data deletion work, except for cases of destroying unnecessary devices, if the device is re-commissioned, an approval of the relevant official shall be obtained in advance.
D. The Ministry is entitled to carry out inspections of the work. E. The devices may be re-used as used devices. However, an approval
shall be obtained in advance. Notes on characteristics of a project/information system
・ Requirements for a connection with an existing system under given operating conditions shall be appropriately detailed.If there is an existing system to be connected, requirements shall be appropriately specified because it will be in given environmental conditions.
・ If there is an existing network operator, the details of cooperation and conditions shall be appropriately stipulated.
・ The examples of descriptions assume a off-site implementation of data deletion work. However, on-site data deletion should be considered since taking data out of the premise is highly risky under current circumstances.
・ If it is necessary for the proposer to understand the detailed requirements, such as technical requirements and constraints, such statements shall also be included. -User organizations (centers) in which the systems are deployed, or
the existing environment -Boundary of responsibility for the procurement -Physical prerequisites in the location where devices, etc. are to be
installed. Notes on security In light of the importance of security, the following requirements / conditions
(if any) shall be specified. Information security requirements (measures) The contractor shall take comprehensive security measures, observe
security policies and security guidelines issued by the Ministry in order to carry out comprehensive measures recognized as security measures by the market. For operations, the contractor shall maintain the security level. With respect to the security measures to be taken by the entire network, cooperation and coordination shall be taken with the existing operator/maintenance controctor
Disposal of devices Except for when destroying unnecessary devices, data shall be
476
Item Description completely deleted so as not to be restored by a third party by using data restoration software, etc., once disposal devices have been removed and displaced.
Security design The contractor shall either carry out design work, such as security
policy design (encryption, FW, IDS/IPS, quarantine) and encription design (encryption specifications, encription method, encription algorithm), etc. or follow the regulations presented together with the specificaitons.
Security inpsection A vulnerability of network devices to be introduced may be identified
and disclosed by a third organization, etc. Problems (if any) shall be appropriately addressed.
477
3. Migration plan
Item Description Outline of service operations
To formulate a plan of work necessary for the migration to a newly constructed network.
Suggested input (Prepared by the procurer)
・ Migration conditions (constraints, etc.) ・ Expected migration work flow
Product (Prepared by the contractor)
(1) Migration implementation plan ・Migration schedule ・Communication method during migration ・Migration criteria, etc.
(2) Migration procedures Matters to be described in specifications
The contractor shall specify requirements for the implementation of or support for migration work through the connection of a newly constructed or extended network to the existing network, as well as items necessary for planning, etc. [1. Basic requirements to be listed]
○Policies and requirements for migration ○Details of the formulation of a migration plan
[2. Requirements to be added depending on type/characteristics of project]
Example /explanation of a description in specifications
Examples of basic items ○Policies/requirement for migration (Details are omitted.)
A. Flexible plan B. Ensuring stable operation and business continuity F. Prompt support for an application connection test, etc. conducted by the
user. The procurer shall make requests for the support from the existing operation/maintenance contractor, if necessary.
B. Formulation of migration procedures for the manager of the individual system and migration procedures for the manager of the user organization
C. Scope of approval from the relevant official and confirmation from the existing operation/maintenance contractor, upon consultation with concerned parties
○Details of the formulation of a migration plan The contractor shall formulate a migration plan with respect to the following items in order to solidly implement migration in a planned manner.
A. Migration implementation framework and roles of migration-related companies and contractor
B. Detailed work and schedule for migration C. Migration environment D. Migration method
478
Item Description Notes on characteristics of a project/information system
In cases of a large-scale separate procurement project, the responsibility demarcation may become unclear. Thus, the responsibilities should be clarified in advance by, for example, creating a table of the division of roles. In cases of a large-scale network covering a multiple number of center’s equipment, the installation and connection of termination units may be conducted simultaneously with the migration following the unit and system tests for the equipment of each center. In that case, it may become closer to reality if the items of “line installation, device emplacement/fitting work” in the previous section in the design/construction are included as part of the migration services in this section and the next section.
Notes on security -
479
4. Support for test and migration judgment
Item Description Outline of service operations
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)
・Implementation requirements for tests ・Outline of acceptance test (performed by the procurer) ・Migration criteria (or criteria for the acceptance test)
Product (Prepared by the contractor)
・Test procedures ・Test plan ・Report on test results
Matters to be described in specifications
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
Example/explanation of a description in specifications
Examples of basic requirements to be described ○Creation of a test plan
The contractor shall create a test implementation plan describing the test framework, detailed tasks and schedule, test environment, test tools and acceptance criteria, etc.
○Implementation of test (description of the implementation details) The contractor shall carry out tests on the new system with respect to the following contents and verify that the system will operate as designed. (Details of tests are omitted.) ・Inter-center test ・Connection test with the business system ・Information security verification test ・Comprehensive test ・Support for operation test (acceptance test, user test)
○Implementation of progress/issue management The contractor shall present management/reporting rules with respect to the progress of tests based on the test plan and operation tasks before the commencement of the tests and gain approval of the Ministry of ___. Consequently, the contractor shall conduct management/reporting in compliance with these rules. ○Report on results The contractor shall compile the test results into a “report on test results” and gain approval from the Ministry of___.
480
Item Description ○Support for acceptance test After the completion of the comprehensive test, etc. conducted by the contractor, etc., the Ministry of ___ shall carry out an acceptance test in order to verify that the new system conforms to requirements. The contractor shall provide support for creating an implementation plan for the acceptance test and acceptance test specifications formulated by the Ministry of ___, as well as support for implementing the acceptance test. ・Other (1) If the use of the data, etc. of the existing system is deemed necessary for
the tests, the contractor shall make a request to that effect to the Ministry of ___. The Ministry of ___ provides the data, etc. only when it is concluded that there is good reason to do so. The contractor shall handle the provided data, etc. with care.
(2) The contractor shall prepare necessary devices and communication lines, etc. for the tests.
Cases where support for migration judgment is defined as service requirement ○Support for migration judgment Migration judgment is a final decision made by the new network side and related individual system’s side as to whether or not to make a conversion to the new network. To that end, the contractor shall implement the following work based on the instructions of the relevant official, in cooperation with the existing operation/maintenance contractor.
A. The contractor shall provide support for the creation of migration criteria that include work status, matters of concern, and verification items for the xx system, etc.
B. Based on the migration criteria, the contractor shall hold a “migration judgment conference” attended by the relevant official, the existing operation and maintenance contractor, the relevant contractor, the PMO, and personnel in charge of the management of individual systems, with an aim to reach a consensus on the finalization of the “migration criteria” and on a conversion to a new network of the xx system.
Notes on characteristics of a project/ information system
3. Refer to design / development
Notes on security The contractor shall thoroughly implement tests for information security. A vulnerability of the network devices to be installed may be identified and disclosed by a third organization, etc. Problems (if any) shall be appropriately addressed.
481
5. Migration Item Description
Outline of service operations
To carry out migration
Suggested input (Prepared by the procurer)
・Division of roles between the procurer and the contractor
Product (Prepared by the contractor)
・Report on migration results
Matters to be described in specifications
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]
Example / explanation of a description in specifications
Examples of specifications of migration work associated with inter-organization network connections, such as centers and introducing organizations ○Policies on migration implementation
A. If the work is suspended due to a failure, etc. during the migration, an initial report shall be made to the concerned parties that may be influenced. The procedures shall be in line with the reporting procedures formulated in the plan.
B. When a problem in the existing system occurs through the connection to the network, the concerned parties shall cooperate in the investigation of the cause. If dispatch of staff to the user organization, etc., is deemed necessary, the arrangement and coordination shall be made with the user organization.
C. In the cases where it is expected that migration/installation may have an impact on the individual systems under operation, etc., the relevant official and manager of the individual systems shall be informed in advance.
D. After the completion of migration/installation, the contractor shall inform the key personnel of the user organization about the completion of work, as well as inform the relevant official and the existing operation/maintenance contractor.
E. Expected main business flow is as described in the reference document. If change in the business flow is deemed necessary for the purpose of efficiency, etc., approval of the relevant official shall be obtained.
○Details of migration work Notes on characteristics of a project/information system
・ In cases of extension of the existing line, the contractor shall consider including such tasks as reporting to the existing operation/maintenance contractor, etc. since use in combination with the existing system is important.
・ The details of the description shall be arranged in accordance with the actual situation, such as the scale of the procured network and the presence or absence of the existing system.
482
Item Description Notes on security
-
6. Operation / maintenance plan
Item Description Outline of service operations
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.)
Suggested input (Prepared by the procurer)
・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
Product (Prepared by the contractor)
・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
Matters to be described in specifications
To list items and service requirements for the preparation of initiation of operation/maintenance [1. Basic requirements to be listed] ○ Requirements to be met by the operation/maintenance contractor ○ Basic requirements for operation/maintenance ○Implementation of operation/maintenance design
-Operation design -Creation of configuration management (host name, IP address,
etc.) and a manual for personnel in charge of maintenance -Formulation of a service level management plan
○Framework and division of roles in operation/maintenance [2. Requirements to be added depending on type/characteristics of project] ○Transfer from the existing operator
483
Item Description Example / explanation of a description in specifications
Examples of descriptions of basic items ○Requirements to be met by the operation/maintenance contractor
The following requirements shall be met by the manager of operation/maintenance work in this procurement. (5). Security manager
Personnel in charge of security management in this procurement shall meet the following requirements.
A. A person with experience in planning and implementing measures to maintain information security and evaluating the results.
○Basic requirements for operation/maintenance (1) Establishment of a stable and efficient system operation/ maintenance infrastructure
A. Since the operation/maintenance of the overall network is implemented by the existing operation/maintenance contractor, the contractor shall follow the instructions given by the relevant official or the procurement office and act in accordance with the advice of the existing operation/maintenance contractor which assumes the role of an administrator of operation / maintenance.
(Details are omitted.) (2) Provision of high quality user support
A. The offices providing user support for the relevant procurement will be consolidated into one contact point which is managed by the existing operation/maintenance contractor to facilitate the convenience of the users. The contractor shall act accordingly.
(The rest is omitted.) (3) Monitoring and continuous improvement of the quality of services
A. Upon coordination with the existing operation / maintenance company, the contractor shall monitor the values of service level items, evaluate the results and report to the relevant official.
(The rest is omitted.) (4)Implementation of security management in operation/maintenance work
A. The contractor shall observe the security policy of the Ministry of ___ and institute a framework to enable the verification of the compliance with the policy
B. The contractor shall implement training/operation based on the security operation manual.
C. The contractor shall institute a framework to enable reporting to the relevant official and take the necessary measures in cooperation with the existing operation/maintenance contractor in the case of an occurrence of a security event.
484
Item Description ○Implementation of operation/ maintenance design
The contractor shall create the following documents (by implementing operation/maintenance design). (1). Operation/maintenance outline
A document equivalent to the “operation/maintenance outline” in the optimization guidelines
(2). Basic design for operation A product stipulating the operation framework for the network and operation procedures
(3). Operation manual A product stipulating work procedures for key personnel in charge of network operations at the time of using devices and defect occurrence.
(5). A manual for the responsible personnel of the user organization and manager of individual systems
A product describing settings necessary for the use of the network, operation method and application method for the responsible personnel of the user organization and manager of individual systems
(6). Configuration management A product concerning network devices and settings that comprise the network.
(9). SLA and service level management plan A document equivalent to the “Service Level Agreement (SLA)” in the optimization guidelines and the service level management plan
○Framework and division of roles in operation/maintenance
To specify the expected framework and division of major roles in the operation/ maintenance work
Requirements to be added depending on type/characteristics of the project ○Transfer from the existing operator
Notes on characteristics of a project/information system
SLA should be concluded for critical systems.
Notes on security ―
485
7. Operation / maintenance
Item Description Outline of service operations
To carry out operations in response to the results of the preparation for initiation of operation/ maintenance
Suggested input (Prepared by the procurer)
(Documents pertaining to operation/ maintenance created in the preparation for initiation of operation / maintenance)
Product (Prepared by the contractor)
Report on the network operation ・ Operation status
・ Incident status ・ Operating performance ・ Expendables status
・ Operation/ maintenance status ・ SLA conformity status, etc.
Matters to be described in specifications
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.
Example/explanation of a description in specifications
Examples of basic items of operation/maintenance and examples of descriptions in cases where there is an existing operation/ maintenance contractor ○Configuration management/change management Configuration management/change management refers to a series of tasks for maintaining and managing the configuration information to the latest version through changes and relocations of connection settings of the user organizations to which the network is connected. If the implementation tasks need to be entrusted to the existing operation/maintenance contractor, the contractor shall file the application with details of the work to the procurer. (1). Target The target of “configuration management/change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and that of new centers, as well as devices newly installed by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2). Job description (Details are omitted)
A. Review of configuration management/change management
486
Item Description procedures
B. Application for change in network connection (processing of ministerial administrative procedures)
C. Coordination for the schedule of change, work details and requested items and creation of an implementation plan
D. Preparation for changes according to the type of lines and device changes, when the changes are deemed necessary
E. On-site study through coordination with the applicant if necessary
F. Network connectivity test G. Handing over the network environment H. When a problem occurs after the transfer of the environment, an
investigation of the cause shall be carried out cooperatively I. The period between the update of configuration management
information and the maintenance management of the latest configuration shall be less than seven days.
○Maintenance
The maintenance work refers to a series of maintenance / inspection work performed when necessary, in order to maintain the network configuration devices. (1). Target The target of “configuration management/ change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and to those of new centers, as well as devices installed newly by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2) Job description (Details are omitted.)
A. Review of a service implementation plan B. Necessary coordination for the work schedule, work details and
requests, C. Network connectivity test D. Handover of the network environment E. Recording/management of maintenance/inspection F. Notification of operation shutdown for maintenance
○Monitoring
Since the monitoring needs to be carried out covering the entire network, including the portion in this procurement, from the security viewpoint, the existing operation/maintenance contractor shall monitor the network in a comprehensive manner; such monitoring tasks include the centers constructed in this procurement and user organizations which carry out line speed up or to which a new line is connected. However, the contractor shall carry out monitoring of
487
Item Description backbone lines provided by the contractor under this procurement.
A. The contractor shall establish a communication flow so as to be able to promptly receive defect information on lines from the line provider and take appropriate measures based on this procurement.
B. When coordination for settings and thresholds is required, an approval shall be obtained from the relevant official and the concerned parties. The contractor shall also respond to the request for change in settings from the user and carry out such setting adjustment.
○Handling of defect
Handling of defects is a series of work related to the recovery of line and devices, etc., which comprise the network. The contractor shall implement the following operations. (1). Target The target of “configuration management / change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and to those of new centers, as well as devices installed newly by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2). Job description (Details are omitted.)
A. Cooperation with the existing operation/maintenance contractor B. Tasks implemented by the contractor
Notes on characteristics of a project / information system
The contractor shall present the requirements for the configuration management, including the management of the existing assets. When commissioning the helpdesk operations in a comprehensive manner to the existing operation/maintenance contractor, the contractor shall be required to provide cooperation so that the existing operation/maintenance contractor can carry out the helpdesk operations smoothly.
Notes on security Handling of incidents To establish a communication flow to enable rapid reception of
defect information and security incident information concerning the network.
Security diagnosis and reporting Continuous all-time monitoring of the traffic status of lines. In
cases of abnormal traffic, etc., the contractor shall conduct an investigation of the cause immediately and report to the relevant official via the existing operation/maintenance contractor.
Security inspection The contractor shall take appropriate measures promptly when a
vulnerability improvement for the introduced network devices is pointed out.
488
6.9.2.2. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware
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. Design/development plan Documents concerning the support for formulating design/development plan
By the commencement of design/development
2. Design/development Design/development implementation plan At the time of formulating design documents Basic design
Detailed design Work diagram and device installation diagram Connection specifications Settings
3. Migration plan Migration implementation plan At the time of formulating the migration plan Migration procedures
4.Support for test and migration judgment
Testing procedures At the time of formulating the test plan Test plan
Report on the test results After the completion of connection test
5.Migration Report on the migration results After the completion of migration
6. Operation/ maintenance plan
Outline of operation/maintenance At the time of formulating documents for the operation/maintenance plan
Operation design
Operation manual Manual for key personnel of user organizations and managers of individual systems Configuration management system or manual SLA, Service level management plan
7.Operation/maintenance Report on network operations Monthly after the commencement of operation
489
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 Input Timing for presenting input
1.Design/development plan
Development schedule At the time of tender publishing
Views of ministries
2. Design/development Basic requirements At the time of tender publishing
User organizations (centers)
Existing environment (network diagram, etc.)
Outlined in the specifications, Details after the conclusion of the contract
Physical prerequisites for device installation
At the time of tender publishing. After the conclusion of the contract for some contents
Technical requirements for network design/development
At the time of tender publishing
Definition of service level items (when necessary)
3. Migration plan Migration conditions At the time of tender publishing Expected migration flow
4. Support for test and migration judgment
Requirements for testing At the time of tender publishing
Outline of acceptance test
Migration criteria
5.Migration Division of roles between the procurer and the contractor
At the time of tender publishing
6. Operation/ maintenance plan
Period of introduction/operation, etc., loan period, payment period
At the time of tender publishing
Configuration management items Configuration management document format
After the conclusion of the contract
7. Operation/maintenance
(Documents concerning operation/ maintenance created in the preparation for the initiation of operation/maintenance)
At the time of tender publishing
490
Examples of the definition of the service level items: All the items and setting values presented here
are just examples and nothing more, and the actual procurement should be based on sufficient
discussions and consent.
1) Service level items (excerpt)
Network devices are regarded as a service level item since they have a wide area of
influence at the time of an occurrence of a defect and are highly important.
The following shows that the target and the evaluation unit (separately stipulated) is set
by a service.
A. Network devices that are components of the internet connection
B. Network devices that are components of the internal connection
Service level item Description Setting value
Availability
The proportion of actual operating time
(operating hours) to expected operating time
More than 99.9%
Mean Time to
Repair (MTTR)
The average monthly time spent on recovery of
devices from the time of an occurrence of a
defect during the service operation hours
Within one hour
Mean Time
between Failures
(MTBF)
The average time elapsed from one failure of a
device to the next.
More than 2920 hours
(four months)
Service level items concerning initial response to defect/inquiry
Service level item Description Setting value
Lead time from the
occurrence of a
defect/inquiry to the initial
response
Time spent from the occurrence of
the defect /inquiry during the
helpdesk operation hours to reporting
on understanding of the status and
initial response, etc. to the relevant
official and the concerned users.
With 15 minutes
(2) Provisions concerning SLA compliance
The objective of Service Level Management (SLA) is to achieve, maintain and improve
the service level that is required for the operations in cooperation between the relevant
official and the contractor. Thus, in the cases where the target value set in the SLA has not
been achieved, the contractor should attain the service level by making further efforts for
improvements in cooperation with the relevant official.
In the case of a service that provides infrastructures having a great impact on the
information system whose users are the general public, is the people on the social
infrastructure, and on the entire system, a fine shall be imposed if the service level target
has not been achieved, considering its significance. (Penalty and incentive based on the
491
SLM settings and the SLM implementation).
(3) Concept of penalties and incentives
A. Ninety percent of the bid price will be considered as a basic fee award and the rest
10 percent as a contingency bonus in accordance with the status of the SLA
compliance. The evaluation shall be conducted based on the monthly report on the
SLA achievement, and the monthly award shall be paid by adding the amount in
accordance with the “degree of attainment” to the basic fee award.
B. With respect to the service level items, the status of achievement of service level
setting values for each service and device shall be evaluated every month.
According to the number of unattained items of the service level setting value, the
“degree of attainment” of a given month shall be evaluated on a 4-point rating scale.
(4) SLA evaluation period
The compliance to the SLA shall be measured from the date of commencement of
operations. However, the fluctuation of the amount of pay shall commence on the third
month after the start of the service.
(5) Measures for the cases where the service level target value continues to be unattained
A. Damage claim
If the cause of extremely low SLA compliance rate without expectation of
improvements is attributable to the contractor, a damage clam may be separately
filed, which shall not exceed the ceiling price set forth in the contract. The following
are the criteria for the period and frequency of the extremely low SLA compliance.
a. The status of “Grade D” continues for “more than three consecutive months,”
“more than four times a year” or “total of 12 times during the operation.”
b. The status of “Grade C” continues for “more than five consecutive months,”
“more than six times a year” or “total of 18 times during the operation.”
c. In cases where damage occurs exceeding the amount of the contingency
bonus, which is 10% of the bid price, due to discontinuity of business caused
by defect, etc.
B. Deprivation of eligibility for bidding
In cases falling under the situation A above, the contractor shall be considered as
having no capacity to provide the quality of service level required by the Ministry,
and may potentially be subject to deprivation of eligibility for bidding for a certain
period of time, rescission of the contract, imposition of a penalty, including
suspension of eligibility for bidding at the time of the next contract renewal.
492
6.9.2.4. Division of roles The following are the examples of the division of roles between the user and the network operator in
the operation and maintenance in cases where the procurement is carried out in combination with the
existing network. System Major roles Remarks
User
Individual system manager
・ The responsible personnel of each system serving as a liaison for the coordination with the operating body
・ Responsible for attendance at work and support in the separation of a defect and investigation of the cause
Allocated to each system
Person in charge of the user organization
・ The responsible personnel of the user organization serving as a liaison for the coordination with the operating body
・ Responsible for the environment development for the user organization, attendance at work, support for defects, etc.
Allocated to each user organization
Consolidated netw
ork operating body
Contractor ・ To cooperate in creating an operation/maintenance plan (developing implementation procedures manual, etc.)
・ To carry out configuration management/change management, maintenance, defect response and regular reporting in line with the operation / maintenance plan
・ To carry out monitoring, evaluation, analysis and improvement of monitoring items for the quality of services
・ To provide information to the existing operation/maintenance contractor in order to report the implementation status to the operating body (the relevant official)
Assignment regarding the scope of the contract
Existing operation/ maintenance contractor
・ To control and manage operation/ maintenance ・ To formulate an operation/ management plan
(implementation procedures, manual development, scheduling, etc.)
・ To carry out configuration management/change management, maintenance, monitoring, defect response, helpdesk operations, and regular reporting, in line with the operation/maintenance plan.
・ To carry out monitoring, evaluation, analysis and improvement of monitoring items for the quality of services
・ To report the implementation status to the operating body (relevant official)
Relevant official (including the process management support contractor)
・To make decisions and give final approval in operation/ maintenance as the operating body
About two persons (excluding the process management support contractor)
493
Examples of the division of roles between the existing network operation contractor and the
contractor in the operation and maintenance in cases where the procurement is carried out in
combination with the existing network
No. Item Description
Services of the
existing operation/
maintenance
contractor
Services of the
contractor
(section of the scope of
the order received)
1 Operation
control
Control and management of the
overall operations for operation/
maintenance
○ ×
2
Configuration
management/
change
management
Response to applications
concerning network and
configuration/change
management
○ ○
3 Maintenance
Maintenance for devices that
constitute the network when
necessary
○ ○
4 Monitoring
Monitoring the operation status of
lines and devices that constitute
the network
○ △
(Monitoring of backbone lines only)
5 Helpdesk
operations
Response to inquiries and
provision of information about the
network
○ ×
6 Defect
response
Repair and recovery of defects in
lines and devices that constitute
the network
○ ○
7
Reporting on
operation/mana
gement
implementation
status
Regular reporting to the network
operating body of the overall
status, SLA achievement status,
and quality monitoring in
operation/monitoring work
○ ○
8 Security
management
Security maintenance of the
network ○
△ (Response to security
incident)
494
6.9.3. Services concerning procurement of communications services 6.9.3.1. Services to be listed in specifications 6.9.3.1.1. Typical service operations
Service
operations Outline of service operations Activities of SLCP-2007
Chapter and section
of specifications
corresponding to
BGP
1.Preparation for installation
Creation of schedule Coordination with ministries on the implementation procedures Preparation for preliminary study, etc.
3.2.1 Preparation for initiation of process (environment development)
Chapter II (4), (5) Chapter IV Chapter V Chapter VI Chapter X Chapter XI 2.Installation Work necessary for service
provision, etc. 2.2 Construction of environment 2.3.1 Preparation of initiation of quality assurance process
3.Operations management/ maintenance
Operation/maintenance for sustainable service provision
1.7.7 Evaluation of system operation 1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification
Chapter V (5) Chapter X Chapter XI Chapter XII
4.Reporting Regular reporting associated with network service operation
1.7.4.1System operation 1.7.4.2 Operation monitoring and collection of operation data Detecting, recording and solving problems, Improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation
495
6.9.3.1.2. Explanations and examples of descriptions in specifications concerning services 1. Preparation for installation
Item Description Outline of service operations
To carry out preparation work, such as creation of schedule, coordination with ministries on the implementation procedures and preliminary study, etc.
Suggested input (Prepared by the procurer)
・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.
Product (Prepared by the contractor)
・Detailed installation schedule ・Report on on-site studies in the building
Matters to be described in specifications
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.
Example/explanation of a description in specifications
Examples of procurement specifications in cases of service procurement ○The contractor shall determine the installation schedule and implement coordination with ministries. ・ The outline of the schedule shall follow the “draft of installation
schedule,” and the detailed installation schedule shall be fixed within 10 days after the successful bid upon consultation with the relevant official. However, dates are subject to change upon consultation between the Ministry and the contractor in the case of unavoidable circumstances. The contractor shall make necessary coordination with the ___ system vendor.
○Implementation of a preliminary study ・ The contractor shall carry out on-site studies (specifically,
confirmation of following matters: installation method and routes of the cables in the building, presence or absence of documents to be submitted, presence of absence of the specific building management contractor, and necessity of work on the building, such as piping work) in the building of each center of the Ministry and submit a report on the studies in writing with elevation views and plan views of the studied locations to the relevant official.
496
Item Description The contractor shall make a request to the relevant official at this point of time for the submission of documents, if there are any documents to be submitted by the Ministry.
・ Estimates shall be separately submitted if the study finds it necessary to carry out incidental work on the installation, such as piping work in the building, etc.
Examples of function specifications of network services to be procured ○Function specifications (1) Internet connection service (Details are omitted.)
The contractor shall provide the internet connection that meets the following specifications as an internet service provider (hereinafter referred to as “ISP”) (i) Bandwidth (ii) Interface at the time of transfer to the Ministry (iii) Requirements as ISP (v) Proxy application for domains (viii) Allocation for IP addresses (xi) Secondary DNS service, etc. (xii) Conditions for an access line between the interchange point of
the contractor and the Ministry, etc. (xv) Conditions for fees, such as a communication fee in cases of
changes in service bandwidth and line types of the internet connection service.
(2) WAN cable (wide area Ethernet service) All of the following requirements shall be met for the provision of a network of the wide area Ethernet service covering all centers of the head office and local branch offices of the Ministry of ___. Please refer to the “list of locations and bandwidth of each center” for the location and connection bandwidths of centers. (Details of requirements are omitted.)
(3) Connection to ___ system (Details are omitted.) ○Period and location of provision (1) Period of provision Date: From M/D/Y to M/D/Y
(2) Location of provision Internet connection service: Within the computer center of the
Ministry of ___ Wide area Ethernet service: Refer to the “list of locations and
bandwidth of each center” Notes on characteristics of a project/information system
In cases where there are existing LAN and WAN services, or where other related systems are procured at the same time, the contractor shall specify matters to be specially coordinated in the implementation of installation work.
Notes on security -
497
2. Installation
Item Description Outline of service operations
To carry out the work necessary for the provision of services
Suggested input (Prepared by the procurer)
-
Product (Prepared by the contractor)
・ Report on the results of installation ・ Work diagram [diagrams indicating the locations of devices
(ODU, distribution boards, etc.) and locations of the cable routes] Matters to be described in specifications
The contractor shall specify matters to be carried out by the contractor with respect to the installation of the communication services [1. Basic requirements to be listed] ○Details of installation and notes ○Items requiring coordination, etc. [2. Requirements to be added depending on type/ characteristics of project]
Example/explanation of a description in specifications
Examples of procurement specifications in cases of procurement of internet connection services and wide area Ethernet services ○Details of introduction work and notes ・ In cases where defects occur in ___ system, internet
connection services or WAN of the Ministry of ___ and such defects are attributable to the contractor in relation to the relevant work, the contractor, at its expense, shall provide alternative functions.
・ The contractor shall create a table of the operation flow and a defect response manual by the day of commencement of the communication services and gain the approval of the relevant official. If there is light work that can be carried out by the relevant official for a prompt recovery from the defect, the details of such work shall be described in the manual.
・ The contractor shall establish a framework to enable the relevant official to check on the performance of the contract at all times
・ In cases where the provision of internet connection services and wide area Ethernet services is not ready by the scheduled date of commencement, which is attributable to the contractor, the contractor shall either continue using the existing WAN cable or internet connection under the current contract with the Ministry or present an alternative plan, and take measures upon gaining approval of the relevant official. All the costs necessary for the measures shall be borne by the contractor.
○Items requiring coordination, etc. ・ The contractor, when starting work at the centers of the
498
Item Description Ministry, shall take statutory procedures (if necessary) to the government offices and inform the relevant official about the completion of the procedures.
・ Compensation for damages to the third party during work, such as damages to buildings and roads, land devastation, etc. shall all be borne by the contractor.
・ When entering the centers of the Ministry to carry out work, the contractor shall submit written documents indicating the details and scope of the work, the number of workmen, work schedule, and vehicles to be used for work to the relevant official two weeks in advance of the start of the work and obtain approval.
Notes on characteristics of a project/information system
In cases where there are existing LAN and WAN services, or where other related systems are procured at the same time, the contractor shall specify matters to be specially coordinated in the implementation of installation.
Notes on security -
499
3. Operation management/maintenance
Item Description Outline of service operations
To carry out operation management/maintenance for sustainable service provision
Suggested input (Prepared by the procurer)
Service level items (when the conclusion of an SLA is required) Operation requirements
Product (Prepared by the contractor) -
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]
Example/explanation of a description in specifications
Examples of procurement specifications in cases of service procurement ○Details of operations management/maintenance
・ The contractor shall establish a framework of network monitoring and defect response on a 24-hour, seven-days-a-week basis. In view of early detection and rapid recovery from defects, monitoring and defect response services for the internet connection and wide area Ethernet shall be consolidated into one contact point.
・ In cases where the system suspension continues for more than five minutes, in principle, after the detection of a defect, the contractor shall notify the relevant official immediately. The contractor shall also report the status to the relevant official every 30 minutes, in principle, until the system is recovered, except if instructed otherwise by the relevant official.
・ In preparation for the occurrence of a defect, the contractor shall establish a framework enabling defect repair and recovery on a 24-hour, seven-days-a week basis. When a defect is detected, the contractor shall exert efforts for rapid recovery to comply with the SLA.
・ When a defect occurs, the contractor shall, at its expense, take appropriate measures to prevent recurrence.
○Notes on operation work ・ When conducting scheduled work and regular maintenance,
the contractor shall make efforts to avoid network shutdown as much as possible. If the shutdown is deemed necessary during scheduled work and regular maintenance, the contractor shall notify and gain approval of relevant official at least two weeks prior to the shutdown.
500
Item Description ・ If it is obvious that a continuation of system operation will result
in a defect, and thus an emergency shutdown is required, the contractor shall decide on the response upon consultation with the relevant official.
Notes on characteristics of a project/information system
The contractor shall consider making a particular request for consolidation of monitoring and defect response services, depending on the status of the system.
Notes on security -
501
4. Reporting
Item Description Outline of service operations
To carry out regular reporting associated with the network service operations
Suggested input (Prepared by the procurer)
-
Product (Prepared by the contractor)
・Operation report ・Report on SLA achievement status
Matters be described in specifications
The contractor shall describe matters to be carried out by the contractor with respect to the report on communications service operations [1. Basic requirements to be listed] ○Details of report [2. Requirements to be added depending on type/ characteristics of project]
Example/explanation of a description in specifications
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.
Notes on characteristics of a project/information system
If reporting on the reliability of the connection with related systems is deemed necessary, such matters shall be entered in the specifications
Notes on security -
502
6.9.3.2. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware
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
installation
Detailed introduction schedule Within 10 days after successful bid
Report on on-site study of the building After the implementation of the on-site
study on preparation for introduction
2.Installation Report on the results of introduction At the time of completion of introduction
3.Operation
management/maintenance
― ―
4.Report Operation report On a monthly or as needed basis after the
commencement of operations Report on SLA achievement status
6.9.3.3.Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance.
The official name of each product and its delivery deadline should be entered in accordance with the
actual situation.
Service Input Timing for presenting input 1.Preparation for
installation
Outline of schedule Included in procurement specifications or as an attachment
at the time of tender publishing
Function specifications Included in procurement specifications or as an attachment
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
management/
maintenance
Service level item Included in procurement specifications or as an attachment
at the time of tender publishing
4.Report ― ―
503
Examples of descriptions of service level items:
5. SLA
(1) The network covering from the Ministry to the Internet eXchange (IX) and the network
comprising the WAN of the Ministry of ___ shall have high reliability and the availability
of the backbone and the monthly availability of every access line provided shall be over
99.9%, respectively.
(2) The definition of the availability is shown below.
In the internet connection service, “availability” refers to the network availability which
covers from the Ministry to ___.
In the wide area Ethernet service, “availability” refers to the network availability of the
backbone of the wide area Ethernet service and the availability of the access line
network in each center to which the WAN of the Ministry of ___ is connected.
The defined availability is the percentage of time of actual operation to the agreed
service time in a month and is calculated in the following way. The scheduled
operating time is, in principle, the time obtained by multiplying the days of a given
month by 24 (hours) and the total down time refers to the accumulated time per month
of experiencing performance problems in receiving or sending data.
Availability (%) = (Scheduled operating time – total downtime) ÷ scheduled operating time × 100
(3) The time of occurrence of a defect refers to either the time when the contractor has
detected the defect or the time when the relevant official of the Ministry (hereinafter
referred to “the relevant official”) has informed the contractor about the defect,
whichever happens first.
(4) The period of a system shutdown which is not attributed to the contractor or due to
scheduled work or regular maintenance shall not be considered as downtime in the
availability calculations.
(5) If it is obvious that a continuation of a system operation will result in a defect and thus
an emergency shutdown is required, the period of time of emergency shutdown shall
be considered as downtime in availability calculations.
(6) Other items related to the SLA shall, in principle, be in compliance with the SLA
stipulated in the service agreement of the contractor. The contractor shall submit the
SLA stipulated in the service agreement at the time of making proposals.
(7) If the business continuity is ensured by line redundancy, etc. even when the lines are
down, such a period shall not be considered as downtime in availability calculations.
504
6.10. Cloud service
Please refer to “4.8 Standpoints of Cloud Users” for this section
505
6.11. Cloud construction
Please refer to “4.9 Standpoints of Cloud Integration” for this section
506
6.12. Security
6.12.1.Definition of procurement area Unlike other sections in this Chapter, the security section refers to the indispensable security
features (security notes) in the procurement of each service.
The security notes provide the essentials to be implemented in the procurement of information
systems, as well as security matters in each service of the procurement area.
This section also includes the use of “the security by design (SBD) as a measure to ensure
information security of e-Government from the stages of planning and design” and “system design for
the risk factor reference model (RM) analysis,” which are specific security approaches to be used in
information system integration.
Figure 6.12-1 Items corresponding to the areas of procurement of services
6.2 ( 等)
要件定義 開発フェーズ 運用・保守フェーズ
6.2 - 1 調達支援
( 等) 6.1 全体計画 策定支援
6.4 運用 6.3
6.3 ハードウェア更改 6.3 機能追加
・ 設 備 ) 6.9 Network procurement
6.7 Tasks incidental to procurement of devices
6.8 Tasks incidental to procurement of iDC equipment
6.12 Security
6.2.3 Support for procurement (Project management, etc.)
Planning phase
Requirements definition phase
Development phase Operation/maintenance phase
6.2.2 Support for procurement (requirements definition, etc.)
6.1 Support for master plan formulation
6.4 Operation
6.3 System integration (design/development)
6.5 Helpdesk
6.6 Maintenance
Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance
507
6.12.2. Notes on security to be commonly listed in specifications 6.12.2.1. Notes on security commonly applied to the procurement of information systems
Basically, security notes to be followed uniformly by each service domain means the compliance
with laws and regulations and the conformity to standards, policies and guidelines, etc. The
contractor should give careful consideration to the contents listed in 1-5 when performing each work
task. All the constraints as requirements for bidding should be listed comprehensively. Standards,
policies and guidelines, etc. to be conformed to should be disclosed to the bidders during the tender.
Notes Outline of notes Points of description
1. Conformity to the “Standards for Information Security Measures for the Central Government Computer Systems”
The contractor shall conform to the “Standards for Information Security Measures for the Central Government Computer Systems” (Decision by the Information Security Policy Council)
The contractor shall indicate the conformity to the standards mentioned in the left column in the section of the “security requirements,” in cases where specifications are created in pursuant to the Basic Guidelines for Government Procurement Related to Information Systems
2. Conformity to security policies issued by each ministry
The contractor shall conform to the information security policies issued by each ministry in pursuant to the above-mentioned “Standards for Information Security Measures for the Central Government Computer Systems” (Decision by the Information Security Policy Council)
The contractor shall indicate the conformity to the standards mentioned in the left column in the section of the “security requirements,” in cases where specifications are created in pursuant to the Basic Guidelines for Government Procurement Related to Information Systems. If the policies mentioned in the left column are disclosed after the conclusion of confidentiality agreement, such matters shall also be mentioned.
3. Compliance with laws and regulations, etc.
The contractor shall comply with laws and regulations concerning the relevant procurement projects, including the Act concerning Protection of Personal Information, the Penal Code, the Copyright Act, and the Unauthorized Computer Access Law, etc.
The contractor shall list laws and regulations concerning the relevant information systems and operations and indicate the conformity to such laws and regulations.
4. Conformity to other guidelines
If there are any guidelines to be followed and handled by the contractor, besides the items from 1 to 3, the contractor shall conform to the relevant guidelines.
The contractor shall identify the guidelines to be conformed to, besides the items from 1 to 3, in accordance with the details of the information system. The specifications shall state the conformity to the guidelines and proposals to realize the guidelines are required.
5. Application of security policies to reconsigned party
If a part of the service is reconsigned upon gaining approval from the relevant ministry, the reconsigned party shall conform to the regulations in the same manner as the contractor.
If there is an option of reconsigning a part of the service, a statement shall be included to the effect that the reconsigned party shall observe the regulations in the same manner as the contractor.
508
6.12.2.2. Standards/guidelines used as a reference “Standards for Information Security Measures for the Central Government Computer Systems” (4th
ed.) (Revision FY 2009) (May 11, 2010 - Decision by the Information Security Policy Council)
http://www.nisc.go.jp/active/general/pdf/K303-091.pdf
6.12.3. Use of the security by design (SBD) as a measure to ensure information security of e-Government from the stages of planning and design
The National Information Security Center, in response to the request from the Information Security
Policy Council, has established and hosted the “committee for the security by design (SBD) as a
measure to ensure information security of e-Government from the stages of planning and design
(hereinafter referred to as the “SBD committee”)” comprising experts and vendors with experience
and knowledge. The SBD committee formulated the “Manual for the Formulation of Requirements for
Information Systems in Government” (hereinafter referred to as “the Manual”) with an aim to reduce
inconvenience to both procurers and suppliers of information systems due to vague procurement
specifications, allowing the integrated implementation of appropriate security measures.
The Manual covers the entire procurement of information systems to be newly constructed or
revised by government organizations and expects that the government’s administrative officials in
charge of procurement of information systems in particular, will be able to formulate security
requirements using the Manual at their responsibility and enter relevant requirements in the
procurement specifications. It is also expected that information system suppliers will have access to
information (information on formulation process, etc.) in the Manual which will help them understand
the security requirements described in the procurement specifications.
At the time of the induction of requirements, it is expected to ensure appropriate security measures
meeting needs by describing significant and effective requirements in the procurement specifications
in a prioritized and emphasized manner, based on the measures for information protection in
information systems and the measures against security breaches.
6.12.3.1. Preparation for the induction of security requirements (creation of system schematic diagram and detailing of requirements)
Firstly, the Manual provides explanation on the induction procedures of operation requirements and
system requirements necessary for security requirements. In these procedures, the personnel in
charge of procurement examines operations related to the information system to be procured,
endorses an operating entity, information and environment for each operation, and creates a system
schematic diagram. Then, the personnel in charge select operation and system requirements, upon
ensuring a certain level of quality or higher, through answering standardized questions based on the
created system schematic diagram.
509
Procedure Outline 1. Examining the objectives and operations
The relevant personnel shall coordinate objectives and operations (operation flow, related documents, etc.) of the information system to be procured through internal discussions.
2. Examining entities related to operations
The relevant personnel shall examine the entities (personnel, organizations and information systems, etc.) of each operation
3. Examining information to be handled
The relevant personnel shall examine the entities and information to be handled by each operation and its flow.
4. Deciding the target of information systematization
The relevant personnel shall clarify the target range of the systematization and examine the relationship if a given system operates in combination with other systems.
5. Deciding the environment used in operations of information systematization
The relevant personnel shall decide on the environment (terminals and lines, etc.) in which the operating entity uses the relevant system.
6. Creation of a system schematic diagram
The relevant personnel shall create a system schematic diagram based on the results of the above and in line with certain rules for description.
7. Detailing requirements by standardized questions
The relevant personnel shall detail the requirements for the target system from three perspectives: namely, “entity,” “information,” and “user environment/method” by answering standardized questions, based on the system schematic diagram.
Individuals
[User environment]- Network computer/ cellular phone
[User registration]- Personal information 1- Personal information 2
[Browsing opinions and comments]- Public information 1- Personal information 3
Open website system of the Ministry
[Storage]- Personal information 1- Personal information 2- Business information 1- Business information 2
Persons on business trip/subscribers
[User environment]- Cellular phone, mobile PC
[Legend]
Name of the entity
[Name of the behavior]- Information- Information
[Name of the behavior]- Information- Information
User environment /method
Name of the entity
Internet[Information registration on the website]- Business information 1- Business information 2
[Website browsing]- Business information 1- Personal information 3
[Input]- Public information 3- Personal information 3- Business information 3
[Output]- Business information 1- Business information 2
Cooperation system with external sources
[Input on the website]- Configuration information
Exclusive network
Government information network
[Notification via email]- Warning information[Downloading on the website]- System data
System administrator
Employees of the Ministry(Agency)
headquarters
Employees of the branch offices, etc.
[Information registration on the website]- Public information 1- Business information 1
[Website browsing]- Personal information 1- Personal information 3
[Information registration on the website]- Public information 2- Business information 2
[Website browsing]- Public information 2
Figure 6.12.2 System schematic diagram
6.12.3.2. Decision on requirements for measures
Next, this section provides explanation on the examination of the direction of measures (policy of
measures) based on the decision criteria (criteria for making decisions on the requirements for
desirable measures to be implemented with priority) as procedures for the induction of security
requirements using the operation results described above (information examined), as well as being
based on the method of deciding the requirements for specific measures conforming to the relevant
policy of measures.
510
Procedure Outline
1. Examination of policy of measures
The relevant personnel shall examine the direction of measures (policy of measures to be implemented with priority) by applying decision criteria to the requirements selected through the system schematic diagram and standardized questions.
2. Decision on the requirements for measures
The relevant personnel shall make a decision on specific requirements for measures that comply with the predetermined policy of measures, while giving consideration to costs, etc.
3. Feedback on the procurement specifications
The relevant personnel shall provide feedback for the above results on the procurement specifications
6.12.3.3. Other The “Manual for the Formulation of Requirements for Information System in Government” (the
Manual) lists the requirements obtained through the above-mentioned process. Although it is not
directly applied to the actual requirements for measures, it includes the task of describing, in the
specifications, the information (e.g. scale of the entity, etc.) deemed useful for the bidding company’s
proposal (discussion).
The Appendix of the Manual includes explanation on the requirements for measures (method of
entering the requirements for measures, assumed threats and examples of implementation, etc.),
correspondence between the compliance items of the Government’s Standards and requirements for
measures in the Manual, and reference documents for the implementation of tasks.
As described above, the use of the Manual is important for assisting the personnel in charge of
procurement (person engaged in administrative affairs) to make a decision on appropriate security
measures for the information system to be procured. It is also expected that the supplier of the
information system will have access to this information (information on the formulation process, etc.)
that helps them to understand the security requirements listed in the procurement specifications.
511
6.12.4. Use of the risk factor reference model (RM) analysis for system design, etc. 6.12.4.1. The relations between “existing standards” and “RM design requirements” and the basics of usage Each item in the “requirements for measures for RM design to avoid ultimate impact on
organizational operations” analyzed with the RM can be considered as specific requirements for
design measures corresponding to the security management measures in the existing standards, etc.
Thus, application to the function requirements/test requirements at the time of contracting will
secure the compliance under the contract with the existing standards, etc.
Since the “requirements for measures for RM design to avoid ultimate impact on organizational
operations” are the design measures derived from the definition of a “cyber attack threat model
(attack scenario),” it is expected to be used as a test scenario at the time of contract. This allows
focus on the confirmation of quality and vulnerability of the functions necessary for the avoidance of
an ultimate impact on organizational operations, leading to improvements in cost performance.
Existing standards, etc.
Requirements for measures for RM design to avoid ultimate impact on organizational operations
Def inition of cyber attack threat model (attack scenario)
Corresponding items
Function requirements/test requirements (specif ications) at the time of placing an order
Contract compliance
Figure 6.12.-3 Relations between the existing standards and requirements for measures for
RM design
A serious issue in the requirement definition and creation of security measures for information
systems is that discussions with concerned parties, such as the customers and contractors, etc.,
must take place at a level of high expertise in the realm of security, which is a non-functional
requirement.
Thus, RM provides a framework where both customer and contractor are able to discuss security
measures for information systems with common standards, with an aim of reaching consensus on the
necessity of implementation of specific measures and the confirmation of design functions based on
the shared awareness of the issues among concerned parties in each stage, which is then intended
512
to improve the precision of the cost estimates and requirements.
The following table shows the process in each stage of the system procurement as a premise for
the discussion on RM.
Expansion to basic system design, production, test, etc., based on the results analyzed during the order placement process
Process Details of implementation Basics of using RM
1.Presentation of system function requirements and other requirements (customer)
2. Realistic and specif ic system conf iguration (contractor candidate)
3. Identif ication of threats and information sharing (customer & contractor candidate)
Def inition of cyber attack threat model (attack scenario)
4. Comprehension of impact on operations and understanding of ef fects of design measures (customer & contractor candidate)
5. Discussion on items of measures for system (customer & contractor candidate)
6. Identif ication of function requirements/test requirements (specif ications) at the time of placing an order
Establishment of operation requirements for the entire system
Establishment of function configuration requirements for the entire system
Understanding of the impact of cyber attack threat model (attack scenario) on system functions
Discussions on the possibility of preventing the impact of cyber attack threat model (attack scenario) on system functions
List of function requirements/test requirements determined in the above
Use of RM cyber attack threat model (attack scenario)
Requesting the contractor candidate for explanation
Use of the following:- Cyber attack threat model (attack
scenario)- Requirements for measures for RM
design to prevent ultimate impact on organizational operations
○At the time of placing an order
○At the time of the system production
7. Expansion to system design/test The contractor shall implement the following:- Design based on the requirements for
measures for RM design- Correction and test on related vulnerabilities
based on the attack scenario
Standard operation procedures as a premise for the discussion on RM are as follows.
The following image shows a standard communication flow between the customer who demands
Objectives of the risk factor reference model
The risk factor reference model was developed to enable the customer and
the contractor for the information system to examine and consider security
measures to be incorporated in the system based on actual threats. This
model aims to design security measures necessary for the information
system under the shared understanding of customers and contractors of the
public and private information system integration.
513
a system using the risk factor reference model and the system vendor who proposes a specific
system and receives an order. Such a communication flow can be incorporated into a part of a
bigger flow implemented, usually at the time of designing a relatively large-scale system, regardless
of whether it is public or private.
Figure 6.12-4 Standard operation procedures of RM
In addition, the following show cases of the use of this model for the response to incidents as an
application of RM.
The risk factor reference model has prepared patterns of target threat and patterns of system
topology to produce a threat catalogue. This allows an understanding of how each target threat
behaves in the system and where problematic phenomena occur. Therefore, when an existing
system is attacked, this can be used for identifying where in the system the problem has occurred and
provide considerations for taking temporary measures for the system, such as bypass measures for
the attacked site, etc.
○Assessment of impact on the system at the time of obtaining attack information
It is used for consideration of impact on the system, the presence or absence of bypass design,
impact on the organizational activities, establishment of temporary measures and planning of
measures in case of cyber attack.
514
Catalog of serious threats
Schematic diagram for patterns
Behavior diagramAttack specifications
Topology basic diagram
Effective design measures
Cases
Organizational issues
At the time of occurrence of cyber attack
Basic diagram (internet connection type)
RM
Basic reference model
Identif ication of reference parts from the basic system configuration
RM users
Impact on own organization and what is the phenomenon on the system (what happens)?
Refer to the “attack specifications and effective design measures” and identify the relevant system applicable to the attack on the server. Consider the impact on organizational activities.If the part “as long as this line of communication is blocked, the system at least is protected” is covered, the system will not fall under the status of “attainment of objective of the attack (the worst case scenario).”
Various arrangements/discussions and decisions on provisional measures (including the number of processes)
Result of trace analysis
Consideration for the provisional measures, etc.
Other, use of usable confirmation tool, etc.■MyJNY version checker■MyJYN security settings checker
Figure 6.12-5 Example of the use of obtained attach information for impact assessment
6.12.4.2. Concept of inducing requirements for RM design measures The risk factor reference model is considered to be a major security measure. Behind this lies the
fact that the effectiveness of the design method to allocate security products within the information
system has significantly declined due to the emergence of new methods of cyber attacks, such as a
targeted attack. In order to resolve this situation, RM has been developed as a method for evaluating
the impact on operations and clarifying necessary measures and costs, based on the reality of the
current cyber threats.
515
Man
agem
ent m
easu
rers
ThreatRiskProblem
Ground for countermeasures?
System design/management measurers
?
RM
ThreatRiskProblem
Ground for countermeasures? System design/management
measurers(Priority response to necessary parts in accordance with the awareness of the issue – increased effectiveness)
(Full-f ledged approach to the specifically described awareness of the issue)
(Can the full-f ledged implementation of management measurers cover present threats?)
Necessary costs
Necessary costs
Clarif ication of the issues and measures
Possible feedback to management measures (particularly to CND section)
Ground for countermeasures Implementation with variation
(increased cost performance)
Implementation reference
Guideline (policy level)
CND: Computer Network Defense Figure 6.12-6 Cost performance of RM
The following shows each analysis component (1-4) of the risk factor reference model (RM). The RM
analyzes cyber threats to the information system in organizations. When requiring the implementation
of RM in specifications, the mission impact of cyber attacks and investment effects should be fully
considered.
Analysis process (1): To define attack patterns as a threat model which specifically analyzes and
interprets the reality of current cyber threats and develop specific attack scenarios
Since threats of today have become diversified, advanced and complex, it is difficult to analyze
(1) To define attack patterns as a threat model which specifically analyzes and
interprets the reality of current cyber threats and develop specific attack scenarios
(2) To design an information system design model as a model in accordance with
each characteristic of the system
(3) To analyze the impact and the effects of design measures by tracing attack pattern
scenarios on the information system design model (attack simulation)
(4) To compile the results of attack tracing (attack simulation) as “system design
measures”
516
the impacts and plan measures if handled individually, and it is impossible to determine the
measures at the contract stage or design stage. Thus, the risk factor reference model has
classified the threats into six patterns by analyzing behavior of actually observed threats, which has
then been compiled into a “Catalogue of Critical Threats,” and the results of the analysis of the
catalogue are organized as attack patterns.
Reflecting “the characteristics of the infrastructure used for Distributed Denial of Service (DDoS) attacks against smart meters” found in DDoS cases in South Korea
Creation of attack bots using exising services, such as iDC, etc.
Case of browsing gumblar infected sites from the intranet
Automatic falsif ication cases caused by an infected web administrator terminal on the relevant intranet
Cases where the intrasites are infected with a Gumblar virus
Solution to the spread of infection from the use of FTP infrastructure
Variation 2: Spam mail directing to unauthorized URL
Pattern 1: Malware infection through browsing of f icial website
Variation 2: " Browsing websites infected with a **.ru:8080 virus"
Variation 1: “Browsing websites infected with a gumblar virus "
Pattern 2: Targeted email attack (information thef t)
Variation 1: File attached email ab
Pattern 4: 「Malware infection through media (information thef t)
Variation 3: " Browsing websites infected with SQL injection "
Pattern 3: Redirection by falsif ied official websites
Variation 2: “SQL injection"
Variation 1: “gumblar.x virus"
Variation 4: " Redirected f rom the search engines "
Variation 1: " Conf icker (worms) spreading via USB "
Clarif icaiton of the reality of threats and specif ication of measures Individual incidents havinng great organizational impact are grouped in any of the patterns and incidents that can be covered with the same measures are grouped in the same category.
Model called operation the “Aurora” attack
Pattern 5: Multiple DDoS attack (attack inf rastructure)
Reference: Existing threats (attacks still observed today)
Pattern 6: Regular DDoS attack
Variation 1: " DDoS attacks on SSL connection "DDoS attacks on SSL connection by BotnetImpact on the internet business settlement
Figure 6.12-7 Attack patterns covered by RM
517
The outline of each attack pattern is described below.
“Pattern 1: Malware infection through browsing official websites (information theft)”
This attack redirects the website to malware distribution sites to steal authentication information,
etc. and setup a backdoor when users browse falsified official websites. Infrastructure used for the
attacks expands through the use of the stolen authentication information.
This corresponds to the cases where the system gets infected when the system user browses the
falsified official site.
Figure 6.12-8 Pattern 1: Malware infection through browsing official websites (information
theft)
518
Pattern 2: Targeted email attack (information theft)
Instead of indiscreetly targeting a large number of users, this type of attack targets individuals in
specific organizations or firms by using a false title, text or sender name, and sends emails with
attached malware.
Once an email is opened, the malware is activated and the system is infected with bot and
organizational information is stolen. Since emails are sent to specific organizations, it is called a
“targeted attack.”
Figure 6.12-9 Pattern 2: Targeted email attack (information theft)
519
Pattern 3: Redirection by falsified official websites
This attack falsifies official websites with a purpose to redirect the site browser to a malware
distribution site.
This corresponds to the cases where website in the system is falsified (link insertion) and
redirected to the malware distribution site for the external browsers.
Figure 6.12-10 Pattern 3: Redirection by falsified official websites
520
Pattern 4 Malware infection through media (information theft)
A virus slipped into the media port, such as a USB port, etc., during the production development
process, etc. enters into the system through the media port. Once entered, the virus updates the
malware onto the infrastructure used for attacks. At the same time, the infection expands through
network infection of the core system and media ports.
Since the attack causes both network failure and server failure, an effective prevention is the
cooperation between the management organizations of both network and server and the security
department in addition to the preparation for separation procedures, etc.
The malware entered into the system sets up a backdoor in the system to scan system information.
Figure 6.12-11 Pattern 4: Malware infection through media (information theft)
521
Pattern 5: Multiple DDoS attacks (attack infrastructure)
A PC infected with malware carries out DDoS attacks on the web server and downloads
instructions and other malware from the malicious server, then sends out mass spam mails and
destroys files in the malware-infected PC.
The multiple-type DDoS is a new type of attack with respect to the infrastructure used for attacks;
for example, the existing VPN network, which has been traditionally constructed as a package of
safety assurance, is used and malware with dispersed functions exercise the attack functions in
conjunction with each other. Since it is difficult to analyze protection information, it will become a
threat that will be hard to address in the future if it is used in various types of attacks.
Figure 6.12-12 Pattern 5: Multiple DDoS attacks (attack infrastructure)
522
Pattern 6 Regular DDoS attack
DDoS attacks on net-business disable sales settlement. With regard to the response to this impact
on business, a comprehensive assessment should be made for countermeasures, while taking into
account the business impact and cost for measures.
In the case of the DDoS that causes a line overload (line bandwidth DoS), protective measures
from the website side, and thus, response coordination with the line side is necessary, and should be
included in the contents of the contract. In this case, cost performance should also be taken into
account.
In the case of a processing load DoS attack, the system will be protected by setting up DoS
mitigation functions on the website side. Attack analysis information is required for the setup. Thus,
an organizational line needs to be secured. In the case of a DoS attack against SSL servers, access
to SSL connections will be lost.
Figure 6.12-13 Pattern 6: Regular DDoS attack
The following “basic model of strategic attacks” and “basis for the definition of cyber attack threat
model (information theft attack scenario)” are the compilation of selected cases commonly found in
the behavior patterns from 1 to 4 in relation to the ultimate impact on organizational operations.
First stage: Initial intrusion into the system
First stage: Initial intrusion into the system
Launch of initial malware into the system occurs through various methods. There are many types of
malware. Malware without a vulnerability patch (zero-day vulnerability) and malware to which
anti-virus pattern files are not applied are also used often. Since these malware are launched through
official connections (HTTP&SMTP), the conventional measures in the first stage (such as FW,
523
anti-virus pattern, and vulnerability patch, etc.) are not infallible.
Second stage: Connection to a malware download server and launch of malware attacks
Malware update themselves through the connection with an external malware download server
and receive attack instructions, etc. Since the connections in this case are normal communications
using HTTP, SSL, etc., detection and blocking by FW, IDS, etc. do not work. The attacks in the
second stage are often undetected because they are difficult to find.
Third stage: Continuous information theft and attack instructions
In the third stage, “information theft,” the ultimate objective of the attack, is carried out based on
the remote attack instructions and the information is transmitted to an external source. Since the
attacks are carried out through normal communications using HTTP, SSL, etc., detection and
blocking by FW, IDS, etc. do not work. The attacks in the third stage are often undetected because
they are difficult to find.
The ultimate threat (challenge) to organizations lies in this third of stage attacks.
As long as the intrusion of the main attack force and its attacks (objective theft) are blocked, the ultimate impact on the organization (system) can be avoided, even if the attack strategies cannot be covered by a vulnerability patch or measures for AV patterns.
Blocking communications in the DL server in the 2nd
and 3rd stages
It is recommended first to stop attacks in the 2nd and 3rd stages and avoid the ultimate impact, followed by extermination of viruses and measures against vulnerabilities.
・Presence of objective/intent/infrastructure used for attacksPreparation stage
First stage ・Initial intrusion into the system (various methods)
(1) Initial malware attached to email for targeted attack(2) DL server redirection by website falsification(3) Initial malware through media(4) Slipping away by abusing a digital certificate(5) Embedding of a redirector exploiting website vulnerabilities
Exploiting vulnerabilities
Second stage
・Connection to DL server and launch of offensive malware
(1) Downloading of malware(2) Sending attack instructions, etc.
Launch of preemptive forces
Invasion of main attack forces
Formulation of operation plan
Pursuit evasion by the attack infrastructure (who and where?)
Analysis and tracking of strategic attack patterns
Selection of characteristics for design measures by tracking down the attack patterns (behavior) and monitoring pattern changes
★ Prevention of organizational impact by blocking the second and third stages
★ Annihilation of threats upon obstructing the attack objective
★ Grasping the entire picture of strategic attack patterns and pattern monitoring
In RM, the target is set to organizations
(1) Planning of attacks through multiple schemes
Use of attack infrastructure
In pursuit of achieving the ultimate goal of attack (thef t)
Third stage ・Continuation of information theft and attack instructions
This is the ultimate threat (challenge) to an organization.
(1) Uploading stolen information
Goal-matching concept
Limitations of the zero vulnerability campaign, etc.
Shifting the axis to measures for impact prevention
It is necessary to re-define threats and re-analyze design concepts and organizational operation concepts in order to avoid mission impact
Basic patterns of strategic attacks Measures for system design management
Figure 6.12-14 Common basic model of cyber attacks
Analysis process (2): “To design an information system design model as a system model in
accordance with each characteristic of the system”
524
In order to analyze the behavior of threats (viruses, etc.) when the information system is attacked,
typical configuration cases of information system are grouped into four “system topology models”
Each system topology model is not necessarily used individually; instead, it is assumed to be used
in combination of several models: for example, a combination of “intranet model” and “iDC model.”
A. Intranet model B. Closed model C. iDC model D. SaaS model
The following is an example of the intranet model
No Model name Outline and characteristics of the system topology model
1 Intranet model ・ Information system configuration most commonly used in public and private information systems
・ Operations are carried out by separating the DMZ (DeMilitarized Zone) in which external web server is installed
to the intranet from the in-house system area which does not
allow direct access from external sources.
・ The intranet model includes a system topology that operates by only installing the DMZ area (such as external public
server, etc.) in the iDC.
・ In many small offices (such as a local office, branch office and sub-branch office) the internet is accessed directly
through the in-house system of each premise without going
through a DMZ. Such configuration is included in the intranet
model.
2 Closed model ・ A configuration found relatively often in the medical information system and the FA system of the manufacturing
industry. The information system is complete within the
premise, which is not connected to the external internet.
Since there is no internet connection, no cyber attacks are
made via network; however, the damage is likely to spread if
virus-contaminated USB memories or CDs are taken in
because patterns are not updated or updating of anti-virus
software is delayed.
3 iDC model ・ Use of iDC exhibits a variety of forms. The iDC model in this section assumes the cases where operations covering the
operation systems are conducted on the iDC.
・ Only the cases where the entire DMZ (such as web server for external sources) is installed in the iDC can be handled by
the intranet model. The cases where a part of business is
conducted by the iDC and the rest of the business is
conducted on the in-house internet can be handled in
525
No Model name Outline and characteristics of the system topology model
combination between internet model and iDC model.
・ This model is different from the intranet model in a sense that there is an impact of sharing switches and servers with iDC
users and an impact of administration terminal access from
the iDC to the systems of several iDC users.
4 SaaS model ・ In SaaS, only subscribed users can use services via the internet, and no system resource management is carried out,
such as in a server or DB, etc.
・ A security measure for SaaS that can be carried out by the user is the access control alone, and the rest of the security
measures are entrusted to a SaaS provider. This is the
difference from the system operations that use the iDC.
Analysis process (3): “To analyze the impact and effects of design measures by tracing attack pattern
scenarios on the information system design model (attack simulation)”
Technical methods have been studied as to the best practices to inhibit threats. These methods include
evaluating the effectiveness of security measures installed on the topology by performing a “threat trace”
(attack simulation), which allows the analysis of influential behavior on each “system topology” of the
“behavior patterns (attack sequence and attack specifications)” that have been created using the “behavior
model.” The “threat trace” has been conducted in accordance with the actual attacks that have occurred.
Analysis process (4): “To compile the results of an attack trace” (attack simulation) into the “system
design measures”
Design measures found to be highly effective by the “threat trace” (attack simulation) were
compiled into the “system design measures” according to each behavior pattern.
From the analyses above, the current attack models have common attack specifications with
respect to the ultimate impact on organizational operations, with some exceptions. It is then clear that
they do not depend on system topology forms and attack behavior patterns. This is thought to be
because attack targets have been gradually immerging into one pattern.
Thus, “common attack scenarios and design measures” have been generalized and organized
as below.
○Definition of cyber attack threat model (attack scenario)
○Requirements for RM design measures (collection of requirements for specifications) for the
aversion of the ultimate impact on organizational operations
526
6.12.4.3. Definition of cyber attack threat model (attack scenario) The conventional design measures have been based on the attack story focusing on the first stage
but are now facing limitations in terms of the number of measures and effectiveness.
Meanwhile, the main objective of the common cyber attack threat model (attack scenario) in recent
cyber attacks is information theft through a process from the first to third stage, and the second and
third stages, which involves external access, have a particularly large impact on the organization
(business).
Thus, besides the conventional measures, the attack threats corresponding to the ultimate impact
on organizations are identified as being the second and third stage attack patterns, which are directly
connected to attack objectives, and are based on the various cyber attack cases of today. Then, the
following two cases have been set as attack models commonly found in various attack patterns.
○ “Information theft attack (including falsification of redirection link embedment on the site)”
○ “Service interruption/ suspension attack”
Attack objectives|+---01_Information theft| +---Pattern 1: Malware infection through browsing official website| | +---Variation 1: Browsing websites infected with a gumblar virus| | +---Variation 2: Browsing websites infected with a **.ru:8080 virus| | +---Variation 3: Browsing websites infected with SQL injection | | +---Variation 4: Redirected from the search engines| +---Pattern 2: Targeted email attack (information theft)| | +---Variation 1: File attached email ab| | +---Variation 2: Spam mail directing to unauthorized URL| +---Pattern 3: Redirection by falsified official websites| | +---Variation 1: gumblar.x virus| | +---Variation 2: SQL injection| +---Pattern 4: Malware infection through media (information theft)| +---Variation 1: Conficker (worms) spreading via USB |+---02_ Disruption/suspension of services | +---Pattern 5: Multiple DDoS attack (attack infrastructure)| +---Pattern 6: Regular DDoS attack| +---Variation 1: DDoS attacks on SSL connection|+---Existing threats (attacks still observed today)
Considering the above, the cyber attack threat model (attack scenario) is defined below. It is
assumed that this scenario will also be used as “test requirements.”
527
Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site)
First stage process
“Initial intrusion
into system”
Method 1 (1) When the user browses the falsified official website, authentication information
in the general PC is redirected to a malware distribution site by exploiting the vulnerability of software in the general PC.
Method 2
(1) An attacker attaches malicious spoofed emails to the general PC within the intranet.
(2) Malware gets activated when the user opens a file attached to the spoofed mail on the general PC. Consequently, the second stage of the process will follow.
Method 3
(1) The website is falsified from an external source through a separately acquired ftp ID/PW.
(2) Redirection embedment (falsification) is conducted on the website to redirect the user to a malware distribution server.
Method 4
(1) Malware filtered into digital memory media, such as USB memory, enters into general PCs through the media port.
(2) Malware infection spreads from the initially infected PC to other general PCs through the network infection, exploiting memory media, file sharing programs and vulnerabilities.
(3) Malware filtered into the general PC gets activated by exploiting vulnerabilities. Consequently, the second stage of the process will follow.
Note: In the case of file migration operation between open and closed systems through USB, etc., the same attack scenario as the open system is applied to the closed system.
Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site)
Second stage process
“Connection to
malware download server
and launch of offensive malware”
Method 1
(1) Function update of the malware and other malware will be downloaded by communicating with an external server (command & malware distribution server)
Note: An official site (on the attack infrastructure) that has been taken over is used as an external server.
Note: External server is constantly changing. Thus, blocking a specific address is ineffective.
Note: FW detection/blocking cannot be implemented since an official service method, such as HTTP and SSL, etc., is used for the communication with external server.
Method 2
(1) When the user browses the falsified official website, authentication information in the general PC is redirected to the malware distribution site by exploiting vulnerability in the software on the general PC, then malware will be downloaded.
Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site)
Third stage process
“Continuation of information theft
and attack instructions”
Method 1
(1) Attack instructions, etc., are sent from the external server (command & malware distribution server) to malware.
Note: Attack instructions, etc., have many specific instructions and it is difficult to clarity or explain the behavior.
Note: 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.
Method 2
(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.
528
Attack scenario of “service disruption/suspension”
Attack process
Method 1
Note: The assumption is that the analysis of attack sources, etc. is difficult because of the flexibility in changing DDoS attack specifications from the official PC, etc., using multiple attack infrastructures. (1) Transmission of a large number of spam mails and destruction of files in the
infected PC, in addition to DDoS attacks (the same as an information theft attack scenario, except for DDoS attack)
Method 2
(2) DDoS attacks by using DDoS tools. Details of attacks are as follows: ・ Searching for simple FTP PW settings (FTP brute force attack) and
falsification of agitation sites. ・ Searching for SQL injection vulnerable sites and falsification of agitation
sites. ・ DDoS attacks by using overseas proxy sites (unable to use country-specific
IP filter). ・ DDoS attacks by using a number of false IPs (unable to use IP filter). ・ Combination of bandwidth-DDoS and load-DDoS attacks.
6.12.4.4. Requirements for RM design measures to avoid ultimate impact on organizational operations Conventionally, the system has been designed based on the concept of “perimeter defense”
against attack methods in the first stage; however, the effectiveness of these measures has become
increasingly limited that attacks on the first stage are often successful.
Thus, examinations were conducted on the “requirements for design measures (including
non-functional requirements) to avoid the ultimate impact on organizational operations” with
emphasis on the measures for second and third stages having large impact on organizational
operations, besides design measures against attack methods in the first stage in the common cyber
attack threat model (attack scenario).
In the information theft attacks, requirements for design measures against common attacks can be
devised since the attack methods in the second and third stages are common. There emerged
threats in the closed system believed to be equivalent to the closed-system threats via media, such
as USB. Since this type of attack technology may be used frequently in the future, requirements are
defined as common design measures regardless of system topology.
Also, the background and objectives of DDoS attacks vary and there are various attack methods
accordingly; however, the type of attack communications is the same from the viewpoint of the
defending system.
Considering the above, the following show the definitions of “requirements for design measures to
avoid the ultimate impact (including non-functional requirements, such as operations management,
etc.)” and “operation conditions as prerequisites for system design” in accordance with the two types
of attack scenarios.
529
Function
requirements item Details of function
requirements Reasons and background for requirements Example of setting
1
Introduction of authentication of dual- element authentication/one-time password
Use of dual-element authentication by combining ftp ID/PW for updating websites and one time password (OTP), etc.
Enhancement of authentication in the case of leakage of ftp ID/PW for website management - Response to Gumblar attacks, etc.
- One-time password OTP)
2 Settings for “LAN for management”
Server management settings for the in-house network, which is not available to external sources (backside LAN)
If the client’s PC infected with malware is used as the terminal for server management, the ftp ID/PW of the site administrator may fall into the hands of the attacker. Embedment of Java Script on the web page can be prevented by limiting the web server for update to a LAN for management (backside LAN) - Response to Gumblar attacks, etc.
- Network topology design
3
Access control of the web server administration terminal
Setting for prohibiting the access to other than designated sites, such as software update for the web server administration terminal
Since the client’s PC may be infected with malware through access to official websites, the infection rate will decline if the access to the administration terminal is controlled, thus reducing the possibility of the theft of critical data, such as the FTP account of the administrator.
- Settings for administration terminal - System proxy settings
4 Checking proxy authentication information
Design of authentication access by authentication proxy at the time of accessing external websites using a general PC
It has been confirmed that authentication information is not often used when a malware transmits information stolen by a unique method of communication to malicious sites. - There is no way of protection if the offensive malware has already been authenticated.
- Authentication proxy
5 Communication control via system proxy
Design of external access via general PC system proxy settings when accessing external websites. Use of firewall, etc. to block external communications that do not go through the proxy using specific port communications (global IP).
When a malware transmits stolen information to malicious sites (theft), it has been confirmed that it often uses an independent communications method using the 80443 port. Many of these communications do not use a system proxy. The malware that uses a global IP for connection trials to an external host can be blocked by FW reel - Ineffective for the malware that uses system proxy settings
- System proxy settings - Setting FW rules
6 Header check of HTTP,SSL connections
Detection/blocking of the contents of HTTP,SSL headers, etc. (GET, POST command)
Many of the following cases uses 80/tcp and 443/tcp: When a malware sends stolen information to the external malicious sites, When downloading new attack code, and When receiving command from C&C server. It has also been confirmed that headers for HTTP connections (method) are deviated from the standard RFC protocol, which is normally used.
7
Use of an Intrusion Detection System (IDS) function (detection of malware download)
Detection of the download of malware and update from external malicious server by using IDS, IPS (In/Out)
IDS (IPS) cannot detect unauthorized communications with unregistered signatures. In order to increase the effectiveness of IDS, timely update of independent signatures for the detection of connections which are different from the usual patters in cooperation with the SOC (Security Operation Center). - However, it depends on the operation capacity of the SOC because it is not an authenticated signature.
- IDS, IPS (including SOC operations)
530
8 Introduction of unknown-virus detection software
Detection of behavior when a malware is exploiting vulnerabilities, including zero day vulnerability
Fight against the unknown virus and unknown vulnerability by detecting an act of attacks from the behavior of vulnerability to a virus on the PC. Products that can detect and protect damage caused by “zero day attacks” have been produced by several companies. - There is a possibility of design/usage consideration as a supplement to existing anti-virus software, upon sufficient evaluation on protective functions and the number of management processes, etc.
- Detection of vulnerability
9 Routing settings, such as router, etc.
VLAN and routing settings limiting to the necessary scope of access by router and SW
In order to minimize the impact on the system, the scope of the attack impact is separated in the network topology design. - Cases of conficker and stuxnet worms, etc.
- Network topology design - Router, VLAN settings for SW
10
Detection of infection activity by monitoring network volume overload
Detection of network infection behavior by volume monitoring, such as file SV, load on SW and log, etc. Settings for abnormal load detection functions on the network and system monitor management functions
Spread of malware network infections within the system can be detected by the network traffic malfunction. Thus, it is effective to monitor the data volume for detection at each site and temporarily blocking connections to routers, etc., in cooperation with the network control department.
Network monitoring function, operation
Requirements for design measures against “service disruption/suspension attacks” (including non-functional requirements for operations management, etc.) Function
requirements item Details of function
requirements Reasons and background for requirements Setting example
1 DDoS mitigation function
Response to DDoS attacks which increase the processing load by setting DDoS mitigation functions, such as FW, balancer, etc. To examine the introduction of DDoS mitigation devices
FW and balancer have DDoS mitigation functions to reduce the impact of DDoS attacks, which increase the processing load, by resetting the device functions in accordance with the DDoS attack instructions. In order to further increase the effect of the measures, consideration should be given to the introduction of the exclusive DDoS device that gives alert to anti-DDoS devices and carries out bandwidth control and access control when detecting communications that have been deviated from the known regular communication traffic patterns. - Cooperation with analyzing organizations for DDoS attack methods, communication details, etc.
- Setting DDoS mitigation functions of FW and balancer - DDoS mitigation device
2 Use of anti-DDoS services of an ISP
Consideration for concluding contracts with ISPs to respond to DDoS attacks that increase load on bandwidth
Even if a DDoS attack has been detected, an individual protection is difficult against a large-scale attack. An ISP provides anti-DDoS measures using a strong backbone. The use of such products should also be considered, when necessary.
- Use of anti-DDoS services
Operation conditions as prerequisites of system design
1
Framework for response to damage as a prerequisite for design
It has become clear from the analysis of attack behavior and attack patterns of recent cyber threats that cyber attacks have advanced. Thus, it is becoming difficult for an individual system department of the user organization to analyze the details of attacks and to take proper recovery measures. A prerequisite for attack response is to clarify the response and division of roles by incorporating the communication and cooperation framework with security vendor or system integrator SIer at the time of designing operation framework.
2
“Preparation for initial response operation procedures” such as blocking infectious communication ports, etc.
“Preparation for initial response operation procedures” to suppress the spread of infections within the system through a containment by blocking or temporary separation of infected communication ports at router sites. *A difference in response speed occurs depending on the preparation of procedures and operations management. *Closing procedures for infected ports of the router and SW *Comprehensive understanding of network failure and server failure and preliminary study on the section to be separated. *Detection procedures by volume monitoring, such as file-SV and load on SW and log, etc.
531
6.12.5. Descriptions concerning security in service in each procurement area
Requirements for security services to be described by each procurement area are included in the
services of the TRM of each procurement area. Security notes and the outline of services described
in each procurement area are shown below. For actual procurement, a check should be carried out to
see whether consideration has been given to the notes listed below.
●6.2. Support for procurement
Notes Outline of notes Corresponding items in TRM
Definition of information security requirements
The customer and the compiler of specifications shall define the information security requirements in pursuant to the “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry. Since the following requirements are particularly required for entry in the Basic Guidelines for Government Procurement Related to Information Systems, they shall be clearly and specifically defined. (1) Definition of authority management (2) Definition of security measures The term “authority management” refers to the management of information pertaining to entity authentication (including identification code and entity authentication information) and approval information pertaining to access control
6.2. Support for procurement 2. Support for definition of requirements
532
●6.3. System integration (design/development) *Applied commonly to 6.3-1~6.3-4
Service item Outline of service Items corresponding to TRM Security measures for development environment
The contractor shall take sufficient information security measures for the environment for development (device, workplace, etc.) when such an environment is prepared by the contractor.
Preparation for development environment
Information security design
The contractor shall carry out information security design in pursuant to the “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry.
Basic plan Detailed plan
Security measures for test environment
The contractor shall take sufficient security measures for the test environment (devices, workplace, test data, etc.) when such an environment is prepared by the contractor.
Unit test, system test, comprehensive test
User training The contractor shall provide information security training for system users.
User training
Information security management
The contractor shall prevent an occurrence of a security-related incident or fault, etc. during each work process. The contractor shall also report to the customer immediately after the occurrence of an incident and minimize the damage as much as possible.
Project management
533
●6.4.Operation
Notes Outline of notes Items corresponding to TRM Handling of operation framework
If a document contains personal information, such as an organizational chart, etc., the document shall be handled in accordance with the importance stipulated in the regulations.
Formulation of operation plan
534
●6.5. Helpdesk
Service item Outline of service Items corresponding to TRM Creating of an outline of implementing information security measures
An outline for implementing information security measures shall be created in the helpdesk operation plan, which shall be finalized upon consultation with ministries.
Formulation of operation plan
Training for helpdesk staff
The contractor shall provide helpdesk staff with training on information security measures to be implemented in helpdesk services.
Development of work environment
●6.6.1. Hardware maintenance
Service item Outline of service Items corresponding to TRM Revision of firmware, configuration change, etc.
The contractor shall obtain the most recent information on firmware related to the stability of security and hardware, such as BIOS, and require the hardware maintenance company to implement updates whenever necessary.
Support for version upgrade
●6.6.2. Software maintenance
Service item Outline of service Items corresponding to TRM Provision of information on security patches
The contractor should provide application maintenance company or system infrastructure maintenance company with information on software bugs, patches and version upgrades, etc. as soon as such information becomes available and should also instruct the application maintenance company or system infrastructure maintenance company to conduct preliminary patch applications. In order to determine the propriety of the immediate patch application, there is a way to add the application maintenance company and the system infrastructure company to the list of recipients of information provided by the software maintenance company, such as information on software version upgrades, etc.
Provision of modification (patch) files, version upgrade programs
535
●6.6.4. System infrastructure maintenance
Service item Outline of service Items corresponding to TRM Information provision and application of security patches
The contractor shall immediately report to the ministries on information pertaining to technical issues of information systems, security vulnerability (security holes), software bugs, patches and version upgrades, etc. In response to the request from the ministries, the contractor shall carry out patch application possibility verification work, patch application work and technical advice for software.
Updating system infrastructure software
●6.7. Tasks incidental to device procurement
Notes Outline Items corresponding to TRM Security design The contractor shall create a security
design in pursuant to the “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry and implement information security measures accordingly.
On-site study/design
Security settings/adjustments
The contractor shall carry out environmental settings and various adjustment work necessary for this system, using the procedures concerning the existing system, introduction method, and the created security design.
Device setup
Updating virus definition file
The contractor shall update the virus software and virus definition files to keep them in the most recent status at all times.
Device setup
●6.8. Tasks incidental to procurement of iDC equipment
Notes Outline Items corresponding to TRM Security monitoring The contractor shall make regular reports
to the relevant official of the ministry about the status of security monitoring (scrutinizing of firewall logs and monitoring of unauthorized accesses, etc.), as well as the monitoring results.
Operation/maintenance (daily)
Security diagnosis and reporting
The contractor shall carry out a regular diagnosis on vulnerability (status, impact and response methods) and report the results to the relevant official of the ministry.
Operation/maintenance (monthly)
536
●6.9. Network procurement
Notes Outline of notes Items corresponding to TRM Definition of information security
The contractor shall specifically define the information security measures in accordance with the importance and risks of information assets in pursuant to the information security policies of the ministries based on the “Standards for Information Security Measures for the Central Government Computer Systems.”
Design/development plan
Requirements for information security (measures)
The contractor shall follow the security policies and security guidelines of the ministry in order to carry out an overall security measure program that has been acknowledged in the market. The contractor shall maintain the security level for operations. The contractor shall cooperate and coordinate with the existing operation and maintenance company for the security measures to be taken on the entire network.
Design/development
Disposal of devices The contractor shall delete data completely after the removal and displacement of unnecessary devices to prevent a third party from recovering the data using date recovery software, etc., except for the cases of destroying the devices.
Design/development
Security design The contractor shall either implement the security policy design (encryption, FW, IDS/IPS, quarantine) and encryption design (specifications for encryption, encryption method, encryption algorithm) or follow the rules presented as equivalent to the specifications.
Design/development
Security inspection Vulnerability of network devices to be introduced may be verified at times and disclosed by third organizations, etc. If there is a problem, the contractor shall take appropriate measures.
Design/development
537
Security test The contractor shall surely implement tests on information security. Vulnerability of network devices to be introduced may be verified at times and disclosed by third organizations, etc. If there is a problem, the contractor shall take appropriate measures.
Support for test and migration judgment
Handling of incidents The contractor shall establish a communication framework to promptly receive information on network faults and security incidents.
Operation/maintenance
Security diagnosis and reporting
The contractor shall constantly monitor the traffic status of lines. If there is abnormal traffic, etc., the contractor shall carry out a causal investigation and report to the relevant official via the existing operation and maintenance company.
Operation/maintenance
Security inspection The contractor shall take measures promptly when a necessity for improving an introduced network device’s vulnerability has been pointed out.
Operation/maintenance
6.12.6. Procurement of services specialized on security
(To be created)
538
6.13. Other
(To be created)
539
7. Recommended Technology Standard
This chapter describes the examples of technology standards that should be given priority in
information system procurement by the government, as well as in the guidelines for selecting them.
The following two documents are the main source of reference information in drawing up the
guidelines for selecting recommended technology standards.
• Framework for Interoperability Relating to Information Systems (Jun. 2007) http://www.meti.go.jp/press/20070629014/siryou.pdf
• The first issue of TRM: Report on the results of validity examination (Feb. 2004) http://www.ipa.go.jp/software/optimize/pdf/technicalveri.pdf
The technology standards have been selected from the viewpoint of implementing separated
procurement as indicated in the procurement guidelines, and the scope of the technology standards
is not intended to be all-inclusive for the technologies to be procured.
7.1. Requirements for technology standards in conformity with the “Framework for Interoperability Relating to Information Systems”
The following is an excerpt from the “Framework for Interoperability Relating to Information
Systems”:
In view toward procuring higher quality information systems - which involves the need for
expanded options for information system construction in governmental/public organizations,
and a fair and transparent procurement environment with proper price settings – promotion of
the following measures are needed to be set forward in the new development and
refurbishment of information systems: withdrawing from dependency on the vendor’s
proprietary technologies, and further pursuit toward openness in the government information
systems.
In the “Basic Guidelines for government procurement related to information systems,” the
government indicates that, regarding the design and development processes, separated
procurement should be the basic procurement policy for the basic infrastructure system and
in each of the functional systems. These individual functional systems, realized by means of
separated procurement in conformity with the basic guidelines, are integrated through the
intermediary of the common infrastructure. The individual functional systems, as a functional
unit, as well as an integrated whole of functional units, must realize all the functions required
540
in the business processes, where information exchange with other individual functional
systems, as well as with the common infrastructure, should be necessary. This translates into
the requirement of interoperability among individual functional systems, and between each of
them and the common infrastructure.
As separated procurement should become the basic policy in the future, as describes above, it
entails the need to select technology standards with priority placed on “interoperability” while
promoting the move toward “separated procurement” and “open architecture.” In addition, selection of
an “open standard” should be the overriding challenge because fair and equitable procurement is the
major premise in government procurement.
7.1.1. Definition of “Opening” and “Open Standard” In the “Basic Guidelines for government procurement related to information systems,” the term
“Opening” is defined as follows.
Lowering of dependency on specific vendor’s proprietary technologies - in terms of
procurement, maintenance and operation - through the breakdown of the information systems
into individual procurements and exchangeable/standardized components, thus enabling an
expansion of the range of business entities eligible to participate in procurement, maintenance,
and operation services.
The “open standard” here represents the technology standards that meet, in principle, all the
following items.
• The technological specifications have to be agreed upon through an open participatory process, and provide disclosure specifically to the level that allows concrete implementation.
• Adoptable by any party.
• Many examples of the technology standard have been launched onto the market.
7.1.2. Requirement to ensure validity as a standard technology In the “Framework for Interoperability Relating to Information Systems,” the following requirements
are placed on the technologies referenced in the TRM, with a view toward standardizing
specifications – an essential element to secure validity as a standard technology.
• The technology is one with standard specifications defined under the initiative for standardizing organizations and other parties, or one in the process of standardizing.
• Management of intellectual property rights (IRP) has to be defined clearly in the standard in a way that allows any party to implement the specifications freely without the possibility of being
541
charged unduly.
From the viewpoint of technological requirements, the following items are to be examined for the
selection of technological standards.
• Track record of successful connections of standards-compliant implementations, or perspective of achieving such connections (verification of connectivity) – a requirement to
ensure interoperability among information systems.
• Track record of successful porting of an application from one standard-compliant implementation to another implementation compliant to the same specifications, or a
perspective of achieving such a porting (verification of portability) – a requirement to ensure
portability of information systems.
• Provision of functions and features that enables continuous expansion and maintenance, including upgrade feasibility and independence from a specific platform (verification of
continuity into the future) – a requirement to ensure usability in the future.
• Applicability of the technology to such business processes as front-office, middle-office, and back-office tasks performed in the ministries, as the TRM assumes these tasks as its
objectives (verification of affinity for the current system).
7.1.3. Guidelines required to establish technology standards In the “Framework for Interoperability Relating to Information Systems,” the guidelines to be
followed by the information system designers and the persons in charge of procurement are provided.
Basically, these guidelines should also be applied to the selection procedures of technology
standards. The guidelines are listed below.
• To expand the range of bidders in the tendering process of separated procurement, restrictions on physical computers and platforms on which the separated functional units operate should
be reduced to a minimum.
• To ensure interoperability among technology components as well as component-by-component exchangeability among them, the technology components deployed in the upper layer must
consist of standardized components – in terms of functions and interfaces provided by the
lower layer technology components - that employ solely the functions and interfaces
compatible with the requirements of an open standard.
• In cases where a functional component based separated procurement and expanded range of options are desired, restrictions on the platform on which the functional components operate
should be reduced to a minimum. Therefore - within the bounds of what the non-functional
requirements permit in terms of performance, security and stability – the service infrastructure
used to invoke external functions should be selected based on the criteria that it can maintain
platform-independence.
• As the data format for data capable of long-term accumulation and exchanged/repeated
542
utilization among a plurality of users, an open and standardized data format should be adopted.
In case more than one open standard is eligible, XML-based standards with a lower
dependence on platforms and specific technologies should be preferentially adopted. In case
more than one XML-based open standard exists, the priority should be given to those with a
plurality of products and vendors that support the standard, especially with future expectations,
from the view of marketability, of wider support from an expanding range of products and
vendors.
• In cases where a functional component based separated procurement and expanded range of options are desired, restrictions on the platform on which the functional components operate
should be reduced to a minimum. In line with this, the format used to exchange messages
among the functional components should also be platform-independent within the bounds of
what the service infrastructure selected for external function invocation permits.
• XML should be used as the message format for exchange among the functional components, as it has lower dependence on platforms and allows description of the message’s logical
structure as a schema. The XML schema must adopt an open standard on a priority basis, and
should be extended as needed. The adopted schema must be made open if interoperability
with external systems is required.
• In conformity with the provisions stipulated in the “Agreement on Government Procurement (GPA)” (Chapter 6-2), international standards and Japanese Industrial Standards should have
priority as the standards to be referenced to by the procurement specifications. In case no
relevant international standards nor Japanese Industrial Standards exist, the next option to
make of reference should be one of some other open standards.
7.2. Items for technology standard evaluation cited in “TRM 1st issue: The Report on the Results of Validity Examination”
In the selection process of important technologies in the 1st issue of the TRM (2004), the following
items were put forward as evaluation criteria.
• The following fact must be included as one of the evaluation items: the technology to be evaluated has been standardized (or is in the process of being standardized) by a
standardizing organization as a set of standard specifications.
• Importance must be placed on the fact that the set of standardized specifications has a wide implementation base, and meets the conditions for widespread use, i.e. the management of
intellectual property rights is clearly defined in the standardization processes in a way that
allows any party to implement it freely without the possibility of being charged unduly.
Therefore, the management status of the intellectual property rights must also be taken into
consideration for the selection of a standard.
• To ensure interoperability among information systems, a track record of successful
543
connections among the standards-compliant implementations, or the perspective of achieving
such connections, must be an item of technological evaluation.
• To ensure portability of the information system, a track record of successful porting of an application from one standards-compliant implementation to another, compliant to the same
specifications, or the perspective of achieving such a porting, must be an item of technological
evaluation.
• One of the technical evaluation items must be the provision of functions and features that enables continuous expansion and maintenance to ensure usability in the future, including for
example, expansion feasibility (scalability) and independence from a specific platform.
• One of the technical evaluation items must be the applicability of the technology to such business processes as the front-office, middle-office, and back-office tasks performed in the
ministries, as the TRM assumes these tasks as its objectives.
• One of the technical evaluation item must be practicality, as well as the potential for the future development of the target technology, as it must be introduced in actual systems and
continuously utilized.
7.3. Guidelines for the Selection of Recommended Technology Standards
7.3.1. Criteria and items of evaluation
In the selection process of the recommended technology standards, which should be derived
based on the “Framework for Interoperability Relating to Information Systems” and the first issue of
the TRM “The report on the results of validity examination,” the candidates must be evaluated in
accordance with the six – as mutually independent as possible - criteria: openness, equitability,
compatibility with business requirements, interoperability, potential for development, and government
regulation.
The evaluation should be quantitative to the maximum possible extent. An appropriate weight
assignment to each of the criterion is also required in view of the particular circumstances of the
objects to be procured and the organizations (the Cabinet Office and Ministries) that perform
procurement. Each of the evaluation criteria is described below.
7.3.1.1. Openness
Openness generally refers to the circumstances where any interested party is able to acquire
information without being hindered by special conditions or barriers, and is also able to grasp the
situations surrounding the standard specifications (e.g. the issue under discussion and the progress
of deliberation) to a satisfactory extent. It implies, as a consequence, the considerations incorporated
in the scheme that the standard specifications, and the organizations that establishes them, should
not endow special interests – from a technical point of view - to particular vendors and groups.
As the scope , or openness, covered by this evaluation criterion is wide, classification is made into
544
the following seven categories: “Openness of participation to the standardizing
organization/committee,” “Openness of decision making processes (including maintenance/support
systems) ,” “Openness of released technical specifications,” “Openness of IPR policy,” “Openness of
data format,” “Vendor independency,” and “Platform independency.” Specific criteria are shown for
each evaluation category.
a) Openness of participation to the standardizing organization/committee
The agency that institutes the standard must be a standardizing organization independent from
specific interest groups. The standardizing organization must not be one whose intention is to provide
benefits to particular parties. Any party, including interested parties - as long as it meets a given set of
conditions - must be allowed to participate in standardizing organizations and deliberative committees.
The set of conditions described above must not contain items that restrict professional affiliation,
expression of thought or opinion, or with a vested interest of the participants.
b) Openness of decision making processes (including maintenance/support systems)
A clear and easy-to-understand decision making process must be provided that enables open
deliberation, including acceptance of requests for content modification of the standard specifications.
Furthermore, a well-organized system must be in place to maintain/support the standard
specifications, whereby parties independent from particular interest groups will take responsibility for
carrying out these tasks.
c) Openness of the released technical specifications
The standard specifications must be released openly in their entirety, enabling all people to gain
access to them on an equal footing.
d) Openness of IPR policy
The conditions regarding IPR policy must be clearly declared.
e) Openness of data format
The data format must be exchangeable, in terms of “convertibility,” with other applications. It must
not depend neither on specific platforms nor on specific applications (from the point of view of the
“Independence of data formats”). In case a plurality of open data format standards exist, from the
viewpoint of the “proactive adoption of a standard capable of data attribute description,” a standard
that comes with a data attribute description capability, or with a standardized schema format must be
preferentially adopted. In particular, in cases where interoperability with external systems is required,
the adopted scheme must be put on open view from the viewpoint of the “disclosure of the schemes.”
f) Vendor independency
The standard specifications must not depend on the products or proprietary technologies of a
545
particular vendor.
g) Platform independency
The standard specifications must be independent from a particular platform to ensure the
information system is compliant to the standard to be utilized into the future, and enables continued
expansion and maintenance. An open standard (schema) must be preferentially adopted, for example,
an industry standard (XML schema) should be given priority.
7.3.1.2. Equity This is an evaluation criterion in terms of the provision of equity in various processes performed by
the standardization organizations and the practices of the standards themselves. The objective of this
evaluation criterion is to eliminate discriminatory conditions or barriers incorporated in the
standardizing processes and the content of the standard itself, and to avoid providing any interested
party with an advantage over others, or conversely, to handicap any party. Equity is often confused
with openness, but the “Evaluation criteria of standards” clearly distinguishes them. The evaluation
items related to this are as follows:
a) Equity of the standardization process
More than one steps must be placed through the process starting from early proposals to the final
approval as a standard, and consensus must be achieved in every one of them in terms of the level of
maturity of the proposed drafts and the contents of deliberation.
b) Consensus based decision making
In the deliberation processes, every effort must be made to reach a unanimous agreement.
c) Equity of decision making
In the decision making process, all participating persons and organizations must be allowed to
execute their own will.
d) Equity of the IPR policy in place
The IPR policy, which has an impact on the utilization of standard specification, must be equitable
and rational to all the users and allow implementation without the possibility of undue charging (e.g.
royalty-free).
e) Equitable maintenance/support system
Any maintenance/support operations of the standard specifications must not provide special
advantages to particular vendors or applications.
546
7.3.1.3. Compatibility with business requirements These evaluation items provide criteria to measure to what extent the standard specifications meet
the needs of the development objectives, functional requirements, and user needs. Specific
evaluation items are as follows:
a) Relevancy to standard specifications
The standard specifications must provide useful and practical measures to solve specific problems.
b) Relevancy to the standardizing organization
The organization that defines the standard specifications must establish specifications that are both
useful and practical for solving specific problems.
c) Conformity with functional requirements
The standard specifications must include technologies conducive to meeting specific requirements.
d) Definiteness of users and objectives
The standard specification must provide clear indications as to “who should use the standard to
solve what type of problem.”
e) Provision of guidelines for applying the standards
Guidelines must be provided to unify application methods of the standard specifications (e.g.
profiles, guidelines), especially in cases where the definitions of the specification allow for a scope of
selection.
7.3.1.4. Interoperability Interoperability designates a set of evaluation criteria that enables such characteristics among the
standard-compliant products and services as: data exchange, replacement by other products,
version-to-version compatibility, and connectivity with other systems, thus preventing various aspects
of the implemented systems to be locked in by a specific vendor. Specific evaluation criteria in this
regard are as follows:
a) Warranty of portability
Track record of successful porting, or a promise of porting, of an application from one
standard-compliant implementation to a dissimilar implementation compliant to the same standard is
required.
b) Standard-to-standard/specification-to-specification interoperability
To realize mutual utilization among standard specifications – i.e. in cases where a plurality of
standard specifications with mutually equivalent functionalities are given – the compatibility among
547
the standards must be guaranteed for the user to select the most suitable one.
c) Version-to-version compatibility
To ensure affinity with the existing standards, the technology must be applicable to existing systems.
This requires upward compatibility to the related standards.
d) System-to-system interoperability
To promote affinity with other systems, the standard must provide a scheme to facilitate linkage with
other systems (including upward applications).
7.3.1.5. Potential for future development Criteria to measure indirect effects gained by adopting a standard specification – e.g. the results
obtained by selecting a standard specification, the impact caused by the selection, and the promise of
future development of the standard. Specific evaluation items classified into this category are as
follows:
a) Ease of extension
To ensure utilization into the future as well as continuous extension and maintenance, the standard
specification must be equipped with the inherent features that will allow easy applications in other
fields other than those originally intended.
b) Scalability
The stipulations provided by the standard specification must be capable of meeting objectives that
are upgraded in size and number.
c) Future potential of technology
The technology – even if it is the most sophisticated at the moment - must be capable of embracing
further improvements in the future.
d) Permeation of the standard specification
A sufficient number of standard compatible products/implementations must be in place from a
plurality of independent vendors, so that the user can have multiple options. In case a plurality of
open standards (e.g. XML) exist, priority for selection must be given to those with a promise of
achieving support from larger number of products and vendors.
e) Maturity of technology
The contents of the specifications must be disclosed openly in a concrete manner to the level that
allows implementation. It is desirable that the standard specification will be in use in a stable form
over a long period of time, with necessary modifications when needed basis as defects are detected.
548
7.3.1.6. Government regulation The Japanese government’s policy imposes a set of requirements on industrial sectors in general.
In particular, adherence to these requirements is sought after in government procurements, making
these an integral part of the evaluation items for selecting a standard specification. Some of the
specific evaluation items are shown below:
a) Accessibility
The evaluation items must be compatible with the accessibility requirements stipulated by the
government.
b) Security
The evaluation items must meet the security criteria stipulated by the government.
c) Green IT
The evaluation items must make an effort to achieve environmental objectives.
d) Privacy
The evaluation items must comply with the “Basic Policy on the Protection of Personal Information”
enacted by the government.
7.3.2. Classification and evaluation criteria of standards
As the target areas of the standards cover a broad array of information technologies, it is
considered inefficient to apply the same evaluation criterion on standards with different scopes of
application. Therefore, the information technology-related standards are broadly classified into the
following nine categories, for each of which a set of category-specific evaluation criteria are defined in
addition to the common criteria. Note, however, that certain standards with very wide applicable areas
may belong to a plurality of categories.
7.3.2.1. Meta-data definition A specification to define syntactic notations and their meanings used in the data definition.
7.3.2.2. Data definition A specification to define binary data formats and data description methods for a text format. The
specification may contain a description of the algorithm used to create the defined data format. Some
definition methods utilize one of the existing meta-data definition specifications, and some may define
their own in their data definition specifications. In the latter case, the data definition includes attributes
for meta-data definition.
549
7.3.2.3. Definition A specification to define the data format – e.g. term definitions, correspondence tables, and code
tables.
7.3.2.4. Algorithm definition A specification to define notations – in terms of syntax and semantics – used to realize an algorithm.
The notation for algorithm definition may use a meta-data definition (e.g. BNF). The specification may
contain a data definition method that is itself manipulated by the algorithm, in which case a set of
attributes for data definition is included.
7.3.2.5. Presentation A specification to define the conversion rules required to achieve user-machine communication – to
present a computer’s internal data to the users, and transmit user instructions to the computer – and
the guidelines describing the rules’ usage.
7.3.2.6. API Specifications to define an interface used to provide services to other programs. The API standard
specification is designed to enhance the freedom of combination among programs. It defines the
following information, as a language binding, required by the caller program to invoke others:
prerequisites for calling, calling name, functions provided, information required to hand over at the
time of invocation, and actions to be taken when the task is normally processed, but abnormally
ended.
7.3.2.7. Protocol The specifications to define the following interactive procedures performed in coordination among a
plurality of programs to achieve a function: calling sequence to accomplish a definite lump of
functionality, the effect to be obtained in a call, and the data format used by each program to
exchange information. The specifications of upper layer protocols are often determined based on the
functions provided by those used in lower layers. API definitions are required to use the protocol of a
program.
7.3.2.8. Algorithm The specifications to determine the mode of processing. Those that determine the encryption
method, data compression method, and others.
7.3.2.9. Process The specifications that define activity processes for an organization, a person, and other entities, or
those that define the methods used to perform an audit on conformity of the process with given rules.
550
These include the rules used to examine if the products are compliant with standards.
7.4. Recommended Technology Standard
This section describes some examples of technology standards that should be given preference in
an information system procurement by the government. Note that the technology standards cited in
this section are for illustrative purpose only: they may be extended or modified in the future as
investigations proceed in accordance with the selection guidelines for recommended technology
standards.
[TRM_STD] ISO/IEC 10646 Recommended standard:
ISO/IEC 10646:2003 Information technology - Universal Multiple - Octet Coded Character Set
(UCS)
ISO/IEC 10646:2003/Amd 1:2005 Glagolitic, Coptic, Georgian and other characters
ISO/IEC 10646:2003/Amd 2:2006 N'Ko, Phags-pa, Phoenician and other characters
JIS X0221:2007 Universal Coded Character Set (UCS)
Remarks (noteworthy reasons for recommendation, etc.):
Characters from around the world have been extensively collected and coded to constitute
ISO/IEC 10646. The standard was instituted by ISO/IEC JTC1, and has been implemented in the
majority of OSs and internet applications with well-established interoperability.
[TRM_STD] TCP/IP Recommended standard:
IETF FC 791: Internet Protocol
IETF RFC 793: Transmission Control Protocol
Remarks (noteworthy reasons for recommendation, etc.):
TCP/IP (Transmission Control Protocol/Internet Protocol) is the standard protocol used in the
Internet and intranets. IP takes care of the 3rd layer (network layer) of the OSI Reference Model,
and TCP the 4th layer (transport layer). TCP/IP has been implemented in all Internet systems,
including Webs, as a basic protocol, and its interoperability is well established. Continuity into the
future is also guaranteed as it will continue to be the protocol of the Internet, as long as the Internet
as we know it exists.
[TRM_STD] HTTP Recommended standard:
IETF RFC 2616 HyperText Transfer Protocol - HTTP/1.1
551
JIS TS X 0085:2004 HyperText Transfer Protocol - HTTP/1.1
Remarks (noteworthy reasons for recommendation, etc.):
HTTP is a request-response protocol connecting the servers and clients. Text data of XML and
other formats is exchanged using this protocol. HTTP is the base protocol for Web systems and
implemented in all of them, meaning that interoperability is well proven. The data type to be
transmitted can be specified using MIME types, providing flexibility as well as ease of expandability.
As long as the Web as we know it continues to exist, continuity of the protocol into the future is also
guaranteed.
[TRM_STD] SQL
Recommended standard:
ISO/IEC 9075-1:2003
Information technology - Database languages - SQL - Part 1: Framework (SQL/Framework)
ISO/IEC 9075-2:2003
Information technology - Database languages - SQL - Part 2: Foundation (SQL/Foundation)
ISO/IEC 9075-3:2003
Information technology - Database languages - SQL - Part 3: Call-Level Interface (SQL/CLI)
ISO/IEC 9075-4:2003
Information technology - Database languages - SQL - Part 4: Persistent Stored Modules
(SQL/PSM)
ISO/IEC 9075-9:2003
Information technology - Database languages - SQL - Part 9: Management of External Data
(SQL/MED)
ISO/IEC 9075-10:2003
Information technology - Database languages - SQL - Part 10: Object Language Bindings
(SQL/OLB)
ISO/IEC 9075-11:2003
Information technology - Database languages - SQL - Part 11: Information and Definition
Schemas (SQL/Schemata)
ISO/IEC 9075-13:2003
Information technology - Database languages - SQL - Part 13: SQL Routines and Types Using
the Java TM Programming Language (SQL/JRT)
ISO/IEC 9075-14:2006
Information technology - Database languages - SQL - Part 14: XML-Related Specifications
(SQL/XML)
Remarks (noteworthy reasons for recommendation, etc.):
SQL is a query language used to define and manipulate data on a relational database. The SQL
552
is a ISO/IEC JTC1 standard, and implemented in all relational database products. Continuity into
the future, as a base language for relational database manipulation, is ensured as long as relational
databases remain in use.
[TRM_STD] LDAP (Lightweight Directory Access Protocol) Recommended standard:
IETF RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol
Remarks (noteworthy reasons for recommendation, etc.):
LDAP is a protocol used to access directory databases, which take control of various
network-related information (user name, machine name, etc). LDAP has a wide spread use in many
implementations provided by various vendors, thus its interoperability is well established.
[TRM_STD] XML (eXtensible Markup Language) Recommended standard:
W3C eXtensible Markup Language (XML) 1.0
JIS X 4159:2002 eXtensible Markup Language (XML) 1.0
Remarks (noteworthy reasons for recommendation, etc.):
XML is a general-purpose data description language used to express structured data in text
format. As XML uses solely texts for description, it can maintain lower dependence on platforms
and proprietary technologies (see the explanation in 6.1.3 “Guidelines assigned to technology
standards”). XML’s ability to clearly define the logical structure of the message as a schema
enables it to be used in all areas, as well as providing ease of expansibility and interoperability. Its
use in variety of fields is well underway – including the methods to express document contents and
the inner structure of applications – and has secured continuity into the future. It also meets the
portability requirements, as it has a verified track record of XML data exchanges among the
XML-based middleware and applications developed on a plurality of dissimilar platforms.
[TRM_STD] XML Schema Recommended standard:
W3C XML Schema Part 1: Structures Second Edition
W3C XML Schema Part 2: Datatypes Second Edition
Remarks (noteworthy reasons for recommendation, etc.):
W3C’s XML Schema (Part1, Part2) is a schema description language used to define a set of tags
for each specific application and specification. The schema defines the elements, attributes, and
hierarchic structure among the elements, and almost all varieties of industry standard XML use
W3C XML Schema. Nearly all of the tools and applications are compatible with the W3C XML
553
Schema, exemplifying well verified interoperability. As an XML structure defining language, W3C
XML Schema allows easy re-definition of information structures as well as easy extension.
[TRM_STD] WSDL (Web Services Description Language) Recommended standard:
W3C Web Services Description Language (WSDL) 1.1
Remarks (noteworthy reasons for recommendation, etc.):
WSDL is a language to define the framework – locations of Web service, message format for
information exchange with the Web service and applications - used to describe the functionality of
Web services and the interface to access these services. Many services that provide WSDL and the
tools for generating it are already in place – e.g. The WS-I Basic Profile defines the profile that
guarantees the interoperability of WSDL. It uses XML as the description format, which provides
independence from a particular OS along with an ease of extensibility. Continuity into the future is
also apparent – e.g. SOA utilizes this language.
[TRM_STD] WS-I Basic Profile Recommended standard:
ISO/IEC PRF 29361
Information technology - Web Services Interoperability - WS-I Basic Profile Version 1.1
Remarks (noteworthy reasons for recommendation, etc.):
WS-I Basic Profile is a profile that shows the guidelines for utilizing various functions provided by
Web-related service standards (SOAP, WSDL, etc). The profile has an effect of enhancing the
interoperability of Web services among products. As exemplified by the effort to incorporate new
standards into the profile in line with the developments in Web service related standards, WS-I
Basic Profile is prepared for continuity into the future.
[TRM_STD] SOAP Recommended standard:
W3C Simple Object Access Protocol (SOAP) 1.1
Remarks (noteworthy reasons for recommendation, etc.):
SOAP represents a basic protocol used for invoking Web services. Connections (message
exchange, etc) using SOAP have been experimented with in a variety of industrial sectors, and
many products supporting this protocol are already in place. DOPG (now-defunct Distributed Object
Promotion Group) confirmed product-to-product connectivity using SOAP, and the interoperability of
this scheme at the practical level has been verified. It employs XML as the description format to
gain independence from particular OSs and to achieve easily extendable specifications, giving
554
promise for continued utilization into the future.
[TRM_STD] X.509 Recommended standard:
ISO/IEC 9594-8: 2001
Information technology - Open Systems Interconnection - The Directory: Public-key and attribute
certificate frameworks
JIS X5731-8: 2003 Open Systems Interconnection - The Directory: Part 8 “Framework for
certification”
Remarks (noteworthy reasons for recommendation, etc.):
X.509 represents a set of specifications that defines the standard format for public-key
certificates, the algorithm used in pass/fail checking of certificates, and other items. X.509-based
electronic certificates have been used globally in electronic certification processes for
e-Governments. Many private-sector certification organizations have also adopted this standard. In
coordination with each other, these organizations constitute PKI, providing a well-verified
interoperability. X.509 - as a international standard defined by ITU-T - is currently undergoing
incremental upgrade/modification, and has continuity into the future.
555
Appendix 1 Case Examples of Procurement
1. Common to all government organizations A database of information system-related government procurement cases:
Covers procurement cases processed by the administrative bodies in the government
http://cyoutatujirei.e-gov.go.jp/
2. Procurement specifications (drafts) prepared by government offices and ministries Cabinet office: Information system-related government procurement
<Integrated information system used for Public Interest Corporation Commission>, <Business
operations/systems required for executing economic/financial policy-related services>, and others.
http://www.cao.go.jp/others/kichou/it/gyouseijouhou.html
National Personnel Authority: National Personal Authority-related government procurement information
<Announcement of general competitive bidding>, <Request for comments> and others
http://www.jinji.go.jp/tyoutatu/index14.4.1.htm
Financial Services Agency: Procurement information
http://www.fsa.go.jp/common/choutatu/index.html
National Police Agency: Government procurement information of information systems
http://www.npa.go.jp/chotatu/seifu_choutatsu/seifu_choutatsu.html
Ministry of Internal Affairs and Communications: Provision of procurement information within the ministry, accounting section of the minister’s
secretariat, government procurement information/planning competition, public offering, etc.
http://www.soumu.go.jp/menu_sinsei/cyoutatsu/cyoutatsu.html
Procurement information of the Statistical Bureau, Director-General for Policy Planning (Statistical
Standards) & Statistical Research and Training Institute, bid invitation
http://www.stat.go.jp/info/chotatsu/mokuji.htm
556
Design and development of the sharing system for government statistics
http://www.stat.go.jp/info/guide/public/05/kaihatsu.htm
Ministry of Foreign Affairs: Procurement information of the Ministry of Foreign Affairs
http://www.e-procurement.mofa.go.jp/kokuji/SyuruiSentaku.html
Ministry of Finance: Government procurement information (all ministries)
http://www.mof.go.jp/jouhou/tyoutatu/seihutyoutatu.htm
Procurement information for Tokyo Customs
http://www.customs.go.jp/kyotsu/chotatsu/tokyo.htm
Ministry of Health, Labour and Welfare: Publication of procurement information relating to information systems
http://www.mhlw.go.jp/sinsei/chotatu/chotatu/index.html
Ministry of Agriculture, Forestry and Fisheries: Bidding information (information regarding the government procurement of information systems)
http://www.maff.go.jp/j/supply/index.html
Ministry of Economy, Trade and Industry: List of bidding information (all ministries)
http://www.meti.go.jp/information_2/publicoffer/00_bid_news_list.html
Others: Ministry of Economy, Trade and Industry CIO/CTO training, 5. Request for proposal templates
(included in procurement support document)
http://www.meti.go.jp/policy/it_policy/CIO/index.html
Preparations manual for making outsourcing specifications of system developments in the Ministry of
Economy, Trade and Industry (plan): request for comment (Jul. 28, 2003)
http://www.meti.go.jp/feedback/data/i30728aj.html
557
3. Procurement plan documents from the offices and ministries National Personnel Authority: Procurement plan documents relating to the design/upgrade of
personnel/payroll systems
http://www.jinji.go.jp/tyoutatu/systemtyoutatujyoho.htm
Cabinet office: Explanations on government procurement relating to the promotion of e-Government
and information systems
http://www.cao.go.jp/others/kichou/it/gyouseijouhou.html
National Police Agency: Information on government procurement of information systems,
procurement plan documents
http://www.npa.go.jp/chotatu/seifu_choutatsu/keikakusyo/keikakusyo.html
Financial Services Agency: Procurement information
http://www.fsa.go.jp/common/choutatu/index.html
Ministry of Internal Affairs and Communications: Information system procurement plan documents
http://www.soumu.go.jp/menu_sinsei/cyoutatsu/joho_system.html
Ministry of Foreign Affairs: Public announcement of procurement plan documents created based on
the Basic Guidelines for government procurement related to information systems
http://www.mofa.go.jp/mofaj/annai/shocho/chotatsu/keikakusho/index.html
Ministry of Finance: Public announcement of information system procurement plan documents
http://www.mof.go.jp/jouhou/tyoutatu/seihutyoutatu.htm
Tokyo Customs: System procurement plan documents
http://www.customs.go.jp/kyotsu/chotatsu/sonota/s_tokyo.html
Ministry of Education, Culture, Sports, Science and Technology: Information system-related
government procurement plan documents
http://www-gpo3.mext.go.jp/kanpo/keikakuidx.htm
Ministry of Health, Labour and Welfare: Procurement plan documents
http://www.mhlw.go.jp/sinsei/chotatu/chotatu/keikakusho.html
Ministry of Agriculture, Forestry and Fisheries: Procurement plan documents
http://www.maff.go.jp/j/supply/nyusatu/system/index.html
558
Ministry of Economy, Trade and Industry: System procurement plan documents
http://www.meti.go.jp/information/publicoffer/sysplan.html
Japan Patent Office: Explanation on the procurement plan documents for the Japan Patent Office’s
basic infrastructure system
http://www.jpo.go.jp/cgi/link.cgi?url=/koubo/choutatu/keikakushyo/kiban_system.htm
Ministry of Land, Infrastructure, Transport and Tourism: Public announcement of information system
procurement plan (based on the basic guidelines for government procurement)
http://www.mlit.go.jp/chotatsu/chotatsushishin/chotatsushishin.html
Japan Meteorological Agency: Procurement plan documents
http://www.data.jma.go.jp/chouta/data/H20/H20jouhousystem/jouhousystem.html
4. Reference Cases of Total Evaluation National Personnel Authority: Evaluation procedure manual for the leasing and maintenance of the
equipment and software used in personnel/payroll-related business information systems
http://www.jinji.go.jp/tyoutatu/090727_nyusatu.htm
Cabinet office: Documents attached/appended to the business statistics system, procurement
specifications, and other requests for proposals (Part 3, Dec. 2008)
http://www.cao.go.jp/kanbou/gyouseijouhou.html
559
Appendix 2 Case Examples: Service Procurement Specifications
The following is a list of case examples that are used as a reference for the sections of Chapter 6 “Procurement
of services.” The titles are tentative translations.
“TRM documents” in the table designates the full set of procurement specifications defined in the following
document (see “References” section): Information-technology Promotion Agency: “Factual Evaluation of
Technical Reference Model”(a survey report, Jul. 2009).
Ministry and agency names are abbreviated as follows:
CO: Cabinet Office
MOFA: Ministry of Foreign Affairs
FSA: Financial Service Agency
JCG: Japan Coast Guard
JMA: Japan Meteorological Agency
MAFF: Ministry of Agriculture, Forestry and Fisheries
METI: Ministry of Economy, Trade and Industry
MHLW Ministry of Health, Labour, and Welfare
MIC: Ministry of Internal Affairs and Communications
MOJ: Ministry of Justice
MOF: Ministry of Finance
MOE: Ministry of the Environment
MLIT: Ministry of Land, Infrastructure, Transport and Tourism
NPA: National Personnel Authority
1. Supports for Overall Planning
2. Support tasks for procurement 1) Requirement Definition
Ministry/ Agency
Procurement Specification Created in
METI FY2010: Tasks to support the creation of system requirements for the next generation basic information infrastructure of the Ministry of Economy, Trade and Industry
2010
560
2) Project Management Ministry/ Agency
Procurement Specification Created in
MHLW Support tasks (process management, etc.) for the construction of an electronic processing system used to handle worker’s compensation receipts
2009
MOJ Procurement specifications: procurement of supporting tasks for total project management of the online registration/deposition application system
2009
NPA Supporting tasks relating to the project management of the design/upgrade of the personnel/payroll business information system: Full set of documents
2009
MIC Outsourcing contracts of the project management supporting tasks for the design/development/operation processes in the integrated wireless station monitoring system
2010
MAFF Supporting task specifications for the forestry insurance business system construction project (FY2010) 2010
3. System Construction (design and development) 1) New Development
Ministry/ Agency
Procurement Specification Created in
TRM Documents
1) Procurement specifications for administrative information delivery services (with application of TRM) 2008
TRM Documents
2) Procurement specifications for groupware and other items used in the personnel information system (with application of TRM)
2008
TRM Documents
4)-1 Procurement specifications for the operational management system (with application of TRM) 2008
MHLW Tender specification for the complete set of tasks for the development of software used in online replacement charging of medical receipts
2009
MHLW Procurement specifications (plan) for the complete set of design/development tasks relating to the workman’s compensation electronic processing system
2009
MHLW Requirements specification for the complete set of tasks involved in the development of the Japan Pension Service ‘s indirect business system
2009
CO Total information system used for Public Interest Corporation Commission 2007
561
2) System Revision Ministry/ Agency
Procurement Specification Created in
MOFA Specifications for the complete set of development tasks associated with the business/system optimization plan of overseas bookkeeping systems
2008
MHLW System revisions within the ministry used for processing general applications and notifications 2008 MOF Procurement specifications (plan) for the complete set of tasks associated with the development of the national
treasury electronic processing system 2009
MOJ Procurement specifications plan associated with the revision of the registration information delivery system 2009 MOJ Specifications related to the design/development/testing of the next generation immigration information system
(optimization of business procedures and system for immigration management), and revision of the integrated data management system
2010
MOE Procurement specifications (plan) of the tasks (design, etc.) relating to the reconstruction of the Ministry of the Environment electronic application/notification system – scheduled from FY2010 to FY2011
2009
JMA Construction, leasing, maintenance, and installation/coordination of the sediment disaster warning information preparation system
2010
MIC Request for proposals for the contracting of design and development tasks for the next generation consumer price statistical survey system
2010
MIC Request for proposals for contracting of the design and development tasks for the statistical survey system shared by ministries
H18
MAFF Procurement specifications for design and development of the perishable goods logistics information data communication system
2008
MHLW Tender specification for the complete set of tasks for the development of software used in online replacement charging of medical receipts
2009
MHLW Procurement specifications (plan) for the complete set of design/development tasks relating to the workman’s compensation electronic processing system
2009
MHLW Requirements specification for the complete set of tasks involved in the development of Japan Pension Service ‘s indirect business system
2009
TRM Documents
1) Procurement specifications for administrative information delivery services (with application of TRM) 2008
3) Hardware Revision Ministry/ Agency
Procurement Specification Created in
MOFA Ministry of Foreign Affairs: specifications of clerical support system for information disclosure 2008 MOFA Procurement specifications for the completed set of tasks involved in the passport application image filing system 2008 MOJ Procurement specifications for the tasks associated with the hardware upgrade of the map information system –
data migration, system switching, and others 2010
MLIT Business application migration tasks associated with the establishment of the one-stop service system for car-ownership protocol
2008
CO Total information system used for Public Interest Corporation Commission 2007 MHLW Tender specification for the complete set of tasks for the development of software used in online replacement
charging of medical receipts 2009
MHLW Procurement specifications (plan) for the complete set of design/development tasks relating to the workman’s compensation electronic processing system
2009
TRM Documents
1) Procurement specifications for administrative information delivery services (with application of TRM) 2008
562
4) Addition of Functions Ministry/ Agency
Procurement Specification Created in
MOFA Full set of task specifications associated with the revision of the region/nations-based ODA grant target figure system
2008
MOFA Procurement specifications associated with the application development and data migration for the international treaties and agreements search system
2008
METI Next generation statistics system maintenance associated with the migration to STATS (addition of a data validation function)
2009
METI Full set of tasks associated with the function creation (tools, etc.) and database migration to the research and statistics system of the Ministry of Economy, Trade and Industry
2009
MHLW Development tasks for the groups of functions (employment insurance protocol and grant funding) required for the implementation of the “Employment stabilization administrative system” (provisional title)
2008
MOF Request for proposals: revision of tasks (e.g. review of sample extraction) used in the network system that performs business corporation statistics survey and others
2010
MOF Program upgrading specifications for Custom Intelligent Database System (CIS) 2008 MOF Full set of specifications for the design/development tasks associated with the inclusions of new tasks and system
optimization of the fiscal loan funding electronic processing system 2007
MOJ Procurement specifications for application function expansion of the next generation registration information system
2008
MOJ Service procurement specifications for performance enhancement of the Ministry of Justice’s total reception/notification system
2008
MOJ Procurement specifications for the tasks required to link the map information system with the new on-line application system
2009
JCG Business system for utilization of Vessel tracking information in coast guard operations 2008 MLIT Air traffic control information processing system: manufacturing and adjustment of the complete control support
system 2010
MLIT Identification information system for vehicle registration: design and development 2009 NPA Design and upgrade tasks for functional enhancement of the personnel/payroll business information system 2009 NPA Full set of specifications for upgrading the personnel/payroll business information system: centralization,
adaptation to the requirements from ministries and other offices, and conformity with institutional reform 2008
NPA Full set of design and upgrading tasks for notification, application, and other functions incorporated in the personnel/payroll business information system
2009
NPA Design and upgrading of the personnel/payroll business information system 2008 MIC Contract of tasks (design, development, construction and others) required to expand functions in the validation
environment within the government authentication infrastructure – tasks associated with the migration to the new encryption algorithm
2009
MIC Contracts for design and development of the supervising system database management functions in the Telecommunications Bureau
2010
MIC Contracts for design and development required for expanding the backbone functions for the supervising system in the Telecommunications Bureau
2010
MIC Contracts of development tasks for information processing tasks used in the supervising system of the Telecommunications Bureau
2010
CO Equipment replacement, functional expansion, maintenance, and operation tasks for the total disaster prevention system
2009
MAFF Specifications for the renovation project of the forest insurance business system, and preparatory tasks to enter it into operation
2009
563
4. Operation Ministry/ Agency
Procurement Specification Created in
TRM Documents
5) Procurement specifications for operation (with application of TRM) 2008
MOFA Full set of procurement specifications for operation and maintenance of the Contents Management System (CMS) used in IT publicity tasks of the Ministry of Foreign Affairs
2009
MOFA Full set of operational tasks of the Secretariat business system 2009 METI Operational management of the server network in the METI infrastructure information system 2008 METI Support tasks for operational management of the statistics information system 2008 MHLW Full set of operational tasks relating to system/work optimization of the supervision, health and safety, and
worker’s accident compensation insurance delivery 2008
MHLW Total operational supervision tasks for the employment security administrative system (tentative name) (scheduled to enter into operation in 2011)
2009
MOF Operation and maintenance of the budget compilation support system 2009 MOJ Procurement specifications for the operation and maintenance of the next generation registration system for the
assignment of accounts receivables, and support tasks of the public records bureaus 2008
FSA Request for procurement proposal related to the operation of the EDINET system – electronic system for disclosure of asset securities reports and other documents
2008
NPA Procurement specifications of help desk support tasks relating to the personnel/payroll business information system
2009
MIC Contract of operations relating to optimization of tasks and systems of the sharing system infrastructure (contract of additional operational tasks required to cope with the hardware and software expansion in the sharing system infrastructure)
2009
MIC Contract of operation and other tasks of the e-Government utilization support center 2007 MAFF Operation support tasks for the information management system of the General Food Policy Bureau 2007
5. Help Desk Ministry/ Agency
Procurement Specification Created in
MHLW Full set of operational tasks relating to the system/work optimization of the supervision, health and safety, and worker’s accident compensation insurance delivery
2008
MHLW Total operational supervision tasks for the employment security administrative system (tentative name) (scheduled to enter into operation in 2011)
2009
MOF Operation and maintenance of the budget compilation support system 2009 NPA Procurement specifications of the help desk support tasks relating to the personnel/payroll business information
system 2009
TRM Documents
5) Procurement specifications for operation (with application of TRM) 2008
564
6. Maintenance 1) Hardware maintenance
Ministry/ Agency
Procurement Specification Created in
MOFA Procurement specifications for leasing and maintenance tasks of the full set (hardware) of the document preparation/editing system
2008
MHLW “Full set of tasks relating to optimizing the business system – introduction of a LAN to hub locations and maintenance – used for the supervision, health and safety, and worker’s accident compensation insurance delivery”
2008
JMA Hardware leasing, maintenance, and installation/adjustment of the volcano monitoring information center 2009 MAFF Maintenance tasks specifications for the national forestry resources database server and others:
h220226_siyou_2 2009
TRM Documents
4)-1 Procurement specifications for the operational management system (with application of TRM) 2008
TRM Documents
4)-2 Procurement specifications for HW (with application of TRM) 2008
2) Software maintenance Ministry/ Agency
Procurement Specification Created in
NPA Leasing and maintenance of hardware and software used in the personnel/payroll business information system (2nd phase)
2009
TRM Documents
4)-1 Procurement specifications for the operational management system (with application of TRM) 2008
3) Application maintenance Ministry/ Agency
Procurement Specification Created in
METI Full set of maintenance tasks for the industrial statistics system (maintenance of operational environment) 2009 MHLW Full set of system revision tasks within the ministry used for processing general applications and notifications 2008 MOF Full set of service contract for revision, operation, and maintenance of the fiscal loan resources electronic
processing system 2007
MOJ Procurement specifications: procurement of business application maintenance tasks for the new registration system installed in 2010
2009
JMA Construction, leasing, maintenance, and installation/coordination of the sediment disaster warning information preparation system
2010
FSA Procurement specifications (plan) for additional design and development for improved operation of EDINET (electronic system for disclosure of asset securities reports and other documents)
2008
MAFF Procurement specifications: revision tasks of the field crop statistical research and data collection program 2009 MHLW Specification of the full set of tasks for the maintenance of applications used in the next generation labor insurance
and collection system 2009
NPA Leasing and maintenance of hardware and software used in the personnel/payroll business information system (2nd phase)
2009
TRM Documents
1) Procurement specifications for administrative information delivery services (with application of TRM) 2008
565
4) System infrastructure maintenance
Ministry/ Agency
Procurement Specification Created in
MHLW Procurement specifications for the provision (design/development, connection, total test and operation) of the integrated network for the Ministry of Health, Labour and Welfare, scheduled to be expanded starting FY2009
2009
MHLW Procurement specifications for the “Full set of tasks relating to optimizing the business system – introduction of a LAN to hub locations and its operation and maintenance – used for the supervision, health and safety, and worker’s accident compensation insurance delivery”
2008
TRM Documents
3) Network procurement specifications (with application of TRM) 2008
7. Tasks associated with instrument procurement Ministry/ Agency
Procurement Specification Created in
TRM Documents
4)-2 Procurement specifications for HW (with application of TRM) 2008
MOFA Full set of procurement specifications for the electronic notification system server and other items used for the procedures to reside in Japan
2008
MOFA Procurement specifications: Leasing and maintenance of the full set of instruments used in electronic bidding and bid opening system
2009
METI Full set of secondary leasing equipment used in the statistical analysis system of the Ministry of Economy, Trade and Industry
2010
METI Equipment used in the general purpose electronic application system of the Ministry of Economy, Trade and Industry
2008
MHLW Procurement specifications for the full set of servers and terminal equipment (introduced in FY2009) used in contact/reception function group of the Employment stabilization administrative system (provisional title)
2008
MHLW Procurement specifications for the full set of sub-system servers and other equipment used for employment placement tasks of the Employment stabilization administrative system (provisional title)
2009
MOF Procurement specifications for the provisions (hardware and others) used in the fiscal loan funding electronic processing system
2009
MIC Leasing of equipment and software used for business/system optimization of the sharing system infrastructure 2008 MIC Leasing procurement specifications for the business/system optimization of users authentication (office staff
inclusive) 2008
MOJ Specification for the procurement of terminal equipment and other items used in the next generation registration information system
2008
MOJ Procurement specifications: procurement of terminal equipment and other items used in the new (FY2010) registration information system
2009
8. Tasks associated with the procurement of iDC equipment Ministry/ Agency
Procurement Specification Created in
TRM Documents
7) IDC procurement specifications (with application of TRM) 2008
MOFA Leasing of the data center and a full set of associated items 2010 MHLW Employment stabilization administrative system (provisional title) data center and a full set of associated items 2008 MOJ Procurement of ancillary facilities required for operation of the new registration information system 2009 MIC Leasing procurement of facility and equipment used for business/system optimization of the sharing system
infrastructure 2008
566
9. Network procurement Ministry/ Agency
Procurement Specification Created in
TRM Documents
3) Network procurement specifications (with application of TRM) 2008
TRM Documents
6) WAN procurement specifications (with application of TRM) 2008
MOFA Full set of procurement specifications for the construction and operation of the open LAN basic business system to be incorporated in the Ministry of Foreign Affairs information network (sharing system)
2008
METI Ministry of Economy, Trade and Industry’s network services 2008 MHLW Procurements related to the renovation of the Ministry of Health, Labour and Welfare's network system 2009 MHLW Procurement specifications for the provision (design/development, connection, total test and operation) of the
integrated network of the Ministry of Health, Labour and Welfare, scheduled to be expanded starting FY2009 2009
MOJ Procurement of the new registration information system communication services (FY2010) 2009
567
Appendix 3 Table: Guidelines on the transition of encryption algorithms
Concerns over the degraded security of the encryption algorithms now prevailing in government
organizations (SHA-1 and RSA1024) have currently been pointed out, producing a demand to make
the shift to an encryption algorithm with higher level of security.
The move requires coordinated and integrated actions in the government from the viewpoint of
securing interoperability among the information systems. To this purpose, the 17th meeting of the
Committee on Information Security Policies (22, Apr. 2008) decided the transition guidelines (see
appendix: “Transition guidelines of the encryption algorithms (SHA-1, RSA1024) currently employed
in the government information systems”).
Improvements and upgrading of the information systems are now underway in conformity with the
transition guidelines – especially relating to the two encryption algorithms (SHA-1, RSA1024) now
prevailing in the government organizations – aiming at completion by the early part of 2014. Along
with this, stop-gap measures (a contingency plan) against rapid degradation of security are now
under consideration.
Note that the need for measures to be established in the offices and ministries toward transition of
encryption systems and implementation of the contingency plan, in line with the above described
transition guidelines, is also explicitly stated in “Standards for Information Security Measures for the
Central Government Computer Systems” (decisions made by the Committee on Information Security
Policies), which defines the whole-governmental standard of the measures to be implemented for
upgrading information security.
In terms of the transition of encryption algorithm, constant gathering of the latest information and
review are highly desired as an abrupt change of situation can not be ruled out.
568
1 現状と課題1 現状と課題
2 暗号の移行指針の概要2 暗号の移行指針の概要
①電子政府システムでは,電子署名等のために暗号が使用されており,SHA-1及びRSA1024と呼ばれる暗号方式を広く使用.
②しかし,このSHA-1及びRSA1024は,安全性の低下が指摘されており,より安全な暗号方式への移行が必要.
③より安全な暗号方式への移行にあたっては,情報システムの相互運用性確保や政府全体の情報セキュリティの向上のため,政府統一
的な移行指針を策定することが必要.
①電子政府システムでは,電子署名等のために暗号が使用されており,SHA-1及びRSA1024と呼ばれる暗号方式を広く使用.
②しかし,このSHA-1及びRSA1024は,安全性の低下が指摘されており,より安全な暗号方式への移行が必要.
③より安全な暗号方式への移行にあたっては,情報システムの相互運用性確保や政府全体の情報セキュリティの向上のため,政府統一
的な移行指針を策定することが必要.
①技術的な対応①技術的な対応
【上記以外の情報システム】
○ 現実的な脅威となる攻撃手法が示された時点で,速やかに別の暗号方式
に変更する等の対応措置を可能とする.
○ 新たな暗号方式は,より安全なものを各府省庁において判断し決定する.
②制度的な対応○ 各府省庁において次を実施
・システムの移行時期を踏まえ,必要な対応の取りまとめ・移行手順書の整備
②制度的な対応○ 各府省庁において次を実施
・システムの移行時期を踏まえ,必要な対応の取りまとめ・移行手順書の整備
③スケジュール○ 内閣官房,総務省,法務省,経済産業省等
新たな暗号方式へ切り替える時期等を2008年度中に検討.
○ 内閣官房,総務省等
相互接続の技術要件,緊急避難対応等について2008年度中に検討.
○ 各府省庁
2010年から2013年までの間に,各情報システムの対応を完了.
○ 内閣官房,総務省,経済産業省
安全性の状況を監視し,必要な情報を速やかに各府省庁に提供.
③スケジュール○ 内閣官房,総務省,法務省,経済産業省等
新たな暗号方式へ切り替える時期等を2008年度中に検討.
○ 内閣官房,総務省等
相互接続の技術要件,緊急避難対応等について2008年度中に検討.
○ 各府省庁
2010年から2013年までの間に,各情報システムの対応を完了.
○ 内閣官房,総務省,経済産業省
安全性の状況を監視し,必要な情報を速やかに各府省庁に提供.
【政府認証基盤とそれに依存する各府省庁の情報システム】
○ 相互運用性確保のため,新旧暗号方式の双方に対応し,
適切な時期に暗号方式を切り替える運用を可能に.
○ 新たな暗号方式として,SHA-256及びRSA2048を採用.
○ 移行完了前に安全性低下の影響が発生する場合に備え,
緊急避難的な対応も想定.
Figure Appendix 3-1 Guidelines Overview of Encryption Method Migration
1. Current Status and Challenges
(1) The e-Government system uses code languages for the implementation of cryptographic processing such as electronic signature. For this purpose, encryption methods called SHA-1 and RSA1024 are widely used. (2) Degradation of security has been pointed out for the encryption methods, producing the need for migration to a safer encryption method (3) The migration process to a safer encryption method requires establishment of unified guidelines by the government to ensure interoperability of the information systems and upgraded government-wide information security
2. Guidelines Overview of Encryption Method Migration
(1) Technical aspects [Governmental authentication framework, and the information systems of ministries and offices that depend on it] ○ To ensure interoperability, the migration process must maintain compatibility with both old and new encryption methods and be capable of switching them at an appropriate time. ○ Adaptation of SHA-256 and RSA2048 as the new encryption methods ○ In view of the concerns of temporal lowering of security prior to the completion of migration, a contingency plan for ensuring security must be provided.
[Other information systems] ○ In view of the possibility of an eminent emergence of an attacking method that threatens security, optional measures must be provided to quickly switch to different encryption methods. ○ Each ministry and office must consider and make decisions on the new encryption method for higher levels of security.
(2) Institutional aspects ○ The following measures must be implemented in each ministry and office - Summarizing and sorting out necessary measures based on the system migration schedule
(3) Schedule ○ Cabinet Secretariat, Ministry of Internal Affairs and Communications, Ministry of Economy, Trade and Industry, and other ministries and offices
Switching schedule to the new encryption method must be studied by the end of FY2008. ○ Cabinet Secretariat, Ministry of Internal Affairs and Communications, and other ministries and offices
Technical requirements for mutual connections, contingency plans and additional measures must be studied by the end of FY2008. ○ Each ministry and office
Each information system must be preparing for the system migration during the period of 2010 to 2013. ○ Cabinet Secretariat, Ministry of Internal Affairs and Communications, Ministry of Economy, Trade and Industry
These offices must always place a check on the state of security, and provide necessary information to the ministries and offices without delay.
569
政府機関における技術仕様等の各種検討の開始
政府機関における技術仕様等の各種検討の開始
新たな暗号方式のみの使用
複数の暗号方式が混在
政府機関の情報システムが対応開始
政府機関の情報システムが対応開始
政府機関の情報システムが対応完了
政府機関の情報システムが対応完了
新たな暗号方式への移行開始(従来の方式の新規使用停止)
新たな暗号方式への移行開始(従来の方式の新規使用停止)
新たな方式への移行完了(従来の方式の消滅)
新たな方式への移行完了(従来の方式の消滅)
従来の暗号方式のみの使用
暗号の安全性を監視
新たな暗号方式への移行完了以前に安全性低下による支障
が発生した場合は,官民連携した緊急避難的な対応を実施
▽2010年度 ▽2013年度 ▽(X-day) ▽(Y-day)▽2008年度
(X,Y-day):関係機関との調整を図りながら,2008年度中に時期を検討
地方公共団体,民間認証局等の対応状況を所管省庁等を通じて把握
政
府
機
関
地方公共団体
民間等
(参考)
米国では期限を決めて対応する
方法を採用し,2010年末以降,政
府機関において,SHA-1の新規使
用を停止する方針.
しかし,SHA-1が2010年に危殆化
するかどうかは専門家の間でも意
見がわかれる.
このため本指針は,暗号の安全性
低下の状況を監視しながら対応す
る方法とし,政府が暗号の安全性
を監視し,安全性低下が早まった
場合は,緊急避難的な対応を実施
(コンテンジェンシープランの発動)
.
(参考)
米国では期限を決めて対応する
方法を採用し,2010年末以降,政
府機関において,SHA-1の新規使
用を停止する方針.
しかし,SHA-1が2010年に危殆化
するかどうかは専門家の間でも意
見がわかれる.
このため本指針は,暗号の安全性
低下の状況を監視しながら対応す
る方法とし,政府が暗号の安全性
を監視し,安全性低下が早まった
場合は,緊急避難的な対応を実施
(コンテンジェンシープランの発動)
.
Figure Appendix 3-2 Migration Schedule up to Completion in Conformity with the Migration
Guideline
Gov
ernm
ent O
rgan
izat
ions
FY2008 FY2010 FY2013
Start of various studies – technical specifications, etc. – in government organizations
Start of system modification in the information systems of government organizations
Completion of system modification in the information systems of government organizations
Start of encryption method migration (novel use of the conventional method is banned)
Completion of migration processes (deletion of the conventional method)
(Reference) The USA has adopted a policy to limit the time: new use of SHA-1 after the end of 2010 will be banned in the government organizations. However, experts have divided opinions if SHA-1 will become too vulnerable in 2010. This guideline applies a policy to keep a watch on the security situations of encryption methods, and take appropriate measures accordingly. In case the security monitoring indicates an earlier-than-expected degradation of security, emergency measures will be put into effect (invocation of the contingency plan)
Exclusive use of conventional encryption methods
Mixed use of conventional and new
methods
Exclusive use of new encryption methods
Security level monitoring of encryption
If secured communication is threatened because of degraded security prior to the migration to the new methods, emergency measures will be brought into effect in coordination between private and public sectors.
Priv
ate
sect
ors
and
loca
l pub
lic
orga
niza
tions
Progress of migration processes in local public organizations and private sector certificate authorities should be monitored through the information provided by the presiding ministries and offices.
(X, Y-day): Timing of system migration must be studied during FY2008, with careful coordination among ministries and offices
570
Appendix 4 References
Following titles are tentative translations.
■Guidelines for Optimizing Operation and Systems (Mar. 2006) e-Government’s unified contact: On promotion of e-Government
http://www.e-gov.go.jp/doc/scheme.html
■Basic Guidelines for Government Procurement Relating to Information Systems (Mar. 2007) Ministry of Internal Affairs and Communications Home Page
http://www.soumu.go.jp/s-news/2007/070301_5.html
■ “Basic Guidelines for Government Procurement Relating to Information Systems: Practical Manual” (2nd edition)
Ministry of Internal Affairs and Communications Home Page
http://www.soumu.go.jp/menu_news/s-news/2007/070919_2.html
■ Framework for Interoperability Relating to Information Systems (Jun. 2007) Ministry of Economy, Trade and Industry Home Page
http://www.meti.go.jp/press/20070629014/20070629014.html
■ Ministry of Economy, Trade and Industry: Knowledge Portable Reference Model (TRM) (Mar. 2005)
Ministry of Economy, Trade and Industry Home Page: EA portal
http://www.meti.go.jp/policy/it_policy/ea/data/report/index10.html
■ “Information Disclosure Policies on Security and Reliability of ASP and SaaS” (Nov. 2007) Ministry of Internal Affairs and Communications Home Page
http://www.soumu.go.jp/menu_news/s-news/2007/071127_3.html
■ Guidelines for Information Disclosure Relating to Safety and Reliability of Data Centers (1st edition) (Feb. 2009)
Ministry of Internal Affairs and Communications Home Page
http://www.soumu.go.jp/main_content/000010165.pdf
571
■ “Guidelines relating to safety management of medical information: for ASP/SaaS Business Operators” (Jul. 2009)
Ministry of Internal Affairs and Communications Home Page
http://www.soumu.go.jp/menu_news/s-news/02ryutsu02_000010.html
■ “Service Organization Control Reports (formerly SAS 70 reports)” http://www.aicpa.org/InterestAreas/AccountingAndAuditing/Resources/SOC/Pages/SORHome.aspx
■ 18th Report of the Auditing Standard Committee (Japanese Institute of Certified Public Accountants) “Control Risk Evaluation in Commissioned Businesses,” (normally referred to as
“No.18 Audit”)
■ National Information Security Center: major released document “Standards for Information Security Measures for the Central Government Computer Systems (4th
edition)” (revised in 2009)
http://www.nisc.go.jp/active/general/pdf/K303-091.pdf
Practical Guide for the “Standards for Information Security Measures for the Central Government
Computer Systems (4th edition)” (revised in 2009)
http://www.nisc.go.jp/active/general/pdf/K303-091C.pdf
Note: The latest version of the Standards for Information Security Measures for the Central
Government Computer Systems was released in Apr. 21, 2011.
- Unified Rules to Guarantee Information Security Measures for the Central Government Computer
Systems (Apr. 21, 2011)
http://www.nisc.go.jp/active/general/pdf/kihan.pdf
- Guidelines for Establishment and Operation of Management Standards and Technical Standards for
Information Security Measures for the Central Government Computer Systems (Apr. 21, 2011)
http://www.nisc.go.jp/active/general/pdf/unyou.pdf
- Management Standards for Information Security Measures for the Central Government Computer
Systems (Apr. 21, 2011)
http://www.nisc.go.jp/active/general/pdf/K304-101.pdf
- Technical Standards for Information Security Measures for the Central Government Computer
Systems (Apr. 21, 2011)
http://www.nisc.go.jp/active/general/pdf/K305-101.pdf
572
- “Management Standards for Information Security Measures for the Central Government Computer
Systems”: Practical Guide
http://www.nisc.go.jp/active/general/pdf/K304-101C.pdf
- “Technical Standards for Information Security Measures for the Central Government Computer Systems”:
Practical Guide
http://www.nisc.go.jp/active/general/pdf/K305-101C.pdf
- Report of the working group on the risk requirements reference model (Mar. 2010)
http://www.nisc.go.jp/inquiry/pdf/2-1_RM-model_Open.pdf
- Manual for establishing security requirements applied to the control of information systems in
governmental organizations (Mar.30, 2011)
http://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf
■ Guidelines for risk evaluation and electronic signature/authentication in online procedures Decisions made in the 41st liaison conference of chief information officers (CIO) from the Cabinet
Office and Ministries (Aug. 2010)
http://www.kantei.go.jp/jp/singi/it2/cio/dai41/41gijisidai.html
■ E-Government Usability Guidelines Decisions made in the 37th liaison conference of chief information officers (CIO) from the Cabinet
Office and Ministries (Jul. 2009)
http://www.kantei.go.jp/jp/singi/it2/cio/dai37/37gijisidai.html
■ Information-technology Promotion Agency: “Factual Evaluation of the Technical Reference Model” (a survey report, Jul. 2009)
Information-technology Promotion Agency Home Page: List of achievements of the project for
promotion of open software utilization (2008)
http://www.ipa.go.jp/software/open/ossc/2008seika.html
- Research report:
http://www.ipa.go.jp/software/open/ossc/download/trm20_report.pdf
- Executive summary:
http://www.ipa.go.jp/software/open/ossc/download/trm20_report_summary.pdf
- Executive summary, supplementary documentation:
http://www.ipa.go.jp/software/open/ossc/download/trm20_report_summary_appended.pdf
- Full set of procurement specifications:
http://www.ipa.go.jp/software/open/ossc/download/trm20_specific_procurement.zip
573
- Full set of total (functional) evaluation criteria:
http://www.ipa.go.jp/software/open/ossc/download/trm20_assessment_1.zip
- Full set of total (general) evaluation criteria:
http://www.ipa.go.jp/software/open/ossc/download/trm20_assessment_2.zip
- Full set of request for proposals:
http://www.ipa.go.jp/software/open/ossc/download/trm20_rfp.zip
■ Information-technology Promotion Agency, SEC BOOKS: “SLCP-2007 (2nd ed.),” Dec. 2009 http://sec.ipa.go.jp/press/20090930_b.html