project visualization system (pvs)

Project Visualization System (PVS)

Project Execution Plan (PEP)

Version: 2.0

Team #2

Name ID E-mail

詹昆宬 109598097 [email protected]

張景博

張雅雯

109598010

109598015

[email protected]

[email protected]

吳昱成 109598063 [email protected]

杜奕萱 109598098 [email protected]

Department of Computer Science & Information Engineering

National Taipei University of Technology

11/23/2020

1

目錄 (Table of Contents)

版次變更記錄 (Change Log) .......................................................................................................... 3

Section 1 專案規劃及查核點 (Project Planning and Milestone Checking) .............................. 4

1.1專案工作內容 (Project Work Description) ..................................................................... 4

1.1.1技術方法 (Technical Approach) .............................................................................. 4

1.1.2分工結構圖 (Work Breakdown Structure) .............................................................. 4

1.1.3工作分包與工作項目估算模型與方法 (Establish Estimates of Project Attributes)

............................................................................................................................................ 5

1.1.4工作分包與工作項目總表 (List of Work Packages and Tasks) ............................. 5

1.1.5工作分包與工作項目內容說明 (Descriptions of Work Packages and Tasks) ....... 6

1.1.6專案生命週期定義 (Project Life Cycle)............................................................... 10

1.2預定時程及查核點 (Schedule and Milestone Checking) ..............................................11

1.2.1預訂查核點說明 (Milestone Checking Description) .............................................11

1.2.2預定時程 (Schedule) ..............................................................................................11

1.2.3時程與進度審查監控機制說明 (Schedule & Progress Monitor and Control

Mechanism).......................................................................................................................11

Section 2 專案成員工作指派 (Personnel) .................................................................................. 12

2.1工作項目或工作分包預估需求與估算之假設條件 (Task Estimation Assumptions) 12

2.2計畫成員指派 (Roles and Responsibilities) .................................................................. 12

2.3調整專案成員 (Adjustments) ......................................................................................... 14

2.4專案專業知識與技能需求 (Requirements of Knowledges and Skills) ....................... 15

2.5訓練計畫表 (Trainning Plan) ......................................................................................... 15

2.6成員參與情況監控機制說明( Monitor and Control Mechanism) (此項目為必要監控

項目) 15

Section 3 資源需求 (Resources) .................................................................................................. 16

3.1計畫經費預算說明 (Budget) ........................................................................................... 16

3.2人事費用估算 (Estimations of Personnel Fee) ............................................................. 16

3.3計畫經費預估表 (Project Cost Estimation) .................................................................. 17

3.4預算監控機制說明 (Budget Monitor and Control Mechanism) ................................. 17

Section 4 資料管理規劃 (Data Management Plan) ................................................................... 18

4.1資料管理計畫 (Data Management Plan) ...................................................................... 18

4.2列管資料總表 (List of Managed Data) .......................................................................... 18

4.3列管資料監控機制說明 (Monitor and Control Mechanism) (此項目為必要監控項目)

18

Section 5 風險評估 (Risk Management) .................................................................................... 19

5.1風險項目評估 (Risks Assessment) ................................................................................. 19

5.2風險監控機制說明 (Risk Monitor and Control Mechanism) (此項目為必要監控項目)

19

2

Section 6 建構管理計畫 (Configuration Management Plan) ................................................... 20

6.1目的 (Purpose) ................................................................................................................. 20

6.2建立基準 (Establish Baselines) ...................................................................................... 20

6.2.1標示建構管理項目(Identify Configuration Items) ................................................ 20

6.2.2運用建立建構管理系統 (Establish a CM System) .............................................. 20

6.2.3建立基準 (Create or Release Baselines) ............................................................... 20

6.3異動追蹤與控制 (Track and Control Changes) ........................................................... 20

6.3.1異動追蹤 (Track Change) ..................................................................................... 20

6.3.2建構控制小組 (Configuration Control Board) ..................................................... 20

6.3.3異動控制 (Control Change) .................................................................................. 21

6.3.4版本控制程式 (The Version Control Tool) ........................................................... 21

6.4達成完整性 (Establish Integrity) ................................................................................... 21

6.4.1建構管理記錄 (Establish Configuration Management Records) .......................... 21

6.4.2建構審核 (Perform Configuration Audits) ............................................................ 21

