情報処理技術者試験☆合格への道

ライフワークとしての資格取得ブログ presented by Pman






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

にほんブログ村 資格ブログ 国家試験へ にほんブログ村 資格ブログ IT系資格へ
 にほんブログ村 資格ブログへ
 ブログの殿堂
資格・スキルアップ Ranking  ナレコム おけいこブログランキング

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

SEO対策・SEOとは
IT  資格  ブログ
受験  日記  合格  論文


最近の記事


リンク集




自己紹介など

    くつろぐ

  • ニックネーム:Pman
  • プロフィール:
     情報処理サービス会社に勤務。主に金融業のソフトウェア開発、システム運用・保守を担当。メインフレームからオープン系まで広く浅く経験。資格取得はライフワークとなりつつある。
    保有資格
    システム監査技術者
    プロジェクトマネージャ
    アプリケーションエンジニア
    テクニカルエンジニア(システム管理)
    ネットワークスペシャリスト
    情報処理技術者(一種、二種)
    電気通信主任技術者(第一種伝送交換)
    工事担任者(デジタル第1種)


  •  質問、要望、感想、応援などは
     下のメールフォームから、直接
     私あてに送ることができます。


     当ブログはリンクフリーですが、
     リンクした場合は、メール又は
     コメントで知らせていただくと
     ありがたいです。

メールフォーム

名前:
メール:
件名:
本文:

広告エリア2












スポンサーサイト

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

論文対策1回目 下書き

 私が一昨年に準備していた論文を、ほとんど原文のままアップする。前々回の記事で「これじゃ受からん」と感じた論文である。いったい何がダメなのか考えてみてほしい。これを下書きとして修正したものを、追って掲載する予定。

<平成13年 問3>

1.プロジェクト概要とテスト計画(設問ア)
1.1.プロジェクトの概要
 A社は、個人住宅ローンを主力商品の一つとする金融機関であり、関東中心に約200店舗を展開している。長引く不況の中、A社では経営基盤の強化策として、システムを再構築することになった。再構築の目標は、オンライン端末による審査、承認、決済等の業務を効率化し、顧客サービス向上とコスト削減を図ることである。
 私の勤務するソフトウェア会社B社は、十数年前からA社システム開発を手掛けてきた。そのチーフリーダを経験してきた私は、今回の再構築プロジェクト立ち上げにあたりB社取締役から権限を委譲され、プロジェクトマネージャに任命された。
1.2.確認項目とその判定基準
 当プロジェクトを成功に導くための必須条件は、審査チェック機能の品質確保と考えた。その理由は、住宅ローン申込から承認までの時間がかかり過ぎるとの苦情を受けたA社が、審査方法を簡略化する方針を定め、これをシステム化要件の骨子としたからである。以上を考慮し、私はテスト計画に次の事項を盛り込んだ。
(1)確認すべき項目
 工程完了毎に品質を確認するため、下記レベル毎にテストの不良摘出件数を定めた。また、不良累積グラフを日々更新し、予定実績管理を遂行した。
 1審査チェック機能の改造部分(単体レベル)
 2審査チェック機能の非改造部分(結合レベル)
 3審査チェック機能の他機能連携(全体レベル)
(2)判定基準
 B社開発標準をもとに不良の目標件数を、上記1では63件、2では28件、3では7件と設定した。開発標準では規模当たりの不良件数を定めており、過去の実績から、信頼できる数値であると私は判断した。

2.テスト段階における品質確保の方策(設問イ)
2.1.テスト実施状況
 単体テストは不良55件で完了し、判定基準を満たしたと判断した。この段階で10件以内の増減は許容範囲と設定していたからである。ところが、非改造部分を含む結合テストは、まだ半分を消化していない段階で、不良件数が目標値28件を超えていた。
2.2.判定基準を満たさなかった原因分析
 結合テストの状況から、品質上の問題があると私は考え、早急に原因を分析した。分析方法は、審査チェック機能のどの部分に不良が多いのか傾向を調べるため、パレート図を用いることにした。チェック仕様は、顧客情報、日付情報、資金情報、物件情報の4グループに分かれ、それぞれのグループはさらに単項目チェックと項目間関連チェックに分かれる。これらをパレート図で分析した結果、資金情報・関連チェックでの不良が全体の約7割を占めていた。
 この部分で不良が多い原因を調査するために、私は仕様の再確認を行うよう設計者に指示した。また、仕様の不備を発見しやすくするために、他の有識者にも協力してもらった。調査の結果、単項目チェック仕様の変更による関連チェック仕様への影響が完全に洗い出されていなかったことが判明した。資金情報は変更項目が多いうえに設計の難度が高いことも、不良が作り込まれた要因であると分析している。
