To Ensure the Reliability of Information Systems · Title: To Ensure the Reliability of Information Systems Author: 広西光一 (富士通株式会社取締役副社長) Created

Copyright 2008 FUJITSU LIMITED

To Ensure the Reliabilityof

Information Systems

October 6, 2008Koichi Hironishi

Corporate Senior Executive Vice PresidentFujitsu Limited

OECD-METI-RIETI Conference


Agenda

What is the reliability of information systems?

Fujitsu’ s approach to ensure reliability

What is needed to ensure reliability?

Wrap up ~To Ensure Reliability

1


What is the reliability of

To realize the expected role of the information system throughout its lifecycle

From a User’s point of view...

Both users and vendors must mutually understand the role of the system and make efforts to realize it.

2

Information Systems?


What is needed to ensure reliability?

Engineering cannot be the only solution to ensure reliability.

Key Point: Elimination of ambiguity and visualization of the requirements

Users and Vendors must understand the requirements correctly

Vendors develop the function with quality based on the requirements.

and

3



To understand the requirements correctly

To develop the function with quality based on the requirements,

Fujitsu is using the approach of “Four Innovations” to improve system development.

Fujitsu develops common views (measures) collaborating with other vendors and users.

4

Copyright 2007 FUJITSU LIMITED5

Developing common views (measures) collaborating with other vendors and users


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~)４



Developing common views (measures)

Common measures for planning, development, operation and maintenance of Information Systems to help mutual understanding of each work item through the life cycle process.

7


Recommendation on involvement of Top Executives of users to clarify the role sharing between vendors and users in the development of Information Systems.




Pursuing how to describe external specification in an easy-to-understand way for users and how to build consensus in business application development.

8

Developing the common views (measures)

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.

Customers’ view study group (2006 -)３








Copyright 2008 FUJITSU LIMITEDCopy right all reserved in Japan National Board of SC7/WG7 & IPA Software Engineering Center 2008

SLCP-Japan Common Framework 2007Revised from SLCP-JCF ‘98

Planning Processes

Acquisition Processes

Supply Processes

Contract Change Mgmt Processes

SoftwareSupport

Processes

Software ReuseProcesses

Agreement Processes

Organizational Processes

added and tailored in JCF

DevelopmentProcesses

MaintenanceProcesses

OperationProcesses

SystemAudit Procs

RequirementsBuilding/Developing

Process

Primary Processes

…

10

①

②

③

④





Common frame for Software Lifecycle Process 2007 （SLCP) (2006~)１


Copyright 2008 FUJITSU LIMITEDCopy right all reserved in Japan National Board of SC7/WG7 & IPA Software Engineering Center 2008

Appendix: Seventeen Principles1. Expectations of users and venders often differ2. Any decision consists of agreement and approval3. Never postpone decisions crucial to the project4. Never proceed to the next process without agreement by stakeholders5. Multi stage contract decreases risks for both parties6. System development costs you much more than software development does7. Emphasize system life cycle cost 8. The objective of the project is meaningful only when everybody knows it9. Requirements are attributed to users after all10. Requirements definition is the baseline of development 11. Good requirements definition describes new business system in detail12. Never implemented are unexpressed requirements13. Qualitative expressions are interpreted in a developers favorite way14. No such requirement as ‘Just same as present’15. An ideal business system will never be realized16. Functional requirements diverge, cost and schedule converge them17. Users are accountable for requirements definition

*for each principle, disciplines in action are described for both user and supplier

12

Planning Processes ＆Requirements Building/Developing Process






Customers’ view study group (2006 - )３


Customers’ view study group


[ Target Phase ]

Direction of systematization

System design

Plan of systematization

Requirements definition

System development

Testing

[ Target Technology Area ]

ScreenScreen

System behaviorSystem behavior

Data modelData model

External design

Internal design

Data model(Specification of database)

Business logic(Specification of detail

processing)

Screen transition/definition

Business process(Specification of business

operation flow and procedure)