Section 7 度量與分析計畫 (Measurement and Analysis Plan) ................................................ 22

7.1目的 (Purpose) ................................................................................................................. 22

7.2蒐集資訊的目的與資訊需求 (Information Needs and Objectives) ............................ 22

7.3基礎度量 (Base Measurement) ...................................................................................... 22

7.4度量與分析工具 (Measurement and Analysis Tool) .................................................... 22

Section 8 流程與產品品質保證計劃 (PPQA Plan) .................................................................... 23

8.1目的 (Purpose) ................................................................................................................. 23

8.2客觀檢視流程與產品 (Objectively Evaluate Process and Work Packages) .............. 23

8.3 專案目標洞察 (Project Objective Insight) ................................................................... 23

8.4管理架構 (Management Architecture) .......................................................................... 23

3

版次變更記錄 (Change Log)

Revisions

Version Primary

Author(s)

Description of Version Date Completed

1.0 詹昆宬

張景博

張雅雯

吳昱成

杜奕萱

需求分析、專案規劃 20/10/07

2.0 詹昆宬

張景博

張雅雯

吳昱成

杜奕萱

專案規劃更新 20/11/23

4

Section 1 專案規劃及查核點 (Project Planning and

Milestone Checking)

1.1專案工作內容 (Project Work Description)

1.1.1技術方法 (Technical Approach)

本專案旨在實作能夠展示視覺化資訊圖表的網頁應用程式，使用者可以追蹤公開的

Repository資訊，如 GitHub 上的 Repository 之 Issue、Commit、SonarQube上的報表等。

本網頁分為伺服器端以及使用者端兩個部分，伺服器端能夠提供使用者身分驗證、使用者權

限與資料管理、專案管理、Repository資訊追蹤的功能；而使用者端則提供可互動的使用者

介面以及圖表，讓使用者能夠檢視專案的資訊。本網頁輔助使用者有系統地查看開發過程中

的專案狀態，如在 GitHub上的的 Issues與 Commits變化等。使用者能夠持續追蹤其訂閱的

專案的開發流程，查看各種不同方式所展示的圖表，快速瞭解專案開發的狀態與團隊效率，

進而修正、改善或維持流程。

實務開發上，我們使用 React製作網頁前端（使用者端），Spring Boot製作後端（伺服

器端）。資料庫使用 PostgreSQL作為我們系統的 DBMS，藉由其所提供的介面與規格來儲

存平台上的各種資料。使用 Selenium撰寫自動化測試，驗證本網頁的正確性。

1.1.2分工結構圖 (Work Breakdown Structure)

5

1.1.3工作分包與工作項目估算模型與方法 (Establish Estimates of Project Attributes)

我們以 Scrum方法進行開發，我們將在每次 Sprint開始時進行 Sprint Planning Meeting，

決定該次 Sprint要做的 Story，並估計該次 Sprint承諾的 Story的 Story Point。

我們採用 Scrum Poker估算 Story Point，小組成員皆有一副 Scrum Poker，透過出牌表示

自己認為最合適的點數，此時點數若無落差即可確認 Story Point，但當點數有落差呈現時，

最高及最低點數者必須說明原因，之後組員將其他組員的想法納入考量並重新出牌，直到小

組成員出的點數皆相同。

1.1.4工作分包與工作項目總表 (List of Work Packages and Tasks)

Story Story Point

[1]

[1.1] 5

[1.2] 5

[1.3] 3

[1.4] 3

[1.5] 13

[1.6] 3

[2]

[2.1] 5

6

[2.2] 2

[2.3] 2

[3]

[3.1] 2

[3.2] 8

[3.3] 2

[3.4] 5

[4]

[4.1] 5

[4.2] 8

[4.3] 5

[4.4] 13

[4.5] 5

[4.6] 8

[5]

[5.1] 8

[5.2] 2

[5.3] 2

[5.4] 1

1.1.5工作分包與工作項目內容說明 (Descriptions of Work Packages and Tasks)

1. 需求文件撰寫

Story

[1.1]

內容說明 As a product owner,

I want a PEP,

so that I can set milestones.

相依性 SE專案需求

Importance 86

Story point 5

Story

[1.2]

內容說明 As a developer,

I want an SRS,

