動画配信サービスってどうなの？

基本的に映画は劇場で観たいのですが、観に行けなかったり、観に行かなかったりした作品はリビングのテレビで観ています。

ここ最近は、駅前のレンタルショップに足を運ぶより、家で動画配信サービスを利用して観ることが多いのですが、巷には様々な動画配信サービスが存在しているので、どれにしたらいいの？というのは悩みどころです。結論から言ってしまえば、今後も状況がまだまだ変化すると思うので、ある日突然、サービスの提供が終了してしまってもショックを受けないように、いつでも乗り換えればいいやという気軽な感じで付きあえばいいのではと思っています。

動画配信サービスの比較サイトなどは世の中に溢れているので、最新の情報はそちらを参考にされるのが良いかと思います。

「動画配信サービス」「比較」などで検索すると比較サイトがたくさん存在してことがわかります。
更新日時を確認して、最新の情報に基づいているかを気を付けます。

以下では、動画配信サービスを選ぶ判断基準や気を付けている点を参考までに紹介します。

観たい作品があるか？

最も基本的なことですが、観たい作品が提供されているかを確認します。ハリウッド超大作などはどのサービスでも提供されているようですが、サービスによって、提供されている邦画やアニメ、国内ドラマ、海外ドラマに特色があるようです。

単品課金か？定額見放題か？

動画配信サービスは、作品ごとに課金されるものと月額固定で見放題のものとに大きく二分されます。前者はレンタルショップで観たい DVD を借りる感じに近いサービスですし、後者は BS や CS の有料チャンネルを契約する感じに近いサービスです。基本的には、視聴頻度によってお得なほうを選べばよいと思います。
いずれにしても、観たい作品をいつでも観られるというところは同じです。

購入か？レンタルか？

単品課金のサービスの場合、サービスによっては、作品を購入するかレンタルするかを選べることがあります。購入した作品はいつでも視聴できますが、レンタルした作品は30日以内に視聴を開始して視聴を開始してからは48時間以内に視聴を完了することといった制約があります。レンタルショップのように延滞は出来ないので、期限内に視聴しないと観られなくなります。（そのときは、再度レンタルすればいいわけですが…）
当然ですが、購入のほうがレンタルより値段は高くなりますが、各サービス間の価格差は殆ど無いという印象です。

Apple iTunes

Amazon インスタント・ビデオ

Google play

基本的には、その作品を今後も繰り返し何度も観るかで判断すればいいと思いますが、自分の場合はレンタルで観ることがほとんどです。

HD か？ SD か？

サービスによっては、画質を選べることがあります。基本的には、視聴するデバイスによって判断すればいいと思います。スマートフォンで観るだけなら SD 画質でも問題ないと思いますし、リビングの大きなテレビで観るなら HD 画質のほうが無難な気がします。自分の場合は HD 画質をテレビで観ています。

ダウンロードか？ストリーミングか？

サービスによって、動画をダウンロードで配信しているものとストリーミングで配信しているものとに二分されます。ストリーミングで配信されている場合は、回線速度によっては視聴中に映像が止まってしまったりすることがあるようなので注意が必要です。回線速度は様々な諸条件で変動するため、一概にこれで大丈夫という基準は言いにくいですが、光回線であることに越したことはないと思います。自分の場合は光回線ですが、映像が止まったりということは無いです。

家のテレビで見るためには？

サービスによって様々です。テレビの LAN ポートに LAN ケーブルを接続して直接インターネットに接続するものもあれば、インターネットに接続されたデバイスをテレビの HDMI ポートに接続するものもあります。手持ちのデバイスだけで観られるのか、新たにデバイスを購入したりしないといけないのか、注意が必要です。

で、結局、どうなの…？

自分の場合、視聴頻度が多くないので定額見放題のサービスは今のところ利用していません。あと、Chromecast があるので、せっかくなら対応しているサービスを PC レスで使いたいというのが最近の心境です。

