系統分析與設計/引言

資訊系統分析與設計-開發生命週期

企業和組織使用各種型別的資訊系統來支援其業務職能所需的許多流程。這些資訊系統中的每一個都有特定的目的或重點，每一個都有自己的生命週期。這個“生命週期”的概念被稱為系統開發生命週期或SDLC，它包括計劃、構建、部署、使用、更新和維護資訊系統的整個過程。新資訊系統的開發涉及幾個不同但相關的活動。這些活動或階段通常包括規劃、分析、設計、實施和維護/支援。換句話說，SDLC 是一個概念模型，它指導資訊系統開發中的專案管理。

根據作者 Harold Kerzner 博士的說法，有十六個要點將導致專案管理成熟度

1. 採用專案管理方法並始終如一地使用它。
2. 實施一種推動組織走向專案管理成熟度的理念，並將其傳達給每個人。
3. 承諾在每個專案開始時制定有效的計劃。
4. 透過承諾現實的目標來儘量減少範圍變更。
5. 認識到成本和進度管理是不可分割的。
6. 選擇合適的人擔任專案經理。
7. 為高管提供專案贊助商資訊，而不是專案管理資訊。
8. 加強所有適當管理層的參與和支援。
9. 關注可交付成果，而不是資源。
10. 培養有效的溝通、合作和信任。
11. 分享專案成功的認可。
12. 消除無效率的會議。
13. 專注於盡早、快速、經濟有效地識別和解決問題。
14. 定期衡量進度。
15. 使用專案管理軟體作為工具；不要將其作為有效規劃或人際交往能力的替代品。
16. 建立所有員工培訓計劃，並根據記錄的經驗教訓定期更新。

系統開發生命週期中的資訊安全

正如 NIST（國家標準與技術研究院）指出的那樣，在 SDLC 的早期包含安全通常會導致比將其新增到執行系統中成本更低且更有效的安全。在確定系統所需的安全性控制時，應解決以下問題

• 系統在實現組織使命中的重要程度如何？
• 系統所需的安全性目標是什麼，例如機密性、完整性和可用性 (CIA)？
  • 機密性是指將資訊訪問限制為僅授權使用者——“合適的人”——並防止未經授權的人員——“不合適的人”——訪問。
  • 完整性是指資訊資源的可信度。它包括“資料完整性”的概念——即資料沒有被不適當地更改，無論是意外還是故意惡意活動。它還包括“來源”或“來源完整性”——即資料確實來自您認為的那個人或實體，而不是冒名頂替者。
  • 可用性是指資訊資源的可用性。當您需要它時不可用的資訊系統幾乎與沒有資訊系統一樣糟糕。
• 哪些法規和政策適用於確定要保護的內容？
• 系統將在其執行的環境中適用的威脅有哪些？

將安全納入 SDLC（NIST 特別出版物 800-64 修訂版 2））

本節介紹了一些安全性注意事項，這些注意事項將有助於將資訊安全整合到 SDLC 的每個階段。

規劃

在開發生命週期的第一階段，安全性考慮對於儘早整合至關重要，從而確保考慮威脅、要求和功能和整合方面的潛在約束。在這一點上，安全性更多地從業務風險的角度來看待，並得到資訊安全辦公室的意見。例如，一個機構可能會發現由於重要網站在關鍵業務期間被修改或變得不可用而導致的政治風險，從而導致公民信任度下降。該階段的關鍵安全活動包括

• 從機密性、完整性和可用性的角度對業務要求進行初步界定；
• 確定資訊分類並識別已知的特殊處理要求，以傳輸、儲存或建立資訊，例如個人身份資訊；以及
• 確定任何隱私要求。

分析

本節探討了 SDLC 第二階段特有的安全性考慮因素。該階段的關鍵安全活動包括

• 進行風險評估並使用結果補充基線安全性控制；
• 分析安全性要求；
• 執行功能和安全性測試；
• 準備系統認證和授權的初始文件；

雖然本節以自上而下的順序介紹了資訊安全元件，但完成順序不一定固定。複雜系統的安全性分析需要迭代，直到實現一致性和完整性。

設計

在 SDLC 的此階段，設計安全性架構。

實施

在此階段，系統將在組織的操作環境中安裝和評估。該階段的關鍵安全活動包括

• 將資訊系統整合到其環境中；
• 計劃和執行系統認證活動，與安全性控制測試同步；以及
• 完成系統授權活動。

維護/支援

