Disciplined Software Engineering Lecture #1

Slides:



Advertisements
Similar presentations
CMU2005 海外エンジニアリングワークショップ参加報告書 1 「真の要求を見極めろ!」: teamB 要求定義をどう捉えるか ● 要求定義とは何か? 製品には、顧客の望むことを正しく反映させる必要がある。 そのために必要なものが要求仕様である。 すなわち、要求仕様とは、顧客と製品を結ぶものであり、これを作ることが要求定義である。
Advertisements

1業務の実施方針等に関する事項 【 1.1 調査内容の妥当性、独創性】  事業の基本方針、目的及び調査内容 記述内容 ・仕様書を踏まえて、本事業の基本方針、目的について具体的に記述する。 ・仕様書を踏まえて、本事業の内容について具体的に記述する。 ・当局が提示した内容以外に、当該事業を効果的・効率的に実施するための新たな提案がある場合、その内容を具体的に記述する。
1 EASE プロジェクトにおける EPM ( Empirical Project Monitor) を用いたプロジェクト管理デモ 奈良先端科学技術大学院大学 産学官連携研究員 松村 知子 2005 年 9 月 30 日 JISA 経営者セミナー.
プロジェクトとは.
背景 ソフトウェアの大規模化・複雑化 生産性と品質の向上 ↓ オブジェクト指向分析設計の適用 開発ツールの投入.
第4章 ABC/ABMと原価情報 原価計算・原価低減の新技法 1.ABCとは何か 2.ABCの有効性 3.ABMとは何か 4.ABMの有効性.
経営情報論B 第一回 講義概要+経営と情報.
プロダクション・マネジメント イントロダクション(第1回)
表計算ソフトで動作するNEMUROの開発
Java I 第2回 (4/18)
機能実現期間の測定による プログラマ能力の実験的評価
OJT研修 「テスト実施、テスト設計の技術習得」 日時: 8月22日(月)  場所: 本社5階.
3-1システム戦略 3-1-3ソリューションビジネス (Point) ・代表的なサービスを通じ、ソリューションの考え方を理解
Disciplined Software Engineering Lecture #8
事業計画 発表者名 | 会社名.
モード付き並列機械における オンラインスケジューリング
グループ研究1班 第一章 経営戦略とは何か 雨森 彩 大嶋 健夫 小沢 博之.
IT入門B2 (木曜日1限) 第一回 講義概要 2004年月9日30日.
オブジェクト指向プログラミング(2) OOPの三大要素 「クラス」「ポリモーフィズム」「継承」
進捗管理 1.進捗度算出 (1)進捗尺度 進捗把握の単位は、細分化されていることが望ましい。 可能ならば1人1週間の作業量を1単位とする
要員管理 要員の質、量、配置、作業状況を管理する 一般的な注意点を下記に示す (1)組織 ・組織構成を明快にする -指示命令系統
Disciplined Software Engineering Lecture #12
「教育工学をはじめよう」  第2章     学会発表に向けて     プロポーザルを書く 発表 菊池 陵  皂 智樹.
SS2009 形式手法の適用ワーキング グループの報告
BPMN(Business Process Modeling Notation)
構成管理 構成管理とは、ソフトウェア開発に於ける成果物をある時点で凍結し、 以降の変更を管理する事をいう
【1.1事業の目的・内容について】 4.2 (別紙1) 提案書雛型 内容及び達成目標 記述内容
プログラミング入門2 総合演習課題 2008年 1/7, 1/21 実施 これまでの講義内容についての腕試し
今日090525の予定 1.範囲の計算の復習→jlect#04A 2.レポートispm2の講評と模範回答→K’sLife
プログラミング 平成23年10月5日 森田 彦.
プログラミング基礎a 第8回 プログラムの設計 アルゴリズムとデータ構造
ソフトウェア工学 第五回 知能情報学部 新田直也.
製造準備段階における 工程FMEAの実施と不具合未然防止
「沖縄におけるスポーツサイエンスの拠点化に向けた
「グローバルものづくり」 を加速させる ISID の “JT 活用” ソリューション群
最適設計と設備投資の経済計算 JMAセミナー 目標 6時間 期間 3ヶ月 講師 MEマネジメントサービス編
ソフトウェアを取り巻く環境の変化がメトリクスに及ぼす影響について
コンポーネントの接続情報を検索する手法について
付属書Ⅰ.5 ハザード分析と 重要管理点 (HACCP).
TIME SIGNAL: 集合知を利用した赤信号点灯時間の取得手法
Disciplined Software Engineering Lecture #4
長期滞在型テレワークの誘致及び導入検討調査
~新たなソフトウェア開発の手法~ 発表 土屋俊介
ソフトウェア設計検証 研究室の紹介 知能情報学部 准教授 新田直也.
品質リスクマネジメント ICH Q9 付属書Ⅰ:リスクマネジメントの方法と手法
IoT活用による糖尿病重症化予防法の開発を目指した研究
「沖縄におけるスポーツサイエンスの拠点化に向けた
言語XBRLで記述された 財務諸表の分析支援ツールの試作
プログラミング基礎a 第8回 プログラムの設計 アルゴリズムとデータ構造
会社名 ビジネス プラン プレゼンテーション.
その他 手法の組合せ.
ビジネス プロジェクトの計画 発表者名 | 会社名.
シナリオを用いたレビュー手法PBRの追証実験 - UMLで記述された設計仕様書を対象として -
コードクローン分類の詳細化に基づく 集約パターンの提案と評価
標準時間の設定と生産性改善 日本能率協会セミナー 目標 6時間 期間 3ヶ月 講師 MEマネジメントサービス編
INTRODUCTION TO SOFTWARE ENGINEERING
1業務の実施方針等に関する事項 【1.1調査内容の妥当性、独創性】
プロジェクト演習 知能情報学部 新田直也.
1業務の実施方針等に関する事項 【1.1事業実施の基本方針、業務内容等】
製品またはサービスの販売 サブタイトル.
保守請負時を対象とした 労力見積のためのメトリクスの提案
開発作業の形式化に基づく プロセス評価 松下誠 大阪大学.
システムとソフトウェア評価: 標準化の目的と必要性
設計工学 内容 目的 ★もの作りのための設計 ★実際の現場で役立つ設計 ★機械設計や機械作りの楽しさを知る。 ★工学的な理屈を考える。
新入社員トレーニング 発表者名 発表日 このテンプレートは、トレーニング資料をグループ設定で紹介するための開始ファイルとして使用できます。
データ中心システム設計方法論“DATARUN” 
プログラムの一時停止時に 将来の実行情報を提供するデバッガ
(別紙1) 提案書雛型 令和元年度 沖縄型テレワーク実装推進調査 ー提案書ー                        (日付)                        (企業名)                        (連絡先等)
オブジェクト指向メトリクスを用いた 開発支援に関する研究 --- VC++とMFCを用いた開発を対象として ---
レポート 進捗状況や状態 サブタイトルの見出し 自分の名前.
Presentation transcript:

