先進的な設計・検証技術事例にみる開発技術のトレ …"g #/²&gFþ w! G #.Fû...

Software Reliability Enhancement Center© 2014 IPA, All Rights Reserved

ET2014

2014年11月19～22日

独立行政法人情報処理推進機構（ＩＰＡ）

技術本部ソフトウェア高信頼化センター（ＳＥＣ）

室修治

先進的な設計・検証技術事例にみる開発技術のトレンド

2© 2014 IPA, All Rights Reserved Software Reliability Enhancement CenterET2014

情報システムの障害状況

SECjournal38号より


2014年4月の障害 1


2014年4月の障害 2


2014年4月の障害 3 組込系？


製品等動向


先進的な設計・検証技術の適用事例報告書2013年度版

http://www.ipa.go.jp/sec/reports/20140530.html

設計・検証事例24件を採録

設計・検証に関する先進的な適用事例を紹介したものであり、導入上の工夫や効果等も記載しており、今後の導入の参考になるもの


事例（1/3）：車載

先進運転支援システム、HV車、EV車、燃料電池車など、車載ECUの役割は増大し、ますます複雑化しています。ECUの開発現場では品質確保が絶対条件の使命であるが、設計時に予測しなかった問題が検証時に見つかることも多く、後戻りのコスト／期間の問題、市場への不具合流出のリスクなど、多くの課題を抱えています。この課題を克服するために、上流品質の向上が叫ばれています。上流品質を向上するための手法の一つとして、シミュレーション技術を活用したモデルベース開発があります。


実機/メカモデル

ソフトウェア検証

HILS コントローラ

ソフトウェア設計モデルでのシミュレーション結果と同様の実行結果が得られることを検証

プログラム作成

（自動コード生成）


適合・評価

ソフトウェア設計

システム設計

Simulink

モデル

Simulink

モデルSimulink

モデル

実機/メカモデル制御モデル

シミュレーションが可能なシステム設計モデルを作成

システム設計

制御モデル


システム設計モデルから制御モデルを抽出し、自動コード生成可能なソフトウェア設計モデルを作成

ソフトウェア設計モデルからの自動コード生成

制御モデル


実機検証（適合・評価）

実機/メカコントローラ

実機による検証／評価

◆モデルベース開発の利点／導入効果（１）

シミュレーション導入による

◆設計品質の向上

◆後戻りの軽減

【設計工程】









適合・評価


システム設計

Simulink

モデル

Simulink

モデルSimulink

モデル



システム設計

制御モデル




制御モデル





◆モデルベース開発の利点／導入効果（２）

【プログラム作成工程】

自動コード生成による

◆正確なプログラミング

◆ヒューマンエラーの低減

◆飛躍的な生産性向上









適合・評価


システム設計

Simulink

モデル

Simulink

モデルSimulink

モデル



システム設計

制御モデル




制御モデル





◆モデルベース開発の利点／導入効果（３）

【検証工程】

リアルタイムシミュレータの導入により

◆設計時に作成したモデルを活用

◆検証項目のデータ化による正確な検証

◆検証の繰り返し／自動化を実現

◆レアケースの検証の実現

◆ログ出力による確実な検証


◆モデルベース開発の効果

◆レガシー開発では、ソフトウェア作成～システムテストの工数が

６２％を占有

レガシー開発


ソフトウェア作成／単体検査

ソフトウェアテスト

システムテスト

開発工数短縮

モデルベース開発導入後《当社比》

システム設計

システム検討


システム設計

システム検討




ソフトウェア開発工数

62%

37%《参考値》

◆モデルベース開発は、ソフトウェア作成～システムテストの工程で

劇的な開発工数短縮


◆モデルベース開発の効果

◆モデルベース開発による品質向上効果とプロセス改善が

最も重要なポイント

レガシー開発





開発工数短縮

モデルベース開発導入後《当社比》

システム設計

システム検討


システム設計

システム検討




ソフトウェア開発工数

62%

37%《参考値》

◆モデルベース開発における設計プロセスが課題であり

最も大きな効果を得られる鍵となる

課題


事例（2/3）：HMI品質メトリクス開発

開発背景• 組込みシステム開発でユーザビリティを向上には、後工程でユーザビリティテスト

の実施が必要だが、開発期間の短縮やソフトウェアの不具合の発生頻度も高く、実施できない

