解決問題
為了解決上面存在的問題，將原來線下的業務線上化，并在計劃過程中引入流程審批，管理計劃的過程就變為平時的OA辦公流程化處理。這樣既保留了現有的計劃業務情況，又提高了部門各級的計劃審批效率。同時針對所有的計劃執行結果，系統自動統計分析，為各個部門領導對員工的計劃執行情況了如指掌，方便對項目的各個環節進行把控，在適當的條件下，進行合適的干預，保證項目計劃的保質保量完成。
略
性能需求以甲方要求的性能需求為準。
安全需求以甲方要求的安全需求為準。核心可以采用https加密等技術來保證數據傳輸的安全。
下表展示的是主要使用角色的需求描述。
角色 | 需求描述 |
領導 | 主要查看各個部門的計劃進度情況，在必要的時候在手機端進行計劃流程的審核。 |
部門經理 | 完成部門計劃的制定，審核部門下普通員工的計劃完成情況 |
普通員工 | 完成計劃的細化工作，對時間線上的計劃作出狀態變更，提交相關的附件，提交給上級領導審核。 |
系統管理員 | 針對不同的項目分類情況，制定不同的快速計劃模板；維護企業組織架構，人員管理，角色分配，管控人員數據權限；制定計劃中的各個審批流程。 |
這里將采用用例圖的方式，簡要描繪不同角色的功能需求情況。
一般用戶的需求用例如上圖。主要圍繞計劃目標的制定，執行過程中的依據的提供，最后計劃的完成情況（結果）來展開。對于普通用戶而言，使用起來沒有什么復雜的過程，只需要按照相關的要求錄入相關的數據，更改相關的狀態即可。
對于管理員來說，需要涉及的功能點就比較多了，首先需要做相關的組織機構的配置，人員的賬戶分配，角色分配，權限的指定，以及設置計劃的模板，配置在計劃管理過程中需要用到的審核流程
技術框架宜采用B/S結構，通信采取https通信，保證通訊信息的穩定，安全。
技術架構能夠良好的適應二次開發擴展（后續集成多系統），以及具備良好的代碼結構。
好的軟件系統，離不開內部的設計原則，本軟件是設計將遵循以下原則進行設計：
依賴倒置原則：考慮到軟件是應對業務產生的具體的需求，高層的模塊不應該依賴底層模塊，二者都依賴于抽象。抽象不應該依賴于實現細節，細節實現應該依賴于抽象。在設計中，高層的模塊應該是穩定的，底層模塊是變化的，抽象的業務結構是穩定的，他們之間的相互依賴需要依照依賴倒置的原則進行設計。
開放封閉原則：在設計的過程中，我們對擴展的堅持開放，對更改的堅持封閉。即是類模塊應該是可以擴展的，對于函數以及方法應該是可以修改的。
接口隔離原則：在類和類之間的相互應該的接口應該盡量小。這種設計可以提高內聚和降低模塊之間的耦合。在一個模塊變動的情況下，相關模塊依賴的接口越少，涉及到的牽連變動也就越少。例如
單一職責原則：設計過程中，我們遵循單一的類實現單一的職責。即是各個類模塊中，各種實現的功能是單一的，不過多的交互。這樣可以降低類的復雜度，一個類只負責一項職責，其邏輯比負責多項職責的類要簡單得多，在編碼過程中也不易出錯，提高類的可讀性，提高系統的可維護性。比如遇到變更，我們只需要考慮變更某一項職責的功能編碼，而不會對其他類造成大的影響。
這里將用邏輯結構圖的形式，展現系統總體的邏輯架構設計。
這里用網絡拓撲結構圖來展示硬件方面的架構設計
推薦服務器配置：
云服務器：ECS
內存：8G
CPU：4核多線程
數量：1-3臺（前期可以將數據庫，緩存，應用配置在一臺服務器）
建議采用云模式，推薦應用服務器網絡帶寬最低4M
存儲空間最低要求60G系統盤，100G數據盤。后續附件增大的情況下，會按實際的需求增加系統盤
操作系統：windows server 2012 64位數據中心版
數據庫：sqlserver 2012 企業版
Web服務器：IIS 8.0以上版本
緩存：redis緩存
這里羅列系統所有涉及到的核心功能模塊，將對每個核心功能模塊進行詳細設計描述。
我們圍繞計劃管理，展示系統整體需要達到的目標
下面，就一些核心模塊進行說明
登錄認證模塊 | |
描述 | 用戶使用系統，必須先登錄進行認證，只有具備認證的用戶才具備系統的合法操作權限。 |
流程 | |
組織架構模塊 | |
描述 | 組織架構是系統的發展業務的基礎，系統組織架構包括對公司信息的維護，公司下部門信息的維護，崗位信息的維護，角色的維護，角色的權限的配置，以及對用戶賬戶的基本維護。一般在系統初始化的時候由管理員錄入相關的基礎數據。
|
流程 | |
系統日志模塊 | |
描述 | 系統在運行過程中，需要對重要的操作做必要的日志記錄，以便后續查詢，對于運行中的異常情況，也會進行捕捉，記錄到日志中，方便開發者定位問題，提升系統穩定性 系統日志模塊提供：
|
流程 | |
流程配置模塊 | |
描述 | 計劃的執行管理，需要流程作為支撐，計劃節點中，審核流程做為任務完成的依據具有積極的作用。 流程的配置是將常用的審核機制模板話，在計劃執行的過程中，用戶只需要提交結果進行審批即可。 主要功能描述：
|
流程 | |
計劃模板模塊 | |
描述 | 在房地產開發計劃的過程中，大部分的項目時間線是固定的，為了方便快捷的制定計劃方案，可以先將固定的計劃用計劃模板進行保存，保存完成后，在具體制定計劃的時候可以套用模板，用戶基本只需要完善一下細節，調整一下時間就可以快速生成一個項目的計劃了。 |
流程 | |
計劃的編制和計劃模板的創建流程類似，這里不重復描繪
計劃執行模塊 | |
描述 | 在計劃執行后需要配合審批模塊將計劃的完成情況，告知相關的審批人員，打通信息的不對稱。 |
流程 | |
系統的設計應該考慮到網絡安全，具備防止被攻擊的功能。
一般在web安全中，我們需要做到防止黑客入侵系統。就阿里云服務器的安全性而言，黑客從一般手段（非用戶程序）中基本不可能入侵到服務器中。在服務器方面，我們將及時的更新安全補丁，防止因為操作系統的漏洞讓黑客入侵。另外安裝相關的服務器安全組件，比如阿里云的云盾產品等也可以極大的提高服務器的安全性能。
但就從程序上，我們也是需要設計防范以下安全的攻擊情況。
描述 | 防御手段 | |
XSS攻擊 | xss攻擊是跨站腳本攻擊，例如在表單中提交含有可執行的javascript的內容文本，如果服務器端沒有過濾或轉義這些腳本，而這些腳本由通過內容的形式發布到了頁面上，這個時候如果有其他用戶訪問這個網頁，那么瀏覽器就會執行這些腳本，從而被攻擊，從而獲取用戶的cookie等信息。 | 1、對于敏感的cookie信息，使用HttpOnly，使document對象中找不到cookie。 2、對于用戶輸入的信息要進行轉義。
|
CSRF攻擊 | CSRF攻擊即跨站域請求偽造，例如，小明在瀏覽銀行A網站的時候并沒有關掉銀行網站，這時小明又訪問了攜帶CSRF攻擊的B網站，而這時候B網站通過對銀行的服務器發送轉賬請求，并且攜帶小明的在銀行網站的cookie信息，在參數上把小明賬號上的錢轉到B網站所有人的賬戶上，這時url得到響應，小明的錢就丟了。 |
4、在HTTP頭中自定義屬性token 并驗證。把token作為自定義屬性放在HTTP的頭中，通過封裝XMLHttpRequest可以一次性給所有請求加上token 屬性。這樣子token就不會暴露在瀏覽器地址中。 |
SQL注入 | SQL注入攻擊，攻擊者在提交表單的時候，在表單上面填寫相關的sql語句，而系統把這些字段當成普通的變量發送給服務器端進行sql查詢，則，由攻擊者填寫的sql會拼接在系統的sql語句上，從而進行數據庫的某些操作。 | 系統設計采用EF數據結構框架，可以從根本上杜絕sql注入 |
身份認證和會話攻擊 | 黑客在瀏覽器中停用JS，防止客戶端校驗，從而進行某些操作。 | 1、隱藏敏感信息。 2、對敏感信息進行加密。 3、session 定期失效
|
權限與訪問控制 | 能通過URL參數的修改達到訪問他人頁面 | 添加權限系統，訪問的時候可以加上相應的校驗。 |
不安全加密存儲 | 敏感信息沒有加密存儲，導致黑客獲取到敏感信息明文 | 1、加密存儲敏感信息 2、不用md5加密
|
上傳漏洞 | 在圖片上傳的時候，攻擊者上傳非圖片，而是可遠程執行的的腳本，這時候，入侵者就可以遠程的執行腳本來對服務器進行攻擊 | 1、限制文件上傳類型 2、使用第三方文件托管等
|
傳輸層未加密 |
| 1、使用安全的https版本 2、敏感信息使用https傳輸 3、非敏感信息使用http傳輸
|
WebShell | 黑客在win系統中向被攻擊網站上傳 abc.asp;.jsp文件，這時候系統識別為jsp文件，然后傳送到服務器的時候，某些系統上面會識別為 asp 文件。 | 限制文件上傳類型
|
功能清單思維導圖