Disciplined Software Engineering Lecture #1 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Sponsored by the U.S. Department of Defense 1999.6.17改訂

コースの目的 プロセスに基づくソフトウエア開発手法を紹介すること 個人のソフトウエアプロセス(PSP)を計測し分析する方法を示すこと 個人のパフォーマンスを改善するためのプロセスデータの使用法を示すこと これらの方法をソフトウェア開発以外のタスクに適用する方法を示すこと

一般的情報 前提条件 何か一つのプログラミング言語を知っていて使えること。 役にたつバックグラウンド 基礎的統計に精通していること。 簡単なフォーマル記法を読む能力があること。 設備 開発環境が利用できる スプレッドシートが使える

コース概要 始めに 1 講義 プロセス を計画すること 5 講義 欠陥管理 4 講義 設計プロセス 3 講義 プロセス開発 1 講義 始めに 1 講義 プロセス を計画すること   5 講義 欠陥管理 4 講義 設計プロセス 3 講義 プロセス開発 1 講義 PSP利用法 1 講義

講義#1 概要 PSPの原則 コストと利益 個人のソフトウエアプロセス(PSP)概要 能力成熟度モデル(CMM) プロセス成熟度 CMMとPSP 最初のPSP0プロセス

PSPの原則‐1 ソフトウエアシステムの品質はその最も悪い部品の 品質に支配される。 ソフトウエアシステムの品質はその最も悪い部品の 品質に支配される。 ソフトウエア部品の品質はそれを開発した個人によって支配される。 即ち個人の 知識 規範(discipline) コミットメント       によって支配される

