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

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






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

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

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

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


最近の記事


リンク集




自己紹介など

    くつろぐ

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


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


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

メールフォーム

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

広告エリア2












スポンサーサイト

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

2.プロジェクト計画策定(4)

 2-9 品質保証計画
  291 企業の品質方針の確立
  292 品質特性・品質項目の明示
  293 採用した品質標準が機能している
  294 文書作成基準の確立
  295 品質保証手順が適切かつ完全
  296 システム構成管理手順が適切
  297 品質レビューの進め方が規定
  298 品質リスクの文書化
  299 品質保証計画の文書化・レビュー
  29A 評価関係者からの承認

 2-A リスク管理計画
  2A1 全リスクの識別・影響の評価
  2A2 詳細タスクへの予防策の組み込み
  2A3 不測事態対応計画の計画
  2A4 リスク監視追跡のための管理表
  2A5 管理計画の文書化・レビュー
  2A6 評価関係者からの承認

 2-B プロジェクト計画書作成
  2B1 目標・成果物・推進体制が明確
  2B2 成果が及ぼす影響が明確
  2B3 実行に際しての前提・制約が明確
  2B4 管理目標としての基準値が適切
  2B5 状況報告の方法・承認ルール
  2B6 問題発生時の対応策の承認ルール
  2B7 スコープ決定時の課題への解決策
  2B8 監視・追跡・管理方針の明示
  2B9 各工程完了を確認する条件の確定
  2BA パフォーマンス計測の項目・方法
  2BB ユーザによる成果物の検収条件
  2BC 完了後評価指標の概要
  2BD 計画の文書化・レビュー
  2BE 評価関係者からの承認

コメント:
 QCD-すなわち品質・費用・納期の3つが、プロジェクトにおいて柱となる管理項目となる。特に品質は、システム利用者が業務を円滑に効率良く行うためにもっとも重視すべき要素であろう。ところで、スキル基準によれば、2-4~2-10までのタスクは並行的に進めるもので、各計画は相互に整合性を保つものとしている。つまり、2-3までのタスクで開発方針やスコープの設定をしたあとは、スケジュール、資源、組織要員、調達、費用、品質保証、リスク管理の7つの計画を策定し、最後にこれらの計画を盛り込んだプロジェクト計画書を正式にまとめる作業となる。リスク管理は6タスクで少ない感じがするけれども、各計画のタスクの中に必ず「リスク」という言葉が出てくることから、じつは非常に重要な位置付けにあるものと読み取れる。

Pman注目:
 2B4 管理目標としての基準値が適切
 スキル基準には「各種管理目標としての基準値が適切かつ完全に定義されていること」と書かれている。例えば、品質目標の場合、レビュー指摘件数やバグ発見数などの目標値がプロジェクト計画書に記載されている必要がある。ところが、あればいいと言うものではなく、プロジェクトにとってその目標値が妥当なものでなければならない。品質基準では、一般的にソフトウェアの規模(プログラムステップ数)をもとに算出したりするが、過去の類似プロジェクトにおける実績を参考にしたほうが適切な基準値になることもある。さらに、リスク要因などを加味したうえで、品質だけでなくコストなどに関する基準もしっかりと定義しておくことが肝要だろう。

 次回予定→ 3.プロジェクト追跡と実行管理
関連記事
スポンサーサイト

コメント

コメントの投稿



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

トラックバック

http://smpman.blog3.fc2.com/tb.php/70-f012c5dc

 | HOME |  ▲ page top


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