so that I can implement the product as the customer wishes.


Importance 87

Story point 5

Story

[1.3]


I want to revise PEP,

so that PEP can meet the process used by our team.

7


Importance 84

Story point 3

Story

[1.4]


I want to revise SRS,

so that SRS can meet stakeholders' requirement with their feedback.


Importance 83

Story point 3

Story

[1.5]


I want a SDD,

so that I can implement product depending on the SDD.

相依性

Importance 85

Story point 13

Story

[1.6]


I want a STD,

so that I can implement testing depending on the STD.

相依性 Story [1.3]

Importance 80

Story point 3

2. UMS

Story

[2.1]

內容說明 As a user,

I want to have an account management system,

so that I can sign up and log in to PVS.


Importance 81

Story point 5

Story

[2.2]


I want to have a prototype of UMS,

so that I can discuss with team member more concretely.

相依性

Importance 89

Story point 2

Story

[2.3]


I want users to link their GitHub account,

so that I can get data from GitHub with their token.

相依性

8

Importance 90

Story point 2

3. PRMS

Story

[3.1]


I want to have a prototype of PRMS,


相依性

Importance 99

Story point 2

Story

[3.2]


I want to have a project repository management system,

so that I can add new repository and keep track of the following

repository.

相依性

Importance 95

Story point 8

Story

[3.3]


I want to search repositories that I followed,

so that I can find them easily.


Importance 73

Story point 2

Story

[3.4]


I want to search repositories that I want to follow,



Importance 62

Story point 5

4. RCS & RVS

Story

[4.1]


I want to have a prototype of RVS,


相依性

Importance 100

Story point 5

9

Story

[4.2]


I want commit data to be shown as chart,

so that I can analyze repositories which I followed.


Importance 98

Story point 8

Story

[4.3]


I want issue data to be shown as chart,



Importance 97

Story point 5

Story

[4.4]


I want to view a code quality report (table and chart, etc.),

so that I can know the code quality.


Importance 91

Story point 13

Story

[4.5]


I want to compare different projects,

so that I can know each team's characteristics.

相依性

Importance 79

Story point 5

Story

[4.6]


I want to view burndown charts in RVS,

so that I can analyze the pace of the development team by

burndown charts.

相依性

Importance 78

Story point 8

5. 軟體品質

Story

[5.1]


I want a SonarQube environment,

so that I can scan my code and maintain code quality.

相依性

Importance 92

10

Story point 8

Story

[5.2]


I want a CI server,

so that I can have automated testing.

相依性

Importance 93

Story point 2

Story

[5.3]


I want to set up Maven in my development environment.

相依性

Importance 94

Story point 2

Story

[5.4]


I want a Selenium environment,

so that I can verify each feature can work as expected.

相依性

Importance 75

Story point 1

1.1.6專案生命週期定義 (Project Life Cycle)

我們使用 Scrum Sprint來定義專案的週期。我們一個 Sprint為二週。

11

1.2預定時程及查核點 (Schedule and Milestone Checking)

1.2.1預訂查核點說明 (Milestone Checking Description)

查核點預定時間查核點概述產品

M1 20.11.03 完成系統的 prototype以及 SRS SRS

M2 20.12.02 Design + Construction of Increment 1 SRS, PEP, SDD

M3 20.12.29 Design + Construction of Increment 2 SDD, STD

M4 20.01.06 Final SDD + STD due SDD, STD

1.2.2預定時程 (Schedule)

Sprint 1 2020/09/30-2020/10/13 PEP

Sprint 2 2020/10/14-2020/10/27 SRS

Prototype

Sprint 3 2020/10/28-2020/11/10 SRS

Prototype

GitHub Data Collection

Sprint 4 2020/11/11-2020/11/24 Revise PEP、SRS

SDD

Commit 資訊視覺化功能

Sprint 5 2020/11/25-2020/12/08 SDD

STD & 建立自動化測試環境

Issue 資訊視覺化功能

SonarQube

Sprint 6 2020/12/09-2020/12/22 Repository 管理功能

使用者管理功能

整合測試+驗收測試

Sprint 7 2020/12/23-2020/01/05 整合測試+驗收測試

1.2.3時程與進度審查監控機制說明 (Schedule & Progress Monitor and Control

Mechanism)