PSP原則‐2 ソフトウエア 専門家として自分自身のパフォーマンス (効率、遂行能力)を知るべきである。 ソフトウエア 専門家として自分自身のパフォーマンス (効率、遂行能力)を知るべきである。 自分の仕事を計測し、追跡し、そして分析するべきで ある。 自分のパフォーマンスのバラツキから学ぶべきである。 これらの教訓を個人的なプラクティス(慣習)の中に組み 入れるべきである。

安定したPSPをもっていると 次の事ができる 仕事の見積もりと計画 コミットメントを遵守すること 無理なコミットメントを押し付けられることへの抵抗 また 自分の能力を理解するようになり 能力改善がより上手にできるようになる

PSPは以下のことをも提供する。 産業界水準の個人的な規範を開発し実行するための証明済み基盤。 個人的プロセスの改善方法を示す規範。 生産性、品質、および予測可能性を継続的に改善するためのデータ。

PSPとは何か? ソフトウエアを開発するための個人的プロセス いくつかの定義されたステップ 帳票類 標準類 自分のプロセスを特徴づけることを支援するための計測と分析の枠組。 自分のパフォーマンスの改善を支援する定義された手続き。

CMM とPSP-1 能力成熟度モデル(CMM)は先導的なソフトウエア グループの支援を得てSEIによって開発された。 個人の仕事のためにある。

CMMとPSP - 2 5 4 3 2 1 *PSPキープラクティス Level 1 Level 5 プロセス変更管理* 技術変更管理* 欠陥予防* 4 Level 4 ソフトウェア品質管理* 定量的プロセス管理* 3 Level 3 ピアレビュー* グループ間調整 ソフトウェアプロダクトエンジニアリング* ソフトウェア統合管理* トレーニングプログラム 組織プロセス定義* 組織プロセス重視* 2 Level 2 ソフトウェア構成管理 ソフトウェア品質保証 ソフトウェア外注管理 ソフトウェア進捗管理* ソフトウェアプロジェクト計画* 要件管理 1 *PSPキープラクティス Level 1

CMM と PSP - 3 CMMは,効果的なプロセス管理のための枠組を用意する。 それは,ソフトウエア専門家が規範化された個人的方法に従うものと仮定している。 PSPは,規範化された個人の仕事のための枠組を用意する。 それは,効果的なプロセス管理を仮定している。

CMMとPSP - 4 管 理 S Q S A E / P ソフトウェア G 開発作業 C M 技術者 管 理 S E P G S Q A / C M ソフトウェア 開発作業 技術者 SEPG - software engineering process group SQA - software quality assurance SCM - software configuration management

PSP概要 - 1 PSPは7つの上向きにコンパティブルなステップで導入される。 各ステップにおいて1つか2つの小規模プログラムを書く。 作業に関するデータを集めて分析する。 作業を改善するためこれらのデータを使って分析 する。

PSP の概要 - 2 PSP3 PSP2.1 PSP2 PSP1.1 PSP1 PSP0.1 PSP0 循環的開発 設計テンプレート コードレビュー 設計レビュー PSP1.1 タスク計画立案 スケジュール計画立案 PSP1 規模見積り テスト報告t PSP0.1 コーディング標準 規模測定 プロセス改善提案 (PIP) PSP0 現行プロセス 時間記録 欠陥記録 欠陥型標準

