計測タイプの決定 計測範囲の決定、アプリケーション境界の決定 データファンクション計測 トランザクショナルファンクション計測 未調整ファンクションポイント計算 調整係数計算 調整済ファンクションポイント計算
計測タイプの決定 計測範囲の決定、アプリケーション境界の決定 データファンクション計測 トランザクショナルファンクション計測 未調整ファンクションポイント計算 調整係数計算 調整済ファンクションポイント計算
概要 概要(変化に強いシステムの構築方法)2000-12-10 データモデル エンティティとリレーションシップ2000-12-28 エンティティのライフサイクル2001-01-12 アプリケーションルール データフローダイアグラムの書き方2001-01-28 アプリケーションルールの定義2001-02-04 プログラム設計 プログラム設計2001-02-18 その他 ことの経緯 その12001-03-04 ことの経緯 その22003-09-21 その他更新:2002-11-24,2002-06-16 作成例:販売・生産・搬送計画立案支援システム 業務概要2001-09-09 データモデル2001-09-16 エンティティのライフサイクル2001-09-30 アプリケーションルール2001-09-23 プログラム設計2001-10-07 各論 データウェアハウス2001-03-25 ファンク
サマリー 1) FP計測のタイプの決定 タイプ1) 新規開発計測 タイプ2) 機能拡張計測 タイプ3) アプリケーション計測 2) 計測範囲の決定、アプリケーション境界の決定 計測範囲を明確にする為にアプリケーション境界を決定する。 3) データファンクションの計測 FP計測2つの計測対象の1つ ILF(Internal Logical File):追加・更新・削除など操作対象となるファイル EIF(External Interface File):参照されるファイル データエレメントタイプ(DET):繰り返しを含まないデータ項目 レコードエレメントタイプ(RET):繰り返しのあるデータ項目 ■ILF、EIFの複雑度 1~19 DET 20~50 DET 51以上DET 1 RET
交通量に見合った道路を作ったり,工場の排煙を減らす高度なごみ処理施設を建設したりする,といった基本的な都市計画がなされていない,つまり「都市基盤」が整備されていなければどうなるか。道路は慢性的に渋滞しており,たどりつくだけで一苦労。街で交通事故が発生しても救急車が現場に到達することさえままならない。工場は排煙をまき散らし,深刻な大気汚染を引き起こす──。 情報システムにも,同じことが当てはまる。豊富な機能を持つアプリケーションを開発することは確かに重要だ。だが,サーバーやストレージの性能や信頼性,ネットワークの回線速度などを無視していては,システムの品質を保つことは難しい。システム開発に携わるあらゆるITエンジニアにとって,システムの性能や信頼性などを左右する「システム基盤」の知識は不可欠だ。そこで本講座では,システム基盤を理解するための基本的な技術や用語から,実践的な開発方法論までを解説
「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。検討の過程で明確にされたいくつかの選択肢があって、ユーザに決断力がないゆえに決めきれていないとすれば、確かに困ったものだと思う。しかし「ユーザがどんなシステムにしたいかをなかなか明確に語ってくれない」といったレベルの悩みなのであれば、問題はどちらかといえば設計者の側にある。 ◆デートの過ごし方を決める過程 休日のデートの過ごし方に関して男性から尋ねられて、事細かに意向を説明してくれる女性はどちらかといえば少ない。たいていは「うーん、いい景色を見て、なにか美味しいものを何か食べたいな」なんて曖昧な答えが返ってくる。そのときに彼は「イイケシキだのナニカオイシイモノなんて曖昧な言い方をされてもわからない。もっと具体的に説明してくれないか」なんて言うだろうか。 そんなことを言う男がいるとすれば、彼女のいぶかる様子に気づくこと
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回は、仕事にプロセス志向を適用し、仕事の流れを図として「見える化」することで、改善すべきポイントがどこにあるかを把握しやすくなることを説明した。この「プロセス図」は見る人にとって理解しやすく、仕事の流れを正しく表現できているものであれば、実際にはどのように描いても差し支えない。 ただ、そうした図を描くときに覚えておくといいルールや、図を他の人と共有する場合に、より都合のよい描き方というものが存在する。まずは、それについて紹介しよう。 図でコミュニケーションのギャップを埋める 先ほど「どのように描いても差し支えない」としたが、実際に仕事の流れ図を描くとき、自分流に描いてしまうと問題が起こるケースもある。たとえば、後で複数の人が集まって図
業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。プロジェクトに焦燥と混乱をもたらすことなく、堅実に開発を進めていくためには、正確で具体的な見積もり手法が求められる。 良く知られた見積もり手法の1つに、ファンクションポイント法がある。外部との入出力に着目して、ソフトウェアの機能から工数を見積もるファンクションポイント法は、有効な見積もり手法である。 だが、実際のソフトウェア開発の現場では、ファンクションポイント法で見積もりを行っているケースは多くはない。その原因の1つには、ファンクションポイント法を使うためには、入出力を定めたモデルの作成や、ポイントの計算方法など、専門的な知識と技能が必要なことが挙げられる。 小規模なソフトウェア開発では、見積もりのしや
1.ソフトウェア開発環境の変化と見積手法 ソフトウェアの開発形態がメインフレーム(以下M/F)からクライアントサーバ(以下C/S)に移ってきている中で、プログラムレベルでは、開発方法が手続き(コード)記述ベースからビジュアル開発ツールベースにシフトしてきている。このため、ソフトウェア規模・工数の見積を行う際に、これまでの事実上の標準だった「LOC(Lines of Code:プログラム行数のこと)」を使うことが困難になってきている。こうした中で、ソフトウェアの持つ機能を数えることでソフトウェアの規模を測る尺度「ファンクションポイント法(以下FP法)」が現在その後を埋める有力候補となっている。 当部では、FP法の普及動向を把握するため、見積手法に関するアンケート調査、FP法先行導入企業に対するヒアリング調査を行ったので、ここにご紹介する。 2.ファンクションポイント法とは FP法は
【自信が持てる見積もり技術】 世界最大のプロジェクトをこう見積もった 大規模,複雑,厳しい納期――。昨年秋に完全統合したJAL/JASの情報システム。成功を収めたプロジェクトの裏に,見積もり精度の高さがあった。プロジェクト・マネージャ(PM)を務めた岡村正司氏に,どのように見積もったのかを聞いた。 【だれも教えてくれなかった外部設計の「極意」】 データモデルの全体像を開発者と発注者が共有する 今回から「受発注システム」を想定して,データモデルを発注者と合意するためのコツを詳細に説明していきましょう。前回述べたように,データモデルは,発注者にとって難しいものです。 【図解で極める要求定義】 属人性の弊害解消に向けて プロセスと成果物の標準を定義 属人的なノウハウを,組織としてのノウハウに昇華しようという試みが始まっている。ヤフーもその1社。標準プロセスと成果物を定義する過程で,策定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く