• 上流工程の段階で開発者がユーザビリティを評価することは、難しい


HMI品質メトリクス開発

開発目的上流工程での仕様開発を対象に、ユーザビリティの知識を持たない設計者が、客観的にユーザビリティの良し悪しを判断できるようなHMIメトリクスを開発し、HMI品質を確保すること



開発プロセスHMI品質メトリクス開発の全容は、以下4つのステップで構成

■ 成果物の定義■ ユーザビリティスコープ定義■ 開発ボリュームの把握

■ メトリクスの開発■ 実製品での評価■ 不足観点分の開発

定義したスコープと分量をもとに、メトリクスを開発する

開発したメトリクスが上流工程の各開発担当者に使える状態を目指す

試行したメトリクスを本格運用させる

■ 開発体制への調整■ メトリクス教育■ 運用ルール

■ 本格運用

システム開発の評価で必要となるユーザビリティの全体像を把握する

運用・展開試行期間メトリクス開発スコープとボリューム

Step1 Step2 Step3 Step4



開発プロセス

目的・システム開発の上流工程でユーザビリティ評価に必要となる項目の全体像を把握

方法・ユーザビリティ評価項目のスコープ定義する・システム開発の分業体制に応じた必要量のボリュームを調べ、開発案件を把握する




■ 本格運用



(1)理解性知覚

見やすいか

01 文字が読みやすいか

04-01-01視認性の高いピクトグラムの大きさ

08-05-01視認性の高いピクトグラムの大きさ

05-01-02 理解しやすい１文の文字数

05-01-03一画面において把握できるアイコンの量

04-01-02 視認性の高い文字の大きさ

02 比喩が用いられているか03 警告音が聞き取りやすいか04 音の種類の区別がつくか

触ってわかるか 05 触って区別がつくようになっているか08-05-0208-05-0308-05-0408-05-05

ブラインド操作しやすいスイッチの提供

08-05-01ステアリングスイッチの形状から操作が分かる

08-05-06操作可能ではない方向にもフィードバックを持たせる

情報の区別がつくか 06 テキストとアイコンの区別がつくか

04-06-01画面タイトルを表示するエリアが、その他のエリアと明確に区別できる

07 ボタンは立体的に表示されているか

08 操作できないボタンはグレーアウトしてあるか（※GUIのみ）

05-08-03注意の向きやすいポップアップ表現

09 文字と背景のコントラストは十分か

アクティブ・非アクティブ

08-09-01適切なフォーカス表現のボタンを提供する

10 表示されている情報の量は適切か

04-10-01判断が容易にできる、項目間に情報の差異があるリスト表示

判断に時間がかからない選択項目数

11 字間や行間は適切か

04-11-01 可読性の高い行間の提供

（未付番）画面上で関連する表示情報の群化

（未付番）画面上で関連する表示情報の群化

- -

- -

- -

- -

04-13-01混在していても違いの分かる線分の表現

04-13-02 線に注意を向けさせる表現

情報が強調されているか 14 利用可能なボタンが強調されているか -

08-14-01タッチの反応領域に一致したボタン設計

15 操作できるウィンドウが強調されているか（※GUIのみ）

04-16-0104-16-02

強調表示目立つ警告表示の提供

関連項目(13-19-01 スピーチUIの機能提示)

17

機能が用意されているか 18 ヘルプ・マニュアルが用意されているか 08-18-01

音声認識画面にはガイダンス機能を用意する

12-17-01ドライバーに不明な用語へのヘルプ情報の提供

12-17-01ドライバーに不明な用語へのヘルプ情報の提供

19 警告・確認画面が用意されているか09-19-0109-19-0209-19-0309-19-0408-19-01

10-19-0109-19-05

・適切な時間でのフィードバック・把握しやすい操作結果の通知・処理状態の表示の有無・処理の進捗状況表示の有無・処理に時間がかかる操作について、処理完了まで待たせない・キャンセルボタンの有無・処理に時間がかかる操作について、確実に通知方法を提供する

ボタンレイアウトは目立つ場所や操作手順に沿って配置されているか

ボデー系汎用CL

大分類

16

12

管理番号タイトル

重要な情報が強調して表示されているか

不要な情報が表示され、情報が埋もれていないか

中分類小分類チェック項目