PSPの概要 ‐ 3 PSP0 - パフォーマンスの,計測されたベースラインを 確立する。       確立する。 PSP1 - 規模,資源、およびスケジュールの計画をする。 PSP2 - 欠陥管理と摘出率(yield)管理を実習する。 PSP3 - PSP手法をより大規模なプロジェクトにスケ‐ル アップする。

コースを終了すると レベル5の業界プロセスのキーエレメントを実習したことになる。 どの方法がもっとも効果的かがわかるようになる。 より良い仕事をするようになる。 長期的な改善目標をもつようになる。

これまでのコースでの結果 以下の図はPSPコースの間に他の人々がどれくらい改善したかを示す。 これらのデータは1994年春にCMUで行われたPSPコースを受講した12人の学生のものである。 データは次に関するものである: コンパイル時間 テストで発見された欠陥 生産性

時間比率(%)

欠陥数/KL

LOC/時間

PSP0のプロセス 簡単な定義された個人のプロセス 現在使っている設計開発方法を使用する。 仕事に関する以下のデータを収集する: 工程毎に使用した時間 コンパイルおよびテストで発見された欠陥の数 プロジェクト計画概要(計画兼報告)をつくる。

PSP0のスクリプト‐1 参照 ‐ 付表 C10 (p.405) 計画立案 ‐ 開発時間を見積もる 計画立案 ‐ 開発時間を見積もる 開発 ‐ 現在の方法を使用して製品を開発する 事後分析 ‐ プロジェクト計画の要約を完了する。その中には各工程に費やした時間、発見された及び作り込まれた欠陥についてまとめる。

PSP0スクリプト‐2 設計‐現行の設計手法を使用してプログラムを設計する。 コンパイル‐欠陥がなくなるまでコンパイルする。 テスト‐プログラムをテストし全ての欠陥を修正する。 発見した全欠陥を欠陥記録ログの中に、工程毎に費やした時間を時間記録ログの中に記録する。

PSP0計画概要(要約)‐1 参照 ‐ 付表C14 (p.407) ヘッダー ‐ 受講者、日付、プログラム名、講師、言語 開発にかかるトータル時間の最良見積値を記入する。 各工程で費やした実際の時間を分単位で記入する。

PSP0 プロセス要素 プロセスのスクリプト プロジェクト計画概要の帳票 時間記録ログ 欠陥記録ログ 欠陥型標準

PSP0計画概要 ‐ 2 累積時間(Time-To Date)‐各工程において費やした時間の現在までの累積値を記入する。 プログラム1Aに対しては、この値はプログラム1Aに対して費やされた時間である。 累積時間の割合(Time-To Date %)‐各工程の累積時間(Time-To Date)のパーセントを記入する。 作り込みおよび除去した欠陥‐各工程で作り込まれた欠陥及び除去された欠陥の実際の数を記入する。

PSP0計画概要‐3 累積欠陥(Defects-To Date)‐各工程で作り込まれ,除去された欠陥の現在までの累積数を記入する。  プログラム1Aに対してはプログラム1Aで作り込まれ,除去された欠陥数である。 累積欠陥数の割合(Defects-To Date %)‐各工程の累積欠陥(Defects-To Date)のパーセントを記入する。

PSP0 時間記録ログ‐1 参照 ー 付表C16 (P.409) ヘッダー ー受講者、日付、講師、プログラム番号 日付ー現在の日付を記入する。 開始 ー一つのプロジェクト工程を開始する時の時刻を分単位で記入する。

PSP0時間記録ログ‐2 終了 ーたとえその工程を完了していなくても、ある プロジェクト工程に関する仕事を停止する時にはその時刻を分単位で記入する。 中断時間 ー開始から終了までの期間で中断によって失った全ての時間を記入する。 差分時間ー 開始から終了までの経過時間から中断時間を差し引いた時間を記入する。

