OECD-METI-RIETI Conference
To Ensure the Reliability
of
Information Systems
October 6, 2008
Koichi Hironishi
Corporate Senior Executive Vice President
Fujitsu Limited
Copyright 2008 FUJITSU LIMITED
Agenda
zWhat is the reliability of information systems?
zWhat is needed to ensure reliability?
zFujitsu’ s approach to ensure reliability
zWrap up ~To Ensure Reliability
1
Copyright 2008 FUJITSU LIMITED
What is the reliability of
Information Systems?
From a User’s point of view...
To realize the expected role
of the information system throughout its lifecycle
Both users and vendors must mutually
understand the role of the system and
make efforts to realize it.
2
Copyright 2008 FUJITSU LIMITED
What is needed to ensure reliability?
Engineering cannot be the only solution
to ensure reliability.
Users and Vendors must understand
the requirements correctly
and
Vendors develop the function with quality
based on the requirements.
Key Point: Elimination of ambiguity and
visualization of the requirements
3
Copyright 2008 FUJITSU LIMITED
Fujitsu’ s approach to ensure reliability
To understand the requirements correctly
Fujitsu develops common views (measures)
collaborating with other vendors and users.
To develop the function with quality
based on the requirements,
Fujitsu is using the approach of “Four
Innovations” to improve system development.
4
Copyright 2008 FUJITSU LIMITED
Developing common views (measures)
collaborating with other vendors and users
5
Copyright 2007 FUJITSU LIMITED
Fujitsu’ s approach to ensure reliability
１
Common framework for Software Lifecycle
Process 2007 （SLCP) (2006~)
２
Ensuring the quality with Top Executives
(2004~)
３
Customers’ view study group (2006 - )
４
The Grades standards for Non-functional
requirements （2007~)
6
Copyright 2008 FUJITSU LIMITED
Fujitsu’ s approach to ensure reliability
Developing common views (measures)
１
Common framework for Software Lifecycle
Process 2007 （SLCP) (2006~)
Common measures for planning, development, operation and
maintenance of Information Systems to help mutual
understanding of each work item through the life cycle process.
２
Ensuring the quality with Top Executives
(2004~)
Recommendation on involvement of Top Executives of users to
clarify the role sharing between vendors and users in the
development of Information Systems.
7
Copyright 2008 FUJITSU LIMITED
Developing the common views (measures)
３
Customers’ view study group (2006 -)
Pursuing how to describe external specification in an easyto-understand way for users and how to build consensus in
business application development.
４
The Grades standards for Non-functional
requirements （2007~)
Visualization of Non-functional requirements such as
performance, operability, security and formulation of the
guidelines for user-friendly methods for consensus building
between users and vendors.
8
Copyright 2008 FUJITSU LIMITED
Fujitsu’ s approach to ensure reliability
１
Common framework for Software Lifecycle
Process 2007 （SLCP) (2006~)
２
Ensuring the quality with Top Executives
(2004~)
３
Customers’ view study group (2006 -)
４
The Grades standards for Non-functional
requirements （2007~)
9
Copyright 2008 FUJITSU LIMITED
SLCP-Japan Common Framework 2007
Revised from SLCP-JCF ‘98
Agreement Processes
Acquisition Processes
③
Supply Processes
Contract Change
Mgmt Processes
Primary Processes
①
Planning
Processes
② Requirements
Building/Developing
Process
Development
Processes
Organizational Processes
Maintenance
Processes
Software
Support
Processes
Operation
Processes
Software Reuse
Processes
…
④
System
Audit Procs
added and tailored in JCF
Copy right all reserved in Japan National Board of SC7/WG7 & IPA Software Engineering Center 2008
Copyright 2008 FUJITSU LIMITED
10
Fujitsu’ s approach to ensure reliability
１
Common frame for Software Lifecycle
Process 2007 （SLCP) (2006~)
２
Ensuring the quality with Top Executives
(2004~)
３
Customers’ view study group (2006 -)
４
The Grades standards for Non-functional
requirements （2007~)
11
Copyright 2008 FUJITSU LIMITED
Planning Processes ＆
Requirements Building/Developing Process
Appendix: Seventeen Principles
1. Expectations of users and venders often differ
2. Any decision consists of agreement and approval
3. Never postpone decisions crucial to the project
4. Never proceed to the next process without agreement by stakeholders
5. Multi stage contract decreases risks for both parties
6. System development costs you much more than software development does
7. Emphasize system life cycle cost
8. The objective of the project is meaningful only when everybody knows it
9. Requirements are attributed to users after all
10. Requirements definition is the baseline of development
11. Good requirements definition describes new business system in detail
12. Never implemented are unexpressed requirements
13. Qualitative expressions are interpreted in a developers favorite way
14. No such requirement as ‘Just same as present’
15. An ideal business system will never be realized
16. Functional requirements diverge, cost and schedule converge them
17. Users are accountable for requirements definition
*for each principle, disciplines in action are described for both user and supplier
Copy right all reserved in Japan National Board of SC7/WG7 & IPA Software Engineering Center 2008
Copyright 2008 FUJITSU LIMITED
12
Fujitsu’ s approach to ensure reliability
１
Common frame for Software Lifecycle
Process 2007 （SLCP) (2006~)
２
Ensuring the quality with Top Executives
(2004~)
３
Customers’ view study group (2006 - )
４
The Grades standards for Non-functional
requirements （2007~)
13
Copyright 2008 FUJITSU LIMITED
Customers’ view study group
[Area targeted by Customers' view study group]
"Study group for customers' view on requirements specification based on a practical approach"
(called "Customers' view study group" hereinafter) targeted the "External design" phase because
it is the phase where developers have lots of contact with customers and customers are involved
until program production.
Then the group targeted three technology areas: "Screen", "System behavior” and “Data model“.
[ Target Phase ]
[ Target Technology Area ]
Direction of
systematization
Screen
transition/definition
Plan of systematization
Business logic
(Specification of detail
processing)
Requirements definition
System design
System development
Testing
External
design
Business process
Internal
design
Screen
System
behavior
(Specification of business
operation flow and procedure)
Data model
(Specification of database)
Data model
(Excerpt from the public presentation by Customers’ view study group on March 18, 2008)
14
Copyright 2008
2007 FUJITSU LIMITED
Customers’ view study group
Customers’ view guideline (Screen design edition)
Introducing , as a tip,
ingenuity and things to
note either to prevent
misunderstanding or to
find perception gap.
Chapter title
The points in
description example
are further explained
in speech balloon.
Description example,
showing both undesirable and
desirable examples which
actually appeared in design
documents.
This example shows one of the
tips when drawing screen
transition diagrams.
Explanation of
description
example
(Excerpt from the public presentation by Customers’ view study group on September 18, 2007)
15
Copyright 2008 FUJITSU LIMITED
Fujitsu’ s approach to ensure reliability
１
Common frame for Software Lifecycle
Process 2007 （SLCP) (2006~)
２
Ensuring the quality with Top Executives
(2004~)
３
Customers’ view study group (2006 -)
４
The Grades standards for Non-functional
requirements （2007~)
16
Copyright 2008 FUJITSU LIMITED
The Grades standards for
Non-functional requirements
„ Why the Grades (levels of) standards are needed…
Functional Requirements
Functional and Non-functional requirements on Information Systems
Specific Function ①
Requirement on availability
Requirement on capability
Recovery from system down
within 3 hours…
Response time within 3
seconds…
Sharing the sales information on the
system.
Availability
Safety
Reliability
Specific Function ②
Maintenance
Inventory management linked to
ordering information
Business Continuity
Emergency Management
Various Nonfunctional
requirements
Capability
Operability
Transitivity
Usability
Security
Challenges for Venders/Users on Non-functional Requirements
It
It is
is difficult
difficult to
to clarify
clarify Non-functional
Non-functional requirements
requirements at
at early
early stage
stage of
of planning
planning
As
As requirements
requirements or
or specifications
specifications are
are still
still vague
vague in
in the
the upper
upper process
process of
of the
the planning,
planning,
venders
and
users
cannot
have
mutual
understanding
on
Non-functional
requirements.
venders and users cannot have mutual understanding on Non-functional requirements.
17
Copyright 2007 FUJITSU LIMITED
The Grades standards for
Non-functional requirements
„ Image of the Grades standards
Item
Grades Chart
Each item of the requirements：
Classification of expected features
Level 1
Level 2
Level 3
Capability
Operability
Emergency
response
e.g. Emergency response
①
②
Protect data as
restorable format
Cost and Development
period ; Low and Short
Ensure business
continuity in case
of failure in each
equipment
③
Ensure business
continuity in case
of larger disruption
Grades (Levels)
List options for each
requirement
Cost and Development Cost and Development
period ; high and Long
period ; Middle
Help mutual understanding on requirements by indicating options for each requirement.
We need the system
performance in an
emergency...
The impact of emergency on
business and recovery level
will be like this...
Determine the level of emergency response
Discussion
Discussion and
and
assumption
assumption on
on
emergency
emergency
response
response by
by
vendors
vendors and
and users.
users.
Levels
Levelschart
chart
18
Copyright 2007 FUJITSU LIMITED
The Grades standards for
Non-functional requirements
Schedule
２００７
First half
Primary
Primary
discussion
discussion
by
by voluntary
voluntary
vendors
vendors
Collect
Collect examples
examples and
and
review
representation
review representation
Start
Pick out Nonfunctional
requirements
２００９
２００８
Second half
First half
Draft
Draft Non-functional
Non-functional
Grades
Grades standards
standards
Review
Review draft
draft standards
standards
by
users
and
by users and promote
promote
dissemination
dissemination through
through
industry
group
industry group or
or
publication
publication
Interim output
Review by Users
Aggregate knowledge of
venders
Draft Grades Standards
Aim to become
De-facto standard!
How to utilize the Grades standards
○Through industry-wide
○In each vendor
・Build consensus on Non-functional
・Reflect the standards in
requirements between vendors and users. requirements definition documents.
19
Copyright 2007 FUJITSU LIMITED
Fujitsu’s practice：
“Four Innovations”
in
System Development
20
Copyright 2007 FUJITSU LIMITED
“Four Innovations” in System Development
Production
Design
zGuidelines
for RDDs *
zInternal audit of RDDs
zIndustry-wide initiatives for
improving RDDs
zCultivating Business Architects
System architecture
zTemplates
for system
development
zIndustrialization
zOffshore development
Maintenance
zService templates
Building/testing
Operation/
maintenance
Way of working for system engineers
z
TPS-based HR development, small group activities
*RDD: Requirement Definition Document
21
Copyright 2008 FUJITSU LIMITED
Innovation in design
„Improvement of the quality of planning and
mandatory review by a third party within Fujitsu
z Guidelines for RDDs*
z Internal Audit of RDDs
z Diagnosis of external specification
関連するSEC書籍
共通フレーム
共通フレーム2007
2007
（SLCP-JCF2007）
（SLCP-JCF2007）
„Human development
zCultivate Business Architects who
support planning, requirements
building and developing processes.
*RDD: Requirement Definition Document
22
Copyright 2008 FUJITSU LIMITED
Innovation in design
Mandatory review of the RDDs* of system integration
exceeding certain size by third party within Fujitsu
Process of requirement
definition
Customer
Process of
external design
Reflect requirements
into external design
RDDs
External design
documents
Fujitsu
Internal audit of RDDs
Diagnosis of
external design
Recommendation
*RDD: Requirement Definition Document
Feed back
23
Copyright 2008 FUJITSU LIMITED
An example of Internal audit of RDDs
Aggregate
AggregateCheck
Check
Consistency
ConsistencyCheck
Check
Environment
In the operation
requirements
Non-functional
requirement B
Non-functional
requirement A
Job
transaction
Between
operations and
Non-functional
requirements
Between
operations and
Functional
requirements
System
performance
Data
Interaction
Environment
Non-functional
requirement B
Job
transaction
System
performance
Non-functional
requirement A
In Nonfunctional
requirements
Interface
Compatibility
CompatibilityCheck
Check
In Functional
requirements
Between Functional
and Non-functional
requirements
24
Interface
Data
Interaction
Copyright 2008 FUJITSU LIMITED
Wrap up ~To Ensure Reliability
25
Copyright 2007 FUJITSU LIMITED
To Ensure Reliability
Improvement of the quality from two aspects
Adopt industrial
standards
Industrial activity
Internal practice
Provide internal
Know-how
Clarification of
requirements by Common
Views (Measures)
Improvement of technologies
by “Four Innovations”
Reliability of Information Systems
26
Copyright 2007
2008 FUJITSU LIMITED
27
29
Copyright 2007
2008 FUJITSU LIMITED