本專案中，大多數的工作都以 Sprint做為基本單位，因此在專案進行中我們將會在每個

Sprint內安排至少一週一次的組員討論（星期三下午），確認進度有無落後。如有進度落後的

情況，則會對當前的進度進行微調。我們在每個里程碑前都會預留一些時間以提供彈性調度。

12

Section 2 專案成員工作指派 (Personnel)

2.1工作項目或工作分包預估需求與估算之假設條件 (Task Estimation

Assumptions) ※工作分包預估方式︰

☐ 歷史資料法

■ 專家法(透過個人專業判斷，進行估算)

☐ 其他估算法

※參數︰

a. 文件︰1頁/ 1人時

b. 系統功能︰1個/ 8人時

c. 假設條件︰以人事行政局公佈的年度上班時間為工作日

d. 一週工作時數為 10小時（加班視專案及課業程度而自行調整）

※專業技能需求：

專業技能需求人數

需求文件撰寫 5

專案管理 5

系統工程 5

軟體設計 5

軟體發展 5

整合與測試 5

2.2計畫成員指派 (Roles and Responsibilities)

姓名縮寫

張景博 CP

張雅雯 YW

吳昱成 YC

杜奕萱 YH

詹昆宬 KC

團隊採用 Scrum的開發模式以及採用 mob programming，因此五位開發人員會在每次 Sprint

中共同開發，完成所有的 Stories。

WBS 活動與交付項目負責人員

1.1 As a product owner,

I want a PEP,

so that I can set milestones.

CP, YW,

YC, YH, KC

1.2 As a developer,

I want an SRS,

CP, YW,

YC, YH, KC

13

so that I can implement the product as the customer wishes.

1.3 As a developer,

I want to revise PEP,

so that PEP can meet the process used by our team.

CP, YW,

YC, YH, KC

1.4 As a developer,

I want to revise SRS,

so that SRS can meet stakeholders' requirement according

to their feedback.

CP, YW,

YC, YH, KC

1.5 As a developer,

I want a SDD,

so that I can implement product depending on the SDD.

CP, YW,

YC, YH, KC

1.6 As a developer,

I want a STD,

so that I can implement testing depending on the STD.

CP, YW,

YC, YH, KC

2.1 As a user,

I want to have a account management system,

so that I can log in to PVS.

CP, YW,

YC, YH, KC

2.2 As a developer,

I want to have a prototype of UMS,


CP, YW,

YC, YH, KC

2.3 As a developer,

I want users to link their GitHub account,

so that I can get data from GitHub with their token.

CP, YW,

YC, YH, KC

◆ 里程碑：Prototyping & SRS CP, YW,

YC, YH, KC

3.1 As a developer,

I want to have a prototype of RMS,


CP, YW,

YC, YH, KC

3.2 As a user,

I want to have a project repository management system,

so that I can add new repository and keep track of the

following repository.

CP, YW,

YC, YH, KC

3.3 As a user,

I want to search repositories that I followed,


CP, YW,

YC, YH, KC

3.4 As a user,

I want to search repositories that I want to follow,


CP, YW,

YC, YH, KC

14

4.1 As a developer,

I want to have a prototype of RVS,


CP, YW,

YC, YH, KC

4.2 As a user,

I want commit data to be shown as chart,


CP, YW,

YC, YH, KC

4.3 As a user,

I want issue data to be shown as chart,


CP, YW,

YC, YH, KC

4.4 As a user,

I want to view code quality report(table and chart etc.),

so that I can know the code quality.

CP, YW,

YC, YH, KC

4.5 As a user,

I want to compare different projects,

so that I can know each team's characteristics.

CP, YW,

YC, YH, KC

4.6 As a user,

I want to view burndown charts in PVS,

so that I can analyze the pace of develop team by burndown

charts.

CP, YW,

YC, YH, KC

◆ 里程碑：Issue及 Commit完整功能（系統完成） CP, YW,

YC, YH, KC

5.1 As a developer,

I want a SonarQube environment,

so that I can scan my code and maintain code quality.

CP, YW,

YC, YH, KC

5.2 As a developer,

I want a CI server,

so that I can have automated testing.

CP, YW,

YC, YH, KC

5.3 As a developer,

I want to set up Maven in my development environment.

CP, YW,

YC, YH, KC