聞き取りやすいか

13

ヘルプ・ガイダンス

スコープと開発案件のボリュームの明確化



開発プロセス

目的・Step1で定義した開発案件をもとに、メトリクスを開発する

方法・開発はユーザビリティの観点を、品質特性、属性、尺度、測定方法に落とし込む・精度は、実機評価を通じて、ユーザビリティ専門家による評価結果と同等の効果を確認する・評価で観点の不足を確認した場合、追加開発する




■ 本格運用



評価不足分の開発

開発



開発プロセス

目的・Step2で開発したメトリクスを上流工程の各開発担当者が運用できる状態にする

方法・開発担当者を巻き込んで試行し、運用上の問題点の抽出と改善を繰り返す

- 各開発担当者へのメトリクス導入教育- メトリクスの有効性向上- ガイドラインの作成- 開発体制への導入マネジメント




■ 本格運用



メトリクス

ガイドラインの作成

開発者による評価

仕様メトリクスの修正



開発プロセス

Step3で試行したメトリクスを、開発工程に組み込み本格運用する




■ 本格運用



メトリクスガイドラインチェックシート

仕様観点

要求仕様書要求分析

問題点一覧仕様作成仕様

仕様担当

メトリクス

顧客に問題点を

報告

ユーザビリティを満たした仕様になる


事例（3/3）：車載

環境・法規

車両レベル

システムレベル

システムユニットレベル

機能レベル

単体レベル（単機能・単一API）

実装レベル

詳細設計

駆動

制御

姿勢

制御

車両レベル妥当性確認

車両要求仕様

システム要求仕様

システムレベル妥当性確認

単体テスト設計

システムデバッグ・調整

実車調整

システムユニットデバッグ

機能デバッグ

単体デバッグ単体テスト

機能テスト

システムユニットテスト

受入テスト

実車テスト

実装・デバッグ・静的解析

システムユニット妥当性確認

システムユニット要件定義

機能設計機能テスト設計

自動車メーカー担当範囲

Tier1担当範囲

Tier2担当範囲

テスト要求分析～テスト設計



自動車メーカーとサプライヤの役割分担従来の開発方法のWモデル表現


従来型の「すり合わせ開発」での状況

開発中に、Tier1のシステム要件・仕様確定に関与

担当者間での暗黙的な合意形成

仕様書に反映されない仕様が発生

確定した要求仕様とシステム仕様との整合が必要（手戻り）

整合結果を残さないと暗黙的で曖昧な仕様書になる

調達条件となる要求仕様が明確に定義されない

複数サプライヤへの標準的な要求仕様にはならない

システム要求仕様の詳細を明文化していないため


従来型開発における課題

環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動

制御

姿勢

制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1担当範囲

Tier2担当範囲




暗黙的な要求仕様による暗黙的な保証範囲が存在

実車テストで問題が無いことも暗黙的に含まれている

サプライヤへの要求はシステムレベルだが・・・



環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動

制御

姿勢

制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1担当範囲

Tier2担当範囲




Wモデルの作業分類と現実の作業範囲が異なる

本来の作業分類の境界

明確に定義されていない作業は、役割や責任が曖昧



環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動

制御

姿勢

制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1担当範囲

Tier2担当範囲




要求仕様の粒度が不揃い

要求内容やサプライヤによる要求仕様の粒度の差異

受入試験項目の粒度も不揃いとなり、品質の安定的確保が困難



環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動

制御

姿勢

制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1担当範囲

Tier2担当範囲




システム検証項目の設計が属人的なスキルに依存

明文化されないシステム詳細を、熟練技術者の知見でテスト設計

漏れは少ないと考えられるが、その確認が出来ず、定型化が出来ない



環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動

制御

姿勢

制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1担当範囲

Tier2担当範囲




追跡性（トレーサビリティ）を確保できない

要求仕様～要件定義・機能仕様～システムテスト～受入テストを紐付けられない

開発状況や品質状況の確認が困難


課題対策の仮説

• 暗黙的な要求仕様による暗黙的な保証範囲が存在

要求仕様の明確化にUSDMが使えるのではないか

• Wモデルの作業分類と現実の作業範囲が異なる

検証プロセスを整備することで改善出来るのではないか

• 要求仕様の粒度が不揃い

USDMとテスト設計技術の活用で改善出来るのではないか

