COCOMOによる見積もり
ゆきみライブラリの開発をCOCOMOを使って見積もる．
COCOMO
規模[K LOC] = プログラム行数[LOC(Lines of Code)] / 1000(Kilo)
工数[PM] = 2.4 × 規模^1.05
期間[M] = 2.5 × 工数^0.38
要員[P] = 工数 ÷ 期間
生産性[K LOC/PM] = 規模 ÷ 工数
ゆきみライブラリの場合
プログラム行数 = 3000
規模 = 3000 ÷ 1000 = 3 [K LOC]
工数 = 2.4 × 3^1.05 = 7.61 = 8 [PM]
期間 = 2.5 × 7.61^0.38 = 5.41 = 5 [M]
要員 = 7.61 ÷ 5.41 = 1.41 = 1 (or 2) [P]
生産性 = 3 ÷ 7.61 = 0.39 [K LOC/PM]
更に詳しく表にする．
規模 [K LOC] 3 工数 [PM] 7.61 開発期間 [M] 5.41 開発要員 [P] 1.41 生産性 [K LOC/PM] 0.39
工数を各局面へ分解
計画と要求定義 0.46 製品設計 1.22 詳細設計 1.96 コーディングと単体テスト 3.16 統合とテスト 1.29 合計 8.07
各局面の工数を各活動へ分解
局面 計画と要求定義 製品設計 詳細設計とコーディング 統合とテスト 合計 要件分析 0.21 0.19 0.26 0.04 0.69 製品設計 0.10 0.49 0.52 0.08 1.17 コーディング 0.02 0.18 2.97 0.44 3.59 テスト計画 0.02 0.07 0.21 0.03 0.31 検証 0.03 0.08 0.31 0.44 0.85 プロジェクト計画 0.07 0.14 0.31 0.09 0.60 構成管理と品質保証 0.01 0.03 0.31 0.09 0.46 文書化 0.03 0.09 0.26 0.09 0.46 合計 0.56 1.22 5.11 1.29 8.07
詳しくは以下の書籍をどうぞ．
- 作者: 山村吉信
- 出版社/メーカー: 翔泳社
- 発売日: 2003/12/06
- メディア: 単行本
- 購入: 1人 クリック: 12回
- この商品を含むブログ (6件) を見る
- 作者: 山村吉信
- 出版社/メーカー: 翔泳社
- 発売日: 2004/06/09
- メディア: 単行本
- 購入: 2人 クリック: 29回
- この商品を含むブログ (14件) を見る
ソフトウェアテスト
こんな本を読んでます．
- 作者: 山村吉信
- 出版社/メーカー: 翔泳社
- 発売日: 2003/12/06
- メディア: 単行本
- 購入: 1人 クリック: 12回
- この商品を含むブログ (6件) を見る
まだ半分くらいしか読んでないですが勉強になります．
ゆきみ要求定義
「ゆきみライブラリ製作プロジェクト」要求定義
1. 機能要求
1.1. 開発環境（ライブラリを利用する環境）
1.1.1. OSは32ビットの日本語版のWindowsXP及びWindowsVistaに対応すること
1.1.2. プログラミング言語はC++03とする
1.1.3. コンパイラ（リンカ含む）は最低でも2種類のフリーソフトに対応すること
1.1.4. DirectX SDKは9.0c (March 2008）とする
1.1.5. C++03標準ライブラリ，WindowsSDK及びDirectX SDK以外の外部ライブラリは必要としないこと
1.2. 動作環境（ライブラリを利用して作成したソフトウェアが動作する環境）
1.2.1. OSは32ビットの日本語版のWindowsXP及びWindowsVistaに対応可能なこと
1.2.2. 最低でも2種類のグラフィックボードで動作すること
1.3 入力
1.3.1. 文字型はchar及びwchar_tに対応すること
1.3.2. char及びwchar_tは簡単に切り替え可能であること
1.3.2.1. ここでの簡単とは，極一部の変更のみで全体を変更できることを意味する
1.3.3. キーボードの入力を簡単に扱えること
1.3.3.1. ここでの簡単とは，クライアントが数回の手続きで一つのデータを取得できることを意味する
1.3.3.2. 入力は対象ウィンドウがフォーカス中のみ受け取ること
1.3.3.3. WindowsAPI及びDirectInputの両方が利用可能なこと
1.3.4. マウスの入力を簡単に扱えること
1.3.4.1. ここでの簡単とは，クライアントが数回の手続きで一つのデータを取得できることを意味する
1.3.4.2. 入力は対象ウィンドウがフォーカス中のみ受け取ること
1.3.4.3. WindowsAPI及びDirectInputの両方が利用可能なこと
1.3.4.4. ウィンドウ上にカーソルがある場合のみ受け取ること
1.4 出力
1.4.1. フルスクリーン及びウィンドウモードで表示可能なこと
1.4.2. スクリーン上の指定した四角形のみへの描画が簡単にできること
1.4.3. 複数のウィンドウに対応すること
1.4.4. 複数のウィンドウへの描画を簡単に操作できること
1.4.5. 動作環境がマルチモニタの場合，動的に対象モニタを指定できること
1.4.6. 指定した解像度でフルスクリーンにした場合，モニタの解像度で表示し，余白を使うことによって元の表示が歪まない機能を提供すること
1.5. ライブラリの機能
1.5.1. ウィンドウの管理
1.5.1.1. 複数のウィンドウを管理できること
1.5.1.2. 簡単に作成が可能なこと
1.5.1.2.1. 矛盾の無いスタイルの設定が可能なこと
1.5.1.2.2. フルスクリーン及びウィンドウモードの指定が可能なこと
1.5.1.2.3. 解像度を設定可能なこと
1.5.1.2.4. ここでの簡単とは，クライアントが数回の手続きで作成できることを意味する
1.5.1.3. 自動的に解放を行うこと
1.5.1.4. ウィンドウの移動が可能なこと
1.5.1.5. 表示非表示の操作が可能なこと
1.5.1.6. ウィンドウがフォーカス状態にあるかどうかを取得可能なこと1.5.2. DirectX管理
1.5.2.1. 簡単に初期化が可能なこと
1.5.2.1.1. 動的にハードウェア処理，ソフトウェア処理を自動で最適なものを選択すること
1.5.2.1.2. ウィンドウで指定した動作モードを再設定する必要がないこと
1.5.2.1.3. ウィンドウで指定した解像度を再設定する必要がないこと
1.5.2.1.4. ビット深度を設定又は自動取得すること
1.5.2.1.5. ここでの簡単とは，クライアントが数回の手続きで作成できることを意味する
1.5.2.2. 自動的に開放が行われること
1.5.2.3. 2D描画
1.5.2.3.1. テクスチャ及びテクスチャの範囲を指定して，指定した場所へ描画可能なこと
1.5.2.3.2. 描画の際，拡大縮小，回転，透明処理を行えること
1.5.2.3.3. 疑似CUI描画を簡単に行える機構を提供すること
1.5.2.3.4. スクリーンの塗りつぶし及びその色の指定が可能なこと
1.5.2.4. テクスチャ
1.5.2.4.1. 相対パス，絶対パスでファイル名を指定して読込み可能なこと
1.5.2.4.2. メモリ上のアドレスを指定して読み込み可能なこと
1.5.2.4.3. 読込みの際に透過色を指定できること
1.5.2.4.4. DirectXがデフォルトで提供する画像ファイルフォーマットをすべて読み込み可能なこと
1.5.2.4.5. テクスチャフォーマットを静的及び動的に設定可能なこと
1.5.2.4.6. 自動的に開放が行われること
1.5.2.4.7. 単体で描画が可能なこと
1.5.2.4.8. テクスチャのビットの書換えや，異なるフォーマット間でのテクスチャのコピー（変換）が可能なこと
1.5.2.5. サウンド
1.5.2.5.1. 相対パス，絶対パスでファイル名を指定して読み込み可能なこと
1.5.2.5.2. メモリ上のアドレスを指定して読み込み可能なこと
1.5.2.5.3. 自動的に開放されること
1.5.2.5.4. 始めから再生が可能なこと
1.5.2.5.5. 途中で再生を停止できること
1.5.2.5.6. 途中で再生を一時停止及び再開できること
1.5.2.5.7. DirectXが標準で提供するすべてのフォーマットに対応すること
1.5.2.6. ムービ
1.5.2.6.1. 相対パス，絶対パスでファイル名を指定して読み込み可能なこと
1.5.2.6.2. メモリ上のアドレスを指定して読み込み可能なこと
1.5.2.6.3. 自動的に開放されること
1.5.2.6.4. 始めから再生が可能なこと
1.5.2.6.5. 途中で再生を停止できること
1.5.2.6.6. 途中で再生を一時停止及び再開できること
1.5.2.6.7. DirectXが標準で提供するすべてのフォーマットに対応すること
1.5.2.7. リソース管理
1.5.2.7.1. テクスチャ管理は「管理側」と「参照側」に分かれること
1.5.2.7.2. 参照側が残っていたとしても，管理側がリソースを破棄すればリソースは正しく開放されること
1.5.2.7.3. 破棄されたリソースを参照側が参照する場合，破棄済みであることが動的に確認できること
1.5.2.8. 文字列
1.5.2.8.1. 2Dでの高速な文字列描画が可能なこと
1.5.2.8.2. 文字列の作成にフォント，サイズ，色を設定可能なこと
1.5.2.8.3. 内部のリソースは自動的に管理すること
1.5.2.8.4. 疑似CUI描画と親和性が高いこと
1.5.2.8.5. C++03標準の文字列型と親和性が高いこと
1.5.2.8.6. 一括描画が簡単に行えること
1.5.2.8.7. 順次描画が簡単に行えること1.6.3. 動作
1.6.3.1. 利用するプログラムはシングルスレッドを対象とする
1.6.3.2. 動作環境に必要なDirectXのDLLファイルがない場合でも，クライアントに通知されること
1.6.3.3. デバイスのロスト及びリストアへの対応機構があること1.6.4. ログ
1.6.4.1. ライブラリ動作中に発生した情報をログファイルに出力すること
1.6.4.2. 出力するログファイルは指定したアルゴリズムで暗号化可能なこと
1.6.4.3. 以下の情報をログとすること
1.6.4.3.1. 起動情報
1.6.4.3.2. プログラムの動作した環境の情報
1.6.4.3.3. エラーが発生した場合のエラー情報
1.6.5. エラー処理
1.6.5.1. エラーはログに記録すること
1.6.5.2. 初期化中などの今後の動作にかかわるエラーは例外を送出すること
1.6.5.3. ライブラリ利用側で無視することが許されないエラーは例外を送出すること
1.6.5.4. その他の重要性の低いエラーは例外以外ですること
1.6.5.5. すべてのクラスは基本的な保障を提供すること
1.6.5.6. 可能な限り強い保障及び例外を投げない保証を提供すること
2. 性能要求
3. 相互運用要求
4. 将来操作要求
4.1. 動作可能なグラフィックボードの必要性能を可能な限り下げる
4.2. 利用可能なDirectXSDKのバージョンを可能な限り下げる
4.3. マルチスレッドに対応する
2.0.19.0 20081221 [1.1.5.]を修正．+『，WindowsSDK』
2.0.18.0 20081220 [1.5.2.3.4.]を追加．
2.0.17.2 20081219 [1.5.1.2.]字を修正．
2.0.17.1 20081219 一部リスト番号が間違っていたのを修正．
2.0.17.0 20081219 [1.6.3.2.]を修正．-『強制終了せずにその旨をユーザに通知可能なこと』+『クライアントに通知されること』
2.0.16.0 20081219 [1.1.5.]を修正．+『C++03標準ライブラリ及びDirectX SDK以外の』
2.0.15.0 20081219 [1.3.2.1.][1.3.3.1-3.][1.3.4.1-4.][1.4.6.][1.5.1.2.4.][1.5.1.6.][1.5.2.1.5.][1.5.2.5.7.][1.5.2.6.7.][1.6.3.3.]を追加．
2.0.0.0 20081214 全面的に書き換え．
1.0.5.0 20080710 「情報出力」を分離．
1.0.4.0 20080710 「正当性と堅牢性」追加．
1.0.3.0 20080710 「タスクにより発生するデータ」を追加．
1.0.2.1 20080610 「セキュリティレベル」の『遅延DLLを用いて』を削除．ユーザの言葉ではないので．
1.0.2.0 20080710 「保守性」を変更．
1.0.1.0 20080710 「文字列の描画」に「スタイルの設定」を追加．
1.0.0.0 20080709
iterator
入力イテレータ
コピーコンストラクタ
operator=()
operator*()
operator++()
operator++(int)
operator==()
operator!=()
非再現性
出力イテレータ
コピーコンストラクタ
operator=()
operator*()
operator++()
operator++(int)
非再現性
双方向イテレータ
operator--()
operator--(int)
ランダムアクセスイテレータ
operator+(int)
operator-(int)
operator+=(int)
operator-=(int)
operator-(iterator)
operator<(iterator)
operator>(iterator)
operator<=(iterator)
operator>=(iterator)
operator[](int)
イテレータクラスを自作する時はstd::iteratorを継承する．
template<typename ValueType> struct my_input_iterator : std::iterator<std::input_iterator_tag, ValueType> { };
Scoped Allocator Model
Scoped Allocator Modelが何かはアキラさんのブログを参照してください．
C++0x Scoped Allocator Model - Faith and Brave - C++で遊ぼう
詳細（コード例）は分からないけど（何となくしか），これってメモリ上で要素同士を順序どおりに隣接させることができるのかな．
std::vector< std::vector<int> > v; int sum = 0; for(std::size_t i=0; i<v.size(); ++i){ for(std::size_t j=0; j<v.size(); ++j) sum += v[i][j]; }
上のコードをC++でやると，当然キャッシュのヒット率が下がる．
Scoped Allocator Modelをうまく使えば，メモリ上に1次元配列のように並べられるのかなぁ．
いや，メモリ上に一か所になるってのは分かるんだけど，順序どおりに並ぶのかどうかだよね．
でもそれはAllocatorとは別か．
そもそもvectorのvectorを使わなきゃいい話だけど．
N2554へのリンクが貼ってあるけど，それ以前にまだ何にも読んでないんだよね．
分かるわけがない．
余裕ができてきたらC++0xの勉強も本格的にやりたいなぁ．
