第六章 軟體需求
※需求型態：
A.使用者需求：用很自然語+圖形描述系統有哪些服務及操作限制條件。(寫給顧客看的)
B.系統需求：結構化文件設定輸出，更詳細的描述系統功能、服務及操作限制條件。
※功能性需求與非功能性需求：
1.功能性需求：描述系統應該提供的服務，系統對特定輸入的反應及系統在特定情況下的行為等敘述。
2.非功能性需求：描述系統提供的功能或是服務的限制，例如時間限制、開發程序上的限制和標準等。非功能需求分為：1.產品需求 2.組織需求 3.外部需求
3.領域需求：來自系統應用領域的需求，該領域所反映的特性和限制。
※完整性：代表使用者要求的服務都應該要定義。
※一致性：需求之間不能有相互矛盾的定義。若使用自然語言來撰寫需求，可能會產生下列問題：
1.不夠清楚 2.需求混淆 3.需求合併
※需求撰寫原則：
1.語言的使用要一致(強制需求通常使用(必須) (shall)，期望需求則使用(應該)(should))
2..利用字型功能來強調重要部分 3.避免使用電腦術語
※SRS：詳盡內容必考，請自行參考作業、講義及課本喔!!
第七章 需求工程程序
※可行性分析
1.可行性研究在決定短期且有核心的系統，是否值得開發。
2.短期專心的研究檢查
a.此系統對整體組織目標是否有貢獻。
b.此系統是否可用現有的技術，在規定的成本及時間限制條件下開發出來。
c.此系統是否可與其他現有系統做整合。
※需求擷取與分析(需求擷取 or 需求發掘)
可行性分析後，需求工程程序下一階段為需求擷取與分析。此階段軟體工程師會與終端使用者一起工作找出系統的應用領域，該提供的服務與系統操作上限制的條件等。
此階段的程序活動：
1.發現需求：與系統的專案關係人進行互動，蒐集他們的需求。
2.需求分類與組織：將此活動的需求依照相關性分類，組織成幾組關係密切的群集。
3.排列需求的優先順序與協調：將需求安排優先順序，發現衝突時經由協調來解決衝突。
4.製作需求文件：將需求記錄成文件，當作螺旋狀下一圈的輸入(文件可能是正規化或是非正規化的需求文件)。
※發現需求的方法如下：
※觀點法
1.觀點法是種結構化的方法，需求因不同的專案關係人而有抽象的觀點並且做相關分類。
2.多維度的分析是重要的，並沒有單一正確方法，分析系統需求。
※觀點法的型態
1.互動觀點：與系統直接互動的人或其他系統的觀點。
適用：提供涵蓋系統功能與介面的詳細系統需求。
(ex:在銀行的ATM系統中，銀行客戶與銀行的帳戶資料庫就是互動者觀點。)
2.間接觀點：自己沒直接使用系統，但會對需求有影響的關係人的觀點。
適用：提供高階的組織需求和限制。
(ex:在銀行的ATM系統中，銀行的管理階層和保全人員就算是間接觀點。)
3.領域觀點：會影響系統需求的領域特性和限制。
適用：提供適用在系統上的領域限制。
(ex:在銀行的ATM系統中，銀行跨行之間的標準就是一種領域觀點。)
※訪談法
1.正式訪談與非正式訪談，需求工程小組會訪問專案關係人一些問題，關於他們現在所使用的系統與即將開發的系統。
2.兩種訪談法的型態：
a.封閉式訪談：有些事已先定義好問題的答案(ex:選擇題)。
b.開放式訪談：沒事先定義好問題和議程，需求工程小組會和專案關係人一起討論某些議題，因而更瞭解專案關係人的需求(ex:問答題)。
※訪談法實行&適用
1.混合封閉式與開放式。
2.想瞭解專案關係人的工作及如何與系統互動和目前系統上遇到的困難，訪談是不錯的方式。
3.訪談法不適合用來瞭解領域需求。
※訪談法的優、缺點
缺點：1.要取得有關組織的需求和限制的知識，訪談法並不很有效率。
2.訪談法本身容易遺漏重要資訊，因此該與其他擷取技術搭配使用。
※使用個案(算情境法的一種表示方式)
1.使用UML表示法來描述物件導向式系統模型的基本功能。
※情境與使用個案
情境和使用個案都是有效率的需求擷取技術，也可搭配某些間接的觀點來使用。但由於它們是針對互動過程，因此在擷取高階的企業需求和非功能需求方面並不那麼有效率。
※情境法
1.情境法透過日常生活的例子知道如何做出系統。
2.應包含：a.一開始系統和使用者預期的情況描述。
b.一個事情正常流程的描述。
c.可能發生的問題及解決方法的描述。
d.同時間可能發生的其他活動的相關資訊。
e.情境完成時的系統狀態描述。
※民族誌法
1.是一種觀察的技術，可以用來瞭解社會與組織的需求，分析人員必須將自己融入在使用系統的工作環境中，觀察與記錄日常的實際工作。
2.人們很難好好解釋或表達他們的工作。
3.觀察社會和組織因素的重要方法。
4.民族誌法能夠找出隱含的系統需求，實際反映員工的使用程序，而不是一般正規的程序。
※民族誌法對兩種需求特別有效
1.從實際的工作方式衍生的需求。
2.從合作及瞭解其他人員活動所衍生的需求。
3.民族誌法可和雛形法合併使用，民族誌法會通知雛形的開發程序，使雛形的循環動作減少。另外，雛形法可以只著重在由民族誌法找出來的問題，這些問題稍後再討論，然後在系統研究的下一個階段找出這些問題的解答。
4.使用民族誌法不適合用來尋找組織或應用領域的需求。必須和其他方法搭配使用。
(ex:使用個案分析法)。
※需求確認：主要是想確認需求是否真正定義出顧客想要的系統。
需求確認階段裡，必須執行下列幾項檢查：
1.確實性檢查：系統提供的功能，哪個最支援顧客的需求。
2.一致性檢查：在文件中需求不能衝突。
3.完整性檢查：需求文件中定義的需求必須包含系統使用者想要的所有功能和限制。
4.實現性：檢查需求是否能真正被實作出來，這些檢查應將系統開發的預算和時程考慮進去。
5.可驗證性：系統需求是要可驗證的方式撰寫。
※Review checks
1.可驗證性：需求的敘述方式是否能夠實際而能進行測試。
2.可理解性：系統的採購人員或終端使用者是否能適當理解需求。
3.可追蹤性：需求的原始提出者是否有清楚的記錄。有時為了評估某項變更的影響，也必須回頭訪談需求的原始提出者。
4.可調適性：需求是否可調整改變。在變更此需求時，能否不要大規模影響其他的系統需求。
※需求的可追蹤性：可能需要維護的可追蹤性資訊分為：
1.來源的可追蹤性：這類資訊會連結需求與提出需求的專案關係人，及提出這些需求的根本原因，當有變更被提出時，便可利用這項資訊找出專案關係人，詢問他們對此變更的看法。
2.需求的可追蹤性：這類資訊會連結在需求文件中相互依存的需求，這項資訊可用來評估，這項變更可能會影響到多少個需求，還有後續的需求變更範圍。
3.設計的可追蹤性：這類資訊會連結需求與實作這些需求的設計模組，這項資訊可用來評估提出的這項需求變更，對於系統設計和實作上的影響。
第十一章 架構設計
※軟體架構：最初的設計程序在確認系統由哪些子系統組成，及建立子系統控制和通訊架構的初始設計程序，
稱為架構設計：
1.系統程序設計的第一階段。 2.設計和需求工程程序之間做連結。
3.為系統建立一個基本的結構化架構。 4.辨識系統主要元件及元件之間的溝通方式。
※明確的設計與記錄軟體架構三個優點
1.與專案關係人的溝通：架構是系統較高階的表示方式，適合不同領域的關係人討論的焦點。
2.系統分析：分析是否能符合某些關鍵需求。
3.大量的再利用：相似需求的系統架構會常類似，可大量再利用已完成的軟體，也可開發類似生產線的架構，讓相同架構可使用在多個相關系統上。
※架構與系統特色
1.效能：將重要的操作侷限在少數子系統中，並盡量將溝通限制在這些子系統之間，意味著須使用範圍較大的元件，不將功能細分太細的程度，減少元件之間的溝通。
2.保全性：建議使用分層式結構，將最重要的元件保護在最內層，並以外層的確認功能保護這些層級。
3.安全性：重要的資料放在少數的子系統中。
4.可用性：要有很多重複元件及容錯的能力。
5.可維護性：使用功能較細微且獨立的元件，以便隨時替換，避免共用資料結構。
※架構模型種類
1.靜態結構化模型：將要開發的各子系統或組成元件以不同的單元來表示。
2.動態程序模型：顯示系統如何組織成執行時的程序，它看起來可能和靜態模型完全不同。
3.介面模型：定義每個子系統透過它們的公共介面所提供的服務。
4.關係模型：顯示各子系統之間的關係，如資料流。
5.分佈模型：顯示子系統如何分佈在各電腦之間。
※系統組織：系統組織是反映出用來建立系統結構的基本策略。
三種廣泛被使用的組織模型：
1.共用資料庫模型 2.共用服務與伺服器模型(主從式模型) 3.層級式或抽像機器模型。
※共用資料庫模型(儲存庫模型)及優、缺點：
1.組成系統的子系統之間，必須交換訊息才能有用的一起運作，交換訊息有兩種基本方式。
a.將所有共用資料保存在一個集中式資料庫，讓所有子系統都可以存取。以共用資料庫為基礎的系統模型有時稱為「儲存庫模型」。
b.每個子系統維護自己的資料庫，需要交換資料時則透過訊息傳遞。
2.大多數會使用大量資料的系統，建議用資料儲存庫。
優點：1.分享大量資料很有效的方法。
2.產生資料的子系統不需顧慮其他子系統如何使用這些資料。
3.子系統不需要考慮資料如何集中化的管理。如備份、保全、存取控制及回復等活動。
4.共用模型透過儲存綱要就可看得出來。只要工具與大家同意的資料模型相容即可。
缺點：1.每個子系統要同意用資料儲存庫，所以妥協是不可避免的。
2.資料演進是困難且成本高的。
3.儲存庫模型會強迫所有子系統使用相同的原則。
4.分佈效率是困難的。
適合在：資料是由某一個子系統產生再由其他子系統使用的應用程式。
(ex:命令與控制、MIS、CAD、CASE工具組等系統都是。)
※主從式模型（client-server
modle）優、缺點
優點：1.資料分佈是明確的。
2.做有效的網路系統使用。 3.容易加入一個新伺服器，或更新現有的伺服器。
缺點：1.沒有共用資料儲存庫模型，子系統會有不同的方法組織它們的資料，變得沒效率。
2.每個伺服器會有重覆管理的動作。
3.沒有集中式的名稱和服務，很難從外面有效的找到伺服器與服務是可用的。
※層級式模型(抽象機器模型)：子系統的介面，將系統分解許多層，讓每層提供一組服務。
優點：
1.此種架構較容易進行變更和移植。
2.若層級的介面改變，也只會影響鄰近的分層。
3.由於層級式系統可將機器之間的相依性侷限在內層，因此較容易為應用程式提供多種平台。
4.如果需要不同的作業系統或資料庫，也只有與機器相關的內層需重新開發。
缺點：此種方式建構系統較困難，內層負責提供基本功能。
適用在：支援增量式的系統開發方法。
(ex:檔案管理功能，這是每層都會用到的，使用者所需的服務必須經過好幾層的存取才能得到處理，因此系統的外層不只是依賴它的下一層而已，這與此模型的原意不符。)
※模組分解方法：子系統如何分解為更細的模組。系統架構分解和模組分解很難分開描述。
不過模組的組成元件通常比子系統還小。
※子系統與模組
1.子系統本身就是一個系統，不需依賴其他子系統提供服務。
2.模組通常式系統的一個元件也不會是個獨立的系統，提供一或多個服務給其他模組或使用其他模組提供的服務。
※模組分解模型：子系統如何分解為更細的模組。建議避免過早承諾系統要並行執行。最好先將系統分解成模組，實作時再決定要採循序還並行來執行。
※物件導向分解法：將系統分解成一組相互溝通的物件。
優點：1.物件導向是鬆散耦合的方式，所以物件的實作可在不影響其他物件的情況下做修改。
2.物件可用來表示真實世界的實體，所以系統架構容易理解。
3.物件導向程式語言是被廣泛使用的。
缺點：1.使用其他物件提供的服務時，物件須明確參考該物件的名稱和介面。
2.太過複雜的實體通常難用物件來表示。
※功能導向(管線&篩選模型)分解法：將系統分解成數個功能模組，這些模組可接受輸入的資料，並以某方式轉換成輸出資料。
1.透過功能轉換，可處理輸入值和產生輸出結果。
2.轉化這方法是常見的。當轉換動作是以批次方式循序處理資料時，這種架構模型稱為「批次循序模型」。
優點：1.支援轉換動作的重複使用。
2.較直覺，許多人認為它們的工作是輸入和輸出的處理動作。
3.因系統演進而要加入新的轉換動作很簡單。
4.要實作成並行或循序系統都很簡單。
不適用在互動式的系統。
※控制模型：主要表達子系統之間控制訊息的流動方式。
在軟體系統中使用的一般控制方式有兩種：1.集中式控制 2.事件驅動式控制
※集中式控制：由其中一個子系統來負責控制、啟動和停止其它子系統。它也可以將控制權轉移給另一個子系統，但後來控制權還是會回到它這邊。
優點：可容易分析出控制流程，瞭解系統回應某些特定輸入的方式。
缺點：正常運算動作以外的例外情況會很難處理。
適用在：軟體及時系統。此種系統的時間限制不會很緊湊。
※集中式控制分為
1.呼叫 / 返回模型（call-return modle）：由上而下的副程式模式，從副程式的最上層開始控制，經過一連串呼叫後傳給下層。只適用於循序系統。
2.管理者模型（manager modle）：可應用在並行系統。將系統中某元件指定為系統管理者，來控制其他系統程序的開始與停止，以及協調。
※事件驅動式控制模型：是由外部產生的事件所驅動，事件的時間點無法由處理該事件的程序所控制。又分為：
1.廣播模型：向所有子系統廣播，任何在程式中設計會處理該事件的子系統都可以回應它。
優點：系統演進比較簡單。若有專門處理某類事件的新子系統要整合到整體系統中，只要向事件處理程式登記它要負責處理的事件即可。子系統不需知道其他子系統的名稱或所在位置，就可啟動它們。各子系統可實作在分散的機器上，而子系統不需瞭解系統是如何分散的。
缺點：子系統不知事件是否或何時會被處理。
適用在：分散在網路上不同電腦的整合子系統。
2.中斷處理式模型：專門用在即時系統上，由插斷處理程式來偵測系統外部的插斷，然後再傳給其他元件處理。
優點：1.非常快速的回應事件。 缺點：1.程式設計非常複雜。
2.插隨身碟會跳出視窗。 2.難以驗證。
適用在：有時間迫切需求的即時系統。
※參考架構：稱為「特定領域架構」，又分兩類：
1.通用模型：真實系統的抽象描述，只包含這些系統的主要特性。通常是由下而上的模型。
2.參考模型：更抽象，且描述更廣泛的系統種類。由上而下的模型。通常是從研究應用領域而產生的，而非從現有系統來的。
第二十二章 驗證&確認
※驗證 VS 確認：確認與確認程序的最終目的，是要建立軟體系統「有符合目的」的自信，但並不表示程式必須完全沒有錯誤，而是表示系統必須好到足以符合需求的用途。
1.確認(Validation)：我們是否開發了對的產品?(流程的最尾端做確認)
2.驗證(Verification)：我們開發的產品是否正確?(流程從頭到尾的驗證)
※驗證與確認程序：V&V的活動在軟體程序的每個階段都進行。
(需求審查→設計審查→程式碼檢查→產品測試。)
兩個主要目標的：1.找出系統的缺失 2.評估系統是否可用或有用
※驗證與確認信賴度：系統的信賴度是根據使用者期望、行銷環境。
1.軟體功能：所需的信心程度根據軟體對組織的重要性而定。
2.使用者期望：使用者期待依不同軟體而信賴度也有高低不同。
3.行銷環境：提早將產品上市是比尋找程式中的錯誤還來得更重要。
※測試的型態
1.確認測試：證明此軟體是客戶想要的且符合客戶的需求。
2.缺失測試：找出系統的缺失，並且找出程式和規格間不一致的地方。
※系統檢查與分析的技術：在V&V程序中，將用到兩個互補的系統檢查與分析的技術。
1.軟體檢查：分析及檢查系統的成果表達。(ex:需求文件、設計圖、程式碼等) 屬於靜態的V&V驗證(靜態驗證)，不需實際執行電腦上的軟體。
2.軟體測試：實際執行軟體且觀察軟體的執行結果。(ex:系統的測試資料和它操作行為的觀察) 屬於動態V&V測試，需實際執行軟體，才能檢視執行結果。
※測試和除錯
1.缺失測試和除錯是不同的程序。
2.還有驗證和確認是要證明軟體系統中有缺失存在。
3.而除錯則是找出缺失在哪並加以修正的程序。
※驗證與確認規劃
1.一開始就要清楚的規劃在可控制的成本下，做到檢查和測試。
2.應在開發程序的早期就開始。
3.驗證與確認的規劃程序應在之間取得平衡，進行驗證與確認的靜態與動態方法。
4.測試規劃與建立測試程序的標準有關，而不是著重描述產品如和測試。
※檢查勝過測試的優點
1.在測試期間，一次檢查裡可找出系統中的多個缺失。
2.尚未完成的系統也可進行檢查，且不必增加成本。
3.檢查除了找出程式缺失外，還可檢查程式是否符合標準，它的可移植性及易維護性。
沒有留言:
張貼留言