5.4 As a developer,

I want a Selenium environment,

so that I can verify each feature can work as expected.

CP, YW,

YC, YH, KC

◆ 里程碑：系統測試完成 CP, YW,

YC, YH, KC

2.3調整專案成員 (Adjustments)

小組人員在開發過程中不會有更換，因此不會有調度問題。

15

2.4專案專業知識與技能需求 (Requirements of Knowledges and Skills)

專業技能及知識預估需要人數預計受訓人員說明

GitHub API 5 3 本專案成員大都沒有相關經驗

JavaScript 5 0 本專案成員已有相關經驗

Java 5 0 本專案成員已有相關經驗

PostgreSQL 5 3 本專案成員大都沒有相關經驗

OAuth 5 5 本專案成員皆無相關經驗

React 5 2 本專案成員部分有相關經驗

Selenium 5 5 本專案成員皆無相關經驗

Spring-boot 5 2 本專案成員部分有相關經驗

Web UI design 5 5 本專案組員大都沒有設計經驗

2.5訓練計畫表 (Trainning Plan)

⚫ 使用者介面設計只能靠成員本身的審美觀念進行設計。利用 material-ui現成的模板設計

出來的Web UI已經具備一定程度的外觀設計，因此不需要特別訓練。

⚫ 網頁前端因為有成員有開發經驗，所以只需要成員在實作時互相學習即可。

⚫ 後端成員均有開發經驗，只是使用的平台不相同而已，不需要特別訓練。

⚫ 單元測試成員均有相關經驗，不需要特別訓練。

⚫ 整合測試成員均無相關經驗，需要特別訓練。

2.6成員參與情況監控機制說明( Monitor and Control Mechanism) (此項目為

必要監控項目)

專案進行中，每星期皆會舉辦一次會議，審視所有人員的工作參與情況以及產出。當專

案進度有所延後，我們會找出問題的癥結點並調整人員配置，並且在能滿足客戶需求的最低

標準下，挑出最重要的工作做，盡可能趕上所規劃的進度。

16

Section 3 資源需求 (Resources)

3.1計畫經費預算說明 (Budget)

Story編號設備費業務費管理費用合計

1.1 1,000 500 1,500

1.2 500 500

1.3 500 500

1.4 500 500

1.5 500 500

1.6 500 500

2.1 600 1,000 500 2,100

2.2 2,000 500 2,500

2.3 1,000

3.1 500 500

3.2 5,000 500 5,500

3.3 5,000

3.4 5,000

4.1 5,000 500 5,500

4.2 5,000 500 5,500

4.3 10,000 500 10,500

4.4 10,000 500 10,500

4.5 10,000 500 10,500

4.6 10,000 500 10,500

5.1 6,000 500 6,500

5.2 6,000 500 6,500

5.3 6,000 500 6,500

5.4 6,000 500 6,500

合計 89,600 4,000 10,000 103,600

（單位：新臺幣）

3.2人事費用估算 (Estimations of Personnel Fee)

工作計畫需求人力：653人時總人事費用：5員

職級單位（時）人事費概算備註

研究生（5人） 653小時

1,306,000

其他（加班費） 0

17

3.3計畫經費預估表 (Project Cost Estimation)

經費項目預定金額說明

設備費 89,600 筆記型電腦 2台、個人電腦 1台、大螢幕 1台

業務費 4,000 一般業務或特殊業務之用，例如文件的產生所使用的資源

費用。

人事費 1,306,000 專案人員共五名的人事費用。

管理費 10,000 專案管理以及其他經費。

合計 1,409,600

3.4預算監控機制說明 (Budget Monitor and Control Mechanism)

本專案有關於預算的監控機制為：

a. 監控頻率：每天監控一次。

b. 實施矯正之基準及其措施：預算使用超過 10%即必須實施矯正措施。矯正措施為開

會決定如何取得資金，或是刪減專案活動。

18

Section 4 資料管理規劃 (Data Management Plan)

4.1資料管理計畫 (Data Management Plan)

本計畫資料管理與儲存方式將分為三種：

主要程式碼︰主要程式碼存於 Github以利進行版本控制。

子文件及可執行檔︰小組成員皆以臺北科技大學提供的Google帳號使用Google雲端硬

