Microsoft Word - SEMAT-vision-ja.doc
ソフトウェア工学の方法論と理論 ソフトウェア工学の方法論と理論 ソフトウェア工学の方法論と理論 ソフトウェア工学の方法論と理論 (SOFTWARE ENGINEERING METHOD AND THEORY – A VISION STATEMENT) By Ivar, Bertrand and Richard (日本語翻訳1 : 平鍋健児) 1. 目的とスコープ 目的とスコープ 目的とスコープ 目的とスコープ(Purpose and scope) Semat の最初の Call for Action では、今後 Semat initiative が扱おうとしている問題の概要を定義 する。 Call for Action Call for Action Call for Action Call for Action ソフトウェア工学(Software Engineering)は未成熟なプラク
SEMAT つづき(ゴールと原則)：An Agile Way：オルタナティブ・ブログ
SEMATのCall for Actionを引き続き紹介します。４章のゴールと５章の原則です。 ゴールには、この活動の目標とトラック（ワーキンググループ）が示されていて、それぞれに活動が進められるようです。 ・ 定義(Definitions)： ソフトウェア工学、およびその領域のその他本質的なコンセプトを定義する。 ・ 理論(Theory)： 本質的な助力を提供する理論（特に数学からの）。 ・ ユニバーサル(Universals)： Sematカーネルに組み込むべき、ソフトウェア工学の汎用要素を特定する。 ・ カーネル言語(Kernel language)： ユニバーサル、プラクティス、パターンを記述する言語を定義する。 ・ 評価(Assessment)： ソフトウェア工学のプラクティス、理論を評価する手法。（Semat自体の評価も含む） ぼくは特に、Theoryに注目しています。ここには
SEMAT.org にて「ソフトウェア工学再建」運動が開始：An Agile Way：オルタナティブ・ブログ
semat.org というサイトで始まっている、「ソフトウェア工学の再建」とも言うべき復興運動をご存知ですか。現在のソフトウェア工学が、あまりにもおそまつであることを省みて、再度、基礎からソフトウェア工学を積み上げようではないか、という動きです。 そこに署名している人たち(signatories)の顔ぶれがすごい。 Pekka Abrahamsson Scott Ambler Victor Basili Jean Bézivin Dines Bjorner Barry Boehm Alan W. Brown Alistair Cockburn Larry Constantine Bill Curtis Donald Firesmith Erich Gamma Carlo Ghezzi Tom Gilb Ellen Gottesdiener Sam Guckenhei
分析とは何か、設計とは何か？：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発を「問題解決」、と見ると、 問題→解という活動だと考えられる。左の「問題」は、問題空間にあり、右の「解」は解空間にある。設計とは、このマッピングを行なう活動だと考える。では、分析とは何か。 実際には、（ソフトウェアでは特に）問題が複雑だったり曖昧だったりすることから、このままではうまく解けない（悪構造 ill-structured problem）。そこで、一旦、この「問題→解」という現実世界の問題をモデル化しよう、ということになる。「問題空間」、「解空間」という空間と直行する空間軸として、上下に「モデル空間」と「現実空間」を導入する。そうすると、４つの象限が現れる。その４つの象限に、現実空間の「問題」と「解」、そして、モデル空間の「分析モデル」と「設計モデル」を置く。ここで、分析モデル＝モデル化された問題 、設計モデル＝モデル化された解である。そして、問題→解という直線的
「ふりかえり」が失敗する８つの理由：An Agile Way：オルタナティブ・ブログ
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
RubyKaigi2007 のトークス資料がアップされました。：An Agile Way：オルタナティブ・ブログ
今年の私の中の最重要イベントだった、RubyKaigi2007。 はじめてRuby界でのライトニングトークスに挑戦したときの資料が、アップされました。（ありがとうございます＞角谷さん） http://www.flickr.com/photos/68498640@N00/sets/72157602641219277/ （最後の４枚のスライドは、後付け、の落ちです） 荒い画像ですが、用意した「情報カード紙芝居」と「その場の手書き」の臨場感がどこまで伝わるかな。。。。上記ページには、録画されたビデオへのリンクもあります。 なお、RubyKaigi2007の全LTの資料のリストはこちらです。 http://jp.rubyist.net/RubyKaigi2007/Program-LT.html
Agile2007 Wednesday：An Agile Way：オルタナティブ・ブログ
Mary Poppendieckのリーダーシップについてのセッションは、立ち見（というか地べた座り）で満席。とくに、ＴＰＳとアジャイルの中から、「人」についての共通の考えを導き出しています。 「標準化」とはなにか。Mary は「現場の経営」（大野耐一の唯二の著書の１つで、最近英訳された）から、以下を引用し、いま、ソフウェア業界、多くの大企業で行われている間違った標準化について、指摘しました。 標準は、カイゼンの最初のベースラインというだけで、変えることが前提なんだ、そして、それはかならず現場で書く。 現在のソフトウェア業界で、いかに多くの「標準」というものが、現場から離れて書かれており、かつ、変えるのが困難か。作るのに１・２ヶ月もかかったら、それはもうダメだ。他人が机の上でつくった標準ではなく、「自分たちが作った標準」でなければ、カイゼンのモチベーションはうまれない。こういう、「あたりまえ
テスト駆動開発のテストは、テストか？―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]
アジャイル開発の中の１つのプラクティスであるTDD(Test Driven Development、テスト駆動開発)に使われるユニット・テスト、というものの役割について、よくテスト界の人との意見の相違がある。テストとしての完全性、や、品質保証についての考え方から見ると、テストとは呼べないのでは？ということ。 最近、アメリカテスト界の有名人であり、アジャイルコミュニティへの貢献も大きい、Brain Marick(www.testing.com/cgi-bin/blog) 氏とメールで話す機会があった。 アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ これは、以前「テストの役割=進捗管理＋設計戦略」 blogs.itmedia.co.jp/hiranabe/2005/08/sd4__c05e.html で 紹介した、t-wadaさんの「テス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