結局のところ、人によってどのサービスが合っているかは違いますし、まだまだ業界が過渡期なところもあるので、いろいろなサービスを試しながら楽しもうかなと思う昨今です。

エクスプレスとインターネット

東海道新幹線のN700系でWi-Fiによるインターネット接続サービスを利用しようとしてトラブったので、そのときのメモ。結論的には、設定の変更漏れが原因でしたが…。

復習を兼ねると、N700系などのWi-Fiインターネット接続サービスを利用するためには、対応プロバイダと契約しておく必要がある。このあたりは、下記のJR東海のサイトを参照。

東海道新幹線Ｎ７００Ａ・Ｎ７００系での車内インターネット接続サービスについて

自分の場合、OCNホットスポットを契約しているので、通常は、NTTコミュニケーションズのホットスポットのサービスエリアか、ソフトバンクテレコムのBBモバイルポイントのサービスエリアでは、Wi-Fiによるインターネット接続が利用できる。

1つ目のトラップは、OCNの料金プランがバリュープランの場合は、認証IDの設定が少し異なっていたというもの。

以前に契約していた料金プランはADSLセットプランでOCNホットスポットをオプションにしていたのだけど、引っ越しを機にバリュープランへ変更していた。引越し先のシェアハウスがインターネット接続サービスを提供しているのでプロバイダ契約は不要だけど、OCNのメールアドレスをそのまま使い続けたかったのと、N700系やマクドナルドでWi-Fiインターネット接続を利用することがよくあるので、OCNホットスポットのオプションを残したかったというので、そうしている。

OCNカンタンコネクトの設定方法を改めてよく見ると、このあたりの認証IDのことがちゃんと書かれている。

OCNカンタンコネクトの設定

２つ目のトラップは、N700系などでは、OCNホットスポットのサービスエリアでログインしなければインターネットへ接続できないというもの。

N700系などは、ホットスポットのサービスエリアでもあり、BBモバイルポイントのサービスエリアでもあるので、OCNホットスポットを契約していれば、どちらのサービスエリアを選択してログインしてもよいのかと思っていたらそうではないらしい。

OCNカンタンコネクトのウィンドウでいうと、1番目のOCNホットスポットサービスエリアを選択してログインする必要がある。2番目のBBモバイルポイントローミングエリアを選択してログインするとエラーになる。

BBモバイルポイントのサイトをよく見ると、提携プロバイダであるOCNでは新幹線車内でのインターネット接続に対応していないことがちゃんと書かれている。

BBモバイルポイント対応プロバイダ

ところで、今回のトラブルで気がついたのだけど、ホットスポットのサービスエリアは2013年7月末で終了してしまうらしい。OCNホットスポットの契約でも、引き続きBBモバイルポイントのサービスエリアは利用できるようだけど、ってことは、N700系などでのインターネット接続サービスは利用できなくなってしまうのかな…？！

【2013/07/24 追記】
2013年8月以降、N700系などでのインターネット接続サービスは、BBモバイルポイントローミングエリアで提供されるそうです。

doxygenを活用したソフトウェア開発プロセスの考察

doxygenで何を書くのか？

　doxygenには様々なコマンドが存在するが、今回は、ソースコードにソフトウェア詳細設計書を埋め込むという観点で、doxygenのコメントとして何を記述すればよいかということを考察する。

　doxygenコメント作法・規約を定義するにあたり、ソフトウェアは以下のような構成をしていることとする。

• 機能ユニット（クラスやスレッド）ごとにファイルを作成する
• 各機能ユニットはソースファイルとヘッダファイルを一組として構成する
• ヘッダファイルには機能ユニット間のインタフェースを定義する
• ソースファイルには機能ユニットの実処理を実装する

ファイルヘッダ

　ファイルヘッダとはファイルの先頭に記述するコメントのことである。ファイルヘッダには、そのファイル全般に関わる事項を記述する。

