スポンサーサイト

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

スポンサーサイト の続きを読む


カテゴリ :スポンサー広告 トラックバック(-) コメント(-)

変更管理

 2010-01-28
・変更が発生する要因は「仕様変更」がほとんど
・発生した変更の起因を特定させること
 →客先の業務変更や組織変更などは顧客起因
 →開発者のスキル不足やヒアリング漏れなどは開発側の起因
・変更管理手順の決定
 →担当者独自の判断で対応してはいけない
 →変更に対して決定権を持つ会議体などで判断する
 →プロジェクトマネージャは全体の進捗、費用、体制等から総合的に判断し
  変更の可否を決定する
 ★変更管理委員会(CCB)
  →変更要求は利用者と開発側の双方で一元窓口を設け集中管理する
  →勝手な判断を行うと統制が取れない
・変更を実施する場合、起因元によって実施方法は異なる
 →顧客側が起因の場合は契約内容の変更となり、納期や費用の見直しが発生する
 →開発者側が起因の場合、スケジュール、費用、体制の見直しを行う。
  費用は持ち出しとなる


変更管理 の続きを読む


プロジェクトの立上げから計画について

 2010-01-25
・プロジェクト立上げ前は、プロジェクトマネージャの範疇ではないが、
 (営業担当者、ITストラテジスト、経営者、部門長などがキーマン)
 プロジェクトマネージャの位置でも提案、構想に加わり、
 実現可能性を検討する場合もある
・プロジェクト立ち上げ時には、プロジェクト憲章が発行され、
 プロジェクトの目的、成果物、スケジュール、予算、機能や制約条件等が
 取り決められる。
・成果物の範囲から作業を洗い出しWBSを作成する、
 その後、WBSの管理方法を定義、文書化する
 (プロジェクトマネジメント計画書)


プロジェクトの立上げから計画について の続きを読む


プロジェクトスコープマネジメントのプロセス

 2010-01-25
・スコープ計画
 →WBSなどをどのように管理していくかの定義、文書化
・スコープ定義
・WBS作成
・スコープ検証
 →ステークホルダーの承認を得る
・スコープコントロール


プロジェクトスコープマネジメントのプロセス の続きを読む


プロジェクト統合マネジメントのプロセス

 2010-01-25
・プロジェクト憲章作成
・プロジェクトスコープ記述書暫定版作成
・プロジェクトマネジメント計画書作成
・プロジェクト実行の指揮、マネジメント
・プロジェクト作業の監視コントロール
・統合変更管理
 →変更要求に関しての可否判断、管理(成果物は常に最新化して管理)
・プロジェクト集結


プロジェクト統合マネジメントのプロセス の続きを読む


WBS

 2010-01-25
プロジェクトの計画立案時に、成果物からのトップダウンで
作業を洗い出し、階層構造で表現したもの。
全ての管理の基本となる。
PMBOKの定義上はスコープマネジメント。

・機能的WBS
 →システムの機能面に着目しブレイクダウンしていく
・設計的WBS
 →作業内容をブレイクダウンしていく
 →最も細かいレベルをワークパッケージと呼ぶ。
・融合WBS
 →上記のWBSを組み合わせたもので、通常はこれを使う
・標準WBS
 →過去プロジェクト、類似プロジェクト、
  または会社で定められているWBSの事


WBS の続きを読む


PMBOK

 2010-01-25
PMI(米国プロジェクトマネジメント協会)が作成した
プロジェクト管理の基礎知識体系

■プロセスグループ
1)立上げプロセス
2)計画プロセス
3)遂行プロセス
4)コントロールプロセス
5)集結プロセス

■知識エリア
・プロジェクト統合マネジメント
・プロジェクトスコープマネジメント
・プロジェクトタイムマネジメント
・プロジェクトコストマネジメント
・プロジェクト品質マネジメント
・プロジェクト人的資源マネジメント
・プロジェクトコミュニケーションマネジメント
・プロジェクトリスクマネジメント
・プロジェクト関連マネジメント


