スクラムは、「役割定義とビジネスと開発の間のコミュニケーションパターン」だということができる。アジャイルは、言ってみれば工学の考え方を開発のソーシャルな面に延長したのだ。
アジャイルは、「ビジネスとソフトウェア工学の間のコネクタ」ということだ。
理論的背景をを求めない 遠吠えに 聞こえるのだが．工学にできない理由を面ってどうなるのだろう？こつこつ メトリックス をして 工学に しなければ と 思う
2009年10月11日日曜日
2009年10月10日土曜日
HTML5時代
サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などである
テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく．CSS, HTML, JS, Media Filesはすべてスタティック・ファイル．
HTMLをスタティックファイルにし、JavaScriptでJSONなりXMLを引っ張って来て表示する設計にしておけば、さすがにそこの仕様定義をおろそかにはできない。
データベースの整合性の責任を１００％Modelに負わせ（つまりModelを単なるO/Rマッパーではなく、ビジネスロジックを含んだモジュールとして設計して作り込む）、そこだけは徹底的なテストケースを作って強固なものにしておくことにより、Controller側の変更で多少のミスをしてもデータベースの整合性が壊れたりしない、という設計にしておくとController側の変更がもう少し気楽に、かつ頻繁にできる．
HTML5の時代かなと思わせる．IEあやうしだ
2009年10月7日水曜日
要求定義
- システム開発の上流工程として最も重要なものとされている、本質的な課題として次の3点が挙げられる
- 要件の目的や要件を決めるべき役割の曖昧さの排除
- 経営層、業務部門、情報システム部門における納得性の高い合意形成
- 要件を洗練させ、十分な検討を経た上で期限内に確定させるマネジメント
新要件定義手法は、
- 要件の構造化
- 因果関係からみた要件の可視化
- 要件を成熟させるプロセス
といった3つの方法論から構成され、要件の階層構造データベース、関係分析ワークシート、要件定義の手順書、要件評価シートなどをユーザーに提供。
要件の構造化
「要件の構造化」では各要件を、経営層、業務部門、情報システム部門の3つの役割と、目的、手段の繰り返し構造によって整理。経営の目的、施策、業務要求、実現手段、システム機能の5つの階層で要件を構造化する。この構造化によって、役割ごとに定義すべき要件、部門間で合意するべき要件が明らかになるとともに、要件の安全性が確認できるため曖昧さを排除できる。
因果関係からみた要件の可視化
5つの階層で構造化した要件の関連をひとめで把握することができるワークシートを用意。 これにより、要件の充分性、妥当性などを客観的に分析することが可能になり、納得性の高い合意形成や優先順序づけにより、要件の絞り込みに貢献できる。
要件を成熟させるプロセス
「要件を成熟させるプロセス」では、要件定義の作業を経営層、業務部門、情報システム部門の間や、関連する業務部門間、部門内の部門長や担当者間といった利害関係者間の調整を考慮した合意形成のための5つのフェーズを用意、12のタスクに分けてタスクごとに利害関係者間の合意形成を、まんべんなくとるための作業を定義する。フェーズは、「スタートライン」「ステージ1」「中間レビュー」「ステージ2」「最終レビュー」と5つの段階。さらに、各タスクの完了時に各要件の検討度合いを38の軸から評価し、要件の成熟度を把握、適切なタイミングでの対策などを可能とする。
失敗するプロジェクトを分析すると、そもそも失敗する商談を獲得してしまうこと、上流工程における要件確定の不備が原因となっていることが多い ユーザー企業には要求と要件が違うということをわかっていただきたい。
要求とはやりたいことを洗い出すものであり、要件とは機能に着目し、投資金額や投資期限を前提として、できる内容を定義するものであり、両者の違いを明確化しなければならない．
富士通の新しい要求定義手法だが、目新しさはない．
2009年10月4日日曜日
2008年5月4日日曜日
登録:
投稿 (Atom)
