實驗九 FBG 團隊項目需求改進與系統設計

任務一

A、《項目需求規格說明書》分析

　　根據老師的指導以及本週所學的OOA，分析改進上週編寫的《項目需求規格說明書》，發現需求項目書UML圖例描述不夠完善，僅僅是用例圖沒辦法更好的表示出軟件設計，因此後期又加了其餘UML模型，具體狀況請見《軟件需求規格說明書》1.1版本（https://github.com/FBGfbg/xuqiu），在此以前特介紹一下OOA以下：

Object-Oriented Analysis——面向對象分析法

OOA的主要優勢

　　（1）增強了對問題域和系統責任的理解；

　　（2）改進與分析有關的各種人員之間的交流；

　　（3）對需求的變化具備較強的適應性；

　　（4）支持軟件複用；

　　（5）貫穿軟件生命週期全過程的一致性；

　　（6）實用性；

　　（7）有利於用戶參與。

OOA的主要原則。

　　（1）抽象：從許多事物中捨棄個別的、非本質的特徵，抽取共同的、本質性的特徵，就叫做抽象。抽象是造成概念的必須手段。

　　抽象原則有兩方面的意義：第一，儘管問題域中的事物是很複雜的，可是分析員並不須要瞭解和描述它們的一切，只須要分析研究其中與系統目標有關的事物及其本質性特徵。第二，經過捨棄個體事物在細節上的差別，抽取其共同特徵而獲得一批事物的抽象概念。

　　抽象是面向對象方法中使用最爲普遍的原則。抽象原則包括過程抽象和數據抽象兩個方面。

　　過程抽象是指，任何一個完成肯定功能的操做序列，其使用者均可以把它看做一個單一的實體，儘管實際上它多是由一系列更低級的操做完成的。

　　數據抽象是根據施加於數據之上的操做來定義數據類型，並限定數據的值只能由這些操做來修改和觀察。數據抽象是OOA的核心原則。它強調把數據（屬性）和操做（服務）結合爲一個不可分的系統單位（即對象），對象的外部只須要知道它作什麼，而沒必要知道它如何作。

　　（2）封裝就是把對象的屬性和服務結合爲一個不可分的系統單位，並儘量隱蔽對象的內部細節。

　　（3）繼承：特殊類的對象擁有的其通常類的所有屬性與服務，稱做特殊類對通常類的繼承。

　　在OOA中運用繼承原則，就是在每一個由通常類和特殊類造成的通常—特殊結構中，把通常類的對象實例和全部特殊類的對象實例都共同具備的屬性和服務，一次性地在通常類中進行顯式的定義。在特殊類中再也不重複地定義通常類中已定義的東西，可是在語義上，特殊類卻自動地、隱含地擁有它的通常類（以及全部更上層的通常類）中定義的所有屬性和服務。繼承原則的好處是：使系統模型比較簡練也比較清晰。

　　（4）分類：就是把具備相同屬性和服務的對象劃分爲一類，用類做爲這些對象的抽象描述。分類原則其實是抽象原則運用於對象描述時的一種表現形式。

　　（5）聚合：又稱組裝，其原則是：把一個複雜的事物當作若干比較簡單的事物的組裝體，從而簡化對復瑣事物的描述。

　　（6）關聯：是人類思考問題時常常運用的思想方法：經過一個事物聯想到另外的事物。能令人發生聯想的緣由是事物之間確實存在着某些聯繫。

　　（7）消息通訊：這一原則要求對象之間只能經過消息進行通訊，而不容許在對象以外直接地存取對象內部的屬性。經過消息進行通訊是因爲封裝原則而引發的。在OOA中要求用消息鏈接表示出對象之間的動態聯繫。

　　（8）粒度控制：通常來說，人在面對一個複雜的問題域時，不可能在同一時刻既能縱觀全局，又能洞察秋毫。所以須要控制本身的視野：考慮全局時，注意其大的組成部分，暫時不詳察每一部分的具體的細節；考慮某部分的細節時則暫時撇開其他的部分。這就是粒度控制原則。

　　（9）行爲分析：現實世界中事物的行爲是複雜的。由大量的事物所構成的問題域中各類行爲每每相互依賴、相互交織。

 狀態圖連接：https://www.processon.com/diagraming/5b0e072ae4b009aef58fa653

 

B、功能分析四象限

連接：https://www.processon.com/view/link/5b0e10e2e4b0e5f3aa6db8d7

 

C、團隊項目WBS

 

