# PEP __sec 1.__ > 1.1 >> 1.1.1 >> __同原版__ >> >> 1.1.2 >> ![](https://i.imgur.com/dedLNH6.png) >> >> 1.1.3 >> 本專案將以瀑布模式(Waterfall Model)作為系統開發方式進行，將每一階段的工作及繳付文件清楚定義後並循序執行，而根據本系統的複雜度，本團隊將開發過程劃分成三個主要階段，分別為分析、設計、實施。開發過程中若在各階段發現錯誤，可允許階段間之回饋，如此能儘早修正以減少系統修改或重做之成本。在每一開發階段結束後可將其作為管理控制的里程碑，除此之外，各個階段的產出皆需須經過確認(Validation)、驗證(Verification)或測試(Testing)。 >> >> 1.1.4 >> (1). 分析 >> -- 可行性分析 >> -- 需求分析 >> -- 系統分析 >> >> (2). 設計 >> -- 概念及框架設計 >> -- 細部設計 >> >> (3). 實施 >> -- 程式編輯與單元測試 >> -- 整合測試 >> -- 安裝與系統測試 >> -- 教育訓練 >> -- 操作與維護 >> >> 1.1.5 >> (1). 分析 >> a. 文件需求 >> -- PEP >> * PEP(Projrct Excute Plan)，也就是本執行計劃文件，其中需載明專案的基本資訊、如何執行專案、如何管理專案等相關細節，並包含以下的內容：專案規劃及查核點 (Project Planning and Milestone Checking) 、時程與進度審查監控機制說明 (Schedule & Progress Monitor and Control Mechanism)、資源需求 (Resources)、資料管理規劃 (Data Management Plan)、風險評估 (Risk Management)、建構管理計畫 (Configuration Management Plan)、度量與分析計畫 (Measurement and Analysis Plan)、流程與產品品質保證計劃 (PPQA Plan) >> >> -- SRS >> * SRS(Software requirements specification)，軟體需求說明書會列出專案開發上，充份且必要的需求資訊。此文件包括功能性需求及非功能性需求，當中非功能性需求以可行性分析為主，比如性能要求、產能標準或者設計限制，也包括用例，敘述在理想情形下，使用者使用軟體的方以及需要提供給的介面，窮舉各個使用情境。軟體需求說明為客戶和供應商協議之基礎，說明軟體產品應該有的機能，同時也是預估產品成本、風險以及時程的實務性基礎，可以預防軟體專案的失敗。 >> >> b. 細項說明 >> * 使用者需求： >> -- 註冊成為系統的使用者 >> -- 對現有的專案進行刪除 >> -- 可以刪除專案內的 Repository(Github, SonarQube, Trello) >> -- 新增 Repository的時候我能夠填入Access token，而不是將 Access Token 放在環境變數內 >> --可以新增 Trello 到專案內 >> >> (2). 設計 >> a. 文件需求 >> -- SDD >> * SDD(Software Design Description)，軟體產品的文字描述，提供軟體開發團隊有關軟體產品的架構指引，會配合軟體的架構圖，其中會再針對軟體中的各模組說明其細部規格。 >> >> b. 細項說明 >> * 前端環境開發網頁框架概念設計 >> * 後端環境開發伺服器框架概念設計 >> * 概念整合討論 >> >> (3). 實施 >> a. 文件需求 >> -- STD >> * STD(Statechart Daigram)狀態圖型會應用到軟體系統中，各個任務的生命週期。任務的生命週期中，會有不同的狀態，藉由不同狀態的檢視，可以去檢查任務是否有未考慮的情況或是邏輯的謬誤。 >> -- 環境建置文件記錄建置步驟 >> * 環境建置文件記錄建置步驟為軟體開發完成後，提供使用者在不同環境下安裝及部署的操作說明，通常會一併配合版本控管的頁面，以markdown的形式記錄在文件中。 >> >> b. 細項說明 >> * 建置環境及編程 >> -- 前端網頁開發環境 >> -- 後端伺服器開發環境 >> -- PostgreSQL 儲存資料 >> -- SonarQube 檢測專案內容 >> >> * 測試 >> -- Unit test測試 >> -- 手動測試 >> -- 修復系統內Bug及SonarQube偵測到的Code smell >> >> 1.1.6 >> 根據本專案的開發模式，會在各個階段進行確認(Validation)及驗證(Verification)，生命週期定義為3個月 >> 1.2 >> 1.2.1 >> __同原版__ >> >> 1.2.2 >> __待畫圖 --> 甘特圖__ >> >> 1.2.3 >> 本專案之時程進度監控機制規劃以月會及週會的方式來進行。其中，月會討論內容會以幾花開始至當前開發階段的進度總覽以及各階段文件內容議題的討論為主，而會議時間定為一到兩小時。週會部分主要針對code review及團隊成員當前進度同步為主會議時間定為30分鐘到一小時 >> * 月會 >> 每月第一週週一下午一點 >> * 週會 >> 每週五早上九點半 >> >> 2.1 >> __同原版__ >> >> 2.2 >> __會在編輯成表格__ >> (1). 分析 >> 文件：PEP、SRS >> 參與人員： >> >> 元件：使用者需求 >> 參與人員： >> >> (2). 分析 >> 文件：SDD >> 參與人員： >> >> 元件：前端框架概念、後端框架概念、整合框架概念 >> 參與人員： >> >> (3). 實施 >> 文件：STD >> 參與人員： >> >> 元件：建置&編程、測試 >> 參與人員： >> >> 2.3 >> 視各個子項目開發複雜度進行調度及支援。 >> >> 2.4 >> __同原版__ >> >> 2.5 >> __待內訓課表設計__ >> >> 2.6 >> 視每週週會進度同步之情況，於當天下午一點另行會議進行修復調整