このページはキーマンズネットに掲載されていたページを元にしています.http://www.keyman.or.jp/

ニルソフトウェア
開発におけるトラブルを未然に防止するには!?

SUMMARY INDEX
ニルソフトウェアは、UML(Unified Modeling Language)に基くダイヤグラム作成が可能なオブジェクト指向用分析・設計用のツール、 Nirvanaを開発・販売させていただいております。分析・設計の文房具として手軽にお使いいただけるNirvanaのニューバージョン発売を機に、開発上流段階における仕様書作成の重要性を皆様にご理解いただければ幸いです。
↓ 仕様書作成の軽視が、思わぬトラブルを招きます
↓ UMLで記述するオブジェクト指向用分析・設計用ツール
↓ Nirvanaは開発者の手軽な文房具です!
↓ よくある質問



現在のソフト開発のライフサイクルにおいて、とかく軽視されがちなのが仕様書の作成です。設計から実装に至るまでのプログラミング作業が重要なのはもちろんですが、仕様書作成を軽視すると、想定外のトラブルが起こりがちです。たとえば、次のようなトラブルは起きていませんか?


こんなトラブル、ありませんでしたか?

  【チェック1】
サービスイン後、度重なる仕様変更の要求が!
決めたはずの仕様をクライアントに十分に理解してもらえてなかった!?

  【チェック2】
開発が進むにつれて仕様書と実際のソフトウェアのソースとの乖離が顕著となり、保守が困難になってきてしまった!

  【チェック3】
派生開発を行っているところで、要求とプログラムの関係がつかなくなってしまった!

  【チェック4】
要求の変更内容や反映時期を間違えてまった!

  【チェック5】
何がベストな仕様なのか、開発者も、クライアントもわからなくなってしまった!

  【チェック6】
顧客要求が変化した時に、クライアントに対して具体的な変更点を指摘できない!

  【チェック7】
仕様書は作ったが、あまりに細かすぎて本来実現したい機能が見えなくなってしまった!

  【チェック8】
仕様書と実際のコードの間に不一致が発生してしまった!

  【チェック9】
メンテナンス作業の段階で、担当者全員が全体の流れを把握しきれなかったため、混乱が生じてしまった!



上記のようなトラブルを一度は経験されている開発者の皆さんも多いのではないでしょうか?
それらのトラブルを回避するために、「誰が見てもわかりやすく、コンパクトで正確な仕様書、ドキュメント」を作成することが重要となってくるのです。





最低限必要となる文書は「文章」で書くことが必要となってきます。図はあくまでも補助的なものとして考えてください。そこには、コードから生成される文書を含む必要はなく、あくまでもコンパクトな記述でいいわけです。また、分析・設計・実装モデルは、その設計理由も記述する必要があります。
「UML を用いて仕様書を書きました。」
これだけでは、わかりやすい仕様書は記述できません。
仕様型(Catalysis)による、図だけではない、明瞭な用語、ドキュメント構造を!
 システムが提供するサービス(アクション)の単位で書く
 オブジェクト同士の関連を書く
 表明(assertion)/宣言的定義を書く~事前(pre)、事後(post)、普遍条件(invariant)定義

仕様型とは?
仕様型とは、システムが持つアクションの形式的な定義です。アクションに対して、簡明で正確な定義を与えることができます。もともとは、オブジェクト指向技術の基礎となっている抽象データ型に由来します。真中の区画はアクション記述における用語間の関係を表します。下端の区分は、表明機構を使ってアクションを表現します。OCLで記述する こともできますし、日本語で書くこともできます。

UML(Unified Modeling language)とは?
国際標準の仕様記述法です。オブジェクト指向分析、設計のために使用できる表記法。
とくに、クラス図、コラボレーション図、シーケンス図、ステートチャート図が使用されることが多く、ユースケース図、オブジェクト図、アクティビティ図、コンポーネント図、配置図なども定義されています。



Nirvanaは、ソフトウェア開発の分析・設計を支援します。ツールそのものもJavaで記述されているので、可搬性があります。利用可能な表記法としてUMLを採用。オブジェクト指向開発における文房具として、気軽にご利用いただけます。
1.分析で現われたオブジェクトをクラス図を用いて表現します。

2.仕様は、これらオブジェクトをインポートしながら記述します。

3.仕様型を詳細化しながら設計型とします。
仕様型図サンプル
クリックで拡大します。





Q1.それほど大規模なシステムでなければ、仕様書の記述にそれほど力を入れる必要はないのでは?
  小規模なシステムであっても、お客様とは何らかのかたちで合意をとる必要があります。仕様型の記述はとても簡明で容易にお客様と合意がとれる形式です。ぜひ、きちんとした仕様書の作成をお勧めします。

Q2.仕様が頻繁に変更になる場合や、仕様が決まらないうちに設計に入らなくてはならない場合も
   あるのですが、その場合でも仕様型の記述は有効なのですか?
  仕様型は最も簡潔なかたちで仕様を表現することが可能です。しかも、システムが提供するサービス単位で記述することがきます。仕様が頻繁に変化するとしても、仕様型として記述しておけば、少なくともどの部分がどのように変わるかが簡単にわかると思います。

仕様が決まらないという場合も全く同様です。すべてが決まっていなくても、部分的に決まっていることがあれば、その部分については記述しておくことで、何が決まって何が決まっていないかも明らかになります

仕様を書くことにより、何が不明で、何を決めなければならないかが見えてくるかもしれません。さまざまな状況があったとしても、仕様記述は開発の効率化に有効な手段であると考えています。

戻る▲


Nirvana製品トップページへ

このページはキーマンズネットに掲載されていたページを元にしています.http://www.keyman.or.jp/