FC2ブログ

駆け出しエンジニアの気ままにブログ

このブログでは、駆け出しエンジニアの私が興味をもったトピックについて不定期に発信しています。

スポンサーサイト  

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

category: スポンサー広告

tb: --   cm: --

駆け出しエンジニアのプロジェクトマネージャ取得への道(2)~午前Ⅱ試験、傾向と対策(テクノロジ編)~  


情報処理教科書 [春期]高度試験午前I・II 2012年版情報処理教科書 [春期]高度試験午前I・II 2012年版
(2011/10/26)
松原 敬二

商品詳細を見る


今回はプロジェクトマネージャの午前Ⅱ対策として、試験問題の傾向確認『テクノロジ』分野の基本をまとめていきます。


午前Ⅱ問題は難しい問題はなく、基本技術者や応用技術者試験に出てきた内容を理解していれば合格点はカバーできそうです。

対策として、出題傾向を確認した後『テクノロジ』『マネジメント』『ストラテジ』分野から重要なものを抜粋してまとめていきます。

このブログと過去門演習で午前Ⅱ対策は十分なはず!


ということで、早速、出題傾向の確認の確認から実施します。

平成21~23年の午前Ⅱ試験問題は以下の通りとなっています。

◆出題傾向確認

問題 平成21年 平成22年 平成23年
1 コードインスペクション プロジェクト憲章(PMBOK) プロジェクト推進のための
事項
2 EVM COCOMO プロジェクト憲章(PMBOK)
3 ファンクションポイント法 プロジェクトスコープ記述書
(PMBOK)
プロジェクトスコープ
(PMBOK)
4 開発プロジェクトの工数 ガントチャート アローダイヤグラム
5 JIS X 0129-1
ソフトウェアの品質特性
クリティカルチェーン法ガントチャート
6 グラフ トレンドチャート クラッシング
7 文書の構成法 コスト分析 ファンクションポイント法
8 リスクマネジメントにおける
EVM算出方法
作業配分モデル JIS X 0129-1
ソフトウェア品質特性
9 デルファイ法 SPA グラフ
10 リスク事象と対応計画 JIS X 0129-1
ソフトウェア品質特性
話の展開順序
11 リスクの高い契約形態 ソフトウェアの保守性 教育技法
12 アクティビティとテスト
の組合せ
マクレガーのY理論 リスクマネジメント(EMV)
13 状態遷移図の特徴 グラフ デルファイ法
14 ハードウェア保守点検 定性的リスク分析
(PMBOK)
リスク対応戦略
(PMBOK)
15 プロセスモデル BPMN RFP作成時の留意点
16 リバースエンジニアリング 論理データモデル作成
におけるアプローチ
システム要件
(共通フレーム2007)
17 データベースサーバ
のハードディスク冗長性
クラス図 DFD
18 業務プログラムの
運用・保守
SOA CMMI
19 ITサービスマネジメント リバースエンジニアリング 保守プロセスにおける改修
(共通フレーム2007)
20 サプライチェーン
マネジメント
フェールソフト システム改善案
21 E-Rモデル ITIL ITIL
22 要件定義プロセス
(共通フレーム2007)
システムの非機能要件 PBP
23 プログラム著作権 情報システムモデル
取引契約書
システム化計画
立案時の作業
24 下請代金支払遅延等
防止法
労働者派遣法 ソフトウェア著作権
25 個人情報保護法 OCEDのプライバシー
保護ガイドライン
製造物責任法


PMBOK、共通フレーム2007の問題が多く、他にも基本情報技術者や応用情報技術者試験で聞いたような単語がほとんどではないでしょうか。

勉強をしている人であれば、いきなり過去問題をやっても合格点を取れるかと思いますが・・・

以下、自分の備忘録も兼ねて『テクノロジ』分野からテスト頻出問題の基本をまとめていきたいと思います。

◆ソフトウェア要件定義

DFD
DFD(Data Flow Diagram:データフローダイアグラム)は、データの流れ(データフロー)とプロセス(処理)の関係を整理する技法です。 物の流れやお金の流れについては検討の対象から外し、データ中心にシステムを図式表現します。図形表現に用いる記号は以下の4つ。

記号名称説明
外部データの発生源(源泉)、または行き先(吸収)
処理データの加工(機能)
データフローデータの流れ
データストアデータの蓄積


fig_dfd

E-R 図
E-R 図(Entity-Relationship Diagram:ERD)は、エンティティ(実体、データ)間の関連を図示する図法で、エンティティを□、エンティティ間の対応関係を矢印(→、←、⇔、―)で表します。

fig_er

UML
UML(Unified Modeling Language:統一モデリング言語)は、オブジェクト指向システムの設計結果を視覚化し、文章化するために用いられる言語です。 言語とはいいますが、一般のプログラム言語とは異なり、図式表現の技法。UMLでは、次に示す図を定義します。

名称説明
ユースケース図システムが提供する機能を表現
クラス図クラスなどの関連(データ構造)を表現
ステートチャート図オブジェクトの状態遷移を表現
アクティビティ図アルゴリズムを表現
シーケンス図オブジェクト間の相互作用を表現


◆モジュール設計

