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

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






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

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

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

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


最近の記事


リンク集




自己紹介など

    くつろぐ

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


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


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

メールフォーム

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

広告エリア2












スポンサーサイト

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

論文対策1回目 修正版

<平成13年 問3>

1.プロジェクト概要とテストでの確認項目・判定基準
1-1.プロジェクト概要
 関東中心に約200店舗を有するA金融機関(以下A行と呼ぶ)は、個人住宅ローンを主力商品の一つとしている。A行では、業務の効率化、顧客サービス向上を目的とし、老朽化した住宅情報システムを再構築することになった。情報処理サービス会社B社の汎用機とA行の各店鋪にある端末を公衆回線で接続する方式から、インターネットを利用したWebベースへと刷新するものである。B社に勤務する私は、プロジェクトマネージャとして全体を統括し、指揮する立場であった。
 プロジェクト成功の条件は、審査チェック機能の品質確保にあった。その理由は、ローン承認までの時間が長いとの苦情に対してA行が審査方法を見直し、今回の再構築に伴って業務仕様を大幅に変更したからである。
1-2.テスト段階での確認項目及び判定基準
 私がテスト計画書に盛り込んだ内容を以下に示す。
(1)確認項目
 対象機能を、新規作成分、修正分、再利用分の3つに分けた。そして、個々のプログラムの単体テスト、再利用部分を含むプログラム間の結合テスト、システム全体の総合テストの各工程毎に、テスト項目消化数、不良摘出件数を確認項目とした。なお、プロジェクトの特性を考慮し、審査チェック機能を重点的に管理する。
(2)判定基準
 上記(1)の通り工程毎に目標値を設定したが、最終的な結果だけではなく途中経過も大切である。そこで私は、過去の類似プロジェクトのデータを参考にして、テスト項目消化数と不良摘出件数について、それぞれ日々の予定数を累積グラフで表した。実績値がこのグラフに近い曲線になり、不良の件数が収束していれば、品質は確保されているものと判定する。

2.テスト段階における品質確保の方策(設問イ)
2-1.テスト実施状況
 単体テストでは、テスト項目消化数は予定通りで、不良摘出件数は目標値より10%ほど少なかった。ただし累積グラフは収束傾向を示していたため、品質の判定基準は満たしていると判断した。ところが、結合テスト工程になると、予定していたテスト項目数の半分も消化していない段階で、すでに不良件数が目標値に近づいており、今後も増えると予測できた。私は、品質上の問題があると考え、早急に原因の究明に当たった。
2-2.判定基準を満たさなかった原因の分析・究明
(1)分析方法・分析結果
 審査チェック機能は全部で約250種類の判定ロジックから成り、顧客情報、日付情報、資金情報、物件情報の4グループに分かれる。さらに各グループ毎に単項目チェックと項目間関連チェックに分かれる。そこで私は、どのグループで不良が多いのか傾向を分析するために、パレート図を利用した。分析の結果、資金情報の関連チェックでの不良が、全体の約60%を占めていた。また、詳細設計の記述誤りや記述漏れに起因する不良が半数近くあった。
(2)原因の究明
 以上の結果から、私は資金情報の設計担当者に対し、再度、設計書を確認するよう指示した。また、設計上の不備を発見しやすくするため、業務に詳しい他の担当者にも協力してもらった。その結果、単項目チェック仕様の変更による関連チェック仕様への影響が、完全に洗い出されていなかったことが判明した。資金情報は設計の難易度が高いうえ、仕様変更の頻度が他に比べて多かったことも、不良が多く作り込まれた要因であった。
2-3.分析結果に基づく施策
 原因分析をもとに、私は、当プロジェクトの品質を確保するため、以下に示す対策を実施した。
