非同步线上检视系统之设计与实作

1、非同步線上檢視系統之設計與實作Design and Implementation of Software Asynchronous Inspection System (SAIS) Version 0.2MemberCommitment signature吳政明吳政明杜永全杜永全2005/09/06此計畫書是依照IEEE1058來編寫的Table of ContentsRevision History21Overview31.1Project Summary3Purpose, scope, objective3Assumption and constraint4Project delivera

2、bles4Schedule and budget summary42Reference53Definition74Project Organization84.1Internal Structure84.2Roles and Responsibility85Managerial Process Plan105.1Project Start-up plan10Staffing plan10Resource acquisition plan10Project Staff training plan105.2Work plan10Work activities10Schedule allocatio

3、n10Resource allocation105.3Control plan12Requirement control plan12Schedule control plan 12Risk management plan125.4Project closeout plan136Technical process plan146.1Process model146.2Methods, tools, and techniques157Additional plan167.1Communication plan168Plan Annex17Revision History版本日期說明作者0.120

4、05/08/30初擬PEP吳政明0.22005/09/21修改、補上不足杜永全1 Overview1.1 Project Summary 1.1.1 Purpose, scope, objective Purpose：軟體檢視(formal inspection)是為了在開發軟體的過程中，及早發現軟體中的缺陷並改正之，以減少軟體開發完成所需的時間。非同步線上檢視系統可以讓參加軟體檢視的所有成員，以非同步的方式在網路上參與檢視計畫，而不受限於時間、地點。Scope：只要向本系統注冊的使用者，皆可以使用本系統；如果沒有注冊的使用者，則可以使用Guest身份，參觀本系統。Objective：IBIS

5、系統將使用者分為三類：moderator、author and other inspectors。 Moderator：檢視團隊的領導人，同時也是整個檢視計畫的負責人。Author：軟體的創作者。Inspectors：參予檢視計畫的成員。整個檢視的過程分為以下幾個階段： 階段名稱說明Planningmoderator從author那取得欲檢視的軟體，並制定整個檢視計畫的Schedule，以及挑選參予檢視計畫的成員Overview為了讓所有成員更加地暸解此軟體以及整個檢視計畫的流程，利用即時通訊軟體舉行一個線上會議。這個階段是非必要的。Discovery關鍵階段。inspectors找出軟體的缺

6、陷並將之記錄下來。CollectionModerator將所有inspector所找到的缺陷集中，並將重複的剔除。Discrimination將缺陷紀錄給author看，確認是否真的為軟體缺陷。這個階段是非必要的。Rework讓author修正所找到的軟體缺陷Follow UpModerator 檢查軟體缺陷是否都被修正，來決定檢視計畫是否結束。我們將以IBIS為範本，依據我們現在的使用環境、大學部學生能力和創意，做出一個屬於我們的SAIS系統。1.1.2 Assumption and constraint 1.1.3 Project deliverables 文件：PEP：專案計畫文件（Pr

7、oject Execution Plan）SRS：需求規格文件（System Requirements Specification）SDD：系統設計文件（System Design Description）STR：系統測試報告（System Testing Document）PFR：專題期末報告（Project Final Report）軟體：非同步線上檢視系統硬體：1.1.4 Schedule and budget summary 我們主要分為五大階段，如下：階段完成日期內容Pase12005/08/31完成專題計畫書 (PEP)Pase22005/12/31完成需求規格書 (SRS)Pas

8、e32006/06/31完成系統設計說明書 (SDD)Pase42006/09/31完成系統與系統測試文件 (STD)Pase595學年發表專題2 Referencel 書籍1 林上傑、林康司，JSP 2.0技術手冊。台彎，碁峰資訊，2004年04月。2 楊淑雅、郭文益、王國恩，FrontPage2000網頁任我行。台彎，新文京開發出版有限公司，2001年12月。3 章魚貓工作室，Dreamweaver MX 2004 e世代的e網頁。台灣，文魁資訊股份有限公司，2004年4月。4 朱志山，Fireworks MX網頁圖像設計師。台灣：上奇科技股份有限公司，2002年8月。 5位元文化，JSP