モジュールの独立性
モジュール設計において、信頼性、保守性を向上させるためには、モジュールの独立性を高める必要があります。 モジュールの独立性を評価する基準に、モジュール強度とモジュール結合度があります。 モジュール強度は、モジュール内部の関連性の大きさ(強さ、高さ)を示す尺度で、モジュール内部の関連性が強い(高い)ほどモジュールの独立性は高くなる。 モジュール結合度は、モジュール間の関連性の大きさ(強さ、高さ)を示す尺度で、モジュール間の関連が弱い(低い)ほど、モジュールの独立性は高くなる。

モジュール結合度内容
データ結合処理に必要なデータを受け渡す。呼び出し側も呼ばれる側も機能的な関係はない。
スタンプ結合データの構造体を引数として受け渡す。呼ばれたモジュールでは、構造体の一部を使用する。
制御結合機能コードを引数としてサブプログラムに渡し、サブプログラムの実行に影響を与える。
外部結合外部宣言したデータを共用する。共通結合との違いは、必要なデータのみ外部宣言することである。
共通結合共通領域に定義したデータ構造(配列や構造体で定義したデータ)を、複数のモジュールで共有する。
内容結合あるモジュールの内容を、直接、参照、利用する。他のモジュールのデータを誤って破壊する可能性が高い。

モジュール強度内容
暗号的強度プログラムを機能的ではなく単純に分割したり、重複する機能をまとめたもので、モジュール内の機能間には特別の関係はない。
論理的強度複数の機能をもったモジュールで、パラメタ(引数)の条件などで処理を選択する。
時間的強度特定の時期に実行されるモジュールをひとまとめにしたもので、複数の機能を逐次的に実行する。初期設定モジュールなどが該当する。
手順的強度複数の逐次的な機能を実行するモジュールで、モジュール内の関連性が強いため、各機能を単独で実行することはできない。
連絡的強度複数の逐次的な機能を実行する点は手順的強度と同じであるが、機能間でデータの受け渡しがある。
情報的強度同一データ構造を取り扱う複数の機能を1つのモジュールにまとめたもので、機能ごとに入口点と出口点をもち、機能ごとに呼び出すことができる。
機能的強度1つの機能からなるモジュールで、命令はすべて1つの機能を実現するためにあり、強い関連性を持つ。

fig_v

再利用技術
再利用技術は、既存のソフトウェアを再利用する技術のことです。再利用技術の方法には、次のものがある。
1)リエンジニアリングによるプログラムの生成
2)ソフトウェアの部品化
3)オブジェクト指向設計によるクラスライブラリ
オブジェクト指向のカプセルかは、手続き(メソッド)とデータを一体化し、外部に対しては必要な情報だけを与えることによって独立性を高める方法です。

リバースエンジニアリング
リバースエンジニアリングは、既存システムを解析し、設計技術を抽出する技術。既存システムの設計者とは別の人が、その内部使用を解析する。 たとえば、高級言語などで書かれたソースプログラムしかないシステムから、ソースプログラムを解析し、モジュール構造図、画面仕様、ファイル仕様などの設計レベルの文章を作成し、そのシステムの仕様を導く。

リエンジニアリング
リエンジニアリングは、リバースエンジニアリングとフォワードエンジニアリングをともなうエンジニアリング。 リバースエンジニアリングで得られた結果を基に、必要な仕様を追加し、新しいシステムを開発する。 新しくシステムを開発する工程を、フォワードエンジニアリングという。

リファクタリング
リファクタリングは、プログラムの保守性・再利用性を高めることを目的に、そのプログラムの提供する機能・仕様を変えることなく、内部構造を再構築(リストラクチャリング)するプログラミング技法。


◆ソフトウェア品質管理

レビュー
レビューとは、作業工程の区切りをつけるもので、各開発工程で作成された文書を会議形式で内容の検証を行うこと。 利用部門、品質保証部門、管理部門、開発部門など、種々の立場の人が参加し、参加者は、それぞれの観点から文書と作業内容を検証する。

レビューには、ウォークスルーやインスペクションなどがある。
ウォークスルーは相互検証という性格をもっており、会議の進行役は出席者の中から選出される。インスペクションは、モデレータという責任者の下に組織的に実施される。
ラウンドロビンレビューはレビューの一種で、目的や特徴も一般のレビューと同じ。また、プログラムのコードをレビューすることをコードインスペクションという。

成長曲線
ソフトウェアのバグ累積件数は、ロジスティク曲線やゴンペルツ曲線などの成長曲線(バグ曲線)と呼ばれる曲線で近似できることが経験的に知られている。 バグの発生件数は最初は時間の経過のわりに少なく、その後、次第に増加するが最後は再び減少し飽和状態となる。これによって、バグの発生を予測できる。

fig_seichou


以上です。

『テクノロジ』分野といっても、プロジェクトマネージャの午前Ⅱでは、ソフトウェア開発関連に特化したものになっています。

量も多くないので、さーっと復習して、過去問演習や、午後Ⅰ試験・午後Ⅱ試験への取っ掛かりにしていただければ幸いです。

今回も最後までお付き合いいただき、ありがとうございました m(_ _)m

(2012年02月22日)




スポンサーサイト

category: 資格対策(PM)

tb: 0   cm: 0

コメント

コメントの投稿

Secret

トラックバック

トラックバックURL
→http://kazufumi1984engineer.blog.fc2.com/tb.php/33-d7b0f7e6
この記事にトラックバックする(FC2ブログユーザー)

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。