ソフトウェア開発の現場で良く聞く発言。 「仕様書をキッチリ書こう」 「きちんとした仕様書を書ける人が欲しい」 「仕様書に記載漏れが無いようにしてくれ」 仕様書とは、完成した文書が一つ有れば全てが片付くような性質のものではなく、何をどう作るかという検討内容を記録として明文化したものだ。だから、仕様書の作成行為そのものが設計行為であり、個々の対応項目を明確にして、設計上の漏れ・不備・矛盾を早期に見つけ出すための重要な作業だ。単に、これをやる、あれをやるという程度の文章の断片が並んでいるようでは、それは仕様書としての役割を果たしてない。 後のテスト工程で火を噴くような開発プロジェクトに共通しているのは、そのような明確な設計工程が欠如している点だ。仕様の検討を疎かにしたり、漏れや矛盾の確認を事前に行っていない以上、潜んでいた問題点が顕在化してくるのは当然のことだ。こんな時「仕様書が無いから」という
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く