http://w.atwiki.jp/minanana/ minanana @ ウィキ ja 2009-11-27T20:50:32+09:00 1259322632 https://w.atwiki.jp/minanana/pages/59.html **links ・[[プロジェクト開始前の準備>http://itpro.nikkeibp.co.jp/article/COLUMN/20080729/311687/?ST=lecture]] WBS分割前に大枠の見積もりを行い，そのうえでWBSの積み上げによる見積もりを行って両者を比較する 実際の開発規模が数倍になることを防ぐには，複数の方法で見積もり，結果を比較することが必須である。最低限，WBS分割前の大枠の見積もりと，WBS の積み上げによる見積もりは実施するべきだ。余裕があれば，大枠の見積もりでも複数の見積もり方法を使って欲しい。比較の結果，大きな差が出た場合は原因を調べる。この過程で，機能の欠落や見積もり漏れを防ぐことができる。 2009-11-27T20:50:32+09:00 1259322632 https://w.atwiki.jp/minanana/pages/58.html **見るべき重点ポイント 支払い 権利 トラブル発生時の対応 ** **関連ドキュメント [[リンク>http://www.atmarkit.co.jp/news/200409/15/req.html]] **分からないことは？ 2009-10-14T19:06:05+09:00 1255514765 https://w.atwiki.jp/minanana/pages/47.html **やること 外作の場合： -Q&A -WT -日程調整 -進捗管理報告 　　方法：進捗報告メール、週１の進捗報告定例会など。 　　　　　詳細スケジュールを出してもらって、進捗を％で管理する等 メールのみのコミュニケーションは避けた方がよいと思います。 やはり直接会って話し合うことは，相互のコミュニケーションを密にする上で重要です。 -工数状況を把握 プロジェクトにおいては，必要な時期に必要なことを行わなければならない。そんなことは当然と思われるかもしれないが，実際には時間経過に伴うプロジェクト特性の変化に対してあまり考慮していないことが多い。例えば，プロジェクトの準備段階にもかかわらず，綿密すぎるくらいに詳細な計画を立てたり，逆にプロジェクトの実施段階にもかかわらず，プランの見直しやレビューを行わないといったことが現実に起こっている。 プロジェクトの計画と実績が乖離をした段階、 計画通りでないことが発覚した時点で変更をかけ、報告を関係者に行う **チェックポイント 工数が、どれだけかかるか-シス技でかかる工数全体の管理は運用課が行っているので、 計画した工数見積と工数実績との間に差異（乖離）が表れた時点で迅速に 運用課担当に報告することが必要となる 少しのずれ（全体見積の１０％以内）であれば、許容範囲とされているが、 １０％を超えた時点で再決裁が必要となる。 外作の場合： +構築変更計画を運用課が提出し、権限のある上司が承認をする（決裁をとる。）決裁が出たら、発注処理が出来る。 +(内示)発注に時間がかかるが、スケジュール的に開発作業開始が必要な場合は、内示を出して、発注前に作業を開始してもらう（口頭）。今、発注書を出している段階で未だ出せないのだが、手続き上の話で、事実上、開始していい。進めてもらうようお願いします。 +発注処理　Flowlitesで発注書を作成、発注書の原本を外部ベンダに渡して発注となる。 **関連ドキュメント **分からないことは？ 2009-07-16T15:58:54+09:00 1247727534 https://w.atwiki.jp/minanana/pages/57.html **戦略策定～企画の段階 新しいシステム（＝新しい業務の仕組み全体）が果たす機能や効果はどうすれば得られるのか、その目的と原理を明らかにします。 業務の仕組み全体の見直しが必須 **要件定義と基本設計 新しい業務の手続きや手順を明らかにし、これに沿ってITに頼る範囲やコンピュータの利用方法を決め、画面・帳票のデザインなども明らかにします。一言でいえば「要求仕様に基づいて“開発するシステムの機能”を決定する工程」 **基本設計（外部設計） 開発しようとするシステムが、コンピュータの外部（ユーザーや外部システム）に対してどのような機能、インターフェイスを提供するかを設計する ** **関連ドキュメント [[リンク>http://www.atmarkit.co.jp/news/200409/15/req.html]] [[リンク>http://www.atmarkit.co.jp/news/200301/22/rational.html]] **分からないことは？ 2009-07-15T20:23:32+09:00 1247657012 https://w.atwiki.jp/minanana/pages/56.html **チェックポイント **短納期開発プロジェクトに適した要求管理のアプローチ 「要求を構造化でき、不備を発見しやすくすること」「要求のセットを明確にし、合意を得ること」「変更による影響範囲を正確に把握できること」） **要求管理のために。 良いユースケースというのは、機能要件を知るべき人々にとって円滑なコミュニケーションを可能にする ユースケースというのは、要求管理の重要な一部分 開発が進む過程で要求のエラーを修正するにはコストがかかりすぎる。そもそもユースケースは、何を構築するのか、あるいは何を構築しないのかをまず明確にすることから始まる。 ユースケースは機能要件をストーリーとして書き出すことが必要である。その後、ダイアグラムに落としていく。しかし、機能要件を書き出す段階が難しい。表（個条書き）のように書いてしまうのは簡単だが、それでは機能要求を十分に補完することは難しい。そのため、一貫した“話（ストリー）”として表現しなければならないのだ。何がどうなったら、どうなるのか。これが起こらなかったら、何が起こるのか？というように。構造化手法で[[システム開発]]の経験があるエンジニアがよく陥る。 では、何をアクターにし、何をユースケースとするのか。その判断基準は何だろうか。アクターの定義にはいろいろな解釈があるが、標準的なTipsとしては、プリンタやDBはアクターにはならない、プログラムをしているシステムはアクターにはならない、デバイスはアクターとしてモデリングしないなどの “常識”を知っておくとよい。このような基本的な指針に沿ってアクターを決めていく。行き詰まったら、無視して先に進むこと。重要だと思ったら、後から追加すればよい。 　ユースケースを書くにはスタイルがある。例えば、フローのステップごとに番号を打つのかタイトルだけにするのか、メインフローとサブフローを分けて表現するのか、使われる用語などなど。ユースケースを書くうえでスタイルを統一することが重要だ。これが守られていない例は多い。 ラショナルが提唱するスタイルは、各ステップにナンバリングをするか名前をつける。メインフロー（main flows）のステップは、代替フロー（alternate flows）を参照しないようにするなどだ（メインフローとは、搭載される予定の機能がトラブルなく推移するフローであり、代替フローは、例外やエラーなどを含むフローである）。ユースケースのスタイルは現在およそ30種類ほどあるが、どれが一番優れているかという議論には意味がない。スタイルが統一されているかどうかが重要になる。スタイルの統一がされていないユースケースは非常に読みにくく、機能要件がうまく伝わらない。ただ、ラショナルでは、要求管理から設計に至るまでをサポートするRUPの存在があり、ユースケースのスタイルとも密接な関係を保っている部分が優位だと考える。もちろん、方法論はなくても開発はできるし、ユースケースも書けるが、ないよりはあった方がいい。 **関連ドキュメント [[リンク>http://www.atmarkit.co.jp/news/200409/15/req.html]] [[リンク>http://www.atmarkit.co.jp/news/200301/22/rational.html]] **分からないことは？ 2009-07-15T19:18:04+09:00 1247653084 https://w.atwiki.jp/minanana/pages/1.html **minanana@wikiへようこそ -右の更新履歴に材料があります。整理されてないが、徐々にまとめる。 **分からないことは？ -[[@wikiの基本操作>http://atwiki.jp/guide/category2.html]] -[[用途別のオススメ機能紹介>http://atwiki.jp/guide/category22.html]] -[[@wikiの設定/管理>http://atwiki.jp/guide/category6.html]] -[[@wiki ご利用ガイド>http://atwiki.jp/guide/]] -[[よくある質問>http://atwiki.jp/guide/category1.html]] -[[無料で会員登録できるSNS内の@wiki助け合いコミュニティ>http://sns.atfb.jp/view_community2.php?no=112]] -[[@wiki更新情報>http://www1.atwiki.jp/guide/pages/264.html]] -[[@wikiへのお問合せフォーム>http://atwiki.jp/helpdesk]] 等をご活用ください **@wiki助け合いコミュニティの掲示板スレッド一覧 #atfb_bbs_list(112) **その他お勧めサービスについて -[[大容量１Ｇ、PHP/CGI、MySQL、FTPが使える無料ホームページは@PAGES>>http://atpages.jp/]] -[[無料ブログ作成は@WORDをご利用ください>>http://atword.jp/]] -[[2ch型の無料掲示板は@chsをご利用ください>>http://atchs.jp/]] -[[フォーラム型の無料掲示板は@bbをご利用ください>>http://atbb.jp/]] -[[お絵かき掲示板は@paintをご利用ください>>http://atpaint.jp/]] -[[その他の無料掲示板は@bbsをご利用ください>>http://atbbs.jp/]] -[[無料ソーシャルプロフィールサービス @flabo(アットフラボ)>>http://sns.atfb.jp]] **おすすめ機能 -[[気になるニュースをチェック>http://atwiki.jp/guide/17_174_ja.html]] -[[関連するブログ一覧を表示>http://atwiki.jp/guide/17_161_ja.html]] **その他にもいろいろな機能満載！！ -[[@wikiプラグイン>http://atwiki.jp/guide/category17.html]] -[[@wiki便利ツール>http://atwiki.jp/guide/category32.html]] -[[@wiki構文>http://atwiki.jp/guide/category16.html]] -[[@wikiプラグイン一覧>http://www1.atwiki.jp/guide/pages/264.html]] -[[まとめサイト作成支援ツール>http://atwiki.jp/matome/]] **バグ・不具合を見つけたら？ 要望がある場合は？ お手数ですが、メールでお問い合わせください。 2009-07-13T15:18:42+09:00 1247465922 https://w.atwiki.jp/minanana/pages/55.html **概要 「情報システム」とは、「ユーザーに意思決定やアクションを起こさせるような仕組みを提供するもの」 # 新しい業務の仕組みを考えること # 業務に合わせてコンピュータシステムを作ること # 業務を刷新し、その効果・効率を上げること システム開発を「企業戦略や業務の流れをあらためて検討・整理するチャンス」ととらえ、コンピュータシステムに対する要求を正確に明示することに専念すべき **関連ドキュメント -[[リンク>http://www.atmarkit.co.jp/im/cits/special/five_system/01.html]] 2009-07-10T16:59:55+09:00 1247212795 https://w.atwiki.jp/minanana/pages/54.html **概要 ITILでは、プロセス（Process）、ピープル（People）、プロダクト（Product）の「3つのP」の重要性がよく指摘されます。どれが欠けても、大きな効果は期待できません **関連ドキュメント -[[リンク>http://www.atmarkit.co.jp/im/cop/special/fivemin/itil/05.html]] 2009-07-10T16:05:20+09:00 1247209520 https://w.atwiki.jp/minanana/pages/53.html **概要 PMO （project management office） [[プロジェクトマネジメント]]・オフィス / プロジェクト管理オフィス 個々のプロジェクトが終了しプロジェクトチームが解散すると、そこで生み出されたPMノウハウは失われてしまう恐れがあるが、こうしたノウハウを吸い上げ、体系化し、ほかのプロジェクトチームに移植するといった知的財産管理的、ナレッジマネジメント的な機能を期待 各案件は、弊社の場合、「○○対応」という形で事業部門から、やってくる。 現状、案件ベースで管理がされている。 しかし、サービス毎にどういう案件を経て、今に至っているか 管理がされると、 そのサービスについて、どういう進化を遂げたのか、 投資対効果はどうだったのか という分析が出来るのではないだろうか。 PMOのもう１つの視点 組織間の調整や会議のファシリテーション、進捗管理やリスクマネジメントなどのプロセス導入、事務作業のサポートなど幅広い。ＰＭ個人の能力に頼るのではなく、組織的な支援を行うことでプロジェクトマネジメントの質を向上させる **関連ドキュメント -[[リンク>http://www.atmarkit.co.jp/aig/04biz/pmo.html]] -[[ITPro>http://itpro.nikkeibp.co.jp/article/COLUMN/20080724/311429/]] 2009-07-10T16:04:11+09:00 1247209451 https://w.atwiki.jp/minanana/pages/25.html **概要 あらゆる現象を洗い出す論理的思考力 いかなるミスをも逃さない緻（ち）密さ システム性能などを定量的に評価する姿勢 **関連ドキュメント -[[BBS記事>http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=10311&forum=25]] [[リンク>http://itpro.nikkeibp.co.jp/article/COLUMN/20090602/331172/?ST=biz_leader]] 2009-07-07T17:10:28+09:00 1246954228