D、用戶故事

   我是一位媽媽，個人孩子今年在上小學五年級。我像往常同樣檢查孩子的做業。我跟孩子每次都須要花費好長時間才能勉強完成做業。我特別渴望解決咱們當下的問題。終於我遇到了它。小學生課後習題答案查詢app，是它拯救了我，也挽回了我作家長的威嚴。我先註冊登陸了。發現有好幾個查詢方式，我一一試了便。第一個查詢方式是拍照查詢，它的操做特別簡單方便，只需把所要查詢的題目拍下來搜索便可。第二個查詢方式是精準查詢，它的界面有四個選項構成的分別是孩子所讀年級的選擇，教材的選擇，章節的選擇，題目的選擇。經過它所得出的答案是特別精準的，沒有任何差錯的。第三個查詢方式是掃碼查詢，它的特別之處就是把所用教材背後的條形碼，放入掃碼區就會一會兒能夠查詢到整本書上全部的課後習題。這三種查詢方式中我大部分所用的是拍照查詢，選擇這個的主要緣由是隻需會拍照就行，對咱們這些文化水平較低的家長而言沒有什麼要求。自從用了這個app以後我省出了許多空閒時間，跟孩子的感情也更深了。維護家長的威嚴，加深與孩子之間感情的最好選擇就是它——小學生課後習題查詢app

E、團隊成員預估任務時間

設計階段	兩週
系統實現	兩週
APP運行與維護	一週

F、製做看板圖和燃盡圖

初始的看板圖和燃盡圖爲下：

在這個過程當中，咱們團隊對已經完成的任務和之後要完成的任務進行了大概的劃分，燃盡圖以下：

 

如下這一版是對整個項目作了細化之後完整的WBS作出來的成果：

 

 

其中看板圖標籤綠色表明家長的功能，紫色表明教師的功能，灰色表明管理員的功能

 

任務二

設計團隊項目系統整體結構和數據庫邏輯結構（E-R圖）。

系統E-R圖連接：https://www.processon.com/diagraming/5b0df204e4b037160973e070

任務三

軟件系統概要設計說明書連接：https://github.com/FBGfbg/xuqiu

任務四

團隊成員具體分工及比重：

團隊成員	任務	比重
馬玉婷	任務1.a 完善《需求規格說明書》 任務1.b 功能分析的四個象限 任務1.e製做任務時間表 任務1.f 建立看板圖和燃盡圖 任務3 撰寫團隊項目軟件系統設計說明書 任務4 編輯博客	35.41%
馬美玲	任務1.a 完善《需求規格說明書》 任務1.c 編制團隊項目的WBS 任務2 設計系統整體結構、製做E-R圖 任務3 撰寫團隊項目軟件系統設計說明書	35.41%
益西卓嘎	任務1.d 以講故事的方式介紹項目中的功能 任務1.g 在博文中編輯改進內容協助調研	29.18%

 兩個問題：

1、系統整體設計和需求分析的關係是什麼？

   需求分析的結果是系統設計的依據。

   需求分析也稱爲軟件需求分析、系統需求分析或需求分析工程等，是開發人員通過深刻細緻的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化爲完整的需求定義，從而肯定系統必須作什麼的過程。需求能夠是用戶提出，也能夠是經過需求分析師分析挖掘用戶數據、行爲等獲得，但歸根到底仍是提出「想要什麼」。
   系統設計是根據系統分析的結果，運用系統科學的思想和方法，設計出能最大限度知足所要求的目標 (或目的) 的新系統的過程。是根據需求對目標（能夠是軟件系統、也多是硬件設備等）進行建模，使之知足需求中的要求。
   需求分析關注系統「作什麼」，設計關注「如何作」，其實這是一個很模糊的說法。不管是在結構化方法中仍是在面向對象的方法中，需求分析的結果既包括了「作什麼」也部分包括了「如何作」，只不過描述「如何作」時抽象的層次比較高。客戶在提出系統需求時，可能對「如何作」提出一些約束條件，開發人員進行需求分析後，進行系統設計。系統設計這個階段的任務是設計軟件系統的模塊層次結構，設計數據庫的結構以及設計模塊的控制流程，其目的是明確軟件系統"如何作"。這個階段又分兩個步驟：概要設計和詳細設計。根據系統需求分析階段所肯定的新系統的邏輯模型、功能要求，在用戶提供的環境條件下，設計出一個能在計算機網絡環境上實施的方案，即創建新系統的物理模型。所以，需求分析的結果是系統設計的依據。

 

2、如何設計系統的整體結構？  

   系統整體設計即對全局問題的設計，也就是設計系統總的處理方案，又稱概要設計。
   製造系統工程整體設計包括：市場調研，技術規格書編寫，初步設計，詳細設計，產品製造等。
   軟件工程整體設計包括：計算機配置設計、系統模塊結構設計、數據庫和文件設計、代碼設計以及系統可靠性與內部控制設計等內容。軟件功能分解屬於下列軟件開發中的整體設計階段，系統設計階段的結果是系統設計說明書，它主要由模塊結構圖、模塊說明書和其它詳細設計的內容組成。 