在此階段，系統已到位並執行，對系統的增強和/或修改已開發和測試，以及硬體和/或軟體已新增或更換。根據安全性要求監控系統以確保其持續效能，並將必要的系統修改納入其中。定期評估執行系統，以確定如何使系統更有效、更安全和更高效。操作持續進行，只要系統能夠有效地適應以響應組織的需求，同時保持商定的風險水平。當發現必要的修改或更改時，系統可能會重新進入 SDLC 的先前階段。該階段的關鍵安全活動包括

• 進行執行就緒審查；
• 管理系統的配置；
• 建立流程和程式以確保操作和持續監控資訊系統的安全性控制；以及
• 根據需要執行重新授權。

處置 通常，系統沒有明確的結束。由於需求的變化或技術進步，系統通常會演變或過渡到下一代。系統安全計劃應隨著系統不斷發展。許多環境、管理和運營資訊仍然相關且有用，可用於為後續系統開發安全計劃。處置活動確保系統有序終止並保留有關係統的關鍵資訊，以便在必要時，可以重新啟用部分或全部資訊。特別強調正確儲存系統處理的資料，以便根據適用的記錄管理法規和政策，將資料有效地遷移到另一個系統或存檔，以便將來訪問。該階段的關鍵安全活動包括

• 構建和執行處置/過渡計劃；
• 關鍵資訊的存檔；
• 介質的消毒；以及
• 處置硬體和軟體。

SDLC 階段

規劃

系統規劃需要使用者定義問題是什麼。規劃可能還包括使用者希望如何解決問題。在這一階段，定義問題的範圍也很重要。定義範圍有助於防止專案出現範圍蔓延。確定問題並選擇一種或多種解決方案後，就開始規劃實施解決方案。可以制定多個方案來確定實施系統的最佳行動方案。

行動方案應記錄完整，並考慮以下因素：展示實現目標的預期活動（里程碑）的開始時間和完成時間的時間表，瞭解實現目標所需的支出，安排定期狀態審查（我們是否按計劃進行？），預計任何組織結構調整以適應目標，預計並規劃風險緩解措施，這些風險可能會阻礙目標的實現，實施決策的政策和程式，以及定義效能標準。

在約翰·薩辛格的“五項主要活動必須存在”的規劃中，正如他在書中解釋的那樣，五項活動應包括

• 定義問題
• 制定專案計劃
• 確認專案可行性
• 為專案配備人員
• 啟動專案

為什麼計劃會失敗？許多原因包括

• 目標/規範未被理解。
• 目標過於龐大，無法在分配的時間內完成。
• 預算不準確。
• 專案人員不足或技能不足。
• 未安排狀態審查或審查不足。
• 士氣低落（沒有承諾）。

規劃中最困難的決定之一是知道何時停止一個專案。這將需要有效的控制和監控系統。如果你無法監控一個系統，你就無法控制它。沒有哪個組織願意承認失敗，但可能在某個時刻，一個專案將無法挽救。這對於資訊科技專案尤其重要，因為技術發展迅速。大多數經理不願過早終止專案，因為職業生涯和自尊心都岌岌可危。沉沒成本謬誤也可能起作用。結果是專案繼續進行，直到無法挽回。為了避免這個問題，必須在規劃階段初期就建立監控和控制系統。至關重要的是，要定義並執行里程碑，如果必要，專案將在里程碑處終止。令人欣慰的是，即使專案被終止，也不意味著它完全失敗。組織可以節省過高的成本，管理層可以吸取教訓，並將其應用於下一個專案。一般來說，有兩種型別的監控：“非正式”和“正式”。非正式通常是普通會議、電子郵件和觀察。正式包括狀態報告、計劃里程碑、審計、審查和基準測試。正式審查通常成本更高，並在系統開發過程中使用。這兩種系統可以組合使用，並涉及以下問題：“使用哪些效能指標？”和“審查多久進行一次？”？必須集中精力識別和糾正失控流程。

分析

分析階段涉及收集系統需求。在這個階段，研究業務需求，旨在提高業務流程效率。系統分析階段側重於系統將做什麼，這種努力將所有利益相關者視為可行的資訊來源。在分析階段，大量時間用於與利益相關者交談並審查利益相關者的意見。IT 專案的常見利益相關者包括

• 架構辦公室
• 測試與認證辦公室
• 記錄管理團隊
• 應用程式支援組

一旦識別出利益相關者，就可以開始收集和分析需求。需求收集必須與業務需求或機會相關。需求分析涉及捕獲需求和分析需求。捕獲需求是指與利益相關者溝通，以就需求達成一致。分析需求是指使用標準工具來生成需求基線。一旦利益相關者對需求達成一致，就建立基線，並將其作為正式的需求來源。