• ファイルヘッダに記述する事項
• 機能ユニットの概要
• 機能ユニットの機能・役割を一行で記述する。
• 注意事項
• 機能ユニットに関する注意事項があれば、箇条書きで記述する。
• 補足事項
• 機能ユニットに関する補足事項があれば、箇条書きで記述する。
• 参照情報
• 機能ユニットに関する参照情報を箇条書きで記述する。例えば、ソフトウェア・アーキテクチャ設計書の該当する章や図表の番号やタイトルなどを記述する。
• 変更履歴
• いつ、誰が、どのような変更を行ったのかを記述する。ファイル全体に関する変更はここに記述する。関数、クラス・構造体などの定義をファイルに追加、またはファイルから削除した場合はファイルヘッダへ記述する。関数内の処理の変更やクラス・構造体のメンバ変数の変更などは、後述するそれぞれのヘッダへ記述する。

• ファイルヘッダのフォーマット

/*---------------------------------------------------------------*/ /** @file ファイル名 @brief 機能ユニットの概要 @attention 注意事項 @note 補足事項 @sa 参照情報 @date 変更履歴 */ /*---------------------------------------------------------------*/

関数ヘッダ

　関数ヘッダとは関数定義の前に記述するコメントのことである。関数ヘッダには、その関数に関わる事項を記述する。

• 関数ヘッダに記述する事項
• 関数の概要
• 関数の機能・役割を一行で記述する。
• 関数の詳細
• 関数の処理内容を箇条書きで記述する。
• 注意事項
• 関数に関する注意事項があれば箇条書きで記述する。
• 補足事項
• 関数に関する補足事項があれば箇条書きで記述する。例えば、関数が実行されるスレッドなど情報を記述する。
• 参照情報
• 関数に関する参照情報を箇条書きで記述する。例えば、ソフトウェア・アーキテクチャ設計書の該当する章や図表の番号やタイトルなどを記述する。シーケンス図の該当する箇所や処理内容を示したフローチャートなどがあれば記述する。
• 引数
• 戻り値
• 変更履歴
• いつ、誰が、どのような変更を行ったのかを記述する。
• 関数ヘッダのフォーマット

/*---------------------------------------------------------------*/ /** @brief 関数の概要 @details 関数の詳細 - 関数の処理内容 @attention 注意事項 @note 補足事項 @sa 参照情報 @param [in] 引数名 引数の説明 @param [out] 引数名 引数の説明 @param [in,out] 引数名 引数の説明 @return 戻り値の説明 @retval 戻り値名 戻り値の説明 @date 変更履歴 */ /*---------------------------------------------------------------*/

クラス・構造体ヘッダ

　クラス・構造体ヘッダとはクラス定義や構造体定義の前に記述するコメントのことである。クラス・構造体ヘッダには、そのクラス・構造体に関する事項を記述する。

• クラス・構造体ヘッダに記述する事項
• クラス・構造体の概要
• クラス・構造体の役割を一行で記述する。
• 注意事項
• クラス・構造体に関する注意事項があれば記述する。
• 補足事項
• クラス・構造体に関する補足事項があれば記述する。
• 参照情報
• クラス・構造体に関する参照情報を記述する。
• 変更履歴
• いつ、誰が、どのような変更を行ったのかを記述する。
• クラス・構造体ヘッダのフォーマット

/*---------------------------------------------------------------*/ /** @brief クラス・構造体の概要 @attention 注意事項 @note 補足事項 @sa 参照情報 @date 変更履歴 */ /*---------------------------------------------------------------*/

doxygenをどのように使うのか？

　doxygenさえ導入すればソフトウェア開発の全てがうまくいくというものでない。doxygenはあくまでもソースコード内に記述したコメントからHTMLやRTF形式のドキュメントを生成するツールにすぎないため、コンポーネント図やシーケンス図などのUMLを用いてソフトウェア・アーキテクチャ設計を実施することは難しい。そこで、ここでは、doxygenをソフトウェア開発プロセスに効果的に導入する方法を考察する。