• システム検証項目の設計が属人的なスキルに依存

要求仕様の明文化とテスト設計技術の活用で改善出来るはず

• 追跡性（トレーサビリティ）を確保できない

上記実現により改善出来るはず（ツール利用は別として）


USDMによる要求仕様を明確化

USDM記述方式の特徴

• 要求を数段（通常は2～3）の階層構造で定義

• 定義された要求に対して、その要求が必要な理由を記述

• 理由を併記することで、解釈の取り違えを抑止することができる

• 階層化した最下層には、要求の仕様（振る舞い）を記述

• 要求および仕様（振る舞い）には、ID を割り付け

（赤）要件合意（黄）機能仕様書確認（青）受入試験結果

（緑）実車テスト結果

< 異常系 >

手動作動要求 S-REQ010 （要求内容を記載）

（例）AAAA機能の作動状態・故障状態に応じたランプ点灯要求をおこなう

理由（要求の理由について記載）

（例）AAAA機能の作動状態・故障状態をドライバーに通知するため

説明（補足説明があれば記載）

S-REQ010-N02 (例)AAAA機能が正常に停止している状態では、AAAA作動灯を消灯する

< 正常系 >

S-REQ010-N01 （要求内容をさらに仕様レベルまでに分割した要求仕様を記載）

(例)AAAA機能が正常に動作している状態では、AAAA作動灯を点灯する

S-REQ010-E01 (例)AAAA機能が正常に動作中に、故障が発生したときは、AAAA作動灯を点滅する

記述内容と質が揃い易い

各仕様項目に受入検証項目を設定すると効果的・テスト設計により網羅性を高め要求の漏れを防止・サプライヤへのテスト要求の明確化


検証プロセスの整備、テスト設計技術の活用

環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動

制御

姿勢

制御





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






車両要求仕様

VV

要求分析

計画設計実装実行

要求分析


要求分析


システムレベルValidation

車両レベルValidation

VシステムレベルVerification

V車両レベルVerification

開発・検証業務フロー、役割分担ドキュメント

検証設計のテンプレートや適用するテスト技法の整備

システムレベルや車両レベルのテスト観点を分類

Validation & Verification のプロセスを適用


Validation & Verification（V&V）

決めたモノを作っているか仕様通りに作っているか

決めたモノは正しいか要求を実現できる仕様・設計か

要求に応えられる性能か

決めたコトをやっているかプロセス・手順通りに実施しているか

決めたコトは正しいか目的を実現できるプロセスか

正確で効率的な手順か

仕様・性能テスト項目

検証要求妥当性確認

プロセス・手順

チェックリスト目的

プロダクト

プロセス

Validation：正しいものを作っているか

Verification：正しく作っているか

妥当性確認検証


V&V作業項目概要

プロダクト

プロセス

Validation：正しいものを作っているか

Verification：正しく作っているか

システムの検証テストアーキテクチャ設計（テスト環

境）

テスト環境構築

テスト実装

検証実行

検証評価・報告

要求仕様の妥当性確認

V&V要求分析

テストアーキテクチャ設計

テスト詳細設計

妥当性確認実行

妥当性確認評価・報告

V&Vプロセスチェックリスト

作業チェックリスト

V&Vプロセス構築 V&Vプロセスフロー

ドキュメントフォーム

ガイドライン


要求仕様明確化に向けた対応

曖昧な要求（要求仕様）

明確にされた要求（要求仕様）

非属人的な要求仕様の作成

要求の漏れ防止

USDM適用で曖昧記述を除去

テスト設計技法の適用で要求項目の漏れを防止

項目の体系化 Wモデル、検証観点の適用で階層化による整理

トレーサビリティにも有効


課題に対する取り組み内容の効果

取り組み内容

課題

USD

M

の活用

ガイドラインの作成

V&

V

プロセスの整

備テスト技術による要

求の整理

要求に対する受入試

験項目設定

第３者による要求仕

様作成

暗黙的な要求仕様による暗黙的な保証範囲が存在○ ○ ○ ○ ○

Wモデルの作業分類と現実の作業範囲が異なる○ ○ ○ ○

要求仕様の粒度が不揃い ○ ○ ○システム検証項目の設計が属人的なスキルに依存

○ ○ ○ ○ ○