2.3.分析結果に基づく施策
 上記の結果から私は、当プロジェクトの品質を確保するために、以下に示す対策を実施した。
(1)体制の見直し
 最初に、プロジェクト体制を見直し再編成を行った。前述のような不良の傾向は、管理者である私が各要員の能力を的確に把握できていなかったことに起因すると考えたからである。
 再編成にあたっては、結合テスト残期間に限り、審査チェック機能に割り当てる要員の増強を図った。増員メンバ2名は、審査チェック以外の他機能を担当していたが、2名とも高スキルであったため、既にテストを完了していたからである。私はこの2名を、作業負荷が大きく難度の高い資金情報に追加した。不良の摘出および不良の除去を集中的に行うためである。さらに、審査チェック機能全体の整合性を確認させることも意図したのである。
(2)仕様の見直しと外部交渉
 前述のように、単項目チェック仕様の変更による関連チェック仕様への影響調査が不足していたことから、仕様の再検討が必要であると考えた。そこで私は、資金情報のテストを中断し、影響調査に専念するよう担当者に指示した。
 影響点のうち、外部仕様に関わるものはすぐにA社へ報告し、仕様を決定してもらうよう交渉した。この決定が遅れるとテストの進捗が止まり、最悪の場合はシステム稼動開始にも影響しかねないため、最優先でお願いしたい旨をA社に申し入れた。
(3)スケジュール調整
 テスト期間は限られていた。結合テストを期限内に終わらせないと、次のシステムテスト工程の開始が遅れることになる。しかし、仕様の再検討、プログラム修正、再テストに費やす時間を見積ったところ、結合テストの完了を10日間遅らせざるを得なかった。一方、システムテスト計画を確認したところ、結合テスト完了が遅れる資金情報に関わる内容は7日目から開始であった。
 そこで、資金情報の代わりに7日目から可能なテスト項目を精査したところ、12日目から開始予定の物件情報に関するテストを前倒しで実施できることが判明した。そして、物件情報の後に資金情報のテストを行っても支障ないため、これらの実施順序を組み替えた。

3.評価および再発防止策(設問ウ)
3.1.実施活動の評価
 仕様上の問題を集中的に検証した結果、外部仕様で2件、内部仕様で7件の不良を摘出できた。以降のテストでは2件摘出し、結合テスト全体では40件となった。これは当初の判定基準28件を超えているが、不良累積グラフは収束傾向を示しており、実質上、品質は確保できたと判断している。テスト後半の高スキル要員投入による不良の早期発見、および、10日間延長による十分な試験項目の消化と確認が功を奏したと考える。
 外部仕様の不良2件は、本来、次工程のシステムテストで発見すべきものであったが、今回の仕様見直しにより机上で発見できたことは大きな収穫であった。その理由は、仮にこの2件が事前摘出されずにテストで発見された場合、作業の大幅な手戻りが発生していたと予測されるからである。
 以上のことから、当プロジェクトにおける品質確保のための活動は、的確なものであったと評価している。
3.2.再発防止策
 特定の処理(資金情報・関連チェック)で不良が作り込まれた原因は、当初の計画で、処理の難易度と要員のスキルに関して正しく分析できていなかったためである。また、テスト前に摘出できなかった理由は、個別のチェック機能の設計レビュー時、全体の関連性や影響点という観点が不足していたからである。これらのことから、今後はプロジェクト計画の段階で「なぜこの体制にしたのか」「なぜこの要員にこの役割を与えたのか」という理由を明確化すると共に、設計レビュー観点の拡大とテスト確認項目の事前検証を特に重視していきたい。
 テスト段階に限らず、あらゆる視点から総合的に判断し、プロジェクトを円滑に運営していくのが私の責務であると考えている。

関連記事
スポンサーサイト

コメント

コメントの投稿



管理者にだけ表示を許可する

トラックバック

http://smpman.blog3.fc2.com/tb.php/82-0df64585

 | HOME |  ▲ page top


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