碟服務，將子文件及可執行檔保存於共用資料夾中。

本文件或光碟資料︰由小組成員共同管理。

4.2列管資料總表 (List of Managed Data)

資料名稱版控

建構

管理

機密

等級

產生

週期

儲存

方式

資料

提供者

資料

使用者

專案執行規劃書否否密 Sprint C 團隊團隊

系統需求規格書否否密 Sprint C 團隊團隊、使用者

系統設計規格書否否密 Sprint C 團隊團隊

主要程式碼是是密 Weekly A 團隊團隊、測試者

整合測試計畫書否否密 Sprint B 團隊團隊、測試者

系統測試報告否否密 Sprint B 團隊、測試者團隊、測試者

系統接受度報告否否密 Sprint B 測試、使用者測試、使用者

4.3列管資料監控機制說明 (Monitor and Control Mechanism) (此項目為必

要監控項目)

(說明監控列管資料之實施矯正措施基準及機制)

本專案監控列管資料之矯正措施基準與機制為：

※ 監控頻率：每兩週監控一次。

實施矯正之基準及其措施：資料管理所列管的所有資料都必須按照資料管理計畫的方

式進行，如果發現任何的資料未按資料管理計畫保管或備份，都必須立刻進行矯正，矯正

措施為立即確認現在狀態，暫停手上所有事情，將所有資料按照資料管理計畫執行後，再

繼續進行相關開發。

19

Section 5 風險評估 (Risk Management)

5.1風險項目評估 (Risks Assessment)

風險項目發生機率影響程度風險發生處理或避免方法

人事變動 5% 低每週固定時間Meeting，了解組員彼此情況

版本衝突 10% 低利用 Git做版本控制

人員的訓練不足 10% 低平日多充實自我能力、組員間彼此互相幫忙

資料庫需求變更 50% 高降低程式的相依度

資料庫伺服器毀損 10% 高定期備份

版控伺服器毀損 < 1% 中 Client端直接回復至版控伺服器

伺服器被入侵 5% 高定期備份、設置使用者權限

5.2風險監控機制說明 (Risk Monitor and Control Mechanism) (此項目為必

要監控項目)

專案目前推估的高風險的發生均為不可預期的事件，因此只能在面對風險時才能做適

時的處理，以下針對高風險議題提出基本的處理方案︰

※ 資料庫需求變更：

解決方法︰盡可能讓程式間相依性變低，當需求異動或需求變更，只需要修改少數資料表的

可能，或者新增資料表但不影響其它資料表的運作。

※ 資料庫伺服器毀損：

解決方法︰每週固定備份資料庫資料，以及當需求有重大變更時也要做一次資料庫備份。

※ 版控伺服器毀損：

解決方法：本專案使用 GitHub作為版控伺服器，毀損機率極低，此外因為團隊皆採 mob

programming，client端有原始碼，直接回復至 GitHub即可。

20

Section 6 建構管理計畫 (Configuration Management Plan)

6.1目的 (Purpose)

本專案系統開發為釋出讓使用者去使用，因此可能需要有長時間維護的工作，或是當新

的需求被提出要加入時，可能需要有開發的工作，而一個良好的建構管理，即可在一邊開發

的同時也可以針對早期版本發現的問題做個別修改，因此才需要此計畫。

6.2建立基準 (Establish Baselines)

6.2.1標示建構管理項目(Identify Configuration Items)

ID 資料名稱版本

管控建構類別產生週期資料提供者資料使用者

1 專案執行規劃書否規格書 Sprint 團隊團隊

2 系統需求規格書否規格書 Sprint 團隊團隊、使用者

3 系統設計規格書否規格書 Sprint 團隊團隊

4 整合測試計畫書否規格書 Sprint 團隊團隊、測試者

5 原始程式碼是原始碼 Weekly 團隊團隊

6 系統測試報告否報告資料 Sprint 團隊、測試者團隊、測試者

7 系統接受度報告否報告資料 Sprint 測試、使用者測試、使用者

6.2.2運用建立建構管理系統 (Establish a CM System)

本專案採用 Github進行建構管理。

6.2.3建立基準 (Create or Release Baselines)

由表 6.2.1得知，沒有版本控管的書面資料，是為隨時跟著系統的開發更新，但企劃書