　では、以下のようなアクティビティを含むソフトウェア・エンジニアリング・プロセスを例に説明する。

• ソフトウェア要求定義
• ソフトウェア・アーキテクチャ設計
• ソフトウェア詳細設計
• 実装
• 単体テスト
• ソフトウェア結合テスト
• ソフトウェア総合テスト

　上記のプロセスのうち、ソフトウェア・アーキテクチャ設計から実装までのアクティビティは以下のようなタスクを含むとする。

ソフトウェア・アーキテクチャ設計のタスク

• 設計条件の確認

　ソフトウェア要求定義で整理・体系化した要求や制約のうち、ソフトウェア・アーキテクチャを設計する上で重要なソフトウェア機能要求、非機能要求および制約条件をリストアップする。将来的に導入することが予想される要求や制約条件も可能な限りリストアップし、ソフトウェア・アーキテクチャを検討する上でのインプットとすることで、近い将来に大幅な見直しが必要となるリスクを低減する。

• ソフトウェア構成の設計

　上記でリストアップした要求や制約条件とハードウェア構成などをもとに、ソフトウェアのレイヤと機能ユニットの分割方針を策定する。また、分割方針に従って、具体的に機能ユニットの分割を行い、各機能ユニットの役割を定義する。機能ユニットの分割は、クラスなどの静的構成とスレッドなどの動的構成の両方について行う。ソフトウェアの構成は、UML2.0のコンポーネント図を用いて表現する。また、実装方針として、ソフトウェア構成と結び付いたディレクトリやファイルの構成、プレフィックスの命名方針を策定する。

• ソフトウェア全体の振る舞いの設計

　上記で分割した機能ユニット間の処理シーケンスを策定する。代表的なユースケースや特異なユースケースに対する処理シーケンスは必ず作成する。ソフトウェア全体の振る舞いは、UML2.0のシーケンス図を用いて表現する。

• インタフェースの設計

　上記で策定した機能ユニット間の処理シーケンスをもとに、各機能ユニットのインタフェース仕様を策定する。

• ソフトウェア・アーキテクチャ設計書の作成

　上記までの検討結果を整理・体系化して、ソフトウェア・アーキテクチャ設計書を作成し、リストアップした要求や制約条件に対するソフトウェア・アーキテクチャの妥当性を検証するという観点でレビューを実施する。

ソフトウェア詳細設計のタスク

• プログラムユニット分割

　ソフトウェア・アーキテクチャ設計で策定した各機能ユニットのインタフェース仕様をソースコードに記述する。このとき、ファイルヘッダや関数ヘッダをdoxygenコメントで作成し、各機能ユニットや各インタフェースの機能を記述する。

　次に、各機能ユニットのインタフェースに対して処理内容をリストアップして関数ヘッダに追記していき、それらを関数として分割する。各関数の仕様もソースコードに記述する。関数ヘッダをdoxygenコメントで作成し、各関数仕様の説明を記述する。

　この時点では、インタフェース仕様や関数仕様のみを記述し、実処理は実装しない。

• プログラムユニット設計

　上記で分割した各関数の処理内容を関数ヘッダに記述する。処理内容が複雑になる場合は別途フローチャートなどを作成し、関数ヘッダの参照情報に追記しておく。

• ソフトウェア詳細設計書の作成

　ソースコードに記述したファイルヘッダや関数ヘッダなどのコメントからdoxygenを使ってドキュメントを生成し、ソフトウェア詳細設計書とする。また、レビューを実施する。

実装のタスク

• プログラムユニットの実装

　ソースコードに記述したファイルヘッダや関数ヘッダなどのコメントに従って実処理を実装し、ソースコードを完成させる。また、doxygenコメントに記述した内容が正しく実装されているかという観点でレビューを実施する。

おわりに

