第5章开发策略课件.ppt

《第5章开发策略课件.ppt》由会员分享，可在线阅读，更多相关《第5章开发策略课件.ppt（61页珍藏版）》请在三一办公上搜索。

1、第6章 開發策略,1,第6章 開發策略1,簡介,本章是SDLC系統分析階段的的剩餘活動。系統分析階段的主要目的是要建立新資訊系統的邏輯模型。,2,簡介本章是SDLC系統分析階段的的剩餘活動。2,開發策略概述,在幾年前，一般公司不外乎自行開發軟體購買套裝軟體(或許需做一些修改)，或聘請顧問或外部資源執行這項工作。今日，公司有更多的選擇，包括應用系統服務提供者(簡稱ASP)、網站代管的軟體選擇，以及提供各種企業級軟體解決方案的公司。選擇最佳的開發方式公司需要考量三個關鍵議題:(1)網際網路的衝擊、(2)軟體委外的各種選項、及(3)內部自行開發軟體的替代方案。,3,開發策略概述在幾年前，一般公司不外

2、乎自行開發軟體購買套裝軟,網際網路的衝擊,軟體即服務SIIA(軟體及資訊產業協會)相信軟體是一種服務的觀念。SIIA指出許多傳統的應用套裝軟體，將被網路服務所取代，而這些服務將免除公司內部員工安裝、維護，升級的責任。SIIA的出版品指出，以服務而非產品的方式取得軟體，將對軟體產業造成巨大的衝擊。,4,網際網路的衝擊軟體即服務4,網際網路的衝擊,傳統與網路為基礎的軟體開發策略 身為系統分析師，你必須考慮系統要在以Web為核心的架構下，或是在傳統的環境中開發。在以Internet為基礎的系統中，網頁會成為應用系統的一部分，而不只是一個通訊頻道。系統分析師需要新的開發工具與解決方案，才能處理新的系統

3、。例如:已經學過兩個以Web為基礎的開發環境，分別是IBM的WebSphere和Microsoft的.NET。,5,網際網路的衝擊傳統與網路為基礎的軟體開發策略5,網際網路的衝擊,雖然網路式系統是主要的趨勢，但許多公司還是仰仗傳統的系統，可能的原因之一是舊有系統不容易被取代;也可能是不需要網路元件，來滿足他們的需求。與傳統環境比較起來，在網路式環境中組建應用系統，可能會提供比較大的效益，有時候也會產生比較高的風險。以下幾節的內容，將列出這兩種開發方式的特徵。,6,網際網路的衝擊 雖然網路式系統是主要的趨勢，但許多公司還是仰,網際網路的衝擊,在傳統開發方式需考量的一些特質:系統設計受到相容性課題

4、的影響，包括現有的硬體及軟體平台和舊有系統需求的影響。系統被設計在區域或廣域的公司網路上執行。系統經常利用Internet連結和資源，但是網頁功能被視為功能的補強而不是設計的核心要素。開發過程通常依循三種主要路徑之中的一種:公司內自行開發、購買套裝軟體必要時做一些修改，或利用外部的顧問。擴充能力*會受到通訊及網路限制的影響。(*指系統能夠處理未來業務量及交易量的能力)許多應用系統需要相當的桌上型電腦運算能力及資源。安全問題通常比網路(web)為基礎的系統單純。,7,網際網路的衝擊在傳統開發方式需考量的一些特質:7,網際網路的衝擊,在一個以網路(web)為基礎的系統開發方式需考量的一些特質:系統

5、是在一個以Internet為基礎的架構之下開發並交付，如.NET或WebSphere。這種開發方式視網站為平台，而不只是通訊頻道。以Web為基礎的系統規模可輕易擴充，並可在不同的硬體環境下執行。大型公司傾向部署以網路(web)為基礎的系統，作為全體企業的軟體解決方案，像是顧客關係管理、訂單處理、以及原物料管理。以Web為基礎的軟體視應用軟體為較不依賴於桌上型電腦運算能力及資源的一種服務。,8,網際網路的衝擊在一個以網路(web)為基礎的系統開發方式需考,網際網路的衝擊,當公司以服務而非產品的方式取得以Web為基礎的軟體時，他們能將內部自行開發的工作降到最低，而藉由支付約定的費用，讓廠商負責安裝