9、動態網頁入門實務。台灣，文魁資訊股份有限公司，2004年8月l 網頁Example1 IBIS Project專題網頁1專題網頁（Project Blog）URL：CMMI1Software Engineering Institute URL：JSP1 JSP學習講義 URL：Java1 JavaWorldTW URL：2 JavaRanch URL：3 The Apache Jakarta Project URL：Page1 酷必網知識社群2 Flash 網路教學3 DOB網站建製百寶箱4 JAVA語法圖書館5 軟體百視達:FLASH MX教學錄影檔6 爪哇博物館7 雄之網頁 別問我是誰 本

10、站只針對留言板而設3 DefinitionJSP：（JavaServer Page）.。主要用來產生動態網頁內容的技術。PEP：專案計畫文件（Project Execution Plan）。PEP的主要目的是描述專題進行的計畫。SDD：系統設計文件（System Design Description）。主要描述你的系統設計。SDD應與 SRS相呼應，亦即，你的設計如何能滿足 SRS 的需求？SRS：需求規格文件（System Requirements Specification）。主要在描述系統的需求，亦即，你的系統提供了什麼功能？STR：系統測試報告（System Testing Docum

11、entt）。如何證明你的系統執行是沒有問題的？STR 應與 SRS 相呼應，亦即，SRS 內的每一個需求怎麼被證實？怎麼被測試？PFR：專題期末報告（Project Final Report）。最後交到係辦的報告，將 PEP、 SRS,、SDD、STP 做為附件。4 Project Organization4.1 Internal Structure專題指導老師指導老師薛念林老師研究室資電225分機3773E - M.tw專題指導助教指導助教郭嘉竣助教研究室軟體工程實驗室分機3722E - Mailyaboe788專題成員專題成員吳政明班級資訊三丙職務專題組長

12、手機0958-897656E - Mailddw521.xyz專題成員杜永全班級資訊三甲職務專題成員手機0921-511089E - M.tw4.2 Roles and Responsibility l 專題指導老師 薛念林老師：扮演整個專題的指導角色，提供專題進行方向、建議和監督專題之進行進度。l 專題指導助教 郭嘉竣助教：在整個專體過程，提供我們所需的資源，輔導我們完成專題。l 專題成員因為現在SRS尚未完成，所以無法規畫每個成員所應該做的工作，所以現在是先以培養專題中所需要的技術為主。5 Managerial Process Plan5

13、.1 Project Start-up plan 5.1.1 Staffing plan 不需要此計畫5.1.2 Resource acquisition plan l 硬體設備資源因為整個系統是架構在網業上的。所需要的資源獲得資源的計畫一個固定的網路空間軟體工程實驗室會提供一個大學部專題Server，來供我們來使用。l 軟體資源目前尚無需要5.1.3 Project Staff training plan 目前尚無計畫5.2 Work plan 5.2.1 Work activities 內容專題計畫書 (PEP)需求規格書 (SRS)系統設計說明書 (SDD)系統與系統測試文件 (STD)

14、發表專題5.2.2 Schedule allocation 我們分成五的階段來完成。階段完成日期內容Pase12005/08/31完成專題計畫書 (PEP)Pase22005/12/31完成需求規格書 (SRS)Pase32006/06/31完成系統設計說明書 (SDD)Pase42006/09/31完成系統與系統測試文件 (STD)Pase595學年發表專題5.2.3 Resource allocation 工作階段第1階段工作名稱專題計畫書 (PEP)需求資源人力2人月硬體設備軟體工具Microsoft Office其他備註工作階段第2階段工作名稱需求規格書 (SRS)需求資源人力2人月硬

15、體設備軟體工具Microsoft Office其他備註工作階段第3階段工作名稱系統設計說明書 (SDD)需求資源人力2人月硬體設備軟體工具Microsoft Office其他備註工作階段第4階段工作名稱系統與系統測試文件 (STD)需求資源人力2人月硬體設備軟體工具JSP、Microsoft Office、MySQL其他備註工作階段第5階段工作名稱發表專題需求資源人力2人月硬體設備軟體工具Microsoft Office其他備註5.3 Control plan 5.3.1 Requirement control plan 目前尚無計畫。5.3.2 Schedule control plan 目