PMBOK の続きを読む


プロジェクトとは

 2010-01-25
・1回限りの繰り返しの無い仕事
・期間が限定されている
・予算が決まっている
・リーダーと複数メンバの組織で実行される


プロジェクトとは の続きを読む


ITIL

 2010-01-23
とは、、
運用管理業務の体系的なガイドライン、
ベストプラクティス集、成功事例のこと

大きく分けて、
サービスサポート
→日常の運用業務に必要な機能とプロセス
サービスデリバリ
→中長期的に安定したサービスを提供する為のプロセス

■サービスサポート
 サービスデスク
  ・一元的窓口の提供(ヘルプデスク)
 インシデント管理
  1)インシデントの検知と記録
  2)分類分けと初期対応
  3)調査と診断
  4)解決と復旧
  5)インシデントクローズ
  6)監視・追跡・伝達・分析
 問題管理
  ・インシデントを解決まで管理する
  ・根本原因の追求、再発防止
  ・必要に応じて、変更管理へ
 構成管理
  ・IT資産の管理(ハード、ソフト、NW、設備、マニュアル)
 変更管理
  ・変更管理手順のルール化と徹底
  ・リソース変更時の手順標準化
  ・変更の承認
 リリース管理
  ・リリース時のルール化と徹底
  ・リソース変更時の作業実施
  ・移行計画、手順書の作成

■サーピスデリバリ
 サービスレベル管理
  ・要求に対しての品質保証、改善
  ・サービスレベルの定義作成、交渉、合意、監視
 ITサービス財務管理
  ・運用、保守に関する費用対効果の管理
  ・サービスの予算化、実績データ収集による、計画値との乖離分析、改善
 キャパシティ管理
  ・サービス利用状況の管理(ディスク容量、端末数、CPU使用率、帯域など)
  ・キャパシティの監視、分析、評価、改善
 ITサービス継続性管理
  ・災害時のサービス継続性管理
  ・企業の事業継続性計画とIT復旧計画の整合性確保
 可用性管理
  ・利用者が求めるサービスを提供できるように管理する
  ・必要な可用性の決定、監視、分析、評価、改善


ITIL の続きを読む


ERPパッケージ

 2010-01-23
とは、、
企業全体の経営資源を有効かつ総合的に計画、管理を行い、
経営の効率化を図る目的で導入される統合パッケージである。

代表的なERPパッケージの機能として、
・財務から販売までのデータベース一元化
・成功企業の業務プロセスをベースにしている
・多国籍対応、DWH機能など

ERPパッケージにおけるカスタマイズとは、、
1)パラメータ設定
2)アドオン開発
3)モディフィケーション(パッケージの改造)

導入の種類は、
・部分導入
 財務会計、販売管理などのモジュール単位で導入する
 導入に関しての負荷は少ないメリットはあるが、
 導入が繰り返される為、都度インターフェースを作成する必要がある
・ビックバン導入
 導入に要する時間ま短い、しっかりした計画のもとに確実に移行しなければ
 企業活動自体ができなくなるという大きなリスクを持つ

導入手順
1)ユーザニーズの確認
 導入目的、適用範囲、適用範囲の優先順位、重要度、必要な機能などを
 ユーザと確認する
2)フィットギャップ分析
 ユーザニーズとパッケージの機能との差分を調査する。
 調査結果はパッケージ適合率など客観的に出せる場合もある。
 デモやチェックリストも用いられる。
3)ギャップの対応
 業務を変更する、またはアドオン開発、モディフィケーションを行う。
 →パッケージ導入の目的、メリットを損なわないように注意
 →パッケージを主に考えるなら、業務改革を行うことをまず考慮する
4)開発フェーズ
 対応方法ごとに開発を進める。
5)導入
 結合テスト、総合テストを経てユーザ受け入れテスト、
 その後に本番稼動