在這個分析階段，分析師正在發現和收集事實。除了與利益相關者會面外，分析師還必須與終端使用者會面，以瞭解使用者的需求，並瞭解影響當前系統的問題，以便協助設計新的、更有效的系統。分析階段必須進行以下幾項活動：

• 收集資訊
• 定義新系統的需求
• 為新系統構建原型
• 確定需求優先順序
• 評估備選方案
• 與管理層會面，討論新的選擇方案

設計

設計階段涉及系統的物理構建。包括網路（硬體、作業系統、程式設計等）的設計或配置，使用者介面（表單、報表等）的設計，系統介面（與其他系統通訊）的設計，以及安全問題。重要的是，要對擬議的設計進行效能測試，並確保它滿足分析階段概述的需求。換句話說，這個階段的主要目標是將先前定義的需求轉換為完整且詳細的規範集，這些規範將在下一階段使用。設計階段需要進行以下一些活動：

• 設計應用程式
• 設計和整合網路
• 設計和整合資料庫
• 建立應急計劃
• 啟動維護、培訓和運營計劃
• 審查設計
• 闡明業務流程和程式
• 建立過渡策略
• 交付系統設計文件
• 審查最終設計

實施

啟動一個專案首先需要記錄需求。應該從這項研究中制定明確的目標，並說明選擇目標的原因。然後需要記錄交付成果以及專案範圍。在初始化過程中可以完善範圍。還應記錄假設和約束。所有利益相關者都應參與此過程。這些資訊將成為專案的章程，也是啟動專案的依據。然後，專案遵循計劃-執行-檢查-行動迴圈（由休哈特定義，並由戴明修改，在 ASQ 手冊中，第 13-14 頁，美國質量協會，1999 年）。每個迴圈的結果將作為輸入連結到下一個迴圈。此過程應提高交付成果被接受的可能性。

為了實現交付成果的接受和目標的實現，必須對正在構建的新系統進行測試。與之相一致的是，必須對終端使用者進行全面培訓，以便公司能夠從新系統中獲益。在實施階段必須執行以下五項活動：

• 構建軟體元件
• 驗證和測試
• 轉換資料
• 培訓終端使用者並記錄系統
• 安裝系統

維護/支援

維護和支援涵蓋系統到位後所需的所有活動。活動包括但不限於

• 使用者電話支援
• 現場使用者物理支援
• 解決新系統可能出現的任何問題
• 為使用者提供支援材料/工具

所需的支援量可能取決於系統。如果它是一個涉及多個不同部門的大型系統，則可能需要更長時間的維護和支援。如果它是一個較小的系統，則可能只需要很短時間的維護和支援。

系統開發方法

本節討論開發基於計算機的資訊系統的最流行方法。一種流行的傳統方法稱為結構化分析，但一種稱為面向物件分析和設計的新策略也被廣泛使用。每種方法都有許多變體。一些組織開發自己的方法，或採用軟體供應商或顧問提供的方法。大多數 IT 專家同意，不存在單一的最佳系統開發策略。相反，系統分析師應該瞭解替代方法及其優缺點。

結構化分析

結構化分析是一種傳統的系統開發技術，經受住了時間的考驗，易於理解。因為它描述了將資料轉換為有用資訊的流程，所以結構化分析被稱為以流程為中心的技術。除了對流程建模之外，結構化分析還包括資料組織和結構、關係資料庫設計以及使用者介面問題。結構化分析使用一系列稱為系統開發生命週期 (SDLC) 的階段來規劃、分析、設計、實施和支援資訊系統。結構化分析依賴於一組以圖形方式描述系統的流程模型。流程建模識別流入流程的資料、轉換資料的業務規則以及產生的輸出資料流。

結構化分析方法需要開發者定義三個方面：1) 系統需要進行的處理；2) 系統需要儲存的資料；3) 系統整體執行所需輸入和輸出。為了瞭解所有這些功能如何協同工作，需要資料流圖 (DFD) 來展示輸入、處理儲存和輸出。

面向物件分析

結構化分析將過程和資料視為獨立的元件，而面向物件分析將作用於資料的過程和資料組合成稱為物件的實體。面向物件分析定義了執行工作並相互互動的不同型別的物件，並展示了完成任務所需的使用者互動，稱為用例。系統分析師使用 O-O 方法來模擬現實世界的業務流程和操作。結果是一組代表實際人員、事物、交易和事件的軟體物件。使用 O-O 程式語言，程式設計師將這些物件轉換為可重用的程式碼和元件。

