データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経
「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。 「データモデルなきアジャイル」の危うさ: 設計者の発言 データモデルは単なるDB構造の話ではない 扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産である
“言われた通り”ではもうダメな理由──「データを中心に考える」とは、どういうことか
前回まで、リレーショナルデータベース（RDB）は、データを行と列の2次元の表形式で表すこと、表形式のデータは物理ファイルに格納されていることについて、Oracle Databaseを例にリレーショナルデータベース管理システム（RDBMS）のアーキテクチャを中心に説明してきました。 昨今、データベース管理者（DBA）／ITシステム管理者などにも、ただシステムを管理したり、業務部門などから依頼されたシステムを言われた通りに構築したりすればいい時代は終わり、「ビジネス視点」、つまり「ITで、いかにビジネス（会社や組織全体の利益や成長）に貢献するか」の視点を持って業務を進行していかなければなりません。 そこで今回は、RDBの「データ」にフォーカスし、ビジネスの成長や変化などによって後々で発生するであろう課題や問題を事前に回避して、ビジネスに役立つデータベース構築を行うために欠かせない「DOA（Da
DOAを捨てた後OOAが混乱を招いている - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
【XDev】「データモデリングで要件定義の精度を上げよう」と，真野正氏
「昨今のシステム・トラブルの原因の一つに，要件定義が甘いことが挙げられる。データモデリングを活用することで，要件定義の精度を高められる」---。9月7日に開催されたソフトウエア開発者向けイベント「X-over Development Conference 2007」で，データアーキテクト 代表の真野正氏（写真）は，「要件定義」に「データモデリング」をクロスオーバーさせるメリットをこう語った。 要件定義が甘くなる一因として真野氏は，「ビジネスが複雑になり，ユーザーでさえ自分たちが何を作りたいのかわからないことがある」と指摘。また，新システムを構築する際に，現行システムの仕様が把握し切れず，ブラックボックスがそのまま受け継がれてしまう危うさにも注意を促した。 データモデルの構成要素は，エンティティ，リレーションシップ，属性の三つ。これらを使ってビジネスルールを表すことで，要件を明確にしやすくな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第4回：届いてないよ、聴かせてよDOA (1/4)