ERPパッケージ導入のメリットとデメリット
・メリット
 低コスト、短期間での導入が可能。
 ヘルプデスクや修正パッチの提供など保守サービスが充実している。

・デメリット
 モディフィケーションを行った場合は、メリットである保守サービスは
 対象外となるケースが多く、別途費用がかかってしまう。
 またモディフィケーションが不可な場合もある。

パッケージ評価選定のポイント
 ・業務の適用度
 ・パッケージの成熟度
  →販売開始からの経過年数、版数、出荷本数
 ・導入実績
 ・開発、販売ベンダの経営安定度
  →仮に取り扱いベンダが倒産してしまうと、その後のサポートが受けれない
 ・サポート面
  →保守の充実度

導入に際しての留意点
 ・導入後の切り替え期間は長めに設定する
 ・ユーザ作業が多いので業務の繁盛期は避ける
 ・カスタマイズ箇所のテストはパッケージの基本部分への影響を考慮する
 ・パッケージに精通した技術者を用意する
 ・ユーザ部門の積極的参加の打診
  →経営トップの参画、要請を得る
  →決定権のある人物の参画
 ・データ整備は新システムのレイアウトを基本として行う
  →新には必須だが旧にないものは注意

ERPパッケージ の続きを読む


各工程のおける役割分担(ウォータフォールモデルを参考)

 2010-01-23
まず、経営戦略に合致した情報戦略を立案し、
システム化構想を確定させるのはITストラテジストの役割である。
そしてプロジェクトの立上げからは、
プロジェクトマネージャーが管理を行います。
具体的なシステム設計を行うのがシステムアーキテクトで
内部設計が応用情報技術者、プログラミングが基本情報技術者です。

・情報戦略立案
 経営戦略や情報戦略を受けてシステム化構想を立案する
 ITストラテジストが行う業務

・システム分析、要件定義
 現状の業務やシステムを分析し、ユーザ要求を明確にすると共に
 システム要件定義書を作成する。
 システムアーキテクトを中心にDB周りの設計も行う。

・システム方式設計
 開発システムの実現方法をHW、NW構成を含めて設計する。
 手作業とシステム化する部分の切り分けもこのフェーズ。

・ソフトウェア設計
 システム化する部分の要求事項を正確に設計書に展開する。
 このときテスト仕様書も合わせて設計する。

・プログラム開発
 プログラム開発、単体、結合テストを行う。
 テスト結果報告書がアウトプットになる。

・ソフトウェア導入支援
 総合テストの実施。ユーザの受け入れテストも行う。
 システムのユーザ引渡しやデータ移行、ユーザ教育を行う。



ドラッカーの基礎を勉強するサイト

各工程のおける役割分担(ウォータフォールモデルを参考) の続きを読む


システム開発方法論

 2010-01-22