　今回は、doxygenを活用したソフトウェア開発プロセスの一例を示した。doxygenに限らず、現在では、様々なソフトウェア開発支援ツールやWebサービスなどをフリーかそれに近い低コストで利用できる環境が整っている。それらを上手く活用し、ソフトウェア開発の本来の目的である問題解決や価値創造に努めていきたい。

参考文献

• doxygenサイト（英文）

http://www.stack.nl/~dimitri/doxygen/index.html 

•  doxygen日本語サイト

http://www.doxygen.jp/

•  電八開発倶楽部

http://www.denshin8.jp/den8dev/doxygen.html

•  サクラエディタ

http://sourceforge.net/p/sakura-editor/wiki/DoxygenComment/

ソフトウェア開発プロセスにdoxygenをうまく導入できないだろうか…。

はじめに

　ソフトウェア開発において、突然の開発要件の追加やバグの修正のために、ソースコードを変更したけれど、ドキュメントを更新していなかったということがしばしば発生する。企業などが業務としてソフトウェア開発を行う場合には、限られた工数で高い機能と品質を実現する必要があるため、ドキュメントとソースコードの内容に齟齬があると、調査に余計な工数を必要としたり、新たなバグを混入するリスクを高めることになる。

　こうした課題に対して、ソフトウェア開発プロセスにおけるサポート・プロセスの作業を詳細に規定することによって、ドキュメントとソースコードの変更内容のトレーサビリティを管理しようと試みることがある。こうしたアプローチは誤りではないが、サポート・プロセスの詳細化や厳格化は、結果的に生産性の低下やコストの増加を招くリスクがあることも事実である。

　ここでは、とくにソフトウェア詳細設計書とソースコードに焦点を当て、ソフトウェア・エンジニアリング・プロセスの観点から、この課題の改善策を考察する。

なぜdoxygenを使うのか？

　そもそも、ソフトウェア詳細設計書とソースコードの内容に齟齬が生じてしまう要因は、それらに論理的な関係はあっても、物理的な関係がないことにあると考える。物理的な関係とは、ソースコードを変更すると自動的にソフトウェア詳細設計書へ反映できたり、またはその逆のことができることを指す。そこで、ここでは、ソフトウェア詳細設計書とソースコードに物理的な関係を持たせる方法を考察する。
　例としては、ソースコードを自動生成できるIDEを導入したり、モデルベース開発の手法を導入するといった方法が考えられる。しかし、ここでは、小規模なプロジェクトや現在進行中のプロジェクトにも比較的に導入が容易な方法として、古くから存在するdoxygenというツールを活用することを検討したい。
　doxygenでは、ソースコードにコメントの形式でドキュメントを埋め込むことになるため、齟齬が生じる問題が発生しにくくなることを期待できる。

どのようにdoxygenを使うのか？

　一方で、doxygenを導入すればソフトウェア開発の全てがうまくいくというものでない。doxygenはあくまでもソースコードに記述したコメントからHTMLやRTF形式のドキュメントを生成するツールにすぎないため、ユースケースやシーケンスなどのUMLを用いたソフトウェア・アーキテクチャ設計を実施することはできない。そこで、ここでは、doxygenをソフトウェア開発プロセスに導入するための方法を考察する。

　ここでは、以下のようなアクティビティを含むソフトウェア・エンジニアリング・プロセスを対象とする。

• ソフトウェア要求定義
• ソフトウェア・アーキテクチャ設計
• ソフトウェア詳細設計
• 実装
• 単体テスト
• ソフトウェア結合テスト
• ソフトウェア総合テスト

　また、上記のプロセスのうち、ソフトウェア・アーキテクチャ設計から実装までのアクティビティは以下のようなタスクを含むとする。

• ソフトウェア・アーキテクチャ設計のタスク
• 設計条件の確認

ソフトウェア・アーキテクチャを設計する上で重要なソフトウェア機能要求、非機能要求および制約条件などをリストアップする。

• ソフトウェア構成の設計