[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“.

(Excerpt from the public presentation by Customers’ view study group on March 18, 2008)


Explanation of description example

The points in description example are further explained

in speech balloon.

Chapter titleIntroducing , as a tip, ingenuity and things to note either to prevent misunderstanding or to

find perception gap.

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.

Customers’ view guideline (Screen design edition)

(Excerpt from the public presentation by Customers’ view study group on September 18, 2007)

Customers’ view study group

15








Why the Grades (levels of) standards are needed…

Challenges for Venders/Users on Non-functional Requirements

As requirements or specifications are still vague in the upper process of the planning, venders and users cannot have mutual understanding on Non-functional requirements.As requirements or specifications are still vague in the upper process of the planning, venders and users cannot have mutual understanding on Non-functional requirements.

It is difficult to clarify Non-functional requirements at early stage of planningIt is difficult to clarify Non-functional requirements at early stage of planning

Maintenance

Safety

Usability

Operability

TransitivitySecurity

CapabilityReliability

Sharing the sales information on the system.

Inventory management linked to ordering informationFu

nctio

nal R

equi

rem

ents Specific Function ①

Availability

Recovery from system down within 3 hours…

Requirement on availabilityResponse time within 3 seconds…

Requirement on capability

Specific Function ②

Business Continuity Emergency Management

Various Non-functional

requirements

Functional and Non-functional requirements on Information Systems

Non-functional requirementsThe Grades standards for


Image of the Grades standardsGra

des

Chart

Each item of the requirements：Classification of expected features

Grades (Levels)List options for each

requirement

Determine the level of emergency response

We need the system performance in an

emergency...

The impact of emergency on business and recovery level

will be like this...

Help mutual understanding on requirements by indicating options for each requirement.

Levels chartLevels chartDiscussion and assumption on

emergency response by

vendors and users.

Discussion and assumption on

emergency response by

vendors and users.

e.g. Emergency response

Cost and Development period ; Low and Short

Protect data as restorable format

①

Ensure business continuity in case of failure in each equipment

② ③

Ensure business continuity in case of larger disruption

Cost and Development period ; Middle

Cost and Development period ; high and Long

Level 1 Level 2 Level 3

Operability

Capability

Item

Emergencyresponse



Schedule

How to utilize the Grades standards○In each vendor

・Reflect the standards in requirements definition documents.

○Through industry-wide・Build consensus on Non-functional

requirements between vendors and users.

２００７２００８

Collect examples and review representationCollect examples and review representation

Draft Non-functional Grades standards

Draft Non-functional Grades standards

Review draft standards by users and promote dissemination through

industry group or publication

Review draft standards by users and promote dissemination through

industry group or publication

Start Interim output Draft Grades Standards

Second halfFirst half

２００９

First half

Review by Users

Primary discussion

by voluntary vendors

Primary discussion

by voluntary vendors

Pick out Non-functional

requirementsAggregate knowledge of

venders

Aim to becomeDe-facto standard!



“Four Innovations”in

System Development

Fujitsu’s practice：


“Four Innovations” in System Development

Way of working for system engineersTPS-based HR development, small group activities

MaintenanceProductionTemplates for system developmentIndustrializationOffshore development

DesignGuidelines for RDDs *Internal audit of RDDsIndustry-wide initiatives for improving RDDsCultivating Business Architects

System architecture Building/testingOperation/

maintenance

Service templates

*RDD: Requirement Definition Document


Improvement of the quality of planning and mandatory review by a third party within Fujitsu

Guidelines for RDDs*Internal Audit of RDDsDiagnosis of external specification

共通フレーム2007（SLCP-JCF2007）

共通フレーム2007（SLCP-JCF2007）

関連するSEC書籍

Human development

Innovation in design

22


Cultivate Business Architects whosupport planning, requirementsbuilding and developing processes.


Mandatory review of the RDDs* of system integration exceeding certain size by third party within Fujitsu

23

Innovation in design


Process of requirement definition

Process of external design

Customer

Fujitsu

RDDs

Internal audit of RDDs

External design documents

Diagnosis of external design

Recommendation

Feed back

Reflect requirements into external design


An example of Internal audit of RDDs

In the operation requirements

Between operations and Non-functional requirements

Between Functional and Non-functional requirements

Aggregate CheckAggregate Check Compatibility CheckCompatibility CheckConsistency CheckConsistency Check

24

Environment

Job transaction

System performance

Non-functional requirement B

Interface

Interaction

Data

Non-functional requirement A

Between operations and Functional requirements

In Non-functional requirements

In Functional requirements

Environment

Job transaction

System performance

Non-functional requirement B

Interface

Interaction

Data

Non-functional requirement A


Wrap up ~To Ensure Reliability


To Ensure Reliability

Improvement of the quality from two aspects

Reliability of Information Systems

Clarification of requirements by Common

Views (Measures)

Improvement of technologies by “Four Innovations”

Internal practiceIndustrial activity


Adopt industrial standards

Provide internal Know-how

Copyright 2008 FUJITSU LIMITEDCopyright 2007 FUJITSU LIMITED2927

Documents

To Ensure the Reliability of Information Systems · Title: To Ensure the Reliability of Information Systems Author: 広西 光一 (富士通株式会社取締役副社長) Created

To Ensure the Reliability of Information Systems · Title: To Ensure the Reliability of Information Systems Author: 広西光一 (富士通株式会社取締役副社長) Created