第5回 仕様整理に「デシジョンテーブル」を使ってみよう | gihyo.jp
はじめに 複雑な仕様を整理する。テスト担当者の仕事の1つはこれです。 ソフトウェアが仕様通りに動くかどうかを確かめるのがテストの役目です。ですが、複雑な条件が絡み合った仕様をテストする場合には、まず仕様を把握し、理解しなければなりません。これがなかなか骨の折れる作業です。 もちろん、この悩みはテスト担当者に限ったことではなく、開発設計者にとっても同じように悩ましい問題でしょう。次から次へとクライアントから降ってくる、追加の要求を、すっきりと仕様に整理して、不具合のないシステムを作ることは決して簡単な仕事ではありません。 とりわけ、やってくる要求は既存のシステムの仕様とは無関係にやってきます。追加の仕様を設計、実装する際には、既存の仕様と整合性をとらなくてはなりません。「とりあえず」、で修正してみたものの、テストをしてみると、不具合が発覚。再度修正したら今度は別のところで不具合が発生…
ソフトウェア開発プロジェクトを蝕む10の典型的な過ち
プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1．「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C#たんと学ぶ／わりと硬派なソフトウェア開発講座 第1回「C#でできること」
