最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
ソフトウェア開発をする上で、要求が実現可能か否かの判断は非常に重要です。その理由は、開発工程の後半のフェイズで実現不可能であることが発覚しても、後戻りがきかない場合があるからです。冷静に考えれば誰でも理解できることですが、なぜかこの手の失敗は多く発生しています。では、失敗しないためには、どのようなアプローチをすればいいのでしょうか。今回は、これに対するひとつの考え方をご紹介します。 1．求められていることは何なのか？ “求められていること”、これはソフトウェアを開発する上で非常に重要であると共に、必ず抑えるべきポイントです。これを外してしまうと実現可否以前に、要求通りのソフトウェアを完成させることができなくなってしまうからです。 求められていること＝要求事項です。 この要求事項は、分類すると以下のようになります。 上記の表は、ソフトウェアに対する品質属性モデルとして、米国ヒューレット・パッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