追跡性（トレーサビリティ）を確保できない○ ○ ○ ○ ○

開発技術者の負荷を増やさない ○


取り組み結果からわかったこと

要求仕様を明確にすること、要求項目を体系的に整理することは、複数の課題に有効であるということ

逆に、要求項目の体系的な整理の妥当性が、課題の解決度合いに影響するとも言える

一つの課題を解決するためには、複数の施策が必要であるということ

各課題が複数の問題を含んでいる、または問題が絡み合っていることによるかも知れない

要求仕様書は、要求者以外の第３者でも作成が可能であるということ

暗黙的な技術を明確にするという面でも有効である


まとめ：日本のシステムズ開発の様々な課題

システムの複雑化に伴う課題

システムの派生やシリーズ化に伴う課題

要求の不適切な分析／定義に伴う課題

要求変更への対応に伴う課題

大きな手戻りの発生に関する課題

関係者間のシステム開発に対する意識の統一や均質化に関する課題


ソフトウェア開発の「成功」とは？

『予想可能なスケジュールと予算の範囲内で、エンドユーザーのニーズを満たす品質の高いソフトウェアの開発が行われること』

参考：RUP/PMBOK/CMMI


MBSE把握のキーワード

全体最適

超上流ーユーザー要求から設計要求まで

把握と合意

システム「ズ」エンジニアリング

分割統治とフィードバックループ

4側面からシステムを捉える

候補から根拠を持って1つを選ぶ


システムズエンジニアリングとは？

システムを成功裏に実現するための複数の分野にまたがるアプローチおよび手段

システムズエンジニアリングでは、開発サイクルの初期の段階で顧客のニーズを明確化し、機能要求を定義し、関連する問題をすべて考慮しながら設計のための総合とシステムの妥当性確認を進める

システムズエンジニアリングでは、ユーザーニーズに合致した品質の製品を供給することを目的とし、ビジネスとすべての顧客の技術的要求の両者を考慮する


システム「ズ」エンジニアリング

「システムとは、定義された目的を成し遂げるための、相互に作用する要素（element）を組み合わせたものである。これにはハードウェア、ソフトウェア、ファームウェア、人、情報、技術、設備、サービスおよび他の支援要素を含む」

INCOSE システムズエンジニアリングハンドブックの定義

ソフトウェアエンジニアリングだけのためのものではない

なのに、なぜSW業界で話題になっているのか？→ 大規模/複雑なシステム開発のキーはSWだと言われているから


MBSEは、システムズエンジニアリング（SE）の一種

SEとは、コスト、スケジュール、リスクの制約下で、利害関係者の期待に応える「システム」を作り上げるための工学知識の体系

要求に合致したシステムを効率的に開発していくためのプロセスや手法についての体系的かつ実践的な指針


超上流ーユーザー要求から設計要求まで

MBSEの活動を一言で言えば、

①要求をまとめ

②アーキテクチャを設計し

③実現工程それぞれに、必要十分な材料を渡す

そして合意はとれた？


部分最適の総和は全体最適なのか？

部分最適とは、ある狭い範囲（見える範囲、考えられる範囲、できる範囲）の行動を最適にすること

市場原理とは、「各人が自己の利益の最大化をめざせば、社会全体の利益も増す」という経済学古典派の概念

合成の誤謬

オイルショック

3.11時の買い占め

「欲しがりません、勝つまでは」

囚人のジレンマ合意があれば、状況は変わる


分割統治とフィードバック・ループ

システム・エンジニアリングの最大の特徴

複雑なシステム開発では、上位レベルの問題点が下位レベルの細部検討時に明確になるという事実

⇒ サブシステムの設計時に気付いた問題点に基づき、前工程の成果であるシステム設計を見直すことが可能な「フィードバック・ループ」が必要。

「フィードバック・ループ」こそ、より品質の高いシステムを作り上げるためのSEの中核プロセス。

戻ってよし。ただし、手遅れになる前に


MBSE導入の３つの効果

製品開発プロセスへの効果

多人数開発への効果

複数製品開発への効果


製品開発プロセスへの効果例

欠陥を早期発見することによって、製品化の時間を短縮し、開発費を抑え、出荷にかかる時間を短縮する

会社効果主な理由

防衛システム開発（米）

製品化時間４０％短縮信頼性・安全性向上