代表的なものは以下の8つ
 1.ウォーターフォールモデル
       抽象的な設計から、より具体的な設計へと進めるモデル。
       各工程にはインプットとアウトプットがあり、
       アウトプット(成果物)を次工程に引き継いでいく。
       →大規模開発向き
       →設計ミスは上流工程の方が下流工程より影響が大きい

 2.プロトタイプモデル
       簡単な試作品を作ってから、本格的な製品を作る手法。
       新規性が高い場合や、ユーザ要件が曖昧な場合に利用される事が多い。
       ウォーターフォールをベースに、一部組み合わせる場合もあり。
       ユーザー要件と開発者の認識ズレの早期認識合意、
       本格開発前に修正できるのがメリット。
       プロトタイプは捨ててしまう場合や、それをベースに開発する場合がある。
           
  3.スパイラルモデル
        システムの部分単位に要求定義・設計・プログラミングを繰り返し行う手法。
       (ウォーターフォールモデルを繰り返す感じ)
        全体を独立性の高いサブシステムに分割し、分割した単位で開発を行う。
        リスクが最小となるプロセスを選択しながら、
        少しづつ開発を行うようなプロジェクトに最適で、
        未経験分野のシステム開発に有効。
        次にある、インクリメンタルモデルとは繰り返しの範囲が異なる。
        スパイラルモデルは要件定義からテスト工程までを繰り返し、
        インクリメンタルモデルでは要件定義は最初に全体に対して行い、
        設計以後を繰り返し順次リリースする。
        →サブシステムの分割に注意
        →部分的に要件定義を行うので、途中で全体の整合性を合わせるのが難しそう
           
 4.インクリメンタルモデル
       最初にシステム全体の要件定義を行い、要求された機能を幾つかに分割して
       段階的にリリースするので、全ての機能がそろっていなくでも、
       最初のリリースからシステムの動作を確認する事ができる。
           
 5.エボリューションモデル(成長モデル)
       システムの要素をとりあえず完成させ、段階的に要素を開発して
       追加していく手法。
       プロセス管理などのように、どんなモジュールからも呼び出す
       カーネルを先に開発して、完成したカーネルのモジュールを
       実行環境として利用しながら、シェルを追加していく
       というようにOSの開発に向いている。
       インクリメンタルモデルと分けて説明される場合、
       違いは分割の仕方になる、エボリューションモデルの場合、
       進化型、つまり各機能の完成度を高めていくイメージになる。
           
 6.ラウンドトリップ
       オブジェクト試行開発において、分析と設計、プログラミングを何度か
       行き来しながらトライアンドエラーで完成させていく手法。
           
  7.RAD
       短期間で行うシステム開発手法。あらかじめ開発期間を数カ月間と限定し、
       少数のグループメンバーで常にユーザーを巻き込みながら、
       効率よくシステム開発を行うもの。生産性を高める為に
       CASEツールを使用する事が多い。
       短期間で行うためにユーザと一体化したワークショップと呼ばれるものを用いる。
       また、要件定義・プロトタイプ作成・ユーザ確認を短期間に繰り返す。
       このとき、無制限な繰り返しを防ぐため、タイムボックスを呼ばれる
       一定の開発期間を設定する。
       →ユーザと一体化した開発
       →設計と製造でそれぞれのスペシャリストにわけない
       →計画・開発・テストなどの工程ごとに分けない
           
 8.XP(エクストリーム・プログラミング)
      10人程度の小チームで、小~中規模のソフトウェア開発に向いた手法。
       開発チーム内では、「コミュニケーション」、「シンプルさ」、
      「フィードバック」、「勇気」
       の4つの価値を創造し、経験に基づいた具体的な12~14個の実践項目を持つ、
       代表的なものは以下
       ・顧客を含めた全員が開発チームを構成する「チーム全体」
       ・余計な複雑さを排除する「シンプルデザイン」
       ・1台の開発マシンを2人で共有して常に共同でコードを書く
         「ペアプログラミング」
       ・小規模な改良を頻繁に行う「スモールリリース」
       ・まずテストを追加し、次にそれを動かすという
     非常に短いライフサイクルを繰り返す「テストファースト」
       ・いつでも、どのペアでも、コードのあらゆる箇所を変更する事ができる
         「コードの共有」


システム開発方法論 の続きを読む


眠りについて

 2010-01-21
・30代から眠りは浅くなる
・日中に脳と体をフルに使う→疲れて夜にぐっすり眠れる(活動的に)
・睡眠時間は7時間が適当。個人差はあり
・寝る前にはアロマテラピーや軽い運動
・ホテルの部屋は眠れる部屋として参考になる
・寝る前に読んで良い本は、短編、明るく落ち着ける話
・自律訓練法
・目覚めたときに決まったことを行う
・起きたら布団の中でも良いので、体を動かす


眠りについて の続きを読む


≪ トップページへこのページの先頭へ  ≫
halken800 Twitter
最近の記事
カテゴリー
タグリスト
最近のコメント
最近のトラックバック
広告



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