以及一些測試報告書確認後將不會異動，因此皆不需要版本控制，唯獨原始程式碼使用 Git

進行版本控制，來達到 6.1所提及的目的。

6.3異動追蹤與控制 (Track and Control Changes)

6.3.1異動追蹤 (Track Change)

a. 提出異動申請(Github Pull Request)。

b. 由 Development Team以及 Product Owner 評估影響層面，並通知相關人員。

c. 由 Product Owner邀集受影響單位進行評估，並決定是否准予異動。

d. 追蹤異動的狀態(例如異動時間、異動版本)。

6.3.2建構控制小組 (Configuration Control Board)

此小組由開發團隊本身自行監控。

21

6.3.3異動控制 (Control Change)

我們採取 github flow:

a. 對於異動的項目對該版本提出一個分支（git branch）。

b. 提出異動申請（GitHub PR）。

c. 再次確認、測試、討論、重構。

d. 異動紀錄以及異動原因皆在 GitHub PR 頁面進行。

e. 確認異動後，merge 該分支到 main。

6.3.4版本控制程式 (The Version Control Tool)

本專案使用 Git來進行版本控制，輔以 Github的服務。

6.4達成完整性 (Establish Integrity)

6.4.1建構管理記錄 (Establish Configuration Management Records)

管理記錄為建立與維護用來描述建構管理項目的紀錄。紀錄皆會被保存在 GitHub PR

Page。

6.4.2建構審核 (Perform Configuration Audits)

為達成對於建構系統中的分支擴充性，團隊們將在新功能開發到整合時，必須使用

git merge –squash合併到 main分支，原本的功能分支不予刪除並使用 tag標示已合併，以

利後期的除錯及維護。

若有其餘開發中分支，應用 git rebase到最新的 main 分支上。

22

Section 7 度量與分析計畫 (Measurement and Analysis Plan)

7.1目的 (Purpose)

度量分析主要在蒐集本專案的各項資訊，以提供各種分析之用，做為日後改善之依據。

7.2蒐集資訊的目的與資訊需求 (Information Needs and Objectives)

序號目的資訊需求

1 客戶滿意度客戶的反應、支援客戶的狀況

2 時程與進度里程碑完成狀況、工作單元進度

3 資源與成本支出、各項資源支援的程度

4 產品品質系統或功能品質、使用者介面的良劣

5 客戶需求的穩定程度客戶需求的異動

6 產品大小每個子系統的大小、功能多寡

7.3基礎度量 (Base Measurement)

序號度量因子

1 客戶滿意度度量經由客戶問題的反應：與客戶互動的時間

2 里程碑完成狀況、工作單元進度里程碑完成的時間、階層中工作單元完成度

3 支出、各項資源支援的程度專案人員投入的工作時數、實際支出數

4 系統或功能品質、使用者介面的良劣系統或功能之錯誤數、使用者反應介面問題

5 客戶需求的異動客戶需求異動個數、個數、無法修改個數

6 每個子系統的大小、功能多寡每個子系統的程式行數、功能數

7.4度量與分析工具 (Measurement and Analysis Tool)

根據團隊成員各自經驗、親自操作、測試之結果，做為度量分析之依據。

23

Section 8 流程與產品品質保證計劃 (PPQA Plan)

8.1目的 (Purpose)

本計畫使專案所有人員能瞭解本專案的流程並追蹤產品品質，亦可當作系統接受度測試

的檢視，以告知使用者本系統的品質趨向。

8.2客觀檢視流程與產品 (Objectively Evaluate Process and Work Packages)

a. 專案成員共同檢視系統執行流程，並依照系統規格書審查。

b. 確認產品符合需求。

c. 專案成員共同審查，並且依照文件進行流程檢驗。

8.3 專案目標洞察 (Project Objective Insight)

a. 開發團隊要與 Product owner討論、確認需求，了解 Product owner所期望的結果。

b. Product owner將需求告知專案成員並審查開發流程。

8.4管理架構 (Management Architecture)

由詹昆宬擔任組長，其他人為組員。此外團隊採扁平化結構，因此若認為系統有任何可

以改善的地方，均可提出想法讓團隊共同評估是否要加入系統需求。專案執行上採用 Scrum，

皆是團員共同合作，不須特別指派工作分工。

project visualization system (pvs)

Documents