(1)要員体制の強化
 前述のような不良の傾向や仕様変更への対応が不十分であった根本的な原因は、私自身がプロジェクトの各メンバーの能力を正確に把握できていなかったことにある。このため、要員体制を強化することにした。
 具体的には、審査チェック以外の機能を担当していた2名のメンバーを、資金情報のテスト要員に加えた。この2名は、A行業務の豊富な知識と経験により能力を発揮し、既に自分たちの作業を終えていたからである。私は、増強したメンバーに不良の摘出および不良の除去を集中的に行わせる、あるいは、各機能間の整合性という観点でテスト結果を検証させることにより、システム全体としての品質確保をねらいとした。
(2)ユーザによる仕様確認の交渉
 単項目チェック仕様の変更による関連チェック仕様への影響調査が不足していたことから、私は、品質の安定化のために、ユーザであるA行にも協力を求めるべきと判断した。そのため、外部仕様に関わる影響点を整理してA行へ報告し、設計変更の方針について確認してもらうよう交渉した。この確認が遅れると品質の保証ができないうえテストの進捗が止まり、最悪の場合はシステムの稼動開始が遅れる可能性もあるため、最優先でお願いしたい旨をA行に申し入れた。
(3)テスト方法の効率化
 期間・コスト・資源が限られたテスト工程では、不良を効率的に発見し除去するための工夫が必要になる。そこで私は、テスト方法を見直し、効率向上のための改善を図った。例えば、ある機能で使用したテストデータを別の機能で再利用する、同じような不良がないかを調べる専任メンバを配置する、不良の状況を管理簿にまとめ優先順位の高いものから除去していくなど、様々な対策を実施した。

3.評価および再発防止策(設問ウ)
3-1.実施活動の評価
 限られた期間内で集中的に不良の除去ができ、無事に稼動開始を迎えることができた。結合テストは見直しの影響から、テスト項目消化数が予定より約20%増、不良摘出件数が予定より約15%増という結果であったが、不良累積グラフは収束傾向を示している。また、次工程の総合テストでは、特に問題は見られなかった。
 一方、ユーザによる仕様確認については、交渉の末、A行側の担当者から理解が得られた。その結果、仕様の曖昧な部分が明確になり、短期間で設計品質を向上させることができた。また、テスト方法の見直しにより項目消化のペースが高まった。
 以上のことから、品質は確保できており、私が実施した活動は効果があったと評価している。
3-2.再発防止策
 特定の処理で不良が作り込まれた真の原因は、処理の難易度と要員のスキルを正しく把握できていなかったことによる。また、テスト前に摘出できなかった原因は、個別のチェック機能の設計レビュー時、全体の関連性や影響点という観点が不足していたからである。
 したがって、今後は、適材適所の要員配置や作業量の平準化などに配慮しながら、設計書及びテスト項目のレビューなど事前の検証に力を入れたい。テスト工程に限らず、あらゆる段階において品質を意識したプロジェクトの運営が必要であろう。


<修正ポイント・考察など>
 悪いところだけを部分的に直そうとしても、うまくいかないことがわかった。論述内容に矛盾がなく全体のバランスを考えた構成にするため、結局、全面的に修正を加えることになった。
 もっとも大きな修正点は、2-3(3)を「スケジュール調整」から「テスト方法の効率化」に変えたことである。題意に合わせるための処置であるが、このように修正したことにより、設問ウの評価でも、効率化について触れておく必要がある。
 また、下書きでは具体的な不良の件数を出していたが、数値を書いたからといって必ずしも説得性が増すということにはならない。むしろ、書き過ぎると逆に不自然というか、うそっぽい印象を与える場合もある。したがって今回は、~%というふうにしてみた。
 全体的には、無駄な記述をなくし、無難にまとまった感じがする。ただ、あらためて読んでみると、何だか面白みがない、という印象を受けた。採点者へのアピール効果のあるトピックスや書き方をさらに研究しようと思う。

<スキル基準>
 論文作成において参考になった以下の基準について、復習しておこう。
  プロジェクト計画策定 2-9 品質保証計画
  プロジェクト追跡と実行管理 3-B 品質管理

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

コメント

コメントの投稿



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

トラックバック

http://smpman.blog3.fc2.com/tb.php/84-7c1a96ff

 | HOME |  ▲ page top


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