上記でリストアップした要求や制約条件とハードウェア構成などをもとに、レイヤと機能ユニットの分割方針を策定する。また、分割方針に従って、具体的にレイヤと機能ユニットの分割を行い、各レイヤと各機能ユニットの役割を明確化する。機能ユニットの分割は、クラスなどの静的構成とスレッドなどの動的構成の両方について行う。

• ソフトウェア全体の振る舞いの設計

上記で分割した機能ユニット間の処理シーケンスを策定する。

• インタフェースの設計

上記で策定した機能ユニット間の処理シーケンスをもとに、各機能ユニットのインタフェース仕様を策定する。

• ソフトウェア・アーキテクチャ設計書の作成

上記までの検討結果を整理・体系化してソフトウェア・アーキテクチャ設計書を作成し、レビューを実施する。

• ソフトウェア詳細設計のタスク
• プログラムユニット分割

ソフトウェア・アーキテクチャ設計で策定した各機能ユニットのインタフェース仕様に対して、処理内容をリストアップしていき、それらをプログラムユニットとする。また、各プログラムユニットのインタフェース仕様を策定する。

• プログラムユニット設計

上記で分割した各プログラムユニットの処理内容を詳細化する。プログラムユニットの処理内容は箇条書きで構わないが、処理内容が複雑で誤解を招く恐れがある場合はフローチャートを作成する。

• ソフトウェア詳細設計書の作成

上記までの検討結果を整理・体系化してソフトウェア詳細設計書を作成し、レビューを実施する。

• 実装のタスク
• プログラムユニットの実装

ソフトウェア詳細設計書に従ってソースコードを作成し、レビューを実施する。

　現実のソフトウェア開発では、上記のプロセスに従ってソフトウェア・アーキテクチャ設計書までは適切に作成していても、様々な理由でソフトウェア詳細設計書は作成していないことがしばしばあると思われる。そこで、ここでは、以下のようにdoxygenを導入して、ソフトウェア詳細設計と実装を行うことを検討したい。

• ソフトウェア詳細設計のタスク
• プログラムユニット分割

ソフトウェア・アーキテクチャ設計で策定した各機能ユニットのインタフェース仕様をソースコードに実装する。このとき、ファイルヘッダや関数ヘッダをdoxygenのコメントスタイルで作成し、各インタフェース仕様の説明を記述する。

次に、各機能ユニットのインタフェースに対して処理内容をリストアップして関数ヘッダに追記していき、それらをプログラムユニットとする。各プログラムユニットのインタフェース仕様もソースコードに実装して、関数ヘッダをdoxygenのコメントスタイルで作成し、各インタフェース仕様の説明を記述する。  

この時点では、インタフェース仕様のみを実装し、実処理は実装しない。

• プログラムユニット設計

上記で分割した各プログラムユニットの処理内容を詳細化して関数ヘッダに追記する。処理内容が複雑で誤解を招く恐れがある場合は別途フローチャートを作成し、関数ヘッダにはリンク情報を追記する。

• ソフトウェア詳細設計書の作成

ソースコードに記述したファイルヘッダや関数ヘッダなどのコメントからdoxygenを使ってドキュメントを生成し、詳細設計書を作成する。また、レビューを実施する。

• 実装のタスク 
• プログラムユニットの実装

ソースコードに記述したファイルヘッダや関数ヘッダなどのコメントに従って実処理を実装する。また、レビューを実施する。

　ファイルヘッダや関数ヘッダをdoxygenのコメントスタイルで作成する際、なにを記述するべきなのかについては次の機会に検討する。

ソフトウェア・アーキテクチャ設計でやるべきことってなんだろう…。

本当はもっと纏まった文章を書くつもりだったのですが、何時まで経っても纏められそうにないし、少し荒削りでも早く出すことが大事だと思いましたので、駄文ですがご容赦ください。書き出しが唐突に始まりますが、これもご容赦ください。m(_ _)m

