「標準ソフトウエア工学教科書」を作ってみたいと思います その１６ ３．４

土日シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は、詳細設計です。

---

■３．４　詳細設計（内部設計）

　前の工程である、外部設計で、以下のものが決まりました
　　・画面定義書
　　・ＤＢ定義書
　　・帳票定義書
　　・サービス定義書

　プログラム内部を決定する内部設計（詳細設計）では、
　　（１）まず、フレームワークを決めます
　　（２）フレームワークが決まると、どんなファイル、クラスを作るか
　　　　　決まってしまいますので、
　　（３）そこの部分を設計します。

以下、それぞれについて説明していきます。

---

（１）フレームワークの決定

　現在のプログラミングでは、
　　　・属人性の排除
　　　・生産の効率性
　　　・変更しやすさ
　などなどの理由から、フレームワークを使った開発が主流です
　（って、言い切っちゃっていいかなあ？）

　画面、ＤＢを使っている場合、ＭＶＣアーキテクチャやその変形に基づく
フレームワークを使うことが多いです。
　ＭＶＣとは、
　　画面部分（Ｖｉｅｗ）と処理＆ＤＢ入出力部分（Ｍｏｄｅｌ）、それぞれの
分離性を高めるために、この間に制御部分（Ｃｏｎｔｒｏｌ）を置いたものです。
　頭文字をとって、ＶＭＣ・・・ではなく、ＭＶＣ

　こうすると、画面と処理部分が分離されるため、画面はデザイナー、処理は
プログラマと別々の人が担当できる（のが理想だけど、そこまではうまくいかない）
のと、画面で変更があったら画面だけ修正、処理で変更があったら処理だけ修正と
いう具合に、修正を局所化できます。

　そして、このＭＶＣアーキテクチャ（やそれに似たもの）を実現するのが
フレームワークです。

　フレームワークには、主に

　　・画面と処理をつなぐ、コントローラー部分のフレームワーク
　　　　（Ｔ２，Ｓｔｒｕｔｓなど）
　　・処理（モデル）部分のフレームワーク
　　　　（Ｓｐｒｉｎｇなど）
　　・ＤＢアクセス部分のフレームワーク（Ｏ／Ｒマッピング等）
　　　　（Ｈｉｂｅｒｎａｔｅなど）　

　などに分かれているのですが、最近は、これらをまとめて、すべての機能を提供する
フルスタックフレームワークが流行です（Ruby on Railsなど）

---

（２）フレームワーク決定→作成物決定

　そして、フレームワークが決まると、何をどのように作ればよいかが決まってきて
しまいます。
　これは、フレームワークを利用する場合、ハリウッドの法則に従わないといけない
からです。

　ハリウッドの法則とは、

　　　私を呼び出すな、必要なら私から呼び出す

　というもので（ハリウッドの女優の、監督への売り込みをうるさく思った監督が、
女優にいうせりふらしい）、フレームワークを決定すると、書くところがきまって
しまい、そこしかかけません。

　たとえば、Ｓｔｒｕｔｓを採用した場合

　　・画面遷移などを書く、Struts-config.xml
　　・実際の画面をＪＳＰで記述（strutsタグ混在）
　　・データバインディングを行うActionForm
　　・データ処理を行うAction

　ぐらいしかかけず、かつ、書き方、内容もきまっています。

　そこで、フレームワークを選択すると、何を書けばいいかがきまります。

---

（３）各部分を設計

　そこで、フレームワークが求めるファイルを、外部設計をもとにつくっていく
ことになります。この段階では、実際にプログラミングするのではなく、クラス図
などを作ることになります。

　　・・・が、作っていってしまったほうが早いかも・・・

---

　実際のフレームワーク決定は、もっと早い段階の場合が多いと思います
　というのは、フレームワークによって出せる画面の限界みたいなのが
あることがあるからです。