6、、調整、並維護該系統。以Web為基礎的軟體通常需要增加一個通訊層，稱為中介軟體(middleware#)，以便與現有的軟體及舊有系統溝通。,9,網際網路的衝擊當公司以服務而非產品的方式取得以Web為基礎的,委外(1),委外(outsourcing#)是指將資訊系統的開發、操作，或維護等工作以支付費用的方式暫時或長期地轉移給提供這些服務的公司。委外可以是小規模的程式撰寫工作，也可以是從服務提供者租用軟體，將基礎業務流程的委外管理(通常被稱為企業流程委外(BPO,business process outsourcing#)或是處理公司全部的IT功能。,10,委外(1)委外(outsourcing#

7、)是指將資訊系,委外(2),委外的成長傳統上，公司把IT業務委外，當作是控制成本及因應科技快速變遷的手法。今日，上述原因依舊，而委外已經成為企業整體IT策略的一部分。在Oracle引用的資料中顯示許多企業花費其IT預算的80%來維護現有的軟體和系統，因而迫使IT經理人浪費時間管理繁瑣的升級工作，而無暇投入能夠獲利的IT專案。一個提供委外解決方案的公司被稱為服務提供者(service provider#)。,11,委外(2)委外的成長11,委外(3),委外有兩種廣為採用的選項，其中牽涉到應用系統服務提供者及提供網際網路業務服務的公司。應用系統服務提供者(ASP,application servi

8、ce provider#)指的是按照使用量的多寡，或是申請的費用，提供軟體應用系統，或存取特定應用軟體的公司。ASP提供的不只是使用軟體授權，還包括將套裝軟體出租給顧客。有些公司提供網際網路業務服務(IBS,Internet business services#)，這些業者針對如訂單處理、帳務，及客戶關係管理等交易提供強而有力的Web為基礎的支援。IBS的另一個術語是代管服務(managed hosting)，因為整個營運是由外部的公司，或是主機來管理。,12,委外(3)委外有兩種廣為採用的選項，其中牽涉到應用系統服務,委外(4),委外的費用目前有幾種模式，包括固定費用、預訂費用，以及按照使用

9、量或交易筆數計算。固定費用模式(fixed fee model)是根據特定的服務或使用者支援等級所設定的費用組合。預訂費用模式(subscription model)則包含變動的費用，這些費用會按照使用應用軟體的人數或工作站數量計算。使用量模式(usage model)或交易筆數模式(transaction model)則是依據交易或作業量，而收取不同的費用。,13,委外(4)委外的費用13,委外(5),委外時應考量的事項 只有當結果符合成本效益的原則，解決方案與公司長期經營的策略方向一致，而且涉及的風險在可接受的範圍內時，才可以將關鍵任務的IT系統委外。公司必須將敏感的資料，交給外部的服務提

10、供者，並信任該提供者維護資料的安全性、機密性，及品質。除此之外，在委外之前，一個公司應小心檢視有關保險、潛在責任、授權及資訊所有權、保固條款，及災難防制復原等議題。,14,委外(5)委外時應考量的事項14,委外(6),考量委外的公司必須瞭解到此種解決方案所能達到的也完全受限於提供該項服務的委外廠商，在此種情境之下，在對委外廠商做任何承諾之前，充分審查委外公司的歷史及財務狀況尤其重要。購併也會影響委外服務的顧客。例如，Compaq及HP已經宣布，在他們合併之後，將重組並簡化新公司所提供的產品及服務。-公司穩定性的考量在某些情況下，一個公司如果沒有足夠的時間或經驗，可以自行處理某些工作時，就會將應

11、用系統的開發或系統修改的任務委託給IT顧問公司。,15,委外(6)考量委外的公司必須瞭解到此種解決方案所能達到的也,委外(7),委外替公司減輕了在忙的時候需要增加IT人員及在工作量減少時需要裁減人力的責任。委外主要的缺點之一是它會提高員工對工作保障的疑慮。境外委外 境外委外(offshore outsourcing#)或全球委外(global outsourcing#)係指將IT開發、支援及操作等作業移轉到其他國家的作法。境外委外的主要原因與國內委外相同:都是為了取得較低廉的成本。境外委外涉及一些關於專案控管、安全問題、文化差異、以及有效通訊等特殊疑慮。採行境外委外之前，它應該仔細分析所有的利

12、益及潛在的各種風險。,16,委外(7)委外替公司減輕了在忙的時候需要增加IT人員及在工,自行開發軟體的選項(1),自製或採購的決策所謂自製就是由公司的IT部門負責組建或開發自製軟體(in-house software#)。所謂的購買套裝軟體(software package#)則是由某個廠商或ASP(Application Service Provider#)取得。套裝軟體可能是一套標準化的商業化程式，或是一套專為購買者設計的客製化(customized#)軟體。開發軟體並從事銷售行為的公司被稱為軟體廠商(software vendors#)。有些公司會藉由客製化，加強商用套裝軟體的功能，並為

13、某一個特定產業而設定軟體的作業環境，這些公司被稱為加值型經銷商(VAR,value-added reseller#)。,17,自行開發軟體的選項(1)自製或採購的決策17,自行開發軟體的選項(2),許多不同類型的公司組織都能使用的套裝軟體，稱之為水平式應用軟體(horizontal application#)。為處理特定類型企業的資訊需求所開發的套裝軟體，則稱之為垂直式應用軟體(vertical application#)。自行開發軟體自行開發的理由:滿足獨特的企業需求-公司在決定自行開發軟體時，往往是因為從市場上買不到可以滿足其獨特需求的套裝軟體。,18,自行開發軟體的選項(2)許多不同類型

14、的公司組織都能使用的套裝,自行開發軟體的選項(3),讓企業程序與政策的變更極小化-如果找到的套裝軟體需要改變現有的運作或程序，公司也可能選擇自行開發該軟體。滿足現有系統的限制-任何新安裝的軟體都必須與現有的系統一起工作。滿足現有技術的限制-新系統必須與現有的硬體和舊有的系統一同運作，那可能會需要一個特定的設計而不是市場上可找到的。開發內部資源和能力-高層主管通常比較偏好有自己內部的IT團隊來提供整體的指導和長期的穩定。滿足獨特的安全性需求,19,自行開發軟體的選項(3)讓企業程序與政策的變更極小化-,自行開發軟體的選項(4),購買套裝軟體購買套裝軟體的理由:成本比較低廉-軟體供應商把開發成本分

15、散到許多客戶上面。實作所需的時間比較短-當你購買套裝軟體時，它已經完成系統設計、程式撰寫、測試及文件的製作。因此，就省下自行開發時會花費在這些任務的時間。經過證實的可靠性和效能的標竿-如果這種套裝軟體已經上市一段時間，任何重要問題應當已經被發現並已由供應商更正完成。需要比較少的技術開發人員 由廠商提供未來的升級版本 利用其他公司做借鏡-能夠與其他公司的使用者聯繫，取得他們對於這種套裝軟體的印象和資訊。,20,自行開發軟體的選項(4)購買套裝軟體20,自行開發軟體的選項(5),套裝軟體的客製 如果軟體產品的標準版本都無法滿足公司需求，則公司可能考慮修改套裝軟體來滿足其需求。客製套裝軟體的三種方式

16、如下:你可以購買基本版的套裝軟體，並由廠商為你客製化(customized#)，以符合你的需求。你可以支付額外的費用，要求他們加強系統的功能，以便滿足你的需求。你可以購買套裝軟體，並自行修改系統的功能。這種作法的缺點之一是，系統分析師和程式設計人員可能不熟悉這套軟體，因此需要時間瞭解，並進行正確的修改。如果產品需要客製(修改)，則購買標準版的某些優點就會消失。,21,自行開發軟體的選項(5)套裝軟體的客製21,自行開發軟體的選項(6),如果由廠商執行客製的任務，修改後的套裝軟體可能更貴，而且可能需要更長的時間。另一個問題是未來的支援:雖然廠商都會定期為標準版升級，但他們可能並不提供客製程式的升

17、級版。另外，如果由購買軟體的公司進行修改，當套裝軟體的新版本推出時，公司可能需要再修改這個新的版本。建立使用者應用軟體 所謂使用者應用軟體(user application#)是利用標準的商用軟體，像是Microsoft Word或Microsoft Excel，這類軟體都已用特定的方式設定，來強化使用者的生產力。,22,自行開發軟體的選項(6)如果由廠商執行客製的任務，修,自行開發軟體的選項(7),利用使用者應用軟體的原因:大多數的IT部門都有一堆來不及處理的專案，而那些為一個人或一個小團隊所作的IT解決方案，經常都不會優先處理，故在這些情況下，使用者應用軟體提供一個低成本的解決方案。許多公

18、司藉由提供更多的資料，以及功能更強的資料管理工具，來提升基層員工的能力。其主要目的是讓基層員工不用IT部門的介入就能更方便地取得執行其業務所需的資料，如此能使得IT部門，更具生產力。但採用這個方式的公司，必須提供提升員工能力所需的技術支援，IT部門常設有所謂的客服中心(help desk#)，或資訊中心(IC,information center#)來負責對使用者提供技術的支援。基於安全性的考量，公司通常會限制這類使用者應用軟體只能在其任職部門內的個人電腦上執行。,23,自行開發軟體的選項(7)利用使用者應用軟體的原因:23,系統分析師的角色,在系統開發過程的這個時間點，公司必須決定是採用某種

19、委外的選項、自行開發軟體、購買套裝軟體、開發使用者應用軟體，還是這些方案的某種結合。例如，若決定自行開發軟體，系統分析師的參與程度，可能比委外或選擇商業套裝軟體時更加深入。當在選擇硬體及軟體時，系統分析師常常擔任評選小組的成員，評選小組也必須包含使用者，讓他們參與評選過程，並對新系統產生歸屬感。評選小組的主要任務，是排除無法滿足需求的系統方案，為可行的方案排定等級，然後將可行的方案呈給管理階層，以便做出最後的裁定。這個過程由仔細研究每個方案的成本與效益開始。,24,系統分析師的角色在系統開發過程的這個時間點，公司必須決定是採,分析成本效益,三種主要的成本分析工具:回收分析、投資報酬率、以及淨現

20、值。回收分析(payback analysis#)決定一個資訊系統要花多久時間，才能藉由減少成本及增加效益，回收所投入的資源。投資報酬率(ROI,return on investment#)是將由專案所得到的總淨效益(回收)，與對專案的總成本(投資)間的百分比。淨現值(NPV,net present value#)是所有效益的總價值減去成本的總價值，並調整效益和成本，以反映發生的時間點。,25,分析成本效益 三種主要的成本分析工具:回收分析、投資報酬率、,分析成本效益(from 張豐雄 著 結構化系統分析與設計),回收分析(還本法):此種方法以還本的年限為基準，亦即計算投資金額需要多少年才能收

21、回。還本的年限愈短，方案愈值得採行。公式如右:PP=C/P其中:PP代表還本年限C代表投資額P代表每年現金回收額例如:建立一個會計系統共需投資150,000元，該系統建立後，每年可減少支出50,000元，其還本年限可計算如下:PP=150,000 50,000=3(年),26,分析成本效益(from 張豐雄 著 結構化系統分析與設計,分析成本效益(from 張豐雄 著 結構化系統分析與設計),投資報酬率(ROI)比較法:此種方法是用以衡量投資所獲得之投資報酬率是否大於投資成本(通常指市場利率)，若答案是肯定的，即表示此方案可行，反之則否。公式如右:ROI=(P C N)(C 2)其中:ROI代

22、表投資報酬率P代表稅後盈餘N代表投資年限(即投資後系統可使用年限)C代表投資金額例如:假設某一系統之投資額為100,000元，實施後每年可增加淨利35,000元，此系統之可使用年限為四年，其投資報酬率可計算如下:,27,分析成本效益(from 張豐雄 著 結構化系統分析與設計,分析成本效益(from 張豐雄 著 結構化系統分析與設計),ROI=(35,000 100,000 4)(100,000 2)=0.2=20%若市場之利率水準不超過20%，則此系統即值得投資建立。淨現值(NPV)法:此法是依據預定回收率，將各期現金流程(現金回收)折為現值，若現值大於系統的投資額，即表示該方案值得採行，其

23、計算公式如下:,28,分析成本效益(from 張豐雄 著 結構化系統分析與設計,分析成本效益(from 張豐雄 著 結構化系統分析與設計),NPV=At/(1+r)t 其中NPV代表現值，t代表期別 At代表第t期現金流程(現金回收)r代表預定回收率例如:某一系統之投資額為180,000元，此系統之使用年限為五年，平均每年可回收現金56,000元，假設其預定回收率為百分之十，其現值可計算如下:NPV=56000/(1+0.1)+56000/(1+0.1)2+56000/(1+0.1)3+56000/(1+0.1)4+56000/(1+0.1)5=212,290(元)大於投資額180,000元，

24、故此系統建立後，必能獲得高效益。,t=1,n,29,分析成本效益(from 張豐雄 著 結構化系統分析與設計,分析成本效益(from 張豐雄 著 結構化系統分析與設計),平衡點分析法:此法是利用座標圖表示新、舊系統的成本消長情形，兩成本線之交點即為兩系統成本相等之平衡點。例如:某公司之會計系統，原使用人工處理，每月費用為350,000元，若改用電腦處理，估計新系統開發費用為750,000元，每月變動費用為200,000元，可計算如下:新系統之作業總成本為:A=750000+200000m(*m代表月數)(將上式視為 y=750000+200000 x)(2)舊系統之作業總成本為:,30,分析成

25、本效益(from 張豐雄 著 結構化系統分析與設計,分析成本效益(from 張豐雄 著 結構化系統分析與設計),B=350000m(視為 y=350000 x)(3)新系統應實施多少個月，始能將其固定成本部分收回，其計算式如下:A=B 即 350000m=750000+200000m 故 m=5(個月)茲繪圖說明如下:,300000,600000,900000,1200000,1800000,1500000,1,2,3,4,5,6,時間(月),成本,(5,1750000),(0,750000),*右圖中紅色線代表舊系統，藍色線代表新系統，由圖可知，從第五個月起，新系統之總成本即較舊系統低，也就

26、是新系統從那時起就開始比舊系統有效益。,31,分析成本效益(from 張豐雄 著 結構化系統分析與設計,取得軟體的過程(1),步驟l:評估資訊系統需求 指出系統的關鍵功能-不論你考慮的是自行開發或委外的選項，都必須發展出一份清楚且詳盡的功能清單，讓它可以作為系統的整體規格。考量網路及網站相關事宜-你必須決定系統將來是否會在網路上、Internet或企業內網路上執行，並將這些需求融入設計中。估計工作量及未來的成長(圖6-16)詳細說明任何硬體、軟體或人員限制你必須決定現有的軟體、硬體或人員等事項，是否會影響購置的抉擇。你必須釐清開發、取得、實作，及維護該系統所需的內部自有人力，並且決定公司是否願

27、意負擔這些比委外高的人力水準。,32,取得軟體的過程(1)步驟l:評估資訊系統需求32,取得軟體的過程(2),準備RFP或RFQ這兩個文件相當類似，但是會使用在不同的情況下，端視你是否已經選擇特定的軟體產品。徵求建議書文件(RFP,request for proposal#)是一份描述你的公司、列出你所需要的IT服務或產品，以及規範必要功能的文件。RFP能協助確保組織的業務需求可被滿足。根據這個RFP，廠商可以判斷是否擁有產品能滿足你的需求。RFP 也要求具體的價格和付款條件。(圖6-17)當你評估對某個RFP的各種回應時，你會發覺有一套評估模式會有莫大的助益。一套評估模式(evaluatio

28、n model)就是一種採用一個共同的量尺以衡量並比較廠商等級的技術。(p255 圖6-19a,圖6-19b),33,取得軟體的過程(2)準備RFP或RFQ33,取得軟體的過程(3),詢價單(RFQ,request for quotation#)在另一方面比RFP明確。當你使用RFQ時，你已經知道要用的是特定的產品或服務，而你需要獲得其報價或競標價格。RFQ可以包括買斷或各種租賃的選項，也可以加入維護或技術支援的條款。步驟2:辨識潛在的廠商或委外選項 如果你需要尋找特定產業的垂直式應用系統，則可以研究產業貿易期刊或網站，搜尋適用於特定產業的軟體評估資訊。另一種方法是與顧問公司合作。聘請顧問的主

29、要優點是，你能夠吸取廣泛的經驗，這是任何單一公司難以提供的。,34,取得軟體的過程(3)詢價單(RFQ,request fo,取得軟體的過程(4),另外一個有用的資源是網際網路上的BBS，其中包含數千個叫做新聞群組(news-groups)的論壇，新聞群組是獲得資訊與其他分析師或IT專業人士交流的好地方。步驟3:評估各替代方案 在辨識各種替代方案之後，你必須選出最適合於公司需要的一種。許多由顧問及軟體出版商所架設的網站中，經常都有產品的參考資料，以及連到其供應商的超連結。在評選的過程中，你應該從現有的使用者取得資訊、試用該應用軟體、並且對各種套裝軟體進行標竿測試。,35,取得軟體的過程(4)另

30、外一個有用的資源是網際網路上的BBS,取得軟體的過程(5),現有的使用者-你可以聯繫現有使用者，取得意見回饋並得知他們的經驗。針對大型套裝軟體，ASP和軟體供應商通常都會提供使用者參考資料。試用-對於水平式應用軟體或小型系統，利用一種展示版本輸入少量交易範例，也是可以接受的測試方式。對於垂直式應用軟體或大型系統而言，則可能需要由IT人員和使用者組成的小組，進行數天或數週的測試。標竿測試-為了判定套裝軟體能否有效處理特定的交易量，你可以進行標竿測試。所謂的標竿(benchmark#)可以測量套裝軟體處理特定資料量所需的時間。例如:某一種標竿測試可以測量處理1,000筆銷售交易所需要的時間。,36

31、,取得軟體的過程(5)現有的使用者-你可以聯繫現有使,取得軟體的過程(6),步驟4:執行成本效益分析步驟5:準備建議書 準備一份建議書，內容包括含各種方案的描述與評估，以及它們的成本、效益、優點及缺點。在此時，你可能需要提交正式的系統需求文件，並對建議的內容進行簡報。步驟6:實作解決方案 實作的工作內容要由你選擇的解決方案而定。與委外比較起來，自行開發需要的時間比較長，而且工作項目也比較多。第10章將詳細討論實作的策略和技術。,37,取得軟體的過程(6)步驟4:執行成本效益分析37,完成系統分析的工作(1),如果要完成系統分析階段，你必須準備系統需求文件，並對管理階層進行簡報。系統需求文件 系

32、統需求文件(SRD，system requirements document#)或稱軟體需求規格(SRS，software requirements specification#)，這份重要的文件是在進入系統設計階段之前，用來衡量系統完成後其效能、準確性，和完整性的起點。系統需求文件就像是一份合約，用來確認系統開發者必須交付使用者的內容。,38,完成系統分析的工作(1)如果要完成系統分析階段，你必須,完成系統分析的工作(2),系統需求文件應當以使用者能夠瞭解的語言來撰寫，讓他們能夠提出意見、建議改進的地方，並認可最後的版本。系統需求文件應當包括一個封面頁和一個詳細的目錄，還可以加上索引和詞彙表

33、，使文件更容易使用。系統需求文件的內容取決於公司和系統的複雜度。向管理階層進行簡報 在向管理階層簡報之前，你可能要先做另外兩個簡報:一個是對IT(資訊科技)部門的主要人員，使他們瞭解情況;另一個是對使用者的簡報，以解答他們的疑問，並請他們提供回鐀。系統需求文件是這三個簡報的基礎。,39,完成系統分析的工作(2)系統需求文件應當以使用者能夠瞭解的,完成系統分析的工作(3),做有效簡報的一些建議:先簡述系統專案的作用和主要目標、本次簡報的目標、及需要做成的決策。彙整主要的可行方案。對於每一個方案，說明其成本、優點和缺點。解釋評選小組為什麼選擇所推薦的方案。預留討論和提出問題及答覆的時間。取得管理階

34、層的最後決定，或同意下個步驟的時間表。對管理階層做簡報的目的，就是要取得對系統開發的批准，並得到管理階層的充分支援，其中包括所需的財務資源。,40,完成系統分析的工作(3)做有效簡報的一些建議:40,完成系統分析的工作(4),管理階層可能選擇以下五種方案之一:系統委外(*需修改書本文字，p261)內部自行開發系統，接下來就可以開始新系統的系統設計階段。購買或訂製套裝軟體 如果套裝軟體不經修改即可使用，你就可以開始規劃系統實作階段。如果必須對套裝軟體進行修改，你的下個步驟就是開始系統設計階段。如果由廠商進行這些修改，你的下個步驟就是開始規劃測試計畫，並製作修改的文件，作為系統實作階段的一部分。進

35、行額外的系統分析工作 停止所有的後續工作,41,完成系統分析的工作(4)管理階層可能選擇以下五種方案之一:,轉換到系統設計階段(1),如果管理階層決定自行開發這個系統，那麼就可以開始過渡到系統設計階段。系統設計的準備工作 當系統設計開始時，你必須擁有正確且易於瞭解的系統需求文件。當你進入設計階段，你必須確定你已經徹底而準確地執行系統分析，並在系統需求文件中呈現分析的成果。邏輯與實體設計間的關係 在SDLC的系統分析階段為一個資訊系統發展出邏輯設計。,42,轉換到系統設計階段(1)如果管理階層決定自行開發這個系,轉換到系統設計階段(2),邏輯設計(logical design#)的作用是定義系統

36、的功能及特色，以及其元件之間的關係。邏輯設計包括系統必須產生的輸出、系統所需的輸入，以及系統必須執行的處理工作，這些工作並不考慮實際的完成方式。一個邏輯設計定義必須發生的內容，而不是如何完成它的方式。因此，邏輯設計不會論及實作的方法。(例如:一個顧客紀錄系統的邏輯設計中，會描述每個顧客必須輸入的資料，指出所有紀錄必須按照顧客編號之順序顯示，並解釋顧客狀態報表中要產生的資訊。至於實際輸入或登錄的資料規格、排序的方法、產生報表的實體過程、及報表的確切格式不是邏輯設計中的內涵。)相對於邏輯設計，一個資訊系統的實體設計(physical design#)是實作該系統的計畫。你會在SDLC的系統設計階段

37、開發系統的實體設計。,43,轉換到系統設計階段(2)邏輯設計(logical desi,轉換到系統設計階段(3),實體設計會以邏輯設計為基礎，並描述特定的的實作方式，很像是描述如何實際構築建物的工作藍圖。邏輯設計關心的是系統必須完成的內容，實體設計則以系統如何滿足這些需求為重點。一般而言，在系統分析工作完成之前，設計階段將無法展開。雖然有些重疊是可能的，但能夠在系統分析階段完全結束後再進入系統設計是比較好的做法。但是，每個情況都不盡相同，例如，如果你發現自己忽略了一個重要的事實、如果使用者提出重大的新需求、或者法令或政府的需求發生變化，你可能會回到發現事實的步驟。,44,轉換到系統設計階段(3

38、)實體設計會以邏輯設計為基礎，並描述,系統設計的準則(1),系統分析師在開始任何元件的實體設計之前，必須瞭解系統的邏輯設計。第一步驟是複習系統需求文件。?實際的設計過程中，(1)最好的開始之處，是從資料設計著手，其中定義了實體資料結構、元件，及關聯性。(2)當資料設計完成，你轉而設計使用者介面，因為它影響使用者與系統之間的所有互動。(3)當你發展使用者介面時你會進行特定的輸入及輸出的設計任務，然後你會進行將設計轉變成程式模組的建構工作。?(與第7章簡介說法不一致-輸出及使用者介面設計，是SDLC系統設計階段的第一件工作。此一說法較為正確，但請參閱下一頁的說明),45,系統設計的準則(1)系統分

39、析師在開始任何元件的實體設計之前,系統設計的準則(2),因為系統的組成元件相互依存，設計階段並不是一系列明確定義的步驟。雖然你可能以某一個元件開始，但是同時處理多個元件也是常見的現象。例如，當你決定改變一種報表格式時，可能會需要改變其他資料設計或輸入畫面。系統設計的最後一個步驟，就是準備系統設計規格，並將結果提交管理階層。SDLC的系統設計階段包括三個主要任務,46,系統設計的準則(2)因為系統的組成元件相互依存，設計階段並不,系統設計的準則(3),步驟活動說明1複習系統需求以熟悉邏輯設計2設計系統使用者介面設計整體的使用者介面，包括:可以讓使用者與 系統互動的螢幕、指令、控制項與功能。輸入程

40、序決定將資料輸入系統的方式，並設計必要的來源文件。輸入與輸出設計每項輸入及輸出格式、報表畫面、及列印報表的實體格式。資料設計決定資料如何被組織、儲存、維護、更新、存取，及使用。系統架構決定處理策略與方法，用戶端/伺服器架構的互動、網路配置，以及Internet與企業內部網路的介面議題。,47,系統設計的準則(3)步驟活動說明47,系統設計的準則(4),步驟活動說明3呈現系統設計內容製作系統設計規格文件，其中詳細說明你對該系統所建議的設計，預計的系統效益，並估計開發與實作的成本。系統設計的目標 系統設計(systems design#)的目標是要建立一個有效、可靠，而且易於維護的系統。如果能滿足

41、定義的需求和限制，則稱為有效的系統。如果系統能夠適當地處理錯誤，如輸入錯誤、程序錯誤、硬體故障，和人為疏失之類的錯誤，那它就是可靠的。如果系統設計良好，有彈性，並且在開發時考慮到未來的修改，它就是一個易於維護的系統。,48,系統設計的準則(4)步驟活動說明48,系統設計的準則(5),設計的考量因素涉及使用者、資料、及架構三方面。使用者的考量因素系統設計期間，你所必須考慮的許多問題之中，最重要的目的莫過於讓系統為使用者所接受，或是讓系統具有親和力。務必要記得的是，你是在為使用者設計這個系統，而且要牢記以下這些基本要點:仔細考慮每一個使用者從系統中得到輸出結果，或向系統輸入內容的發生點。最重要的是

42、使用者介面一定要易學易用。輸入程序應該妥為紀錄、容易遵循、直觀，而且容許犯錯。輸出應當具有吸引力且易於瞭解。預期使用者、系統與組織在未來可能產生的需求。(如:欄位的有效值是:F表示全職員工，P表示兼職員工。根據這個欄位的數值，不同報表上將印出全職或兼職的字樣。這兩個數值可以寫死在程式中，但是設計獨立的資料表，記載類屬代碼和標題內容，則是比較好的選擇。寫死在程式中確實比較簡單，但是如果組織增加另外一個數值，像是以X表示彈性職務，則程式設計人員就必須修改全部的報表程式。)提供彈性。(如:將應收帳款系統中餘額超過$5000的全部客戶顯示在螢幕上-利用參數(parameter#)可輸入不同金額，但設定

43、預設值(default#)為$5000),49,系統設計的準則(5)設計的考量因素涉及使用者、資料、及架構,系統設計的準則(6),資料的考量因素資料的輸入與儲存，是系統設計時所考量的重要部分。以下是一些應遵循的準則:資料應當在它產生的地點即刻輸入系統，因為遲延會造成資料的錯誤。例如銷售人員應當在接受訂單時，輸入新訂單的資料。資料應該在輸入時即刻驗證，以便立即發現錯誤。儘可能採用自動化的資料輸入方法。存取資料項目應當受到控制，對重要資料值的所有輸入或變更，都應當提出報告。追查重要資料輸入與變更的報表，稱為稽核軌跡(audit trails)。應該記錄每一項資料的輸入與修改。資料應該只輸入系統一次

44、。應該避免重複的資料。,50,系統設計的準則(6)資料的考量因素50,系統設計的準則(7),架構的考量因素 你應該考慮下列建議:使用模組化設計。在模組化設計中，你建立個別的處理工作元件，稱為模組(module#)，它們連結於較高階層的程式或處理工作。在傳統的結構化設計中，每一個模組代表DFD上面顯示的一個特定的處理工作或次處理工作。物件導向設計，每個物件類別都被表示為一個程式碼模組。(參閱下一頁)設計執行單一功能的獨立模組，會比較容易瞭解、實作，及維護。獨立的模組還提供較大的彈性，因為它們能夠單獨開發與測試，然後在開發過程的稍後階段再把它們結合起來。,51,系統設計的準則(7)架構的考量因素5

45、1,系統設計的準則(8),1輸入成績,測驗成績,學生,任課老師,作業成績,各種成績,成績資料,2計算成績,各種成績,學期成績,3列印成績,學期成績,導師,全班成績單,個人成績單,0成績系統,1輸入成績,2計算成績,3列印成績,資料,處理的流程,52,系統設計的準則(8)1測驗成績學生任課老師作業成績各種成績,系統設計的準則(9),設計上的取捨 你將會發現，設計目標間經常互相衝突。例如，為了讓系統便於使用，可能使得編寫程式的要求更加複雜。為了使系統更富彈性，可能就會提高維護需求。大多數你將面對的設計取捨決策，都能夠歸納為品質與成本之間的基本衝突。雖然每一個專案都有預算和財務限制，你還是應當避免會

46、形成短期節省，但後續成本可能偏高的決定。例如，你嘗試降低實作成本而減少系統測試及使用者培訓的花費，可能造成未來較高的運作成本。,53,系統設計的準則(9)設計上的取捨53,建立雛型,建立雛型(prototyping#)指的是在開發初期，對所提議的資訊系統以快速的方法建立的一個可運作的版本，稱為雛型(prototype#)。雛型的建立涉及不斷重複做分析、設計、塑模及測試等一系列的工作。建立雛型的方法 系統分析使用兩種不同的建立雛型方法:系統式雛型建立及設計式雛型建立。系統式雛型建立(system prototyping)的最終產出是一個功能完備而且能運作的資訊系統模型(也稱為演進式雛型建立)。快

47、速應用系統開發方法(RAD)很仰賴雛型的建立。在使用RAD方法時，由使用者、經理人、IT人員等所組成的小組，共同開發資訊系統的模型，並演進為完整的系統。(圖6-29),54,建立雛型建立雛型(prototyping#)指的是在開發初,建立雛型,系統分析師也會運用雛型來驗證使用者的需求，隨後雛型即被丟棄，而實作的工作則持續下去。這種方法被稱為設計式雛型建立(design prototyping)或拋棄式雛型建立(throwaway prototyping)。設計式雛型建立的最終產出是一個經過使用者認可的模型，可用來記錄最終系統的各項功能，並進行標竿測試。(圖6-30)雛型建立有許多優點:可避免使

48、用者與系統開發人員間的誤解。以雛型為基礎，系統開發人員可為最終系統訂出準確的規格。,55,建立雛型 系統分析師也會運用雛型來驗證使用者的需求，隨後雛型,建立雛型,經理人可以更有效地評估工作模型，而且會比用書面規格更加正確。在最終系統完成之前，系統分析師可以用雛型來發展出測試及訓練的程序。建立雛型可以降低風險及潛在的財務危機，這些狀況會在最終系統無法支援業務需求時發生。雛型建立有以下潛在的問題:開發的速度快，可能會產生品質上的問題，而這些問題往往要到完成的系統開始運作之後才被發現。其他的系統需求，如可靠性及維護的難易度，無法由雛型確切地測試出來。對於非常複雜的系統，雛型會變得無法掌握而且難以管理

49、。,56,建立雛型 經理人可以更有效地評估工作模型，而且會比用書面規格,建立雛型,建立雛型的工具 大多數雛型的建立都是運用CASE 工具、應用程式產生器、報表產生器、畫面產生器，及第四代語言。在第四代語言(4GL,fourth-generation languages#)中，其指令與人們所使用的自然語言非常接近。例如，一個4GL陳述的範例PRINT ALL PRODUCTS WHERE CODE=IN STOCK AND STATUS=OK 雛型的限制 通常，系統最終版本要求的效能水準，都會比雛型所能提供的更高。,57,建立雛型建立雛型的工具57,建立雛型,雛型的限制:雛型只是能運作的系統，但

50、其工作效率遠低於完整開發的系統。因為它只是一個模型，而不是完成的系統，因此雛型的處理及回應速度都比較慢。雛型同時也可能欠缺安全性的需求、例外及錯誤狀況的處理程序、以及其他的必備功能。即使有這些限制，系統開發人員還是可以藉由加入必要的功能，將雛型提升為最終的資訊系統。否則，就可以丟棄雛型，並繼續完成SDLC的其餘階段。即使雛型未能演進為最終的系統，它還是可以確保最終產品能滿足所有需求。滿足系統需求是系統開發的終極目標，而雛型則是過程中非常有價值的工具。,58,建立雛型雛型的限制:58,軟體開發的未來趨勢,InfoWorld雜誌針對300多名IT專業人士進行調查，向受訪者問到有關軟體開發未來趨勢的