PR
Freepage List
Comments
taranco
ブログの何が良いのかを試してみようと思う。 扱ってるテーマは以下の５つになる予定。 1.北海道日本ハムファイターズ 2.ブログ実験 3.IT 4.脳死・臓器移植 5.電車男
Keyword Search
▼キーワード検索
ＹＡＭＡＫＯのアサ…
YAMAKO(NAOKO)さん
casual kids ヘルツェコ☆さん
北海道日本ハムFIGHT… maynorthさん
MY FAVORITE ぽろんぽろんさん
部屋が片付きません。 にぱ。さん
casual kids ヘルツェコ☆さん
北海道日本ハムFIGHT… maynorthさん
MY FAVORITE ぽろんぽろんさん
部屋が片付きません。 にぱ。さん
2005/07/07
カテゴリ： IT
■■４．トップダウン設計とトップダウンテスト■■
■4.1 トップダウン方式のあらまし
・トップダウン設計と構造化プログラムは根本的に別物である。
□トップダウン設計
・規模の大きい複雑な問題をより規模の小さい簡単な問題に分割する設計手法。
□トップダウンコーディング
・上層部の管理モジュールの設計を終えると直ちにそのコーディングを始めるやり方。
□トップダウンテスト（トップダウン開発）
・下層部のモジュールのコーディング開始前に、システム雄上層部のモジュールのテストを行うやり方。
・トップダウン設計の長所…複雑で大きな問題を解決可能な小さな問題に分割する。
□主要なインタフェースは開発プロジェクトの開始時からテストできる。
□ユーザはシステムの稼働をその目で確認できる。
・システムのスケルトンバージョンが実際に稼働するところをユーザに見せられる。
□スケジュールの問題がもっとうまく扱える。
・トップダウンでもボトムアップでも、スケジュールの問題は存在する。しかし、トップダウン方式で開発を進めていれば、はるかに政治的に強い立場に立つことができる。
□デバッグが楽になる。
・テスト…対象とするプログラム又はシステムが正しく動作すること、あるいは誤って動作することを実証するための工程。
・デバッグ…プログラムのバグを見つけて、とことん追いつめていく作業。
・トップダウン方式のテスト環境では、何故デバッグが容易になるのか。
→スケルトンモジュールにあるモジュールを追加してバグが発生した場合、それは追加したモジュールか、インタフェースのどちらかにある場合がほとんどだ。もしわからなければ、ダミースタ部をもう一度戻せばよい。
□プログラマの士気が高まる。
・開発段階の早いうちから、仕事の結果や進捗状況が目に見える形で把握できる。
・たいていのプログラマはペーパーワークは嫌いである。しかしプログラムを作ることは好きだ。たとえスケルトンプログラムでも。
□テストのための仕掛けは不要。
・スケルトンモジュール自身が自然にテストドライバの役目を果たす。
□革新的トップダウン開発と保守的トップダウン開発の混同
革新的：Ｍ１設計→Ｍ１ＣＤ→Ｍ１テスト→Ｍ２設計→…
捕手的：Ｍ１設計→Ｍ２設計→Ｍ３設計→Ｍ１ＣＤ→…
・ユーザが気まぐれである程、革新的である方が望ましい。
・時間的に余裕が少ないときは、革新的手法で成果を出す。
・見積が正確に必要ならば、保守的手法をとるべき。
・革新的トップダウン方式が適切でない状況においては、ユーザ側の圧力に屈してこの開発方法を採用してはならない。
・ユーザが希望するシステムを十分に把握できないうちに、保守的トップダウン方式により、完全なシステム設計を狙ってはならない。
・開発管理者たるもの、トップダウン方式ではプロジェクト開始直後から自由にコーディングを始めて良いなどと、騙されてはいけない。
□マシンタイムの不足
・ボトムアップ方式に比べて早い時期にマシンタイムが必要になる。これが時としてマシンタイムの不足を招く。担当者はトップダウン方式のテストを放棄しがちになる。
・既存のスケルトンモジュールに一つずつ新しいモジュールを追加するという基本手順の代わりに、ある快走のモジュールをまとめて追加する。
□テスト用ハードウェアの不足
・実際と同じハードウェアを用いたテストは高価になる。開発プロジェクトの期間を通して、高価なハードウェアを遊ばせるのを懸念するわけだ。
□要員問題
・開発の中期以降の要員を当初から確保する場合、彼らも上位モジュールの設計に参加させるべきだ。たとえコーディングレベルやレビュー、W/Tだけだとしても。必要かどうかわからないような最下層モジュールのコーディングを担当させるよりは、はるかに有益である。
□下位モジュールを変更すると最上位モジュールに影響が波及することへの懸念
・この懸念が特に大きい場合は、保守的トップダウン方式を採用する。
□トップダウン方式のプログラムテストとボトムアップ方式のシステムテストを抱合わせるという過ち
□複数チームで編成する開発プロジェクトでの意思疎通
・ミーリーの法則…やがて姿を現すシステムの構造は、そのシステムを開発した組織構成を反映したものになる。
□トップダウンバージョンを視覚化する難しさ
・ユーザを何とかシステムの初期段階のバージョンに参加させることだ。
□開発スケジュールと予算の再交渉
・ユーザは都合のよいようにシステムの仕様が変更でき、しかもスケジュールの追加や開発コストのオーバーを考えなくて良いと彼らに思わせるのは間違いだ。従って、変更に伴う追加作業が無い場合でも、スケジュールと開発コストに関する交渉段階を必ず踏むべきである。
■参考本
■4.1 トップダウン方式のあらまし
・トップダウン設計と構造化プログラムは根本的に別物である。
□トップダウン設計
・規模の大きい複雑な問題をより規模の小さい簡単な問題に分割する設計手法。
□トップダウンコーディング
・上層部の管理モジュールの設計を終えると直ちにそのコーディングを始めるやり方。
□トップダウンテスト（トップダウン開発）
・下層部のモジュールのコーディング開始前に、システム雄上層部のモジュールのテストを行うやり方。
・トップダウン設計の長所…複雑で大きな問題を解決可能な小さな問題に分割する。
□主要なインタフェースは開発プロジェクトの開始時からテストできる。
□ユーザはシステムの稼働をその目で確認できる。
・システムのスケルトンバージョンが実際に稼働するところをユーザに見せられる。
□スケジュールの問題がもっとうまく扱える。
・トップダウンでもボトムアップでも、スケジュールの問題は存在する。しかし、トップダウン方式で開発を進めていれば、はるかに政治的に強い立場に立つことができる。
□デバッグが楽になる。
・テスト…対象とするプログラム又はシステムが正しく動作すること、あるいは誤って動作することを実証するための工程。
・デバッグ…プログラムのバグを見つけて、とことん追いつめていく作業。
・トップダウン方式のテスト環境では、何故デバッグが容易になるのか。
→スケルトンモジュールにあるモジュールを追加してバグが発生した場合、それは追加したモジュールか、インタフェースのどちらかにある場合がほとんどだ。もしわからなければ、ダミースタ部をもう一度戻せばよい。
□プログラマの士気が高まる。
・開発段階の早いうちから、仕事の結果や進捗状況が目に見える形で把握できる。
・たいていのプログラマはペーパーワークは嫌いである。しかしプログラムを作ることは好きだ。たとえスケルトンプログラムでも。
□テストのための仕掛けは不要。
・スケルトンモジュール自身が自然にテストドライバの役目を果たす。
□革新的トップダウン開発と保守的トップダウン開発の混同
│Ｍ１│
└──┘
┌─┴─┐
┌──┐┌──┐
│Ｍ２││Ｍ３│
└──┘└──┘
革新的：Ｍ１設計→Ｍ１ＣＤ→Ｍ１テスト→Ｍ２設計→…
捕手的：Ｍ１設計→Ｍ２設計→Ｍ３設計→Ｍ１ＣＤ→…
・ユーザが気まぐれである程、革新的である方が望ましい。
・時間的に余裕が少ないときは、革新的手法で成果を出す。
・見積が正確に必要ならば、保守的手法をとるべき。
・革新的トップダウン方式が適切でない状況においては、ユーザ側の圧力に屈してこの開発方法を採用してはならない。
・ユーザが希望するシステムを十分に把握できないうちに、保守的トップダウン方式により、完全なシステム設計を狙ってはならない。
・開発管理者たるもの、トップダウン方式ではプロジェクト開始直後から自由にコーディングを始めて良いなどと、騙されてはいけない。
□マシンタイムの不足
・ボトムアップ方式に比べて早い時期にマシンタイムが必要になる。これが時としてマシンタイムの不足を招く。担当者はトップダウン方式のテストを放棄しがちになる。
・既存のスケルトンモジュールに一つずつ新しいモジュールを追加するという基本手順の代わりに、ある快走のモジュールをまとめて追加する。
□テスト用ハードウェアの不足
・実際と同じハードウェアを用いたテストは高価になる。開発プロジェクトの期間を通して、高価なハードウェアを遊ばせるのを懸念するわけだ。
□要員問題
・開発の中期以降の要員を当初から確保する場合、彼らも上位モジュールの設計に参加させるべきだ。たとえコーディングレベルやレビュー、W/Tだけだとしても。必要かどうかわからないような最下層モジュールのコーディングを担当させるよりは、はるかに有益である。
□下位モジュールを変更すると最上位モジュールに影響が波及することへの懸念
・この懸念が特に大きい場合は、保守的トップダウン方式を採用する。
□トップダウン方式のプログラムテストとボトムアップ方式のシステムテストを抱合わせるという過ち
□複数チームで編成する開発プロジェクトでの意思疎通
・ミーリーの法則…やがて姿を現すシステムの構造は、そのシステムを開発した組織構成を反映したものになる。
□トップダウンバージョンを視覚化する難しさ
・ユーザを何とかシステムの初期段階のバージョンに参加させることだ。
□開発スケジュールと予算の再交渉
・ユーザは都合のよいようにシステムの仕様が変更でき、しかもスケジュールの追加や開発コストのオーバーを考えなくて良いと彼らに思わせるのは間違いだ。従って、変更に伴う追加作業が無い場合でも、スケジュールと開発コストに関する交渉段階を必ず踏むべきである。
■参考本
お気に入りの記事を「いいね！」で応援しよう
[IT] カテゴリの最新記事
-
個人情報保護法（４） 2005/08/05
-
個人情報保護法（３） 2005/08/02
-
個人情報保護法（２） 2005/08/01
【毎日開催】
15記事にいいね！で1ポイント
© Rakuten Group, Inc.
