このページはキーマンズネットに掲載されていたページを元にしています.http://www.keyman.or.jp/
SUMMARY | INDEX | |||||||||
|
|
現在のソフト開発のライフサイクルにおいて、とかく軽視されがちなのが仕様書の作成です。設計から実装に至るまでのプログラミング作業が重要なのはもちろんですが、仕様書作成を軽視すると、想定外のトラブルが起こりがちです。たとえば、次のようなトラブルは起きていませんか? |
【チェック1】 サービスイン後、度重なる仕様変更の要求が! 決めたはずの仕様をクライアントに十分に理解してもらえてなかった!? |
【チェック2】 開発が進むにつれて仕様書と実際のソフトウェアのソースとの乖離が顕著となり、保守が困難になってきてしまった! |
【チェック3】 派生開発を行っているところで、要求とプログラムの関係がつかなくなってしまった! |
【チェック4】 要求の変更内容や反映時期を間違えてまった! |
【チェック5】 何がベストな仕様なのか、開発者も、クライアントもわからなくなってしまった! |
【チェック6】 顧客要求が変化した時に、クライアントに対して具体的な変更点を指摘できない! |
【チェック7】 仕様書は作ったが、あまりに細かすぎて本来実現したい機能が見えなくなってしまった! |
【チェック8】 仕様書と実際のコードの間に不一致が発生してしまった! |
【チェック9】 メンテナンス作業の段階で、担当者全員が全体の流れを把握しきれなかったため、混乱が生じてしまった! |
上記のようなトラブルを一度は経験されている開発者の皆さんも多いのではないでしょうか? それらのトラブルを回避するために、「誰が見てもわかりやすく、コンパクトで正確な仕様書、ドキュメント」を作成することが重要となってくるのです。 |
最低限必要となる文書は「文章」で書くことが必要となってきます。図はあくまでも補助的なものとして考えてください。そこには、コードから生成される文書を含む必要はなく、あくまでもコンパクトな記述でいいわけです。また、分析・設計・実装モデルは、その設計理由も記述する必要があります。
|
「UML を用いて仕様書を書きました。」 これだけでは、わかりやすい仕様書は記述できません。 |
|||
|
|||
|
Nirvanaは、ソフトウェア開発の分析・設計を支援します。ツールそのものもJavaで記述されているので、可搬性があります。利用可能な表記法としてUMLを採用。オブジェクト指向開発における文房具として、気軽にご利用いただけます。 |
|
Q1.それほど大規模なシステムでなければ、仕様書の記述にそれほど力を入れる必要はないのでは? | |
小規模なシステムであっても、お客様とは何らかのかたちで合意をとる必要があります。仕様型の記述はとても簡明で容易にお客様と合意がとれる形式です。ぜひ、きちんとした仕様書の作成をお勧めします。 |
Q2.仕様が頻繁に変更になる場合や、仕様が決まらないうちに設計に入らなくてはならない場合も あるのですが、その場合でも仕様型の記述は有効なのですか? |
|
仕様型は最も簡潔なかたちで仕様を表現することが可能です。しかも、システムが提供するサービス単位で記述することがきます。仕様が頻繁に変化するとしても、仕様型として記述しておけば、少なくともどの部分がどのように変わるかが簡単にわかると思います。 仕様が決まらないという場合も全く同様です。すべてが決まっていなくても、部分的に決まっていることがあれば、その部分については記述しておくことで、何が決まって何が決まっていないかも明らかになります。 仕様を書くことにより、何が不明で、何を決めなければならないかが見えてくるかもしれません。さまざまな状況があったとしても、仕様記述は開発の効率化に有効な手段であると考えています。 |
このページはキーマンズネットに掲載されていたページを元にしています.http://www.keyman.or.jp/