　この内部設計までで詳細化はまず終わりで、以降の工程は(プログラミングや
ＳＱＬなどに）変換していく作業になっていきます、。

「標準ソフトウエア工学教科書」を作ってみたいと思います その１５ ３．３

土日ではなくなってしまいましたが（＾＾；）

土日シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は、外部設計です。

---

■３．３　外部設計

　前回、要求分析で要求をだしたので、次に、この要求を満たすシステムを設計していきます。
　設計については、ここで、２つに分けて考えます。

　　１．ユーザーや外部システム等（ユースケースのアクター）で見える部分。
　　　　→インターフェース、特にユーザーインターフェース（ＵＩ）

　　２．ユーザーや外部システム等（ユースケースのアクター）で見えない部分

　１は外部に見えるところなので、外部設計、２は、内部部分なので、内部設計となります。
　今回は、このうち、外部設計について行います。

------

　外部設計に関して、一番大きな部分は、
　　　１．ユーザーとのインターフェースを決める、ユーザーインターフェース
　　　２．他システムがアクセスするＤＢ、ファイル部分
　　　３．Ｗｅｂサービス等の場合、通信部分のインターフェース（引数と返り）
　　　４．２．３の基本となるコード化

　画面メッセージを分ける場合もありますけど、それは、１に含まれると、ここでは考えましょう。
　２に関して、先ほどの説明だと、他に見えるところだけでもいいのでは？と思うかもしれませんが、このテーブルは見えて、あのテーブルは外部に出さないので、設計しないとなると、検証できなくなってくるので、この場合、外に見えるか否かにかかわらず、全体を設計します。

　なお、ユーザーインターフェースとの矛盾をチェックするために、仮に他システムがＤＢ、ファイルにアクセスしないとしても、外部設計でＤＢ、ファイル設計するのが普通だと思います。

　なお、４のコード化設計は行うのですが、１、２をしているときに自動的に出来てしまうので、意識して行うのは、１のＵＩ、２のＤＢ，ファイル定義で、最近のＷｅｂサービスにおいて、３を考えるという形です。
　なお、以降面倒なので、ＤＢ，ファイル設計と書かずに、ＤＢ設計としてしまいます。

--------------

　では、ＵＩ，ＤＢをどのように設計していくかですが、まず、前提について、確認してみます。
　前提として、要求仕様では、こんなことをしているのでした。

（１）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、

（２）えらい人からえらくない人へ、仕事を分割していく
　　　→その仕事の範囲をざっくりと図や文にまとめる

（３）最終的に、仕事を受け持つ担当者に行き着く
　　　担当者のやるべきことを、入力と出力に着目して、記述する
　　　→機能要求

（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）

（５）機能要求、非機能要求を要求仕様書という形でまとめる


つまり、（３）の段階で、入力と出力は、決まっているはずです。
なので、この入出力を検討します。

（あ）（３）の入出力を、画面、帳票、ＤＢなど、メディアごとに分ける。

（い）画面について
　　　　（い－１）画面全体のルックアンドフィールを決める
　　　　　　　→全体的な画面イメージ
　　　　　　　　（背景、大きなレイアウト、ナビゲーション等）

　　　　（いー２）（あ）で抽出した画面を、１画面にするか、複数のものを
　　　　　　　　　まとめるかなど考慮して、画面割りをきめる。

　　　　（い－３）画面をどのように遷移させていくか、画面遷移をきめる
　　　　　　　　　　　→追加する画面が出てくるかも

　　　　（い－４）各画面の画面レイアウトを決める

　　　　（い－５）い－３、い－４をまとめて、画面定義書とする
　　　　　　　　つまり、画面定義書は、画面遷移図と画面レイアウトからなる

　　　　（い－６）お客さんにチェックしてもらって、承認を得る


（う）ＤＢについて
　　　　（う－１）どのようなテーブルがいるか決める
　　　　　　　→正規化したりして

　　　　（う－２）テーブルの項目などを決める

　　　　（うー３）テーブルの妥当性を確認する
　　　　　　　　・入力したデータで、必要なものは保存されているか
　　　　　　　　・容量などの見積もりで、無茶はないか？

　帳票に関しては（い）の画面を帳票にかえて読み替えてください。ただし帳票遷移はありえないので、そこは無視します（い－３はない）
　Ｗｅｂサービスに関しては、（う）のテーブルをサービスに読み替えてください。
　　　　　

（え：成果物）結果として、画面定義書、ＤＢ定義書、帳票定義書、サービス定義書ができます。

------------

　Webアプリケーションの場合、画面をＨＴＭＬで記述しておくと、レイアウトは画面イメージを貼るだけだし、お客さんと確認するとき、ブラウザを使ってプレゼンできます（＝プロトタイプになる）。
　このＨＴＭＬで画面をつくるということが、後工程でとても楽になることなのですが、
　それは、後工程の話としておいておきます。

　上記のやり方だと、画面・帳票のレイアウト、遷移に関しては、この外部設計の段階で確定し、ＤＢはおおよそ決まります（内部設計や実装で変更もありえる）。

　ただし、画面設計はそこまでやらないという考えもあります。
　項目をこの段階では確定させない（確定できない）という考え方で、その場合、画面定義書は、内部設計でつくられます。
　が、この方法の場合、お客さんに見せるのがもっと後になり、画面が内部設計中に動くので、内部設計にダイナミックな修正が入ります。これを嫌う場合、ここ（＝外部設計）で大まかに確定してしまいます。

---

「標準ソフトウエア工学教科書」を作ってみたいと思います その１５ ３．２

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

昨日、アップしそびれた分、「３．２　要求分析」です。

---

３．２　要求分析

　前回の超上流で、プロジェクトの目的と、プロジェクトマネージャーぐらいは決まった。
　そこで、次の段階としては、一般的に考えると、

（１）プロジェクトマネージャー（部長くらいとしよう）は、
　現場責任者（課長）をあつめて、プロジェクトの目的などを
　話します。

（２）現場責任者（課長）は、大まかに仕事と担当者の関係はわかるので、
　それをもとに、担当者を指名して

（３）担当者が業務内容を話します。
　ここで、業務の入出力が決まります。

（４）さらに、システム化するに際して、ユーザーインターフェース
　や、応答時間など、業務以外の部分を決めます。

（５）それらをまとめます。


　前回の話で、（１）のプロジェクトマネージャーとか目的等は決まりました。
このあと、（２）、（３）の作業をして、現場担当者の作業（入力－処理－出力）
を明確化するのですが、それには、構造化手法と、オブジェクト指向の方法があります。


------


　構造化手法の場合は、まずシステム全体の入出力を考え、コンテキスト・
ダイアグラムを作成します（ＤＦＤでプロセスが１個のもの）。

　それから、システムを詳細化していきます。
　企業であれば、部長から課長、係長、現場担当者という具合にヒアリングをかければ、
詳細化されていくはずです。それを表現します。

　途中の管理職の人が、現場の詳しいことがわからないようであれば、入出力は
省略し、こんな機能があるというＤＭＭの形で詳細化していき、
　課長、係長と下がっていくと、どこかで入出力がはっきりするようであれば、
そこからＤＦＤを使って書き起こすのがいいと思います。

　どちらのケースでも、最終的な現場担当者の作業は、業務流れ図として表現します。
　業務流れ図では、どのデータを何から（画面から、ＤＢから等）入力し、どこに出力
するか、どのような手順で処理するのか、処理するための条件があるのかが、図で
書き表わされます。

　これができると、データベースに書くべき内容がわかり、エンティティが出てくるので
ＥＲ図がかけます。

　ＤＦＤは、上位のＤＦＤと詳細化した下位のＤＦＤで、外部からの入出力が一致して
いないといけません（一致していなければ間違い）。
　また、ＤＦＤのファイルとＥＲ図のエンティティ、業務流れ図のＤＢが対応している
はずです（１対１でなくてもよいが、ＥＲ図にあるエンティティが理由もなく、ＤＦＤや
業務流れ図にまったく出現しないのは、不自然）。


-----------

　一方、オブジェクト指向の場合、ユースケース図から始まります。

　まずは、部長が課長に仕事を割り振られ、課長が担当者に割り振るとき、課長は、
担当者に、ある仕事をしてもらうことを期待して、割り当てるのが普通と考えられ
ます。
　もちろん、「お手伝い」「遊軍」としてわりあてることもありますが、その人
たちは無視します。すべてお手伝いというのはすくなく、受注、倉庫番とか、
なんらかの仕事はあるんじゃないでしょうか？もし、全員お手伝いだとしたら、
その会社はシステム導入以前に問題があると思います。

　その仕事に、だれが関係するかを考え、仕事関係者をアクター、仕事をユースケース
としてユースケース図を描きます。
　が、ユースケースは動詞の形が望ましいです。たとえば、「倉庫番」は、「倉庫番する」
というのは不自然ですので、「入庫する」「出庫する」「在庫照合する」などに分かれます。

　まず、大きくざっくりと描くことが大事で、たとえば「入庫する」を「積みおろしする」
「検品する」「データ入力する」とか、細かく分けちゃうと、混乱します（これは、あとの
アクティビティ図に描きます）

　とはいえ、ユースケースも細かくすることはあります。

　まあ、そんな形で充分細かくなったら、担当者が行う作業を、手順とともに表現する
アクティビティ図を作成します。
　しかし、アクティビティ図は、構造化分析の業務流れ図ほどの表現力をもちません。
　入出力は表現できません。
　そこで、ユースケース記述というのを作って、そこの基本系列等に、入出力を文章で
描いていくことになります。

　なお、データ構造に関しては、ユースケース記述を見れば書けることになります。
　ＵＭＬはＥＲ図はないので、これに相当するクラス図で描くことになりますが、実際は
ＥＲ図を使ってしまうことが多いです。

-------------------

　上記の方法により、業務の入出力が決まりました。
　構造化手法の場合には、業務流れ図に、オブジェクト指向の場合には、
ユースケース記述に業務内容（入力－業務－出力）の流れは、記述されています。

　次に（４）の業務以外の要求についてまとめます。
　
　ちなみに、（３）のような業務に関する要求を、機能要求、
（４）のような、業務以外の要求を、非機能要求とか言ったりします。

　非機能要求は、上記、オブジェクト指向分析で利用する図（ＵＭＬ）でも、
構造化手法分析で利用する図でも表現されないし、明確な分析方法はありません。
（ちなみに、ＳｙｓＭＬの要求図では表現できます）。


そこで、

　非機能要求グレード
　http://sec.ipa.go.jp/reports/20100416.html

　のようなチェックリストを基に考えたり、機能要求を基に考えたり、
　 JIS X 0129-1 (ISO/IEC 9126 )のソフトウェアの品質特性を基に
考えます。


　ここまでくると、（５）のように要求仕様書としてまとめられます。
　まとめ方としてはＩＥＥＥ８３０等に基づいてまとめるのが、今のところ
よいのでしょうか？

----------------

　この要求仕様書の作成方法は、各社各様です。上記の方法は、公開されている、
一般的な方法について描いただけです。
　ただ、手法の側面をそぎ落とし、誰が何をやっているのかだけに注目すると

（１：前提）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、

（２）えらい人からえらくない人へ、仕事を分割していく
　　　→その仕事の範囲をざっくりと図や文にまとめる

（３）最終的に、仕事を受け持つ担当者に行き着く
　　　担当者のやるべきことを、入力と出力に着目して、記述する
　　　→機能要求

（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）

（５：成果物）機能要求、非機能要求を要求仕様書という形でまとめる

という形になると思います。

「標準ソフトウエア工学教科書」を作ってみたいと思います その１４ ３．１

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回から「第三章　ソフトウエアプロセス各論」です。
今回は「３．１　超上流開発」です。

---

第三章　ソフトウエアプロセス各論

　これから３章で、ソフトウエアプロセスの各論に入っていきます。

　ソフトウエアプロセスの方法論は時代によって、大きく変わって生きます。
　構造化手法とオブジェクト指向では、ぜんぜん違う部分もあるし、開発のときに書く図については、まったく違うものです。

　なので、方法論に目を取られると、あまりの違いに、ある手法を身につけても、１０年もたったら、意味ないものになってしまうんではないかと思ってしまうと思います。

　しかし、方法論の奥に潜む、「何を決めているのか？」ということは、実はあんまり変わっていなかったりします。
　ソフトウエアプロセスは、そこを抑えることが重要だと思います。
　最終的には、入力と出力、その間をつなぐ処理がわかれば、プログラミングできます。
　しかし、要求から、一足飛びに、そこに行き着くのは、問題がいろいろあるので、途中、いろいろなことを決めていきます。その過程について、抑えていくことが重要で、方法論は、そのための手段にすぎません。

　「何を決めているか？」

そこを抑えていってください。そうすると、どうしてこういうことをしているのかが見えてくると思います。

---

■３．１　超上流開発

　開発は、要求分析から始まることが多いと思います。
　要求分析は上流工程と呼ばれます。
　では、その要求は、どこから生まれてくるのか？
　と考えてしまうと、要求分析＝上流工程の上を考えないといけなくなります。
　この部分が、超上流工程なのですが、超上流という場合、アカデミックと実務の人たちでは、別のことを想定しています。

----

　アカデミックでは、超上流工程は、開発しようとするシステムに関係がある人（ステークホルダー）を見つけてきて、その人たちの目的や要望を分析することになっています。

　具体的には、

・ステークホルダーの抽出
・ステークホルダーの価値観などから、ゴールを見つける
　　　CATWOE分析→ソフトシステム方法論
・ゴール指向分析などで、ゴールを詳細化する
　　　KAOS,i*など
・詳細化したゴールが、「こうすれば実現可能になる！」というレベルまで
　落としこむ→実現可能なユースケース＝要望

　という風に考えて生きます。
　このとき、ゴールから詳細化していくわけですが、その過程で、
ロジカルシンキングやKJ法、ブレーンストーミングやマインドマップなどの
手法を使っていきます。


----

　一方実務的には、経営理念をもとに会社を設立し？、そのビジョンを実現するために、なにを実現するかを考えます。

　具体的には、
　　・自分たちは何に優れていて、外部環境から考え、何をすべきなのかを、
　　　SWOT分析を通して考え、
　　・そして、どんな事業をすべきかをPPMによって分析します。
　　・その結果、
　　　　　　ある事業において、自社は何が優れているから、勝てる！
　　　という、主要成功要因（クリティカルサクセスファクター：CSF）をみつけ、
　　・それに数値目標（KGI）／評価指標（KPI）などをつけるのですが、
　　　その際、、
　　　　「財務の視点（過去）」
　　　　「顧客の視点（外部）」
　　　　「内部業務プロセスの視点（内部）」
　　　　「イノベーションと学習の視点（将来）」
　　　の“4つの視点”を用いて、考えてまとめると、バランス（ト）・スコアカード
　　　BSCになります。
　このようにして、戦略を練っていくということになっているのですが・・・

　・・・まあ、ここまではしないかな？
　でもSWOTくらいは、まとめないにしても考えるかな・・・


　とにかく、戦略ができると、その戦略を実現するために、情報システムは、どうしたらよいかと考えます。さらに、戦略をもとに、中長期計画から、部門ごとの短期計画に落とし込まれることにより、戦術化します。マーケティングなら４P、財務なら資金調達とか・・・
　その際にも、システム化が必要になるかもしれません。

　まあ、このようにして、システム化案が出され、それを実現するための中心人物であるプロジェクトマネージャーが選出されるという形でプロジェクトが始まります。この場合、大雑把な目的はあるけど、プロジェクトマネージャー以外はあんまり決まってないかな？


----

　このように、アカデミックな手法と実務では、大きく違っていますが、
　違っている中にも共通点があります。

　　１．システム化するということは決まっている
　　２．少なくとも、プロジェクトマネージャーは決まっている
　　３．目的がある。

　２は、だれが・・に相当します。３は、何を・・・に相当します。

　つまり、超上流にはいろんな形態はあるけど、
　　　このプロジェクトは、どんな目的で、だれが取り仕切るか
　は決まるといえそうです。

　次の要求分析で、このことが、大きな意味を持ってきます。

「標準ソフトウエア工学教科書」を作ってみたいと思います その１３ ２．８

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．８　そのほかのモデル」です。

---

２．８　そのほかのモデル

　ソフトウェアプロセスのモデルは、他にもあります。
　たとえば、形式仕様のBメソッドのように、変形していって、最終的にプログラムをつくるという方法等です。
　「ソフトウェア工学　理論と実践」では、今まで挙がっていたソフトウエアプロセスのモデルのほかに、操作的仕様、変形モデルがあります。

----

　しかし、実際に現場で使われているモデルは、今まで出てきた典型的なソフトウエアプロセスモデルを、自社用にカスタマイズして使っています（テーラリング）。
　したがって、会社ごとに微妙に違ったプロセスモデルを持っています。
　さらに、プロジェクトごとにもカスタマイズしてしまうため、いろいろなプロセスモデルが乱立しているのが、現状です。


　それでは、各社で共通してプロジェクトを行うようなときに困るので、ソフトウエアプロセスの共通のものさしが必要になってきました。それが共通フレームなのですが、その話は５章ですることとして、２章のお話は、ここまで。次の３章で、具体的な開発のプロセスをフェーズを追って見ていきます。

「標準ソフトウエア工学教科書」を作ってみたいと思います その１２ ２．７

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．７　アジャイル、特にスクラム」です。

---

■２．７　アジャイル、特にスクラム

　前回、少し書きましたが、今まであげてきたソフトウエアの開発モデルは、基本的には、開発する内容や要求が、極端に変わらないものでした。

　しかし、現代の社会においては、状況が劇的に変わり、要望もそれにつれて大きく変わることがあります。極端な場合、真逆にすらなります。

　たとえば、フリーソフト。昔は、「ビジネスに使うな！」という指示があったほどです。
　９０年代前半までは、まだそうだったと思います。
　今、そんなことをいう人はいません。むしろ、ApacheやTomcatを「使え」という指示です。
　真逆です。
　たしか、２０００年ごろか、それくらいかに、大きく逆転したと思います。



　現在、真逆化？していることといえば、ケータイの私物でしょうか？
　いままでビジネスで私物をつかうとか、考えられなかったけど、
　あと数年たてば、あたりまえになるかもしれません。
　自分のケータイを会社でつかうことが・・・

---

　ここまで大きな変化でなくても、最近は要望は時々刻々と変化します。
　開発期間中でさえ、「あ、この高速処理は、新しいハードになったから、いらなくなったよ」とか、「今開発中のシステム、会社の部門を再編するから、業務フロー変わるよ！」といった、大きな仕様変更が起こりえます。

　そのような事態に対応するには、今までのような、要求を固定化するようなやり方ではだめです。もっと要求を短期間に、俊敏に変えられるやり方でないとだめです。
　その要求の変化に「俊敏に」対応できるのが、アジャイルです。

　アジャイルには、XP、SCRUMなど、いろいろあります。
　今回は、SCRUM(スクラム）を見てみます。

---

　SURUMの説明としては、

http://www.mountaingoatsoftware.com/system/asset/file/195/RedistributableIntroToScrum_JA.ppt
　にみんなが使える？PowerPointのプレゼンテーションがあります。

　今回は、そこの図を使います。こんなかんじ


　まず、いろいろな要求、図だと、「ギフト包装」とか「クーポン」とか「キャンセル」とか「返品」とか。これらを、「プロダクトバックログ」として記録しておきます。
「クーポン」が２つあるように、すでに記録された要求に、追加、修正されることもあります。

　さて、それら要求されていることを、どのようにして開発していくか？
ということですが、まず、開発期間を、２～４週のスプリントという期間
に分けます。そして、その中でやることをプログラムバックログから
取り出して（例では「返品」を取り出しています）、スプリントゴールと
します。

　そのスプリントゴールを細分化して、スプリントバックログとし、
　朝、朝会をして、今日やることを、そのスプリントバックログから
取り出し、一日のうちに、その課題を行う（２４時間のループ）

　ということを繰り返します。

　こんなかんじで、時々刻々と要求が変わると、時々刻々とバックログも変わり、
それに対応してやることも変わっていくというわけです。

---

　このようにして、要求にアジャイルに対応する方法論がではじめています。

「標準ソフトウエア工学教科書」を作ってみたいと思います その１１ ２．６

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．６　スパイラルモデル」です。

---

■２．６　スパイラルモデル

　前回反復型モデルを取り上げましたが、よくこれをスパイラルモデルという人がいます。
　しかし、本当は、スパイラルモデルというのは、別のモデルでちゃんと実在します。
　今回は、その「スパイラルモデル」が、反復型モデルとどう違うのか？について述べたいと思います。


　スパイラルモデルとは、バリー・ベーム（というのが普通だと思います。Wikipediaではボームになっていますが。ちなみにつづりはBarry W. Boehm）が

A Spiral Model of Software Development and Enhancement[1]

で示したモデルを指します。具体的には、以下の図のように開発していきます（[1]より引用）。

何回もぐるぐる回っていますが、一番内側から

　　１回目のループで運用コンセプト
　　２回目のループでソフトウエア要求を
　　３回目のループで設計を
　　４回目のループで詳細設計から実装、テストを

しています。

　そしてそれぞれのループで

　　・目標、代替案、制約の決定
　　・代替案とリスクの評価
　　・開発とテスト
　　・計画

　を行っていきます（[2]の記述をそのまま使っています）。
　各ループにおいて、プロトタイプを作成し、リスクを評価しているところが特徴です。


　ということは、確かに反復していますが、

　　　反復型の場合は、何回も製品リリースすることもあるのに対し、
　　　このスパイラルモデルは１回の製品リリースだけ

　に対するものです。
　
　また、反復するという意味では、アジャイルにも似ていますが、

　　スパイラルモデルは、ある要求があって（それは真逆になるような劇的な変化はなく）、
　　　　そのリスク評価や不明点の解消のためにプロトタイプを使い繰り返しを行うのに対し、

　　アジャイルは、常識が真逆になるような、劇的な社会の変化や、
　　ユーザーが、「あんた自分の言ってることわかってんの？」と言いたくなるような、
　　要求がわからないような状況の中でも、システムを作っていかなければならない場合に
　　利用可能な手法です。

　なので、学術・研究者などで言う「スパイラルモデル」は、反復型より範囲は狭く、
　アジャイルほどの変化を想定していないといえます。

参考文献
[1]　Boehm, B. W.;TRW Defense Syst. Group, Redondo Beach, CA
"A spiral model of software development and enhancement"
IEEE Computer Society Volume: 21 Issue:5 (1988)pp 61 - 72

[2]　シャリ・ローレンス・プリューガー著　堀内　泰助訳
「ソフトウェア工学　理論と実践」ピアソンエデュケーション
(2001)pp64

「標準ソフトウエア工学教科書」を作ってみたいと思います その１０ ２．５

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．５　反復型モデル」です。

---

２．５　反復型モデル

　前回、ウォーターフォールモデルの問題点として、

・問題点１
　要求仕様を満たすような設計・実装は、実現できないような場合、設計・実装の段階になるまでわかりません。

・問題点２
　ウォーターフォールでは、開発が完了するまで、実際にシステムを稼動して利益を得ることができません。

　ということをあげました。そして、その解決方法として、インクリメンタルモデルをあげたのですが、この問題点として

・問題点３
　すでに稼動しているサブシステムがある場合、新規サブシステムはそれに拘束される。

をあげました。

　今回は、別の問題解決方法、反復型(繰り返し）モデルをあげます

---

　ウォーターフォールでは、まず、全体の要求分析が終わってから、次の設計工程に行きました。反復型では、そうではなく、

１．まずは、絶対必要な機能をあげ、分析します
２．その必要部分の設計、実装をしてリリースします
３．まだできていない機能のうち、必要な機能を分析します
４．２に戻る

こうすると、ずっと、２→３→４→２→３・・・・と繰り返します。
そして、いつか、全機能がそろって、完成します。

こういうやり方です。

　なお、このやり方を、ぐるぐる回っているのでスパイラルという人もいますが、
スパイラルモデルとは、このモデルではない、ちゃんとしたモデルをベームという
人が提唱しています。情報処理試験等で、スパイラルモデルといった場合は、
そのベームの提案したほうをさします。

　一般の人が普通の会話で言う場合は、反復型、ベームの提唱したもの、どちらも
ある場合がありますね。

---

　これは、問題点１を解決しています。必要部分を先に実装して、早期に確認しています。
　問題点３も解決しています。
　全体の必要部分を先に全部作ってしまうため、その部分で、インターフェースの整合性を
とってしまうからです。

　問題点２は、作り方によります。必要部分を使うだけで利益を得られれば、解決したことになりますし、そうでない場合は・・・

　そこで、どういう順番で、何を作るか？ということが重要になります。
　それを空気を読んでいろいろできるようにしたのが、アジャイルのスクラムで、それについては、２回先で触れますが、その前に、先ほど出てきたベームのスパイラルモデルについて説明します。

　

「標準ソフトウエア工学教科書」を作ってみたいと思います その９ ２．４

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．４　インクリメンタルモデル」です。

---

２．４　インクリメンタルモデル

　ここまでの話の流れをまとめると、以下のようになります。

・まず、ソフトウエア開発のプロセスとして、ウォーターフォールモデルが出てきた。
・それを変形したV字型モデル等がある
・ウォーターフォールの問題点を解決するために、さまざまなモデルが出てきていて、
　間違った要求仕様で開発しないようにするための手法として、プロトタイプがあった。

　今回も、ウォーターフォールモデルの問題点の改良版を見ていきます。
　まずは、解決すべき問題点についてですが、ウォーターフォールモデルでは、さらに２つの問題点があります。

・問題点１

　要求仕様を満たすような設計・実装は、実現できないような場合、設計・実装の段階になるまでわかりません。ウォーターフォールでは、設計・実装の段階から要求仕様に戻るということはしないし、そもそも、ウォーターフォール云々という前に、設計・実装から要求分析に戻ると、手間や開発リスクが増大します。


・問題点２
　ウォーターフォールでは、開発が完了するまで、実際にシステムを稼動して利益を得ることができません。しかし、その間に世の中が変化し、当初の要求でシステムを開発・稼動しても意味がなくなってしまうようなことが起きてしまったら、その開発経費は無駄になってしまいます。


　この問題点を解決する方法の１つが、インクリメンタルモデルです。

----

　インクリメンタルモデルでは、システムをいくつかの部分に分割し、その部分ごとに、作っていきます。

　たとえば、会社全体のシステムを作る場合、受注、発注、在庫、財務など、いくつかの部分（サブシステム）にわけ、その部分部分を作っていきます。今回は受注、受注ができたら発注・・のように。

　この方法だと、

・問題点１については、全体を作るより、サブシステムを作るほうが、早くできるので、設計・実装に入るタイミングも早くなり、最悪、要求仕様を修正しなくては、できないという場合になっても、全体を直すより、サブシステムを直すほうが、被害が少なくてすむ

・問題点２については、サブシステムを稼動する（上記の例だと、受注システムだけを稼動する）だけでも意味があるのであれば、システム全体を開発するより、サブシステムを稼動するほうが、早期にできるので、早い段階から、利益を享受できます。
　環境の激変により開発を中止するにしても、サブシステムだけの被害ですむので、少額の被害ですむことが期待されます。

----

　というと、なんかこのシステム開発方法がよさそうに見え、実際、サブシステムごとに開発していくというインクリメンタルモデルは多く行われている（と思います）のですが、問題もあります。

　それは

・すでに稼動しているサブシステムがある場合、新規サブシステムはそれに拘束される。
　稼動している既存サブシステムを修正するのは、コスト高になる。

　　たとえば、受注システムが稼動している段階で、発注システムを考える場合、
　発注システムは、受注システムのDBやDBの稼働環境に影響を受けます。
　もし、受注システムのテーブルを修正しないといけないとなった場合、稼動している
モノに対して、修正をかけ、稼動しているシステムをとめて、データ移行して、
修正版を入れなおして、それが完璧に稼動しないといけないです。

　そのハードルは、結構高かったりします。

「標準ソフトウエア工学教科書」を作ってみたいと思います その８ ２．３

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．３　プロトタイプ（RAD)」です。

---

■２．３　プロトタイプ（RAD)

　前章（２．２）で見た、V字型、フィードバックV字、W字型開発も結局、ウォーターフォールを踏襲しているものでした。

　これらの方法に共通している問題として、開発リスクが先送りされてしまうという欠点があります。

---

　たとえば、
　　「携帯の画面から受注データを送信する」
　　「その際、商品名は、選択できるように」
　という仕様があったとします。

　現実的には、商品が１００００点もあったら、商品名を選択するのが大変です。
　だから、画面入力を考えれば、この仕様は、単純にはできない（何か工夫しないとできない）ということになります。


　ウォーターフォールで開発する場合、この仕様の問題が露呈するのは、画面設計段階です。
　しかし、そのとき、画面設計の人が、この問題を見落とし、１００００点もあるものをドロップダウンリストで設計してしまったら、どうなるでしょう。
　プログラムが作成され、単体、結合テストまで行ってしまいます。
　結合テストのとき、１００００件もドロップダウンできない！と気づき、修正がかかります。　このときは、画面設計まで戻って修正しないといけません。

　一般に、外部設計や旧来言っていた基本設計でのミスは、その設計をテストする結合テストまで、露呈しない危険性があります。よく、結合テストで問題が連続的に発覚、デスマーチになるのは、要するに、設計ミスです。

　では仮に、画面設計のとき、それに気づいて、画面を、「大分類」「中分類」「小分類」と３つのドロップダウンリストにしたらどうでしょう。なんかよさそうです。でも、ユーザーから見たら、大分類、中分類、小分類がどうなっているかわかってなかったとしたら、これは不便そうです。この不便さは、ユーザーの受け入れテストまで、発覚しないかもしれません。
　受け入れテストで発覚したら大変です。大きな作り直しになります。

---

　そこで、プロトタイプを開発することになります。
　画面だけを表示するとか、さらにちょっとしたデータを入出力するだけなら、ツールを使って簡単に作れる場合があります（というか、画面だけなら、たいてい簡単に作れます）

　ですので、設計段階で画面を作ってしまい（これがプロトタイプ）それをお客さんに見せて、OKを取っておけば、上記のような問題は起こらないはずです。このように、要求分析、設計段階で、画面などを部分的に作って(プロトタイプ）、お客さんや関係者などと確認を取りながら開発する方法が、プロトタイプ開発です。

---

　プロトタイプ開発の場合、作った画面等を、後工程で使うかどうかという話があります。
　このとき、後工程で使わない場合は、作ったプロトタイプを「モックアップ」ということがあります。また、プロトタイプは必ずしも「コンピューターで動くものでなくてはならない！」と定義されたものではないようです。紙レベルの紙芝居風のものも、プロトタイプということがあります。

　なお、上記の例の場合、画面は、この方法で問題を早期発見できますが、そもそも、１００００件の商品データを携帯側にどう持つのか、通信で送れるのか？といった、性能面はプロトタイプを作るだけでは、発見することが難しいです。
　つまり、プロトタイプを作れば完璧というわけではなくて、作っても検討しなければいけない問題が、まだ残っているわけです。

「標準ソフトウエア工学教科書」を作ってみたいと思います その７ ２．２

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．２　V字型、フィードバックV字、W字型開発」です。

---

■２．２　V字型、フィードバックV字、W字型開発

　前章の２．１では、ソフトウエアプロセス、すなわち以下に示すプロセス

　　要求分析
　　設計
　　　外部設計
　　　詳細設計
　　実装（プログラミング）
　　テスト
　　　単体テスト
　　　結合テスト
　　　総合テスト

　を単純に順番に並べるウォーターフォールモデルについて説明しました。

　ここで、開発プロセスの関連について考えるます。
　要求分析→設計→実装の内容を、テスト工程で確認しているいう関係になっています。
　そこで、この関係を明確に示すと、

　　要求分析　　　　　　　総合テスト（性能テスト等：非機能要件）　
　　設計
　　　外部設計　　　　　　結合テスト　
　　　詳細設計　　　　　　単体テスト
　　実装（プログラミング）

となります。これを、美しく？すると

　要求分析　　　　　　　　　　　　総合テスト　
　　　外部設計　　　　　　　　結合テスト　
　　　　　詳細設計　　　　単体テスト
　　　　　　　実装（プログラミング）

おお、美しいVの字が・・・
というので、V字型開発といいます。
つまり、V字型開発は、要求～実装までのテスト関係を明確にしただけで、
順番に行うということは、ウォーターフォールと同じです。

---

　さらに考えてみると、ウォーターフォールは、前の工程が終わったら、次の工程に進むわけだから、次の工程に進むときには、前の工程のテスト仕様書は書けるということになります。

　こんなかんじ

　要求分析　総合T仕様書作成　　　　　　　　　　総合T仕様書受入　　　総合テスト　

　　　外部設計　結合T仕様書作成　　　　　　結合T仕様書受入　　　結合テスト　

　　　　　詳細設計　単体T仕様書作成　　単体T仕様書受入　　　単体テスト

　　　　　　　　　　　　　　実装（プログラミング）

（Tは、テストのこと）

おお、美しい？Wの文字が・・・？？

というので、このように、次の工程に進む際、前の工程のテスト仕様書を作成してしまい、テスト時、そのテスト仕様書を受け入れて、テストを実施する開発方法をW字開発といいます。

---

　ここまでは、結局ウォーターフォールモデルのパラダイム、すなわち、工程が終わってから、次の工程に進むというパラダイムは崩れていません。
　しかし、そのパラダイムは現実的には厳しいものがあります。
　次工程に行ってから、前工程の間違いに気づくこともあるからです。

　そこで、次工程に行ってから、間違いに気づいたら、１つ前の工程に戻るという開発方法が考えられました。こんなかんじ。

　要求分析　　　　　　　　　　　　総合テスト　

       ↓↑　　　　　　　　　　　　　 ↓↑　

　　　外部設計　　　　　　　　結合テスト　

　       ↓↑　　　　　　　　　 ↓↑

　　　　　詳細設計　　　　単体テスト

　　　       ↓↑　　　　　 ↓↑

　　　　　　実装（プログラミング）

　これが、フィードバックしているV字型モデル、フィードバックVです。

---

「標準ソフトウエア工学教科書」を作ってみたいと思います その６ ２．１ ウォーターフォールモデル

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．１　ウォーターフォールモデル」です。

---

第二章　ソフトウエアプロセスのモデル

２．１　ウォーターフォールモデル

　１．３章で、ソフトウエアプロセスは

　　要求分析
　　設計
　　　外部設計
　　　詳細設計
　　実装（プログラミング）
　　テスト
　　　単体テスト
　　　結合テスト
　　　総合テスト

　というものがあると書きました。
　では、これを、どのような順番に行っていったらよいでしょうか？
　それが、ソフトウエアプロセスのモデルということになります。

　単純に考えると、「順番にやっていけばよい」ということになります。
　それが、ウォーターフォールモデルです。
　順番にやっていきます。前の工程が終わるまで、あとの工程を行いません。

　この方法、単純でよいのですが（そして今でも使われていますが）、問題もあります。

　大規模なものだと、要求仕様が作成されてから総合テストが終わるまで、何年もかかります。その間に市場環境が変わったり、発注元の事情が変わったりして、修正したくなっても、工程が進んでしまえば、前の工程には戻れない。
　また、後工程になって、この仕様ではできない！と気づいても、前工程には戻れない・・・
　このように、後工程で前工程に戻って修正できないということは、危険がいっぱいになります。この危険性を、抑えるため、

　　　・プロトタイプを作って確認する
　　　・部分部分作っていく
　　　・繰り返し開発していく
　　　・やるべきことをバックログとしておき、状況に応じてやっていく

　など、さまざまな改善手法がでてきました。
　ここでは、以降、ウォーターフォールの改善型の手法を見ていくことになります。

---

「標準ソフトウエア工学教科書」を作ってみたいと思います－その４ １．２ ソフトウエア工学とは

　シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「１．２　ソフトウエア工学とは」です。

---

１．２　ソフトウエア工学とは

　私たちは、毎日、コンピューターに様々な情報処理をさせています。
　計算もそうですし、文書を作成したり、インターネットで検索したり・・・
　しかし、そのたびに、「電子卓上計算機」「文書作成機」など、それ専用のコンピューターをもっていたら、大変なことになってしまいます（そういう時代もあったのですが・・・）
　そこで、今では、プログラムという、コンピューターに処理させる内容を(電気的に）書いて、それを入れ替えるようなことによって、様々な処理を行っています。
　このプログラムがソフトウエアということになります。そして、処理するコンピューターがハードウエアです。

　学問的にコンピューターを扱う場合、コンピューターそのものを科学するということもできます。プログラムとは何か、ソフトウエアとは何か、コンピューター上にプログラムをどのように表現したらよいのかなどなどです。
　そういうコンピューターを科学することを、「コンピューターサイエンス」といいます（まんまやん）。

　一方、ソフトウエアというのは、何か情報処理させるために作られるモノなので、情報処理したい要求に応じて、コンピューターやコンピューターサイエンスの成果を駆使して、どのようにソフトウエアを上手に作るかという工学的アプローチもあります。これが、ソフトウエア工学です。

　つまり、ソフトウエア工学とは、

　顧客の要望に応じたソフトウエアを上手に作るために、コンピューターサイエンスを基礎として、コンピューターを使いこなすソフトウエアを作るための工学

　です。

　では、ソフトウエアを上手に作るには、どうしたらよいのでしょう。
　それには、手順があります。

---

　次回は、「１．３　ソフトウエアプロセスとは」です。

「標準ソフトウエア工学教科書」を作ってみたいと思います－その３ １．１ 情報処理とは

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います
　という話を前回書きました。

今回は「１．１　情報処理とは」です。

---

■１．１　情報処理とは


　人々は毎日、いろんな活動をしています。ご飯を食べたり、寝たり、ご飯を食べたり・・あれ？
　ま、とにかく、ご飯を食べることを考えましょう。
　給料日、お金を下ろしてきて、お昼ご飯を食べることを考えます。
　そうすると、こんな活動をします。

　　会社の事務のおねえさんが、銀行に給料を振り込む
　　私が、銀行でお金を下ろす
　　私が、松屋にいく（吉野家でもすき屋でもいいんだけど）
　　松屋で、食券を買う
　　松屋で、牛丼をたべる

　このうち、「松屋で牛丼を食べる」場合、牛丼はモノなので、私の代わりにあなたが食べたとしても、活動目的は達成されません。活動目的は、「私のおなかを満たすこと」ですが、あなたが食べたら、私は、まだおなかがすいたままです。

　ところが、銀行に給料を振り込む場合、最近は、モノが動いているのではないです。
　お札を持っていって、銀行に振り込んでいるわけではなく、「いくら、だれかさんに振り込んでください」という情報を銀行に伝えて、銀行は、それを受け取って処理しています。

---

　このように、モノではなく、モノの一部の特性（数量とか）を取り出すと、それは、データ、情報ということになります。
　そして、このデータを入力とし、なんらかの処理（変換・計算）をして、目的となる出力を得ることが情報処理ということになります。

　この情報処理、モノが動いているわけではないので、実は、他の人がやってもOKです。
　振込みは、事務のおねえさんでなく、おにいさんがやってもいいし、ロボットがやってもいいかもしれません。
　となると、そういうことを電気的にしてくれる機械を作っちゃえということになります。
　この機械が、電子・計算・機「コンピューター」になります。

---

　なので、現在では、情報処理というと

　　何らかの入力をもとに、コンピューターがさまざまな処理を行い、結果としての出力を得ること

　ということになります。
　
　そしてこの、入力→処理→出力の一連の行為を、「アクティビティ」と呼びます。

　なお、コンピューターは、目に見えて使うこともありますが、「松屋で、食券を買う」のときのように、見た目は食券を売っている機械なのですが、中で、コンピューターに相当するものが入っている場合があります。この場合、コンピューターが「組み込まれている」ということで、「組み込み」といいます。

---

次回は、「１．２　ソフトウエア工学とは」

「標準ソフトウエア工学教科書」を作ってみたいと思います－その２ 目次

　「標準ソフトウエア工学教科書」を作ってみたいと思います
　という話を前回書きました。

今回は目次です。

こんなかんじで、考えています

---

第一章　ソフトウエア工学とは
１．１　情報処理とは
１．２　ソフトウエア工学とは
１．３　ソフトウエアプロセスとは

第二章　ソフトウエアプロセスのモデル
２．１　ウォーターフォールモデル
２．２　V字型、フィードバックV字、W字型開発
２．３　プロトタイプ（RAD)
２．４　インクリメンタルモデル
２．５　反復型モデル
２．６　スパイラルモデル
２．７　アジャイル、特にスクラム
２．８　そのほかのモデル

第三章　ソフトウエアプロセス各論
３．１　超上流開発
３．２　要求分析
３．３　外部設計
３．４　詳細設計
３．５　プログラミングと単体テスト
３．６　結合テスト
３．７　総合・システムテスト

第四章　ソフトウエアプロセスの周辺
４．１　プロジェクトマネジメント
４．２　ソフトウエアメトリクス
４．３　ソフトウエアプロセスの評価
４．４　形式仕様
４．５　ユーザー中心指向

第五章　ソフトウエアプロセスの実例
５．１　ICONIX等
５．２　共通フレーム２００７
　

---

とりあえず、こんなかんじ。
書いていくうちに追加・変更するかも・・

３章は、オブジェクト指向テイストになってしまいます。
ただ、他の本と違い、PMBOKみたいに、入力、出力を明確にし、
その上で、技法？を書きたいと思います。