一、系統設計的主要任務是進行整體設計和詳細設計。

（1）整體設計 

總  體設計包括系統模塊結構設計和計算機物理系統的配置方案設計。 

<1>系統模塊結構設計 。系統模塊結構設計的任務是劃分子系統，而後肯定子系統的模塊結構，並畫出模塊結構圖。

<2>計算機物理系統配置方案設計 。在進行整體設計時，還要進行計算機物理系統具體配置方案的設計，要解決計算機軟硬件系統的配置、通訊網絡系統的配置、機房設備的配置等問題。計算機物理系統具體配置方案要通過用戶單位和領導部門的贊成纔可進行實施。 

（2）詳細設計 

   在整體設計基礎上，第二步進行的是詳細設計，主要有處理過程設計以肯定每一個模塊內部的詳細執行過程，包括局部數據組織、控制流、每一步的具體加工要求等，通常來講，處理過程模塊詳細設計的難度已不太大，關鍵是用一種合適的方式來描述每一個模塊的執行過程，經常使用的有流程圖、問題分析圖、IPO圖和過程設計語言等；除了處理過程設計，還有代碼設計、界面設計、數據庫設計、輸入輸出設計等。 

二、系統設計原則  

（1）簡單性：在達到預約的目標、具有所須要的功能前提下，系統應儘可能簡單，這樣可減小處理費用，提升系統效益，便於實現和管理

（2）靈活性和適應性：以便適應外界的環境變化。可變性是現代化企業的特色之一，是指其對外界環境的變化的適應能力。系統的可變性是指容許系統被修改和維護的難易程度。一個可變性好的系統，各個部分獨立性強，容易進行變更，從而可提升系統的性能，不斷知足對系統目標的變化要求。此外，若是一個信息系統的可變性強能夠適應其它相似企業組織的須要，無疑地，這將比重新開發一個新系統成本要低得多。 

（3）一致性和完整性：一致性是指系統中信息編碼、採集、信息通訊要具有一致性設計規範應標準；完整性是指系統做爲一個統一的總體而存在，系統功能應儘可能完整。  

（4）可靠性：系統的可靠性指系統硬件和軟件在運行過程當中抵抗異常狀況的干擾及保證系統正常工做的能力。衡量系統可靠性的指標是平均故障間隔時間和平均維護時間。前者指平均的先後兩次發生故障的時間，反映了系統安全運行時間，後者指故障後平均每次所用的修復時間，反映系統可維護性的好壞。只有可靠的系統，才能保證系統的質量並獲得用戶的信任，不然就是沒有使用價值。     

   提升系統可靠性的途徑主要有： 

     1）取可靠性較高的主機和外部設備； 

     2）硬件結構的冗餘設計，即在高可靠性的應用場合，應採起雙機或雙工的結構方案； 

     3）對故障的檢測處理和系統安全方面的措施，如對輸入數據進行校檢，創建運行記錄和監督跟蹤，規定用戶的文件使用級別，對重要文件的拷貝等。

（5）經濟性：系統的經濟性是指系統的收益應大於系統支出的總費用。系統支出費用包括系統開發所需投資的費用與系統運行維護費用之和；系統收益除有貨幣指標外，還有非貨幣指標。  系統應該給用戶帶來相應的經濟效益。系統的投資和經營費用應當獲得補償。須要指出的是，這種補償有時是間接的或不能定量計算的。特別是對於管理信息系統，它的效益當中，有很大一部分效益不能以貨幣來衡量。  

三、系統設計的目的      

   系統設計的目的是在保證明現邏輯模型功能的基礎上，儘量提升目標系統的簡單性、可變性、一致性、完整性、可靠性、經濟性、系統的運行效率和安全性，將分析階段所得到的系統邏輯模型，轉換成一個具體的計算機實現方案的物理模型，包括計算機物理系統配置方案報告和一份系統設計說明書。

3、實驗心得

   通過了一段時間的磨合，咱們團隊的凝聚力有了很大的提高，你們從剛開始的不明白本身的定位到如今可以迅速分工找到合適本身的任務並保質保量的完成，咱們真的成長了不少，也在這個過程當中進一步的明白了團隊凝聚力和小組合做的優點，雖然跌跌撞撞，但咱們在茁長成長。

   除了團隊的成長以外，通過幾回有目的有方向的實驗任務，咱們隊對軟件工程這門課的認識又加深了許多，同時也對學好這門有了更大的信心，相信通過系統的學習，咱們團隊會更加出色。