PSP0 時間記録ログ ‐ 3 工程 作業していた工程を記入する。 工程の名前を使う。 コメント ー次のことを記述する。 中断理由 実行していたタスク 作業に顕著に影響を与える他のもの何でも。

欠陥記録ログ‐1 参照 ー 付表C18 (p.411) ヘッダ‐ ー受講者、日付、講師、プログラム番号 日付 ー欠陥を発見し修正した日付を記入する。 番号 ー この欠陥の一意番号を記入する。各プロジェ クトで1から始める。

欠陥記録ログ ‐ 2 型 ー欠陥型標準から欠陥の型を記入する。 作込み ー欠陥が作り込まれたと判断する工程を記入する。 除去 ー欠陥を発見し修正した工程を記入する。

欠陥記録ログ ‐ 3 修正時間 ‐ 欠陥の修正にかかった時間を記入する。 正確に時間を測るか、あるいは最良の判断で記入 する。 修正時間 ‐ 欠陥の修正にかかった時間を記入する。 正確に時間を測るか、あるいは最良の判断で記入 する。 修正欠陥 ‐ もしこの欠陥が他の欠陥の修正中に作り込まれたのであれば、その欠陥の番号を記入するかまたはもし知らなければXを記入する。 説明 ‐ 欠陥とは、プログラムが適切に開発され、改善され、あるいは使用されるために変更されなければ ならないそのプログラムの中の全てのものである。

欠陥型標準 ‐ 1 参照 ー付表 C20 (p.413) 欠陥型標準は欠陥カテゴリーの一般的な集合を提供する。 この標準を自分自身の標準で置き換えても良いが、変更をガイドするデータを所有するまでは簡単な型標準をじっくり使っていく方が一般に賢明である。

欠陥型標準 ‐ 2 PSP欠陥型は次のようになる : 10 - 文書 20 - 構文 30 - ビルド、パッケージ 40 - アサインメント 50 - インタフェース 60 - チェッキング 70 - データ 80 - 機能 90 - システム 100 - 環境

演習課題 #1 テキストのまえがきと第1章、第2章を読むこと。 PSP0を使ってプログラム1Aを書くこと。(P.488-9) 演習課題 #1 テキストのまえがきと第1章、第2章を読むこと。 PSP0を使ってプログラム1Aを書くこと。(P.488-9) プログラム仕様については付録Dを見ること。(P.376-9, 405-413) PSP0の定義と例については付録Cを見ること。 提出物とそれらの順序と内容については付録Cの中にある仕様に従うこと。

プログラム 1A 一連の数値の標準偏差を計算せよ。その時n個の 数値はリンクリストに保有されている。標準偏差は次の ように計算される: i は数値に対するインデックス、そして Xavg はこれらの数値の平均値である。

示唆 ‐ 1 プログラムは単純にすること。小さなプログラムからでも大きなプログラムと同様に多くのことを学ぶであろう。 レポートと標準は単純に,かつ短くすること。 必要ならPSP教材を自由にコピーしたりそれを素材にしてもよい。 一回目に正しくやること。確信がなければ納得できるまでやりなさい。

示唆 ‐ 2 ソフトウエアは個人ビジネスではないので、1人だけで仕事をする必要はない。 しかしながら、見積もり、設計、及びコードは自分自身でつくらなければならない。 他の人に自分の仕事をレビューしてもらい、その結果として自分の仕事を変更しても良い。 あなたのプロセスレポートの中にこの支援について触れ、あなたと仲間が使ったレビュー時間を含め、発見した欠陥について記録すべきである。

PSP0評価基準 プロセスレポートは 完全で、 読みやすく、 規定した順序を守らなければならない。 プロセスデータは 正確で、 精度がよく、 自己完結的でなければならない。

講義1から記憶すべきメッセージ 1 - PSPはあなたが良い仕事をするように支援する ための1つの定義されたプロセスである。