明確なサブシステム間インターフェース定義開発初期の実行可能なプロトタイプ作成

General Motors 通常5年かかる新車開発を29ヶ月で

モデル駆動開発サブシステム間コミュニケーションの視覚化シミュレーションによるモデルのテスト

鉄道設備会社（豪）国際的分散開発プロセスを国ごとの安全性基準に適合

要求と設計の整合性を保つ環境の準備


多人数開発への効果例

効果的な要求管理とそれに基づいた基本設計の実施による開発効率化


Astrium(EU) 容易な情報の発見、様々な開発活動の一貫性保持、容易なコミュニケーション

文書ベースのSEをMBSEに

コンシューマ・エレクトロニクス開発（日）

国際的分散開発のための機能アーキテクチャの単純化開発手戻り防止

複雑度を下げるための抽象的なサブシステム（Cabity）を定義


複数製品開発への効果例

再利用の単位を明確にするとともに、車輪の再発明を防止し、無駄な再利用を減少させることで、効率よく製品系列の製品群を開発する


iPLON GmbH(独) 25%の障害減少開発時間が5ヶ月→2ヶ月＆10,000ユーロの開発費節約（製品ごと）

MBSEと、UMLを用いたソフトウェア開発を組み合わせ、要求分析からテストまで一貫してモデルを用いる開発プロセスを構築

テレマティックスサービスプロバイダ（米）

30 日以内で提供サービスを変更し、ビジネス急速立ち上げすることが可能に

ビジネス要素と、オープンテクノロジーを組み合わせたビジネスインフラの構築

FORD（米）技術要素のベースライン構築（モデルベースの再利用）

PLM、ALM、要求、アーキテクチャを結合


収集事例からのまとめ

（１）V字モデルのプロセスにおける左辺の活動の成果が、右辺の検証の成果にポジティブに影響する。

（２）左辺の活動としては、要求の早期獲得のみならず、より厳密な獲得が以降の活動における手戻りを減少させる。

（３）結果として、左辺において、その中でもより上流、即ち要求獲得及び定義、更にそれをベースとした仕様記述への工数のシフトが起こる。

（４）要求獲得及び定義、更に仕様記述に関わる活動として、モデル化及びモデルの実行あるいはシミュレーションが行われる。

（５）結果として、上流における品質の作り込みが開発プロセス全体における手戻りを減少させると共に検証への工数を削減させ、生産性が向上する。

（６）更に、リリース時の品質も向上する。

共通フレーム2013より


事例の募集

今年度も設計、検証の事例を募集しています。

ぜひご協力ください。


Windows Server 2003のサポートが、2015年7月15日に終了します。サポート終了後は修正プログラムが提供されなくなり、脆弱性を悪用した攻撃が成功する可能性が高まります。

サポートが継続しているOSへの移行検討とOS移行に伴う周辺ソフトウェアの影響調査や改修等について計画的に迅速な対応をお願いします。

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

IPA win2003 検索詳しくは

■WindowsXPを利用されている方は、サポートが継続しているOSへの移行検討をお願いします

脆弱性が未解決なサーバ

脆弱性を悪用した攻撃

ホームページの改ざん

重要な情報の漏えい

他のシステムへの攻撃に悪用

業務システム・サービスの停止・破壊

データ消去

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

IPA XP移行検索


ｉパス検索

iパスは、IT化された社会で働くすべての社会人が備えておくべきITに関する基礎知識を証明する国家試験です。

国家試験

公式キャラクター

上峰亜衣

日本の元気をiパスで！


Check！Catch！

Search！

Click！

先進的な設計・検証技術事例にみる開発技術のトレ …"g #/²&gFþ w! G #.Fû...

Documents

Transcript of 先進的な設計・検証技術事例にみる開発技術のトレ …"g #/²&gFþ w! G #.Fû...

先進的な設計・検証技術事例にみる 開発技術のトレ …"g #/²&gFþ w! G #.Fû...

Documents

Transcript of 先進的な設計・検証技術事例にみる 開発技術のトレ …"g #/²&gFþ w! G #.Fû...

先進的な設計・検証技術事例にみる開発技術のトレ …"g #/²&gFþ w! G #.Fû...

Transcript of 先進的な設計・検証技術事例にみる開発技術のトレ …"g #/²&gFþ w! G #.Fû...