O-O 分析使用物件模型來表示資料、行為以及物件如何影響其他物件。透過描述支援業務運營所需的物件（資料）和方法（過程），系統開發人員可以設計可重用的元件，從而實現更快的系統實施和降低開發成本。許多分析師認為，與結構化分析相比，O-O 方法在當今動態的商業環境中更靈活、高效且更現實。面向物件方法有很多好處，它們提供了自然性和可重用性。這種方法很自然，因為人們傾向於用有形的物件來思考事物，並且因為組織內的許多系統使用相同的物件（例如視窗、對話方塊、選單和按鈕），因此可以重複使用這些類。此外，O-O 分析為流行的 O-O 程式語言（如 Java 和 C++）提供了輕鬆的過渡。

其他開發策略

除了結構化分析和 O-O 方法之外，還有其他由各個公司建立的系統開發技術。例如，微軟開發了一種稱為 Microsoft Solutions Framework (MSF) 的方法。使用 MSF，您可以設計一系列模型，包括風險管理模型、團隊模型，每個模型都有特定的目的和輸出，這些輸出有助於系統的整體設計。儘管微軟流程與 SDLC 階段導向方法不同，但 MSF 開發人員執行相同型別的計劃、提出相同型別的事實調查問題、處理相同型別的設計和實施問題，並解決相同型別的問題。MSF 使用 O-O 分析和設計概念，但還考察了圍繞資訊系統開發的更廣泛的業務和組織環境。

臨時的

臨時的，是指可以用於完成特定任務的東西，但使用的方法無法用於其他過程。就像即興工作一樣，不需要進行重大規劃。整個專案無法以這種程度運作。可以使用模板來建立專案，但使用臨時的，這是不可能的。總的來說，術語“臨時的”意味著僅用於此目的。

結構化/瀑布

瀑布模型是系統開發生命週期方法的流行版本，它被認為是在軟體工程預測/自適應尺度上最左邊的模型。瀑布模型通常被認為是系統開發生命週期的經典方法（主要是預測性的），它描述了一種線性且順序的開發方法。瀑布開發為開發的每個階段都設定了明確的目標。完成一個開發階段後，開發過程將繼續（從瀑布中落下）進入下一階段，並且不能回頭。

瀑布開發的優點是它允許部門劃分和管理控制。可以設定時間表，為每個開發階段設定截止日期，產品可以透過開發過程像汽車一樣在洗車場中移動，理論上可以按時交付。開發從概念開始，經過設計、實現、測試、安裝、故障排除，最終進入運營和維護。每個開發階段都按嚴格的順序進行，沒有任何重疊或迭代步驟。

瀑布開發的缺點是它不允許進行太多反思或修訂。一旦應用程式進入測試階段，就很難返回並更改在概念階段沒有經過深思熟慮的內容。這種純粹的瀑布模型使得很難做到這一點，因為沒有出錯的餘地，而這在處理人類時實際上是不可能的。

但是，在預測/自適應尺度的右側，我們能夠在不同的階段進行修改；這被稱為修改後的瀑布模型。在修改後的瀑布模型中，專案的階段將重疊，相互影響和依賴。例如，如果分析階段完成，專案進入設計階段，但分析階段的要求遺漏了一些內容，使得在設計階段難以實施，則需要新增額外的專案管理任務，從而導致重疊。

效率是重疊發生的另一個原因。一些活動依賴於先前工作的成果。在專案規劃階段，可能需要新增一些額外的專案管理任務，在分析階段，可能需要新增額外的分析活動，在設計階段，可能需要新增額外的設計活動。基本上，修改後的瀑布模型是一個更有效的模型。如今，許多資訊系統和專案都是基於修改後的瀑布模型。

原型設計

原型設計是構建系統模型的過程。就資訊系統而言，原型設計用於幫助系統設計人員構建一個對終端使用者來說直觀易操作的資訊系統。原型設計是一個迭代過程，是系統開發生命週期分析階段的一部分。

在這個分析階段，原型設計通常被稱為發現原型，非常重要，因為它旨在瞭解使用者的需求。原型並非為了實現完整的功能而構建，而是為了檢視原型是否能夠實現企業試圖實現的目標。有時，終端使用者試圖改進業務流程或簡化流程。無論如何，透過使用試用報告和螢幕，分析師可以向終端使用者解釋如何更新和改進其業務流程。如果企業決定實施新技術，那麼發現原型設計可以幫助確定是否實施新技術，以及新技術是否與企業的業務需求相符或是否可行。

原型設計有多種形式 - 從低技術含量的草圖或紙質螢幕（Pictive）開始，使用者和開發人員可以在其中貼上控制元件和物件，到使用 CASE（計算機輔助軟體工程）或第四代語言構建的高科技作業系統，以及介於兩者之間的所有形式。
原型設計的優點包括；

