サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
Pixel 10
www.h6.dion.ne.jp/~akn
■進捗管理の目的 プロジェクトが納期を守れるようにコントロールする事。 ■進捗管理の方法 進捗計画に従い、個々の作業が遅れずに行われているかどうかを確認する。 作業毎にかかった時間を記録し、計画と実績の差異を分析する。時間がかかり過ぎているようであれば、何らかの問題が起きていると考えられる為、担当者に事情聴取する。 管理対象に優先度をつけ、重点的に管理すべきものとそうでないものを区別して行う。 進捗会議を定期的に開催し、メンバーの報告を受けて進捗管理表に記録する。 進捗会議のサイクルが短いほど問題の早期発見が可能である。 進捗会議は週一回くらいのサイクルで行うのが望ましい。 メンバーの進捗報告だけでなく、構成管理ツールを使って成果物の完成度や更新状況等からも進捗状況を確認する事。 進捗管理表だけでなく、メンバーの様子を見る事も大切である。 メンバーが疲れていたり、悩んでいたりすると生産性
■障害管理の対象 ハードウェア ソフトウェア ネットワーク アプリケーションプログラム ■障害管理の方法 障害の発生日時や発生場所は、原因追求や影響調査で必要になる為、把握しておく。 どのような現象が発生しているのかを連絡者から詳細に聞き出す。 エラーメッセージやエラーログ、データの状態等からシステムの状況を把握し、いつ、どこに、どのような影響があるのか確認する。 原因を特定し、業務が速やかに再開できるよう、暫定対応を施す。 本来あるべき状態になるよう、恒久対応を施す。 同様の障害を防止する為に関連箇所についても対応する。 ■障害の原因 ハードウェア障害 ソフトウェアのバグ トランザクション量増加によるレスポンス低下 設計ミス プログラムミス プログラム改修によるデグレーション 入力データチェック漏れ テスト不十分 プログラムバージョン不整合 環境設定ミス データの移行漏れ 移行手順ミス
■品質計画の目的 プロジェクトの目的とする品質を定義し、それを確保する為の計画を立てる。 ■品質計画の考え方 品質や性能はコストとトレードオフの関係になる。 予算の範囲内で品質や性能を確保しなければならない為、優先順位をつける必要がある。 スコープ定義や要件定義に基き、成果物の品質を定義する。 成果物の使用目的や使用範囲によって求められる品質が異なる。 要件定義や各設計（システム設計・基本設計・共通設計・外部設計・内部設計）の工程段階では、成果物のレビューを行い、製造前に欠陥の予測と予防を行う。 各工程で必要な成果物がそろっているかどうかでも品質がある程度測れる。 機能別に障害発生時の対応を検討し、絶対に障害が許されないものとそうでないものを選り分けて明確にしておく。 絶対に障害が許されないのは、人命にかかわるものや多大な損失につながるもの。 テスト内容やテスト範囲によっては、テストツール
セキュリティポリシー セキュリティリスク 情報セキュリティにおける脅威 セキュリティ対策の種類 セキュリティの物理的な対策 セキュリティの技術的な対策 セキュリティの組織的な対策 情報セキュリティに関する法律
■開始条件 ユーザ側で要求事項が整理されている事。 システム開発案件を受注し、契約が締結されている事。 ■要件定義の目的 業務をシステム化するときにユーザの要求をまとめる作業を要求定義という。その成果物を要求定義書という。 要求を実現するために、システム化の要件をまとめる作業を要件定義という。その成果物を要件定義書という。 要件定義は、システム化の範囲を明確にし、システム開発にかかる工数や費用を見積もる為にも行う。 ■要件定義の担当 要求定義、および要件定義はユーザ中心で行うべきである。 ユーザ側で関係部門の担当者を集めて、システム化の委員会を発足させ、要求事項の導出やとりまとめ、要件定義を行う。 開発者は情報システムに関する専門知識を提供し、ユーザの要件定義作業を支援する。 ■要件定義の方法 ユーザはシステム化したい事を明確に定義し、開発者に漏れなく伝えなければならない。 ユーザは自らの
■開始条件 総合テストが完了している事。 ■システムテストの目的 ハードウェア、ソフトウェア、アプリケーションの関係において信頼性や性能に問題のない事を確認する。 ■システムテストの方法 システムテスト計画を立てる。 修正にかかる工数や体制を予め取っておく。 システムテスト仕様書はシステム設計書を基に作成する。 システムテスト計画書やシステムテスト仕様書のレビューを行い、テストパターンやテスト項目の過不足、テストの妥当性についてチェックする。 システムテストにて、性能テスト(パフォーマンステスト)と障害テストを行う。 システムテスト結果を評価し、次の工程に進むべきかどうかの判定を行う。 ■性能テストの方法 性能テストの為に、本番運用と同等以上のデータを準備する。 性能テストの為に、本番運用と同等以上のトランザクションを発生させるツール、もしくはオペレータを準備する。 サーバの各種資源(CP
■目的 コミュニケーションルールを設ける事により、コミュニケーション不足を起因とするミスやロスを低減する。 ■コミュニケーション手段 コミュニケーション手段は、立ち話･面談･会議･電話･電子メール･掲示板･メモ･回覧等がある。 適切なコミュニケーション手段を選択する為のルールを決めておく。 ■会議体 プロジェクト発足(キックオフ)会 要件確認会議 仕様確認会議 ユーザ進捗報告会 内部進捗会議 ユーザレビュー会 内部レビュー会 サブシステム間仕様調整会議 課題解決会議 ユーザ連絡会議 内部連絡会議 各種テスト計画会議 本番稼働判定会議 障害対策会議 プロジェクト完了報告会議 ■議事録 日時 場所 参加者 議事内容 発言者 決定事項（期限/実施責任者/実施担当者） 検討事項（期限/検討責任者/検討担当者） 保留事項 承認印欄 ■コミュニケーションルール 悪い報告を叱らない。 嘘をつかない。 推
システム化の目的 システム化全体計画の留意点 システム化対象業務の選定 最新情報技術の調査・選定 業務の理解 業務モデルの作成 アーキテクチュアの策定 費用対効果の予測 システム化と情報戦略の整合性 システム化全体計画書の作成と承認
開始条件 要件定義の目的 要件定義の担当者 要件定義の方法 要件定義の基になる資料 要件の種類 要件定義の確認 要件定義書の項目 要件定義書作成時の注意点 要件定義の変更管理 成果物 終了条件
「情報戦略の立案」のページを更新しました。 「調査の方法」のページを更新しました。 「システム化全体計画の策定」のページを更新しました。 「個別システム開発計画の策定」のページを更新しました。 「プロジェクト計画」のページを更新しました。 「スコープ定義」のページを更新しました。 「進捗計画」のページを更新しました。 「費用計画」のページを更新しました。 「組織計画」のページを更新しました。 「PMO (Project Management Office)」のページを更新しました。 「外注計画」のページを更新しました。 「品質計画」のページを更新しました。
このページを最初にブックマークしてみませんか？
『www.h6.dion.ne.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
