BLOG TARANCO

日ハム資料館

Comments

taranco @ Re:やったね！おめでとう！！(10/24) にぱ。さんチキバンの女子のコールは…

にぱ。 @ やったね！おめでとう！！内野で観戦した友達によると、ﾁｷﾊﾞﾝはかな…

taranco @ Re:(o￣ー￣o) ﾑﾌﾌ(10/22) にぱ。さん今日こそ決めてもらいまし…

にぱ。 @ (o￣ー￣o) ﾑﾌﾌ明日になりそうですﾅｧ～～♪ ﾜﾀｼはﾚﾌｽﾀ…

taranco @ Re:あと10万人(10/06) ぽろんぽろんさん勝ちましたね！明…

Profile

taranco

フォローする

Keyword Search

▼キーワード検索

Favorite Blog

ＹＡＭＡＫＯのアサ… YAMAKO(NAOKO)さん
casual kids ヘルツェコ☆さん
北海道日本ハムFIGHT… maynorthさん
MY FAVORITE ぽろんぽろんさん
部屋が片付きません。 にぱ。さん

< 新しい記事

新着記事一覧(全440件)

過去の記事 >

2005/07/30

■■14.スケジュール、予算、プロジェクト管理に与える影響■■

■14.1 見積とスケジュール作成に与える影響
・開発プロジェクトの見積について、科学的、道理的で過りのない方法を知らない。
・スケジュール遅延の大部分は、システム・テストおよびインテグレーションと称する雲をつかむような工程で起こっている。

■14.2 従来型のマイルストン法（標識点）に与える影響

■14.3 マイルストンと構造化技法
・構造化技法を導入した後では、システムのバージョンごとにマイルストンを設定することになる。これは、開発状況が目に見える点で優れている。

■14.4 まとめ
・見積方法は従来通りでよい。

・以降に続く従来のマイルストンを廃止し、トップダウン開発によるバージョンをマイルストンにする。

従来のマイルストン例　　　新しいマイルストン－－－－－－－－－－－　　－－－－－－－－－－システム要求書の受領　　　┐ システムスタディ開始　　　├従来通り　　　〃　　　　完了　　　┘ 新システム仕様書完成　　　┬保守的トップダウン方式では　　　〃　　　　承認　　　┘従来的新システム設計完了　詳細モジュール設計完了　　バージョン１システム稼働コーディング完了　　　　　　　〃　　２　　　〃単体テスト完了　　　　　　　　〃　　３　　　〃システムテスト完了　　　　　　　　　：受入テスト完了　システム本番稼働　　　　　バージョンｎ本番システム稼働

■■15.どんな問題が起こるか■■

■15.1 社内根回しのコツ
・管理者でない場合は、「静かな改革」を起すべきである。
・構造化プログラミング、ウォークスルー、構造化分析を密かに進めるのだ。
・成果が出れば、手法を問われることになる。

■15.2 個人的問題
・現在のプログラマやアナリストは、一日８時間職業的にプログラムを組んでいれば生活できる。
・彼らの多くは自分の仕事に興味を持てず、でたらめに手慣れた方法でプログラムを書いているに過ぎない。

■15.3 時間的ズレの問題
・構造化技法が全社的に効力を発揮するまでには、軽く２～３年はかかる。

■16.1 はじめに

■16.2 ユーザの分類

□経験レベルでの分類
・アマチュア…コンピュータは恐ろしい。ディスケットの挿入もできない。・初心者…表計算やデータベースの簡単な処理経験を持つ。　　　　　アプリケーションも同じように簡単にできると思いがち。・熟練者…若年層に多いだろう。

■16.3 パソコンに潜む危険性
・エンドユーザは自分でシステムを運用できることを知ってしまった。

□危険性
(1)テスト不足・第４世代言語やスプレッドシートの結果をきちんとテストすることは少ない。 (2)ローカル・データベースの存在・あらゆる部門のユーザが勝手にデータベースを持つことになれば、　データベースの冗長度、同期化、一貫性の問題はかなり深刻になる。 (3)バックアップとセキュリティ・どちらも全く対処されていない。 (4)関係文書の不足・プライベートなシステムは人がいなくなればなくなってしまう。

