• 検索結果がありません。

IPA セミナー第 8 部 11/21( 金 )15:50-16:40 ソフトウェア開発データ白書 の新分析項目のご紹介 独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェア高信頼化センター (SEC) 研究員佐伯正夫研究員松田充弘 ET 年 11 月

N/A
N/A
Protected

Academic year: 2021

シェア "IPA セミナー第 8 部 11/21( 金 )15:50-16:40 ソフトウェア開発データ白書 の新分析項目のご紹介 独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェア高信頼化センター (SEC) 研究員佐伯正夫研究員松田充弘 ET 年 11 月"

Copied!
45
0
0

読み込み中.... (全文を見る)

全文

(1)

IPAセミナー第8部 11/21(金)15:50-16:40

独立行政法人情報処理推進機構(IPA)

技術本部 ソフトウェア高信頼化センター(SEC)

研究員 佐伯 正夫

研究員 松田 充弘

ソフトウェア開発データ白書2014-2015の

新分析項目のご紹介

ET2014 2014年11月19~22日

(2)

目 次

1.生産性に関する変動要因について

2.信頼性に関する変動要因について

3.各工程における規模、成果物量および工数の相関

(3)

ソフトウェア開発データ白書の定期的発行

◇統計情報 statistical Information プロファイル、規模、工数、工期、

Profile, Size, Effort, Duration 生産性、信頼性とそれらの変動要因

Productivity, Reliability and their Variation Factors

◇データ項目、メトリクス、分析方法、知見 Data Items, Metrics, Analyzing Methods, Knowledge

Own

Repository

組織/企業における定量的管理

Quantitative Management in a organization

生産性向上, 信頼性向上 Improve software productivity and reliability

◇Benchmarking and management decisions about software development practices. ◇Areas for improvement are identified.

ソフトウェア開発データ白書

White Paper 2014-2015

Software Development Project data from

29

companies in Japan. Repository

3,541

project data set

IPA/SEC

collect every year publish every 2 years

参考

use as reference

☆毎年データ収集、隔年で白書発行

(4)

ソフトウェア開発データ白書の定期的発行(つづき)

☆IPA/SECは、ソフトウェア開発データ白書作成を

通じて得られた知見を基に、IT プロジェクトベンチ

マーキング国際標準規格(ISO/IEC 29155 シリー

ズ)の標準化に貢献している。

IPA/SEC has been contributing standardization

of ISO/IEC 29155 series ” Information

technology project performance benchmarking

framework” by using knowledge of the White

Paper.

今秋10月1日に、ソフトウェア開発 データ白書2014-2015を発行

(5)

生産性および信頼性の変動要因について

Example of productivity/reliability variation factor

model

生産性の結果指標 FP当り実績工数 開発プロセス Development Process 設計文書化密度 テスト密度 ・ ・ ・ Q,C,D要求 Requirements 顧客の協力度合い Cooperation Degree of Customer プロファイル Profile 開発環境 Environment 組織の成熟度 Maturity of Organization 信頼性要求レベル 開発期間 発注仕様の確定時期 レビュー・承認の実施時期 ・・・ レビュー工数比率 レビューでの欠陥摘出率 テスト工数比率 ・・・ CMMIレベル 品質保証体制 ・・・ 開発規模 新規/改良 ・・・ ソフトウェア資産の 整備度 ・・・ スキルレベル 業種、システム種別 要件定義への顧客参加度合い

Result Index of

Productivity

信頼性の結果指標 KFP当り 発生不具合密度 SLOC当り実績工数 KSLOC当り 発生不具合密度

Result Index of

Reliability

・・・

☆種々のエリアの変動要因が考えられる。

(6)

1.生産性に関する変動要因について

生産性の結果指標

FP当り実績工数

Work Effort per Unit FP Size 開発プロセス Development Process

設計文書化密度

Documentation Density: The Number of Design Document Pages per Unit FP Size (Basic Design + Detailed Design)

テスト密度

Test Density:

The Number of Test Cases per Unit FP Size (Integration Test +

System Test) Q,C,D要求 Requirements プロファイル Profile

信頼性要求レベル

Reliability-Requirements-Level

開発規模

Functional Size (FP)

Result Index of

Productivity

の要因について紹介する。

(7)

1.生産性に関する変動要因について(つづき)

検索条件

Search Criteria)

◇ 新規開発(New Development)

◇ FP計測手法(FP Count Approach): IFPUG, SPR or NESMA

◇ FP規模(FP Size) > 0

◇ 開発工数(Work Effort) > 0

◇ 開発5工程が揃っているプロジェクト

(Development Phases are from Basic Design to System Test.)

<比較方法(Comparison Method

◇ 中央値を境に2群に分けて、両者のFP当り実績工数を比較する。

Divide numeric data into two groups by the median, and compare

the work effort per unit FP size of both.

◇ 対数化データに対して、平均の差の検定(Welchのt検定)を行う。

Perform Welch's t test for the data after logarithmic transformation.

(8)

1.生産性に関する変動要因について(つづき)

信頼性要求レベルが高い集合の方がFP当りの工数が大きい傾向が見られる。(1%有意) つまり、信頼性要求レベルが高くなると、FP生産性が低下する傾向が窺える。

0

10

20

30

40

50

低い (Low)

高い (High)

信頼性要求レベル

Reliability-Requirements-Level

N = 83

N = 86

FP当り実績工数

(man-hours/FP) 低 F P 生 産 性 高 IF Reliability-Requirements-Level is high,

(9)

1.生産性に関する変動要因について(つづき)

FPが大きい集合の方がFP当りの工数が大きい傾向が見られる。(3%有意) つまり、開発規模が大きくなると、 FP生産性が低下する傾向が窺える。

0

10

20

30

40

50

60

FP小(Small)

FP大(Large)

FP規模

FP size

FP当り実績工数

(man-hours/FP) 低 F P 生 産 性

N = 193

N = 193

IF FP size is large, then FP productivity is low.

(10)

1.生産性に関する変動要因について(つづき)

設計文書化密度が高い集合の方がFP当りの工数が大きい傾向が見られる。(1%有意)

0

10

20

30

40

50

60

低い (Low)

高い (High)

設計文書化密度

Documentation Density:

Document Pages per Unit FP Size

FP当り実績工数

(man-hours/FP) 低 F P 生 産 性

N = 69

N = 70

IF Documentation Density is high,

(11)

1.生産性に関する変動要因について(つづき)

テスト密度が高い集合の方がFP当りの工数が大きい傾向が見られる。(1%有意) つまり、規模当りのテストケース数が多くなると、 FP生産性が低下する傾向が窺える。

0

10

20

30

40

50

60

低い (Low)

高い (High)

テスト密度

Test Density:

Test Cases per Unit FP Size

FP当り実績工数

(man-hours/FP) 低 F P 生 産 性

N = 136

N = 137

IF Test Density is high, then FP productivity is low.

(12)

1.生産性に関する変動要因について(つづき)

まとめ (Summary)

ソフトウェア開発データ白書用に収集した現行プロジェクトデータによれば、開発規模(FP)と 工数には強い相関関係が見られるものの、バラツキが小さくない。 業種、開発プロジェクトの種別(新規/改良)、開発規模の他、規模当りの設計書ページ数、 規模当りのテストケース数、信頼性要求レベル等によって変動する傾向が見られる。

自組織のソフトウェア開発プロジェクト群のデータに基づいて、自組織に

おける生産性変動要因を見出すこと、そして見積り/計画の妥当性評価

にあたっては、その生産性変動要因による変動を勘案しながら評価する

ことが望ましい。

◇ Find productivity variation factors in each organization.

◇ Evaluate the validity of estimated efforts by taking the productivity

(13)

2.信頼性に関する変動要因について

信頼性の結果指標 開発プロセス Development Process

Q,C,D要求 Requirements

信頼性要求レベル

Reliability-Requirements-Level

Result Index of

Reliability

KFP当り 発生不具合密度 Defect Density: The number of defects per 1000 FP in the first 6 months of use of the software 組織の成熟度 Maturity of Organization

テストスキル

Test Skill

定量的な出荷品質基準

Quantitative Criteria of Quality Evaluation for Delivery

(14)

2.信頼性に関する変動要因について(つづき)

<検索条件(Search Criteria)>

◇ FP計測手法(FP Count Approach): IFPUG, SPR, NESMA

◇ FP規模(FP Size) > 0

◇ 開発5工程が揃っているプロジェクト

(Development Phases are from Basic Design to System Test.)

◇ 稼働時の発生不具合数(The number of defects in the first 6 months

of use of the software) >= 0

<比較方法(Comparison Method

◇ 変動要因のカテゴリ間で、FP当り実績工数を比較する。

Compare the work effort per unit FP size between categories of

each variation factor.

◇ 平均の差の検定(Welchのt検定)を行う。

Perform Welch's t test for the data.

(15)

2.信頼性に関する変動要因について(つづき)

信頼性要求レベルが高い集合の方が発生不具合密度が低い傾向が見られる。(4%有意) つまり、信頼性要求レベルが高いとFP信頼性が高くなる傾向が窺える。

0

5

10

15

20

25

高い(High)

低い(Low)

信頼性要求レベル

Reliability-Requirements-Level

発生不具合密度

(No. of defects/1000FP) 低 F P 信 頼 性

N = 89

N = 98

IF Reliability-Requirements-Level is high,

(16)

2.信頼性に関する変動要因について(つづき)

組織に定量的な出荷品質基準が有る方が発生不具合密度が低い傾向が見られる。(8%有意) つまり、定量的な出荷品質基準が有ると信頼性が高くなる傾向が窺える。 0 5 10 15 20 25 30 35 40 基準有り

Criteria are established

基準無し

No Criteria

定量的な出荷品質基準の有無

Quantitative Criteria of Quality Evaluation for Delivery

F P 信 頼 性 高 発生不具合密度 (No. of defects /1000FP)

N = 46

N = 102

IF criteria are established, then FP reliability is high.

(17)

2.信頼性に関する変動要因について(つづき)

テスト要員のスキルが十分な方が発生不具合密度が低い傾向が見られる。(5%有意) つまり、テスト要員のスキルが十分であると信頼性が高くなる傾向が窺える。

0

5

10

15

20

25

30

35

40

45

50

スキルが十分

Sufficient Skill

スキルが不足

Insufficient Skill

テストスキル

Test Skill

発生不具合密度

(No. of defects/1000FP) 低 F P 信 頼 性

N = 45

N =68

IF test skill is sufficient, then FP reliability is high.

(18)

2.信頼性に関する変動要因について(つづき)

まとめ (Summary)

ソフトウェア開発データ白書用に収集した現行プロジェクトデータによれば、開発規模、 業種、開発プロジェクトの種別(新規開発/改良開発)の他、信頼性要求レベルおよび 組織の成熟度に関する要因(定量的出荷品質基準の有無、テストスキル)によって、 FP信頼性が変動する傾向が見られる。

自組織のソフトウェア開発プロジェクトデータ、自組織の成熟度に関する

データおよび出荷後の(あるいはサービスイン後の)不具合密度等に基づ

いて、自組織における信頼性変動要因を見出すこと。そして、それらの

信頼性変動要因に関して信頼性向上方策を検討することが望ましい。

◇ Find reliability variation factors in each organization.

◇ Consider reliability Improvement policy in relation to the reliability

variation factors.

(19)

3.各工程における規模、成果物量および工数の相関

開発規模(FP 規模)と各工程の成果物量との間、および各工程の成果物量と各工程の工数との 間には、強い(又は中程度の)正相関が見られることが分かった。 開発規模 FP size 各工程の開発工数 Effort(man-hour) In each phase 各工程の成果物量 Amount of deliverables In each phase

工程(phase)

*

成果物量(Amount of deliverables )

要件定義

Requirement Definition

要件定義書ページ数

The Number of Pages of Requirement Definition Documents

基本設計

Basic Design

基本設計書ページ数

The Number of Pages of Basic Design Documents

詳細設計

Detail Design

詳細設計書ページ数

The Number of Pages of Detail Design Documents

製作

Manufacturing

実効KSLOC実績値

Actual Source Lines of Code÷1000

結合テスト

Integration Test

結合テストケース数

The Number of Test Cases of Integration Test

総合テスト(ベンダ確認)

System Test by vender

総合テスト(ベンダ確認)ケース数

The Number of Test Cases of System Test by vender correlation correlation

(20)

3.各工程における規模、成果物量および工数の相関(つづき)

<相関係数(R)表

correlation coefficient table

Phase Requirement Definition Basic Design Detail Design manufacturing Integration Test System Test by vender FP ⇔ Amount of deliverables

0.56

0.68

0.72

0.77

0.64

0.43

Amount of deliverables ⇔ Effort

0.67

0.81

0.80

0.79

0.65

0.42

FP ⇔ Effort

0.76

0.79

0.84

0.81

0.76

0.73

<条件(Conditions)> ◇ 新規開発(New Development)

◇ FP計測手法(FP Count Approach): IFPUG, SPR or NESMA ◇ FP規模(FP Size) > 0

◇ 成果物量(Amount of deliverables)>0 ◇ 開発工数(Work Effort) > 0

◇対数化したデータで相関係数(R)を求める。

Calculate coefficient of correlation from data after logarithmic transformation. 次ページ以降に、詳細設計および結合テストにおける相関を表す散布図等を示す。 (他の工程の散布図等は割愛する。)

(21)

3.各工程における規模、成果物量および工数の相関(つづき)

<工程:

詳細設計

Detail Design Phase>

0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 Pages /FP FP当りの詳細設計書ページ数

Detail Design Document Pages /FP

1 10 100 1000 10000 100000 1000000 1 10 100 1000 10000 100000 詳細設計書 ページ数 No.of Pages 機能量(FP size) FPと詳細設計書ページ数との関係

FP ⇔Number of Pages of Detail Design doc.

(logarithmic)

N=93 R=0.72

(22)

3.各工程における規模、成果物量および工数の相関(つづき)

<工程:

詳細設計

Detail Design Phase>

1 10 100 1000 10000 1 100 10000 1000000 詳細設計書ページ数

Number of Pages of Detail Design

詳細設計書ページ数と詳細設計工数との関係

Number of Pages ⇔ Effort (Detail Design)

(logarithmic) N=93 R=0.80 詳細設計工数 Effort (man-hour) 0 1 2 3 4 5 6 7 8 詳細設計書ページ当りの詳細設計工数

Effort /Page (Detail Design) 人時/ページ

Man-Hour /Page

(23)

3.各工程における規模、成果物量および工数の相関(つづき)

<工程:

結合

テスト Integration Test Phase>

1 10 100 1000 10000 100000 1000000 1 10 100 1000 10000 100000 結合テスト ケース数 No.of Test Cases 機能量(FP Size) FPと結合テストケース数との関係

FP ⇔ Number of Test Cases of Integration Test

(logarithmic) N=192 R=0.64 0 1 2 3 4 5 6 7 8 ケース/FP Cases/FP FP当りの結合テストケース数

(24)

3.各工程における規模、成果物量および工数の相関(つづき)

<工程:

結合

テスト Integration Test Phase>

1 10 100 1000 10000 100000 1 100 10000 1000000 工数 Effort (man-hour) 結合テストケース数

Number of Test Cases of Integration test

結合テストケース数と結合テスト工数との関係

Number of Test Cases ⇔ Effort (Integration Test)

(logarithmic)

N=192

R=0.65

0 1 2 3 4 5 6 7 人時/ケース Man-Hour /Test Case 結合テストケース当りの結合テスト工数

(25)

3.各工程における規模、成果物量および工数の相関(つづき)

まとめ (Summary)

開発規模(FP 規模)と各工程の成果物量との間、および各工程の成果物量と各工程の工数 との間には、強い(又は中程度の)正相関が見られることが分かった。

自組織の各ドメインにおいて、開発規模、各工程の成果物量、各工程の

工数との間の相関を確認した上で、各工程の成果物量に着目した「見積

りの妥当性評価」を行うことが有効と考えられる。

◇ Examine the following correlation in each organization.

・Correlation among functional size and amount of deliverables

in each phase.

・Correlation among amount of deliverables and efforts in each phase.

◇ Evaluate the validity of estimated efforts by taking the above

(26)

おわりに (Closing Remarks)

ソフトウェア開発データ白書用に収集した現行プロジェクトデータを分析することによって、

生産性および信頼性に関して新たに見られた傾向を紹介した。

これらの傾向は、業種を始め様々なプロファイルのプロジェクトデータが混在した中でも見ら

れる傾向であることから、各組織の同種のドメインにおいては、より強い傾向が見られること

が期待される。

☆各組織において、定量的管理(定量データを活用したマネジメント)を推進しよう。

Let’s promote quantitative management based on own repository

in each organization.

☆各組織の定量的管理推進において、ソフトウェア開発データ白書の次の情報を、

ご参考にして頂きたい。

◇収集データ項目 ◇メトリクス ◇分析方法 ◇分析結果(統計情報および知見)

Please use the following information on the White Paper as reference.

◇Data Items ◇Metrics

◇Analyzing Methods

◇ Statistical Information and Knowledge

☆本講演で紹介した内容を含む、ソフトウェア開発データ白書2014-2015の補遺を、

今年末にWebサイトに掲載する予定である。併せてご参考にして頂きたい。

The addendum of White Paper2014-2015 will be placed in the web site

at the end of this year. Please use it as reference, too.

(27)

組込みソフトウェア開発データ白書

の取組状況

(28)

組込みソフトウェア開発データ白書の取組状況

2013年度

「製品・制御システム定量データ収集・分析WG」

立ち上げ

プロジェクトデータ約100件提供(7社)

分析試行

分析試行の結果

組込み分野特有の傾向を確認

1.

言語による生産性の違い(C vs C++)

2.

テスト工程のバグ密度(結合テスト vs 総合テスト)

プレス発表(7月@ETWest2014) “データ提供企業募集”

(29)

組込みソフトウェア開発の推移

SEC設立当初(10年前)

業界が未成熟

プロジェクトの定量的管理の土台が固まっていない

実のところ定量的管理が出来ていない

SECは、ソフトウェアエンジニアリング手法

先進企業のベストプラクティスを収集・整備

開発現場への導入推進

そして現在

定量データによる開発の基礎となる開発プロセスの導入が

進んでいる

組込みデータ白書によるベンチマークの機運が高まる

(30)

組込み分野のベンチマークの課題

組込みソフトウェア開発の定量データ収集・分析に

よるデータ白書が必要

多種多様な組込み分野でベンチマークを可能にするため

の課題

組込み分野の製品や機器は使用される環境が様々

ソフトウェアを実行させるプラットフォームも様々

(31)

組込みシステムの特徴

用途

●家庭用電気機械器具(一般家電製品、デジタル家電) 炊飯器、洗濯機、エアコン、電話機、デジタルカメラ、テレビなどAV機器、ゲーム機、携帯電話 ●輸送機器 自動車のコントロールユニット、カーナビゲーションシステム、航空機、船舶、宇宙船、エレベーター、鉄道車両 ●産業用機器、機械設備 POSレジ、信号機、複写機、自動販売機、産業用ロボット、工作機械、ATM、人工衛星 ●医療用機器 自動血圧計、心電計、除細動器(AEDなど)、CT、MRI

規模

物理量(ハードウェア)を殆ど変化させずに機能(量)を変化させることが可能

用途・機能(規模)拡大

(32)

2013年度の取組み

組込み分野の課題

組込み分野の製品や機器は使用される環境が様々

ソフトウェアを実行させるプラットフォームも様々

「収集・分析の仕方を工夫」

製品分野共通の特性による整理

リアルタイム性の度合い、大小

自然環境からの影響度合い、大小

ユーザの多様性の度合い、大小

ネットワーク接続の有無

稼働の形態(非停止、オンデマンド)

(33)

収集データ項目

開発プロジェクトの特徴

・新規開発/派生開発、・新技術を利用する開発か否か

システム特性

・製品の特性、・(市販)パッケージ利用の有無、・CPUアーキテクチャ、 ・OSアーキテクチャ、・開発対象プラットフォーム、・開発言語

開発の進め方

・開発ライフサイクルモデル、・類似プロジェクトの参照の有 無、 ・ツールの利用有無

製品に強く要求される特性

・信頼性、・使用性、・性能・効率性、・保守性、・移植性、・ セキュリティ

開発要員の経験とスキルの習熟度

規模

工期

工数

・人月、・人時、・人月の時間数

開発体制

実施工程のパターン

品質

・検出バグ現象数、・検出バグ原因数、・品質保証の体 制有無、・品質基準の有無、・レビューの有無、・テスト 計画書の有無、・テスト計画書レビューの有無

プロジェクト評価(品質、納期、コ

スト)

(34)

分析項目

工数 と 工期の関係

規模 と 工数の関係

規模 と 発生不具合数の関係

(1) 結合試験、(2) 総合試験

規模 と 発生不具合密度の関係

(1) 結合試験、(2) 総合試験

規模 と テストケース数

(1) 結合試験、(2) 総合試験

規模 と テスト工期

(1) 結合試験、(2) 総合試験

等。

層別化の分類項目

・新規開発/派生開発、・製品の特性、

・CPUアーキテクチャ、

・OSアーキテクチャ、・開発言語、

(35)

分析結果の例(1) 「開発規模と工数の関係」

0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 0 1 0 , 0 0 0 2 0 , 0 0 0 3 0 , 0 0 0 4 0 , 0 0 0 5 0 , 0 0 0 6 0 , 0 0 0 7 0 , 0 0 0 実績工数 【 人時 】 SLOC実績値【SLOC】

主開発言語別の分類と

SLOC規模と工数(改良派生開発)

b:言語C c:言語C++ N=44 ◆ 言語C □ 言語C++ 開発規模(プログラム行数) 実績工数(人時) 主開発言語別の分類と 開発規模と工数(派生開発)

A

B

・言語による生産性の違い Aの部分をみると、C++言 語の方がC言語よりも生産 性が高いことがうかがえる が、母数が少ないため、今 後、もっと多くのデータを収 集して調べる必要がある。 一方、Bの部分をみると、 開発規模が小さいところで は、開発言語に関わらず 生産性にばらつきがあるこ とがうかがえる。 データ提供企業の募集に より、さらに多くのデータを 収集し、分析を進める必要 がある。

(36)

分析結果の例(2) 「開発規模とバグ密度の関係」

0 1 2 3 4 5 6 7 8 0 10 20 30 40 50 60 70 80 総 合 テ ス ト 検出バ グ密 度 【 件 /K SL O CSLOC実績値 【KSLOC】 SLOC規模と結合テスト検出バグ密度 (改良派生開発) N=59

N=57

開発規模(プログラム行数) 結合テスト検出バグ密度(件/ KSLO C)

開発規模と結合テスト検出バグ密度

(派生開発)

結合テストにおける バグ密度(単位規模 あたりの検出バグ件 数)からは、開発規 模が小さい部分で、 バグ密度にばらつき があることがうかが える。 母数が少ないため、 さらに多くのデータを 収集し、分析を進め る必要がある。

(37)

分析結果の例(2) 「開発規模とバグ密度の関係」

図2-2「開発規模とバグ密度の関係」(総合テスト)

0 1 2 3 4 5 6 7 8 0 10 20 30 40 50 60 70 80 総 合 テ ス ト 検出 バ グ密 度 【 件 /K SL OCSLOC実績値 【KSLOC】 SLOC規模と総合テスト検出バグ密度 (改良派生開発) N=54

N=46

開発規模(プログラム行数) 総合テスト検出バグ密度(件/ KSLO C)

開発規模と総合テスト検出バグ密度

(派生開発)

一方、総合テストにおけるバグ密度から は、結合テストに比 べて、開発規模に関 わらず、バグ密度が 0に集中していること がうかがえる。 これらの傾向から、 総合テストは、バグ が無いことを確認す るために行われてい ることがうかがえる が、母数が少ないた め、データ提供企業 の募集により、さらに 多くのデータを収集 し、分析を進める必 要がある。

(38)

組込みデータ白書公開までのスケジュール

2014年12月

・データ収集期限(WG参加企業から)

2015年 春

・WG参加企業向け限定版発行予定

2015年 秋

・公開版発行予定(書籍販売とPDF版ダウンロード)

(39)

ご参加いただける企業を募集いたします

統計処理ができるほどのデータ件数が必要

目標件数500件

⇒ 分析結果の信頼性を向上させるため

⇒ 分析の種類を拡大させるため

データ白書の利便性を向上

参加企業募集

(40)

活動の進め方

WG参加企業の利点

WG内限定の分析レポートを提供

WG参加企業独自の分析が可能なツールの利用

WGを設置し継続的改善を進める

※参加企業名と委員名は非公開

秘密保持契約締結

※厳重なデータの管理実施

(41)
(42)
(43)

Windows Server 2003のサポートが、2015年7月15日に終了します。

サポート終了後は

修正プログラムが提供されなくなり

、脆弱性を悪用した攻撃が成功す

る可能性が高まります。

サポートが継続しているOSへの移行検討とOS移行に伴う周辺ソフトウェアの

影響調査や改修等について

計画的に迅速な対応

をお願いします。

会社の事業に悪影響を及ぼす被害を受ける可能性があります

IPA win2003

検索

詳しくは

脆弱性が 未解決なサーバ

脆弱性を

悪用した攻撃

ホームページの改ざん 重要な情報の漏えい 他のシステムへの攻撃に悪用 業務システム・サービスの停止・破壊 データ消去

Windows Server 2003のサポート終了に伴う注意喚起

(44)

iパス

検 索

iパスは、IT化された社会で働く

すべての社会人が備えておくべき

ITに関する基礎知識を証明する国

家試験

です。

国家試験

公式キャラクター

上峰 亜衣

日本の元気

をiパスで!

(45)

Check! Catch!

Search!

参照

関連したドキュメント

「地方債に関する調査研究委員会」報告書の概要(昭和54年度~平成20年度) NO.1 調査研究項目委員長名要

であり、最終的にどのような被害に繋がるか(どのようなウイルスに追加で感染させられる

データなし データなし データなし データなし

海洋技術環境学専攻 教 授 委 員 林  昌奎 生産技術研究所 機械・生体系部門 教 授 委 員 歌田 久司 地震研究所 海半球観測研究センター

瀬戸内千代:第 章第 節、コラム 、コラム 、第 部編集、第 部編集 海洋ジャーナリスト. 柳谷 牧子:第

Advancement of a remote controlled laser cutting system for fuel debris in various configuration (in air, underwater, emerging, non emerging) and collection of dust and fumes

人類研究部人類史研究グループ グループ長 篠田 謙一 人類研究部人類史研究グループ 研究主幹 海部 陽介 人類研究部人類史研究グループ 研究員

パターン No.1:平穏な海域で AP オートモードで、舵角 2 度、1 分間に 2 回発生 パターン No.2:やや外乱の多い時、オートモードで、舵角 5 度、1 分間に