以下のようなアクティビティを含むソフトウェア・エンジニアリング・プロセスで、ソフトウェア・アーキテクチャ設計のアクティビティでやるべきタスクについて考察してみた。

• ソフトウェア要求定義
• ソフトウェア・アーキテクチャ設計
• ソフトウェア詳細設計
• 実装
• 単体テスト
• ソフトウェア結合テスト
• ソフトウェア総合テスト

ソフトウェア・アーキテクチャ設計のタスク

設計条件の確認

ソフトウェア・アーキテクチャを設計する上で重要なソフトウェア機能要求、非機能要求および制約事項をリストアップする。このとき、リストアップする要求や制約事項に漏れがあると、後の工程でソフトウェア・アーキテクチャの大規模な見直しが必要となるリスクを高めることになるため、漏れを防止するという観点から適切にレビューを実施することが重要である。
　また、ここで策定するソフトウェア・アーキテクチャは、その後2〜3年は大きく見直すことなく使い続けることも目標とするため、将来的に導入することが予想される要求や制約事項も可能な限りリストアップする。

ソフトウェア構成の設計

上記でリストアップした要求や制約事項とハードウェア構成などをもとに、レイヤと機能ユニットの分割方針を策定する。レイヤの分割方針では縦方向の役割分担の考え方を策定し、機能ユニットの分割方針では各レイヤにおける横方向の機能分担の考え方を策定する。また、機能ユニットの分割方針は、クラスなどの静的構成とスレッドなどの動的構成の両方について策定する。
　策定した分割方針に従って、具体的にレイヤと機能ユニットの分割を行い、各レイヤと各機能ユニットの役割を明確化する。

ソフトウェア全体の振る舞いの設計

上記で分割した機能ユニット間の処理シーケンスを策定する。全てのユースケースに対して処理シーケンスを作成する必要はないが、代表的なユースケースや特異なユースケースに対する処理シーケンスは必ず作成する。ここでも、重要なユースケースに対する処理シーケンスの検討漏れを防止するという観点から適切にレビューを実施することが重要である。

インタフェースの設計

上記で策定した機能ユニット間の処理シーケンスをもとに、各機能ユニットのインタフェース仕様を策定する。

ソフトウェア・アーキテクチャ設計書の作成

上記までの検討結果を整理・体系化して、ソフトウェア・アーキテクチャ設計書を作成する。また、リストアップした要求や制約事項と検討したソフトウェア・アーキテクチャとの間に不整合はないかという観点からレビューを実施する。

ソフトウェア詳細設計のタスク

プログラムユニット分割

ソフトウェア・アーキテクチャ設計で策定した各機能ユニットのインタフェース仕様に対して、処理内容をリストアップしていき、それぞれをプログラムユニットとする。このとき、ソフトウェア・アーキテクチャ設計では検討しなかった全てのユースケースに対して処理シーケンスを作成し、インタフェース仕様を策定しておく。リストアップした処理内容に同じものがあれば、プログラムユニットを共通化する。また、各プログラムユニットのインタフェース仕様も策定する。

プログラムユニット設計

上記で分割した各プログラムユニットの処理内容を詳細化する。プログラムユニットの処理内容は箇条書きで構わないが、処理内容が複雑で誤解を招く恐れがある場合はフローチャートを作成したほうがよい。

ソフトウェア詳細設計書の作成

上記までの検討結果を整理・体系化して、ソフトウェア詳細設計書を作成する。また、プログラムユニットの分割が最適に行われているかという観点からレビューを実施する。

実装のタスク

プログラムユニットの実装

ソフトウェア詳細設計書に従って、ソースコードを作成する。また、レビューを実施する。

 　現実のソフトウェア開発では、ソフトウェア・アーキテクチャ設計書は作成していても、ソフトウェア詳細設計書は作成していなかったり、作成していても更新できていないためにソースコードと内容が乖離していることがあると思われる。こうした課題の改善策は別の機会に考察する。