■■17.第４世代言語と構造化技法■■

■17.1 はじめに
・第１世代…マシン語
・第２世代…アセンブラ
・第３世代…COBOL、FORTRAN、PASCAL、PL/I…

■17.2 第４世代言語の特徴
・データベースの定義と作成が簡単。
・言語はコンパイラではなく、インタプリタで処理することが多い。
・ユーザフレンドリ機能を備えている。
・リポート作成の細部は自動的に処理してくれる。
・特定情報の検索/照会機能。

■17.3 第４世代言語の利点
・システム開発プロジェクトにおいて、プログラミング工程の生産性を１０倍に上げることができる。
・プログラミングの細部を作り直す必要がない。
・プログラムメンテナンスの生産性は飛躍的に向上する。

■17.4 第４世代言語の欠点
・システム分析工程の改善効果はない。
・既存データベースとの互換性がない。
・処理効率の問題
・第４世代言語自体の機能不足

■17.5 結論
・利用環境さえ適当ならば、第４世代言語は情報処理の強力な武器になる。

■■18.プロトタイピング■■

■18.1 はじめに
・プロトタイピングは構造化技法と併用してこそ意味がある。

■18.2 プロトタイピングを採用する理由
・ユーザとシステム・アナリストとの間の意思疎通を図る手段。
・作成と変更が迅速に、しかも簡単にできる。

■18.3 プロトタイピングに適した環境の前提条件
・対象システムのユーザが唯一人であるか、同一部門に所属し、所在地も同一地域内にある少人数の集団であること。
・既存のデータモデルがあるか、簡単に作成できること。
・対象アプリケーションが小規模～中規模であること。

■18.4 プロトタイピングに潜む危険性
・プロトタイピングといえども本格的な業務が可能。
・プロトタイピングは使い捨てされる。
・プロトタイピングは論理モデルの考え方を排除する。
・プロトタイプは時間の浪費か？

■18.5 結論とコメント
・プロトタイピング自体は良い考え方である。
・どんなに素晴らしいツールでも凡庸な人が使えば多くを期待できない。
　むしろ有害なこともある。
・プロトタイピングの考え方と構造化技法の概念は、双方が互いの存在を許さないなどというものではない。

■■19.データ・モデリング■■

■19.1 はじめに
・すべてのシステムはある程度の機能とデータ、それに時間的要因に依存する。

■19.2 現状の認識
・機能モデリングの考え方、データ・モデリングの視点、状態遷移という見方は相互に矛盾するものではない。むしろ補完し合うシステムの見方なのだ。

■19.3 現状の問題点
・データベースの管理チームがあるならば、機能モデルから作成するべき。
（データモデルは上記チームが作成する）
・データモデルを作成してない場合は、機能モデルとデータモデルを同時並行して作成する。
・全社的なデータモデリングを実施しておらず、データ自体もそう複雑でないならば、機能モデルだけで充分である。

■■20.構造化技法の将来■■

■20.1 はじめに

■20.2 自動化ツール
・1980年代半ばになって、充分使い物になる自動化ツール製品が現れた。

□できること
・図作成のサポート
・データディクショナリのサポート
・一貫性チェック

■20.3 再利用可能コード

□再利用可能コードのライブラリ化が失敗している理由
・機能の範囲が曖昧で、あらゆる機能を取り込んだプログラムは再利用されない。
　特定アプリケーションの要求を満たさないから。
・ライブラリに登録するのは簡単だが、検索して利用するのは難しい。
　テスト中のものがある時はなおさら。

■20.4 複雑さのモデル

■20.5 正しさの証明
・テストとはエラーが存在しないことの証明ではなく、エラーが存在することの証明である。（Edsger Dijkstva）
・今日稼働している重要システムのほとんどには、まだ日の目を見ないバグが潜在している。

■20.6 プロジェクト・マネジメント

お気に入りの記事を「いいね！」で応援しよう