Press Enter■Copyright(c) 2000-2009 ITmedia Inc. 著作権はアイティメディア株式会社またはその記事の筆者に属します。（著作権について） 当サイトに掲載されている記事や画像などの無断転載を禁止します。 「＠IT」「＠IT自分戦略研究所」「＠IT情報マネジメント」「JOB＠IT」「＠ITハイブックス」「ITmedia」は、アイティメディア株式会社の登録商標です。 当サイトに関するお問い合わせは「＠ITへのお問い合わせ」をご覧ください。
テンプレートから学ぶ 受注する開発者のためのテスト仕様書
1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。 お客様（発注者）はプロジェクトを起案する際、何を作るかを「
Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby
以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日本語訳である。 ThoughtWorksは、2006年から本格的なプロジェクトにRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。
「現状のソフトウェア開発は間違っていないか？」（プロセス編）
失敗例その1 「要件定義が終わらない」 ユーザーから要求を聞き出し、システム要件に落とし込んでいくのが要件定義だ。要件定義が終わらないかぎり基本設計に移れない。しかし、要件定義がいつになっても終わらない。その理由として、ユーザーからうまく要求を引き出せないことがある。そもそも今回のシステム開発でユーザーが具体的に何をやりたかったか、どんなものをIT化すればよいのかがはっきりしない。3カ月と予定されていた要件定義工程はすでに１カ月オーバーしてしまっている、しかもユーザーが満足するような要件定義書がいまだにできていない。 失敗例その2 「設計工程の無駄」 オープン系の開発でウォーターフォール開発を行っている。設計工程は、基本設計、詳細設計に分かれている。基本設計では、要件定義に基づき、主に画面などユーザーがシステムを利用するうえで意識する部分を設計し、詳細設計では、それをプログラムにつなげるた
分散バージョン管理Git/Mercurial/Bazaar徹底比較
分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理
分散プロジェクトの誤謬 - steps to phantasien t(2008-02-26)
タネン本を始めとする分散システムの教科書で必ずとりあげられる話題に "分散コンピューティングの誤謬" がある. 以下 Wikipedia から引用. ネットワークは信頼できる. レイテンシはゼロである. 帯域幅は無限である. ネットワークはセキュアである. ネットワーク構成は変化せず一定である. 管理者は一人である. トランスポートコストはゼロである. ネットワークは均質である. ネットワークプログラミングをしたことがあれば, いずれも該当のバグに思いあたる節があると思う. これらはみな複数台の計算機が関わる際の問題であり, いわばコミュニケーションの問題. 同じ問題は計算機同士に限らず, 人と人の間, 組織の間でもおこる. 順番に例を並べてみる. <伝言や連絡は信頼できる> : できない(よね?) ミーティングには欠席者がいる. 後輩は話を聞いてない. メモもとらない. メールはスパムに
IPAフォーラム2007で討論してきた - 東大MOT学生の奮闘記
10月30日に行われたIPAフォーラム2007の『「学生から見たＩＴ産業」と「ＩＴ産業から見た学生」〜ＩＴ産業は学生からの人気を回復できるか〜』と題された討論会でしゃべってきた。IPAとは情報処理推進機構の略で、情報処理技術者試験とか、未踏ソフトウェア創造事業をやっているところ。 大学の先生から、討論会に出る学生を求めいているという話を聞いたのが討論会に参加したきっかけ。僕はてっきり、IT産業の未来について語り合うのかと思っていたのだが、「IT産業は3Kのイメージが強く、就職において人気がなくなってきているが、どうすればその人気を回復できるか」というタイトルを聞いて、ちょっとがっかりした。 ＠ITにこの討論会についての「IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ − ＠IT」という記事が上がっていた。ちなみに、記事の最初の写真に討論会に参加した学生が写っているが、前列の
404 Blog Not Found:惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら
2007年10月26日01:45 カテゴリ翻訳/紹介Art 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら 全プログラマーが泣いた。 If architects had to work like programmers... 実は一つだけ「ローカライズ」にあたって変えた前提があります。日本ではこちらの方が実情に沿っているでしょう:) 建築士様、 家を一つ設計施行してくださいな。まだ何が必要か具体的なことはわからないので、そこはよきに計らう方向で。 寝室の数は、2から45までの間。寝室の追加と削除は簡単に出来るようにしといて下さいね。青写真が出来次第あたしが何が気に入ったかを最終判断します。それぞれの青写真について明細書を付けるのをお忘れなく。後で気に入ったのをピックアップできるように。 完成後の家の費用は、今住んでいる家よりも安上がりでないと駄目なことを留意してくださいな。そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