• 縮短開發時間和成本
• 使用者參與
• 可量化的使用者反饋
• 促進系統實施
• 更高的使用者滿意度
• 向開發人員展示未來潛在的增強功能

另一方面，缺點包括；

• 分析不足
• 使用者期望最終系統的效能與原型相同
• 在最終產品釋出之前就實施的誘惑
• 開發人員對原型的依賴
• 文件不完整

原型設計的最佳理由是它允許程式設計師與客戶合作，以確保系統能夠滿足客戶的期望。然而，這是一把雙刃劍。問題是，大多數情況下，原型是一種笨拙、快速解決問題的方法，通常需要進行重大重建，而且大多數程式設計師對拋棄自己的程式碼以採用新的簡化方法猶豫不決。因此，最終得到的程式碼會包含一個接一個的補丁，難以維護。此外，在原型設計過程中與客戶的來回溝通可能會導致專案範圍蔓延。每次你以為自己完成了，就會有一些改進或新功能被提出來。這將阻止專案簽署。為了避免這種情況，請確保存在專案計劃，其中指定了迭代次數，併為新增新功能設定了截止日期。

增量/迭代

增量方法是將專案劃分為多個[儘可能]獨立的部分，並以相同/不同的速度開發這些子部分，並在準備好時整合它們。例如，開發一個社交網站，包含會員註冊、登入、忘記密碼、會員資料、搜尋會員、好友列表、部落格、部落格搜尋、照片、照片搜尋和訊息等功能。根據產品所有者的需求，開發團隊可以從會員註冊、登入、會員資料和搜尋會員開始。這些部分可以在準備好後完成並整合到一個公共儲存庫中。一旦這些部分準備好，就選擇下一個部分。也可以同時處理所有部分，並在準備好後將它們整合到中央儲存庫中。
根據 Alistair Cockburn 的說法，迭代開發是一種重新安排工作時間的方法，其中預留時間來修改和改進系統的一部分。

螺旋模型

螺旋模型是 SDLC 中較新的自適應方法之一。基本上，自適應方法是一種開發方法，它將包括在專案進行過程中調整的計劃和模型等專案活動。螺旋模型包含幾個自適應特性，這些特性將在專案的開發過程中反覆迴圈，直到專案完成。

螺旋生命週期以螺旋模型的形式顯示，該模型從螺旋的中心（向內）開始，首先是規劃階段，最終以螺旋狀向外展開，反覆迴圈，直到專案完成。規劃階段將包括諸如可行性研究、使用者需求調查、總體設計選擇、生成實現方案和實現策略等活動。該階段的目的是獲得足夠的資訊來構建原型。

快速應用開發（RAD）

快速應用開發利用工具來促進系統開發，以滿足激進的時間線。[1] 關鍵重點是重複使用已建立的工作模型[原型/模型/使用者介面/線框][2] 關鍵目標是減少花在分析上的時間，這是透過使用工作模型進行設計來實現的

建模

建模有助於更好地理解需求。視覺化建模幫助我們理解和組織複雜的努力。符號在任何模型中都扮演著重要角色。據說，如果你不能記錄你的工作成果，你很可能會失敗。統一建模語言 (UML) 提供了一種非常強大的符號，它從分析到設計不斷發展。它是一種用於指定、視覺化和記錄正在開發的面向物件系統的成果的語言。你可以使用 UML 對在任何型別的硬體、作業系統、程式語言和網路上執行的任何型別的應用程式進行建模。它是面嚮物件語言和環境的自然選擇，但你也可以用它來對非面向物件的應用程式進行建模。

面向物件開發

在編碼之前，應該對虛擬碼、演算法和要使用的高階語言（C、C++、C#、Java 等）有一個瞭解。這將幫助你設計一個用於特定目的的系統。現代程式設計通常需要面向物件的方法來進行軟體開發。面向物件開發試圖利用物件的分類、關係和屬性來幫助程式開發。物件可以是任何物品或概念。物件包含屬性和操作，它們相互作用以滿足特定的需求。屬性是與物件相關的屬性，而操作是物件可以執行的方法或動作，以修改自身或資料。對物件中資料的訪問只能透過物件的稱為物件介面的操作來實現。物件的函式繫結到它使用的資料。你可以輕鬆地更改控制物件實現方式的細節，以提高效能、新增新功能或修復錯誤，而無需更改介面。這使得專案的其他部分可以訪問物件並保持不變。

概述

本書分為 5 個主要單元

• 規劃
• 分析
• 設計
• 實施
• 維護/支援

問題

資訊系統的技術需求類別有哪些？