16、前我們製作了一個專題網頁（Project Blog ），來控管我們的專題進度，在網頁內容中，我們製了三個項目如下。項目功能Blog專題日誌。每個星期確實記錄專題進度，即使沒有進度也要寫無進度，來掌握目前確實的進度。Diary心的目誌。撰寫屬於自己的學習心得，待專題完成時，在加以彙整，即可完成專題心得（lesson learned）。Schedule專題計畫。規劃每個月的進度，在計畫日期到了時，檢視自己是否有如期完成；如果沒有的話，則深入檢討為何沒有如期完成的原因。透過專題網頁的管理，可以讓老師、專題助教、專題成員，可以非常清楚、容易的得知目前的進度，如果發現進度落後，可以即時叮嚀專題成員。如果

17、發現專題落後時，我們先檢討落後原因，在找出適當的處理方式。落後原因處理方式成員能力不足詢問成員是否有能力克服此問題，如果確定無法克服或是需要較長的時間，因而會在導致專題進度更嚴重落後的話，將此問題轉交由其他成員來完成，如果長時間發現此成員都是處於這樣的情況的話，證明此成員無能力應付此專題，將會要求他退出此專題計畫。成員怠惰叮嚀、要求盡快補齊落後的進度，如果此成員長時間處於這樣的表現的話，將會要求他退出此專題計畫。其它視情況而定，在跟其他成員討論，做出適定的處理方式。5.3.3 Risk management plan 專題進度落後，是導致專題失敗最大的風險，所以我們做了以下工作來控管我們的專題

18、進度。l 避免風險方面我們製作了一個專題網頁（Project Blog），來控管我們的專題進度，在網頁內容中，我們製了三個項目如下。項目功能Blog專題日誌。每個星期確實記錄專題進度，即使沒有進度也要寫無進度，來掌握目前確實的進度。Diary心的目誌。撰寫屬於自己的學習心得，待專題完成時，在加以彙整，即可完成專題心得（lesson learned）。Schedule專題計畫。規劃每個月的進度，在計畫日期到了時，檢視自己是否有如期完成；如果沒有的話，則深入檢討為何沒有如期完成的原因。透過專題網頁的管理，可以讓老師、專題助教、專題成員，可以非常清楚、容易的得知目前的進度，如果發現進度落後，可以即時

19、叮嚀專題成員。l 處理風險方面我們先檢討落後原因，在找出適當的處理方式。專題失敗風險處理方式成員能力不足詢問成員是否有能力克服此問題，如果確定無法克服或是需要較長的時間，因而會在導致專題進度更嚴重落後的話，將此問題轉交由其他成員來完成，如果長時間發現此成員都是處於這樣的情況的話，證明此成員無能力應付此專題，將會要求他退出此專題計畫。成員怠惰叮嚀、要求盡快補齊落後的進度，如果此成員長時間處於這樣的表現的話，將會要求他退出此專題計畫。其它視情況而定，在跟其他成員討論，做出適當的處理方式。5.4 Project closeout plan 目前尚無計畫。6 Technical process pla

20、n 6.1 Process model 典型的開發模型就是Waterfall Model，當然我們已經有其他更好的模型(事實上Waterfall Model亦已被認為在很多方面也乏善足陳)，不過Waterfall也能反映開發軟件的重要步驟和階段，而我們又是第一次開發系統，所以我們選擇用典型的Waterfall Model來當作我們的開發模型。Waterfall Model分為五個階段l 需求分析和規格 (Requirement Analysis and Specification)定義"What is the problem"，定清用家需求，並建立文件說明。l 系統設計 (

21、Design)定義"How to solve the problem"，設計出解決用家需求的系統，包括了Architectural Design和Detailed Design。l 編碼和模組測試 (Coding and Unit Testing)將系統分割成不同模組，並各自進行編碼和測試。l 整合和系統測試 (Integration and System Testing)將所有模組整合成完整系統並作最後測試。l 發行及維護 (Delivery and Maintenance)將產品發行或給用戶運行，並開始進行維護，包括修正性、調整性和改良性的維護。Waterfall Mo

22、del工作內容用家需求分析和規格(Requirement Analysis and Specification)1. 完成PEP專案計畫文件。系統設計(Design)1. 完成SRS需求規格文件。編碼和模組測試(Coding and Unit Testing)1. 完成SDD系統設計文件。整合和系統測試(Integration and System Testing)1. 完成STR系統測試報告。發行及維護(Delivery and Maintenance)1. 完成PFR專題期未報告。6.2 Methods, tools, and techniques Methods：目前尚無計畫Tools：l UML