第3章 項目前期_第1頁
第3章 項目前期_第2頁
第3章 項目前期_第3頁
第3章 項目前期_第4頁
第3章 項目前期_第5頁
已閱讀5頁,還剩96頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、 項目前期的主要工作,包括現狀分析(含硬件分析、組織分析和業(yè)務分析)、需求收集、粗略設計和可行性分析。本章介紹了項目前期開展這些工作的主要內容和原則,并以實例對比介紹了使用結構化方法和面向對象方法進行項目前期工作的思路和模型構建,最后給出項目前期有關文檔的描述格式。第三章 項目前期 3.1項目前期的主要工作3.2 結構化的項目前期實例3.3 面向對象的項目前期實例 3.4項目前期的文擋描述規(guī)范第三章 項目前期 從項目擬定到正式開始之前,軟件團隊開發(fā)人員必須和用戶通力合作,了解問題的性質、工程目標和規(guī)模。 由于管理信息系統(tǒng)通常都是完成日常性的事務性操作,因此必須在現狀分析(包括硬件分析、軟件分析

2、(含組織分析、業(yè)務分析)的基礎上,了解現實系統(tǒng)的運行機制; 通過與用戶的交流,了解現實系統(tǒng)中需要自動化或改進的環(huán)節(jié),并進一步收集用戶關于目標系統(tǒng)的其他需求與約束條件; 在此基礎上進行目標系統(tǒng)的粗略設計,給出大致的未來目標系統(tǒng)的構成框架; 針對給出的系統(tǒng)構成框架,從經濟、技術、法律、環(huán)境等方面進行分析,明確是否存在滿足用戶需求的可行解。 在進行現狀分析、需求收集和粗略設計時,建立相關模型并輔以文字描述,能夠幫助開發(fā)團隊和用戶更好地理解所做的工作成果,最后把這些活動的結果,結合可行性分析結果,撰寫相關的文檔。 3.1項目前期的主要工作 3.1項目前期的主要工作 3.1.1 現狀分析3.1.2 需求

3、收集3.1.3 粗略設計3.1.4 可行性分析 任何企業(yè)或事業(yè)單位,都是由一定的硬件(建筑、道路、房屋、設施等等,如果該組織有一定的信息化基礎,則應該包括信息化的硬件設施-計算機網絡)和軟件(內部部門構成、崗位構成、崗位職責、業(yè)務處理的流程、各種規(guī)章制度等等,以及現有的計算機軟件系統(tǒng))構成。 為了開發(fā)替代現有的人工系統(tǒng)或舊軟件系統(tǒng)的全新信息系統(tǒng),需要對目標單位進行現狀分析。 3.1.1 現狀分析1.硬件分析 硬件是建設目標系統(tǒng)的物質基礎;軟件是建立目標系統(tǒng)的運行平臺。為了開發(fā)替代現有的人工系統(tǒng)或舊軟件系統(tǒng)的全新信息系統(tǒng),需要對目標單位進行現狀分析。從軟件開發(fā)的角度,現狀分析需要關注目標單位的硬

4、件(建筑布局和網絡硬件設施)、軟件(組織構成、崗位職責和業(yè)務處理的流程、現有軟件的系統(tǒng)高層結構)。 3.1.1 現狀分析 項目情況千差萬別 (1)目標系統(tǒng)完全是從無到有建立,硬件分析不僅是指對目標單位的建筑布局結構進行分析,作為后續(xù)粗略設計中網絡硬件設計的基礎(對于小型目標單位或組織,計算機網絡的部署和安裝可能會非常簡單,此時可以不考慮對其建筑布局進行分析); (2)項目是基于目標單位已經擁有一定的網絡和計算機硬件設施進行,計算機網絡可以直接沿用現有設施,則硬件分析主要是指對現有網絡硬件設施進行分析; (3)用戶對目標系統(tǒng)有全新的或性能提升的需求,需要基于現有的網絡硬件設施進行升級改造,硬件分

5、析包括對目標單位的建筑布局結構、網絡硬件設施同時進行分析。 3.1.1 現狀分析-硬件分析 網絡硬件分析主要是了解并描述目標單位現有的網絡及硬件設施構成、網絡連接情況。網絡拓撲圖是硬件分析的主要工具,網絡拓撲是從用戶、硬件設計團隊的視角,反映現實系統(tǒng)的硬件構成。 3.1.1 現狀分析-硬件分析2軟件分析 假如管理信息系統(tǒng)完全是從無到有建立,軟件分析主要是指對目標單位的組織構成和業(yè)務流程進行分析,作為后續(xù)粗略設計中軟件系統(tǒng)設計的基礎;如果項目是對目標單位現有多個子軟件系統(tǒng)進行集成,軟件分析主要是指各個現有子軟件系統(tǒng)的總體框架進行分析(包括系統(tǒng)體系結構、系統(tǒng)構成、功能結構和軟件配置);如果用戶對目

6、標系統(tǒng)有全新的需求和性能提升,需要對現有子軟件系統(tǒng)進行擴充、升級或改造,軟件分析包括對目標單位的組織和業(yè)務進行分析,也包括對各個現有子軟件系統(tǒng)的總體框架進行分析。3.1.1 現狀分析A. 組織分析 組織分析的目的在于掌握目標單位的組織構成、崗位設置和相關職能。對于任何一個企事業(yè)單位,組織機構、崗位構成、崗位職責都是最為直觀、簡單,并且具有相當的穩(wěn)定性,很少發(fā)生頻繁變化的情況。首先進行目標單位的組織分析,有利于為系統(tǒng)分析人員進行后續(xù)的業(yè)務分析打下良好的基礎。3.1.1 現狀分析-軟件分析A. 組織分析3.1.1 現狀分析-軟件分析 A. 組織分析進行組織分析建模,應該把握以下原則:(1)以組合關

7、系反映組織構成。 (2)組織構成應適度。(3)允許做一定的凝聚、合并或增補;(4)最終必須細化到崗位。 (5)組織分析應適度考慮擬開發(fā)系統(tǒng)的邊界。3.1.1 現狀分析-軟件分析B業(yè)務分析 廣義的業(yè)務流程,從客戶角度出發(fā),認為它是與客戶價值的滿足相聯(lián)系的一系列活動。而狹義的業(yè)務流程則從實際操作者的角度出發(fā),是為達到特定的價值目標而由不同崗位(人員)分工協(xié)作完成的一系列活動。 可以把針對客戶的廣義業(yè)務流程稱為外部業(yè)務;為保證外部業(yè)務完成的業(yè)務稱為內部業(yè)務。 以商場為例,外部業(yè)務有針對客戶的購物;為保證客戶的購物業(yè)務順利完成,商場內部有訂貨、貨物上架、盤點 等內部業(yè)務。3.1.1 現狀分析-軟件分析

8、B業(yè)務分析 外部業(yè)務,發(fā)起者未必就是外部客戶;除非外部客戶也可和軟件系統(tǒng)進行交互。 比如銀行的柜臺存取款服務,客戶往往是不能和軟件系統(tǒng)交互的,這種情況下,該業(yè)務的發(fā)起者是銀行的柜臺服務人員; 如果客戶是通過ATM機進行存取款服務,此時客戶因為和軟件系統(tǒng)直接交互,因此稱為ATM存取款業(yè)務的發(fā)起者。 內部業(yè)務,發(fā)起者一定是機構內部的工作人員。3.1.1 現狀分析-軟件分析B業(yè)務分析(結構化方法)3.1.1 現狀分析-軟件分析B業(yè)務分析(面向對象方法)3.1.1 現狀分析-軟件分析B業(yè)務分析業(yè)務流程具有以下特點:(1)具有層次性。 (2)合作關系。(3)構成業(yè)務流程的每個活動都有數據的變換或處理,都

9、有信息的反饋,即每個活動都有一個或多個輸入,輸出一個或多個結果。3.1.1 現狀分析-軟件分析B業(yè)務分析進行現實系統(tǒng)的業(yè)務流程建模,通常需要把握以下原則:(1)以客戶為中心。(2)遵循由粗到細的建模步驟。 (3)以崗位為最基本的構成單位、以崗位職責為最基本活動元素。(4)建模業(yè)務流程,無須考慮流程中可能出現的異常情況和錯誤。(5)允許建立可選的業(yè)務流程。( 6)可以在業(yè)務流程中反映相關的數據處理和變換。 采用結構化方法或面向對象方法進行業(yè)務分析建模,描述的細節(jié)稍有不同。3.1.1 現狀分析-軟件分析C. 現有軟件系統(tǒng)分析 現有軟件系統(tǒng)分析是指當項目不是完全從頭開始的時候,各個現有子軟件系統(tǒng)對未

10、來目標系統(tǒng)有重大影響,必須對現有軟件系統(tǒng)的總體框架進行分析,包括各個子系統(tǒng)的系統(tǒng)體系結構、功能結構和軟件配置(系統(tǒng)架構),以利于節(jié)約用戶成本,以最快的速度開發(fā)用戶需要的軟件系統(tǒng)。3.1.1 現狀分析-軟件分析 項目前期的需求,是開發(fā)團隊收集的軟件相關方對于軟件的一系列意圖、想法轉變?yōu)檐浖_發(fā)人員所需要的有關軟件的技術規(guī)格。需要注意的是,項目前期的需求不是嚴格的需求分析的產物,可能不完整、不清晰,允許有遺漏,忽略其中大部分細節(jié),開發(fā)團隊可以在后續(xù)工作進行修改和補正。3.1.2 需求收集 軟件需求包括3個不同的層次業(yè)務需求、用戶需求和功能需求,涵蓋軟硬件的需求則謂系統(tǒng)需求。除此之外,還包括各種非功

11、能需求。 實際上,業(yè)務需求(系統(tǒng)需求)反映的是高層務虛的目標,如提高工作效率、節(jié)約運行成本、降低勞動強度、快捷反映市場變化等等抽象的需求;用戶需求則是針對客戶而言,軟件系統(tǒng)能夠為客戶做什么,體現為某個完整的業(yè)務實現;而功能需求針對的是具體操作人員,能夠替代操作人員做什么,體現為特定功能模塊。 系統(tǒng)需求用于描述包含多個子系統(tǒng)的產品(即系統(tǒng))的頂級需求。當整個系統(tǒng)既有軟件系統(tǒng),又有硬件系統(tǒng)和人工系統(tǒng)時,用系統(tǒng)需求來替代業(yè)務需求。3.1.2 需求收集 非功能性需求是關于軟件的外界特征的規(guī)格表述,主要是對軟件性能指標和對質量屬性的描述。包括業(yè)務規(guī)則、質量屬性、外部接口、限制等待。 業(yè)務規(guī)則本身并非軟件

12、需求,因為它不屬于任何特定軟件系統(tǒng)的范圍。然而,業(yè)務規(guī)則常常會限制誰能夠執(zhí)行某些特定功能,或者規(guī)定系統(tǒng)為符合相關規(guī)則必須實現某些特定功能。有時,功能中特定的質量屬性(通過功能實現)也源于業(yè)務規(guī)則。所以,對某些功能需求進行追溯時,會發(fā)現其來源正是一條特定的業(yè)務規(guī)則。 質量屬性對產品的功能描述作了補充,它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性。外部接口對系統(tǒng)與外部世界的外部界面進行描述,約束是對設計與實現的約束。3.1.2 需求收集 項目前期的需求獲取,直接來源于與用戶的交流(業(yè)務需求/系統(tǒng)需求、用戶需求、非功能性需求)和業(yè)務分析(功能需求)。與網絡環(huán)境

13、、系統(tǒng)平臺、運行環(huán)境等有關的非功能屬性,這類需求主要通過設備或軟件供應商、安全服務提供商、同類用戶等來獲得。數據需求可以通過調查同類用戶或歷史數據獲得。 需求獲取的方式可以是由用戶主動提出,也可以通過與用戶交談,或對用戶進行問卷調查、跟班作業(yè)、原型系統(tǒng)等方式獲取。 需求是用戶對軟件的合理請求,但并不意味著開發(fā)者對用戶的無條件順從,必須建立在開發(fā)團隊和用戶共同討論、相互協(xié)商的基礎上。3.1.2 需求收集 項目前期往往要給出未來軟件系統(tǒng)的大致框架,讓開發(fā)團隊成員對未來軟件系統(tǒng)有初步了解。這要求給出未來軟件系統(tǒng)初步總體的設計。 主要包括體系結構設計、硬件(網絡)系統(tǒng)設計、應用系統(tǒng)(包括系統(tǒng)構成、功能

14、結構、軟件配置)設計、安全設計、配套設計。 3.1.3 粗略設計 體系結構從用戶、高層管理者和系統(tǒng)分析人員的視角,以抽象的角度反映軟件系統(tǒng)的構成部件以及部件之間的聯(lián)系。 硬件(網絡)系統(tǒng)設計從網絡設計、安裝維護人員的視圖,反映用傳輸媒體互連起來的各種系統(tǒng)硬件設備的物理布局。 應用系統(tǒng)設計從系統(tǒng)管理者、安裝維護人員角度反映系統(tǒng)構成,從用戶角度反映功能結構,從系統(tǒng)管理者和安裝維護人員角度反映軟件在不同設備上的安裝配置,系統(tǒng)構成、功能結構、安裝配置從不同角度反映信息系統(tǒng)的構成。 安全設計從主要反映安全保障體系的設計。 配套設計主要反映機房配套設施的建設安裝設計。 3.1.3 粗略設計 體系結構設計、

15、硬件(網絡)設計、安全設計、配套設計的依據主要來源于從用戶收集的非功能性需求,這些設計一旦獲得用戶確認,通常在項目前期即穩(wěn)定不變;應用系統(tǒng)設計(包括系統(tǒng)構成、功能結構、軟件配置)的主要依據是組織分析和業(yè)務流程分析。通常,項目前期的應用系統(tǒng)設計(包括系統(tǒng)構成、功能結構、軟件配置)都是粗略的,不是來源于精確的系統(tǒng)需求分析,因此項目前期的應用系統(tǒng)設計和項目總體設計階段的設計結果是有差異的,總體設計階段的設計結果更為準確、精確,符合用戶需求和實際情況。 3.1.3 粗略設計1體系結構設計 任何復雜的系統(tǒng)都需要一個體系結構來提供其演化的戰(zhàn)略性環(huán)境描述。體系結構提供了對組成系統(tǒng)的組件或構造塊的描述以及這些

16、組件間復雜的內部關系。軟件系統(tǒng)體系結構涉及需求和系統(tǒng)結構,包括軟件和硬件,使得軟件系統(tǒng)的設計概念可以被有效地表達和交流。 3.1.3 粗略設計2硬件(網絡)設計 對于某些需要從頭開始或性能改進顯著的軟件系統(tǒng),硬件建設是系統(tǒng)建設的重要一環(huán)。硬件(網絡)設計用網絡拓撲圖描述。 網絡拓撲圖主要由結點和鏈路構成。節(jié)點就是網絡單元,代表網絡系統(tǒng)中的各種數據處理設備、數據通信控制設備和數據終端設備,節(jié)點可以有不同的描繪形式。鏈路是兩個節(jié)點間的實際存在的通信連線,通常用無箭頭線描述。 較大型的局域網中通常會采用混合結構,以充分考慮用戶數據傳輸需求的情況下,發(fā)揮各種不同傳輸介質的性能,降低購置成本和使用成本。

17、 3.1.3 粗略設計3.應用系統(tǒng)設計 項目前期的應用系統(tǒng)粗略設計包括系統(tǒng)結構設計、功能結構設計和軟件配置設計。 3.1.3 粗略設計3.應用系統(tǒng)設計(1)系統(tǒng)結構設計 系統(tǒng)結構設計從項目管理者、高層管理者視圖,從物理構成角度反映未來系統(tǒng)的構成。系統(tǒng)結構設計依據業(yè)務分析的結果,反映未來軟件系統(tǒng)的大致統(tǒng)物理構成。一個完整的軟件系統(tǒng),既有執(zhí)行界面交互和業(yè)務處理的程序模塊、還有包括數據存儲的文件系統(tǒng)或數據庫系統(tǒng),以及信息輸出的表格、人工處理過程等等構成元素。 在結構化方法中,采用系統(tǒng)流程圖(名為流程,實際上不是流程而是構成)來描繪系統(tǒng)物理模型。系統(tǒng)流程圖表達的是軟件系統(tǒng)的物理構成以及系統(tǒng)各部件的流動

18、情況,而不是表示對信息進行加工處理的控制過程。各構成部件之間的連接是有向的,反映的是各部件之間的數據流向。 在面向對象方法中,通常采用組件圖來描述系統(tǒng)物理模型。需要注意的是,面向對象方法下的標準組件圖主要用于描述子系統(tǒng)、軟件包、組件等等的構成,沒有提供關于外部系統(tǒng)、人工處理過程、數據庫或文件系統(tǒng)、信息輸出的表格等等的標準描述元素,為了能夠達到與結構化方法下系統(tǒng)流程圖同樣的目標,開發(fā)人員可以借鑒系統(tǒng)流程圖,對組件圖模型描述元素自行擴充,以支持外部系統(tǒng)、人工處理過程、數據庫或文件系統(tǒng)、信息輸出表格的描述。 3.1.3 粗略設計3.應用系統(tǒng)設計(1)系統(tǒng)結構設計 3.1.3 粗略設計3.應用系統(tǒng)設計

19、(2)功能結構設計 功能結構是面向用戶視圖,以功能模塊構成的角度反映系統(tǒng)構成。功能結構設計要求將系統(tǒng)的功能進行分解,按照從大到小,從粗到細,從上到下,按功能從屬關系表示出來。功能結構體現的是包含關系,即上層功能包括 (或控制)下層功能,愈上層功能愈籠統(tǒng),愈下層功能愈具體。功能模塊可以根據具體情況分得大一點或小一點。分解得最小的功能模塊可以是一個程序中的某個處理過程,而較大的功能模塊則可能是完成某一任務的一組程序(子系統(tǒng))。通常用樹型的功能結構圖描述軟件系統(tǒng)的功能結構。 3.1.3 粗略設計3.應用系統(tǒng)設計(2)功能結構設計 3.1.3 粗略設計3.應用系統(tǒng)設計(3)系統(tǒng)配置設計/系統(tǒng)架構設計

20、系統(tǒng)配置設計反映重要軟件構件在網絡不同硬件系統(tǒng)中的分布配置。結構化方法下,系統(tǒng)配置設計往往用系統(tǒng)架構圖描述,在面向對象方法下,系統(tǒng)配置設計可以用系統(tǒng)架構圖,也可以用配置圖進行描述。配置設計可以直接在網絡拓撲圖上反映重要軟件的配置,也可以忽略網絡連接設備,只反映重要軟件的配置。如果忽略網絡連接設備,則配置設計往往可以構成橫向分層的計算模式圖描述。按照軟件系統(tǒng)計算任務的不同分布,將軟件系統(tǒng)劃分為以大型機為中心的集中計算模式、以服務器為中心的計算模式。 3.1.3 粗略設計3.應用系統(tǒng)設計(3)系統(tǒng)配置設計/系統(tǒng)架構設計 C/S模式下前端客戶(由微機或工作站承擔)主要負責GUI用戶界面程序和部分業(yè)務

21、,用戶通過GUI界面程序和軟件系統(tǒng)交互,可以輸入數據、運行服務器上的程序并得到計算結果;后端服務器部分(通常由微機或大型機承擔)負責數據存儲、管理以及必要的業(yè)務應用等負擔較重的工作,它接收客戶發(fā)來的信息、運行服務端功能并將運行結果返回給客戶機。根據客服機承擔任務的輕重,C/S模式可進一步分為胖客戶機模型和瘦客服機模型。在胖客戶機模型下,客服機負責顯示、業(yè)務處理過程,服務器只負責數據存儲和管理;在瘦客戶機模型下,客戶機只負責顯示處理,服務器負責業(yè)務處理過程、數據存儲與管理。如果將前端顯示、業(yè)務處理、數據管理和存儲分布在不同設施(但也可以分布在相同設施),則構成3層C/S模式。 3.1.3 粗略設

22、計3.應用系統(tǒng)設計(3)系統(tǒng)配置設計/系統(tǒng)架構設計 3層C/S模式將應用系統(tǒng)的邏輯合理地劃分出3層,保持了邏輯的相對獨立性,有利于提高系統(tǒng)的維護性和擴展性;能夠為各層選擇相應的平臺和應用系統(tǒng),實在處理負荷能力與處理特征上分別適應各層要求,并具有良好的可升級性和開放性;支持各層的獨立并行開發(fā),各層可以選擇不同開發(fā)語言;中間業(yè)務層屏蔽了客戶直接訪問數據庫的權利,整個具有較高的安全性。 3.1.3 粗略設計3.應用系統(tǒng)設計(3)系統(tǒng)配置設計/系統(tǒng)架構設計 B/S模式是指基于瀏覽器、WWW服務器、應用服務器(和/或數據庫系統(tǒng))的互聯(lián)網計算模式,B/S模式繼承和融合了傳統(tǒng)C/S模式中的網絡軟、硬件平臺和

23、應用,由于無須關心客戶機上的維護升級,只需關注服務端的WWW服務器、應用服務器(和/或數據庫系統(tǒng)),因此具有更加開放、應用開發(fā)速度快、生命周期長等特點,應用的安裝擴充和系統(tǒng)維護升級更為方便。B/S結構提供異種機、異種網、異種應用服務聯(lián)網和統(tǒng)一服務,具有最現實的開放性基礎。 3.1.3 粗略設計3.應用系統(tǒng)設計(3)系統(tǒng)配置設計/系統(tǒng)架構設計 系統(tǒng)構成圖(結構化思想下的系統(tǒng)流程圖,或面向對象思想下的組件圖)、功能結構圖、配置圖(結構化思想下的系統(tǒng)架構圖,或面向對象思想下的配置圖/系統(tǒng)架構圖)從不同角度反映系統(tǒng)的軟件部分的構成,系統(tǒng)構成圖(流程圖或組件圖)反映的是系統(tǒng)的全部軟件構成,包括程序、AP

24、I庫、中間件、數據存儲(文件系統(tǒng)或數據庫)和報表;功能結構圖則更為單純地描述系統(tǒng)軟件構成中用戶可見的功能(模塊);配置圖(系統(tǒng)架構圖或配置圖)主要反映重要的軟件系統(tǒng)或構件在網絡硬件環(huán)境中的安裝配置情況。 3.1.3 粗略設計3.應用系統(tǒng)設計(3)系統(tǒng)配置設計/系統(tǒng)架構設計 集中計算模式將軟件系統(tǒng)的絕大部分計算任務交由大型機承擔,不具備資源的終端通過硬件連線直接連接到主機或終端控制器上,終端只承擔簡單的結果顯示和輸入接口功能。 以服務器為中心的計算模式以服務器為中心,PC機工作站與大型機連接成局域網, 它進一步可分為客戶機/服務器計算模式(即C/S模式)和瀏覽器/服務器計算模式(即B/S模式)。

25、 3.1.3 粗略設計網絡配置圖 網絡拓撲圖和配置圖匯聚在一起4. 安全設計 安全設計主要反映系統(tǒng)安全保障體系的設計。進行系統(tǒng)的安全設計,首先必須擬定安全設計的依據、目標和原則,從管理和技術(包括物理層、網絡層、系統(tǒng)層和應用層)兩方面進行安全威脅分析。建立對系統(tǒng)提供保護的整體策略集合,即安全體系框架。規(guī)劃合適的安全域劃分,設計合理的安全技術體系和安全管理體系。 3.1.3 粗略設計5. 配套設計 配套設計主要反映機房配套設施的安裝設計。包括供配電規(guī)劃、UPS系統(tǒng)規(guī)劃、綜合布線和消防設計。 3.1.3 粗略設計進行項目前期的粗略設計,應遵循以下一些基本原則是:(1)首先以分層思想進行系統(tǒng)的體系結

26、構設計,給出系統(tǒng)全局的架構。(2)進行網絡硬件拓撲設計,應充分考慮用戶前期投資和未來需求,在延續(xù)性與適當先進性之間保持平衡。(3)應用系統(tǒng)粗略設計應從開發(fā)人員角度、用戶角度、維護管理人員角度出發(fā),分別建立他們所關心的不同模型。即保證有系統(tǒng)構成圖、功能結構圖和配置圖。 應用系統(tǒng)粗略設計不關心系統(tǒng)軟件構成。(4)安全設計應全面考慮系統(tǒng)面臨的各種威脅,在安全和成本之間進行平衡。(5)配套設計是粗略設計不可或缺的部分,對于未來系統(tǒng)的良好運行維護關系重大。(6)粗略設計階段的體系結構設計、網絡拓撲設計、應用系統(tǒng)設計、安全設計和配套設計給出的是從不同角度關于未來目標系統(tǒng)的總體設計。通常系統(tǒng)的體系結構設計、

27、網絡拓撲設計、安全設計和配套設計在項目確定后就保持穩(wěn)定、不再改變。但應用系統(tǒng)設計往往在項目需求分析后,需要根據需求分析結果,進行更準確的總體設計。 3.1.3 粗略設計可行性分析主要包括以下分析活動:(1)經濟可行性分析。(2)技術可行性分析。(3)運行、操作可行性分析。(4)法律可行性分析。 可行性分析最終要對以后的行動提出建議。如果問題沒有可行的解,分析人員應建議停止該項目,以避免造成進一步的浪費;如果問題值得解決,則提出并評價實現系統(tǒng)的各種可行的開發(fā)方案,從中選擇一種最佳方案,并為系統(tǒng)制定一個初步的開發(fā)計劃。3.1.4 可行性分析 由于系統(tǒng)是從空白開始,系統(tǒng)分析師在項目前期,分別進行了現

28、狀分析(忽略硬件分析,做了組織分析、業(yè)務分析,忽略現存軟件系統(tǒng)分析)、需求收集、粗略設計和可行性分析,并形成相應的結果。3.2 結構化的項目前期實例3.2.1 組織分析3.2.2 業(yè)務流程分析3.2.3 需求收集3.2.4粗略設計3.2.5 可行性分析3.2 結構化的項目前期名稱名稱符號符號含義含義方框部門無箭頭線部門之間的包含關系3.2.1 組織分析 組織模型的基本元素,主要有方框和無箭頭線,方框代表部門;無箭頭線表示各個部門之間的包含包含關系;建模組織機構時,應注意以下幾點:(1)組織機構模型是一個樹形的構成圖。(2)上層機構與被包含的下層機構之間,是“包含關系”,不應以箭頭線連接。(3)

29、無關的機構、崗位無須建模和描述。(4)可以對職能相似的部門、同一部門內職能類似的崗位進行合并。(5)組織機構圖只是簡略描述組織機構構成,對于不同機構的職能、內部構成以及崗位的職能應以更詳細的文字進行全面描述。3.2.1 組織分析 通過調研,系統(tǒng)分析師了解到圖書館的大致組織情況并進行建模。A 圖書館概況(略)B 圖書館組織機構圖(部分)3.2.1 組織分析(實例)C 機構職責機構職責C.1 參考咨詢部參考咨詢部C.1.1 部門概況部門概況 參考咨詢部是圖書館為加強學校的文獻信息保障能力,拓寬圖書館的信息服務功能設立的部門。主要圍繞學校教學科研活動,利用先進的信息服務手段,依靠圖書館豐富的館藏資源

30、以及良好的館際協(xié)作網絡,為校內外用戶提供各種咨詢服務。包括:科技查新、問題咨詢、學科服務、情報分析、檢索教學與讀者培訓、電子資源引進、整合及推介、館際互借與文獻傳遞服務等。C.1.2 部門職責部門職責 (1).負責讀者參考咨詢和教育部科技查新站的綜合管理與協(xié)調服務 (2).負責支持學校教學科研的學科服務,綜合協(xié)調學科服務工作。(3).負責支持學校教學科研的情報分析服務,綜合協(xié)調情報分析服務工作。(4).負責虛擬網絡咨詢,并與其他業(yè)務部門溝通與協(xié)調。(5).負責文獻檢索課的教學。(6).負責組織讀者培訓和新生入館教育。(7).負責電子資源的評估引進、揭示、推介和使用分析。(8).負責網絡資源的搜

31、集整理及導航建設。(9).負責校內外讀者原文索取和館際互借。(10).負責圖書館網站內容的維護和更新。(11).跟蹤國內外圖書館的最新發(fā)展,負責數字圖書館資源和服務的需求分析。 (12).負責本部門的設備管理和消防安全的相關工作。3.2.1 組織分析(實例)C.1.3 部主任崗職責部主任崗職責 (1).打開情報服務局面,提供優(yōu)質的情報服務。(2).主持本部的業(yè)務、行政工作并協(xié)助館黨政領導做好本部員工的思想政治工作,對本部工作職責所規(guī)定的各項工作任務及其執(zhí)行結果負全面責任。(3).規(guī)劃部門的發(fā)展,負責制訂本部的工作計劃并組織實施。 (4).不斷完善本部的崗位責任制,建立與健全各項規(guī)章制度;檢查本

32、部各項日常工作的執(zhí)行情況,及時解決出現的問題。(5).做好本部職工在職培訓與職業(yè)道德教育工作:制訂培訓計劃、組織培訓工作,定期考核效果。(6).檢查、指導本部職工的工作,定期進行考核;定期總結工作;打印統(tǒng)計報表,并向本部職工與館領導報告。(7).顧全大局,維護部門團結,搞好部門之間協(xié)調工作。(8).關心群眾生活,在力所能及的范圍內幫助職工解決實際困難。(9).完成館領導交給的其它任務。 C.1.4 信息服務崗信息服務崗1職責:職責:C.2 讀者服務部讀者服務部 3.2.1 組織分析(實例) 業(yè)務流程圖的基本元素,主要有泳道、行為、箭頭、表單。其中泳道代表組織結構中特定崗位; 行為是組織中特定崗

33、位的具體某個職能; 實心箭頭線表示各個不同職能之間的銜接關系,虛箭頭線表示每個職能的數據流入和流出; 表單是完成每個職能活動的數據流入和流出。 3.2.2 業(yè)務流程分析名稱符號含義泳道代表組織結構中特定崗位的責任行為崗位的具體某個職能箭頭線表示活動的順序關系虛箭頭線表示每個職能的數據流入和流出表單表示業(yè)務活動中的表格、單據業(yè)務流程圖的基本元素3.2.2 業(yè)務流程分析建模業(yè)務流程時,應嚴格遵循建模原則,以保證獲得規(guī)范、統(tǒng)一的業(yè)務流程模型。特別地,應注意以下幾點: 每個業(yè)務流程都是一個單獨的業(yè)務,可以獨立存在;為每個業(yè)務描述單獨的流程,流程反映活動的開始到結束,但不能同時反映業(yè)務流程的服務對象和業(yè)

34、務流程的發(fā)起者; 業(yè)務流程不能過于細化。業(yè)務流程中的單元活動以對應于組織機構模型中特定部門或部門內的崗位職能,最好以崗位職能為宜;未來業(yè)務流程中每個需要自動化的單元活動,都由完成事務的某個模塊來實現。 流程反映的是正常情況下的活動流轉,通常不應出現循環(huán)控制結構。業(yè)務流程通常只有一個開始活動,一個或多個結束活動,因此當業(yè)務存在可選路徑時,允許出現條件控制結構。3.2.2 業(yè)務流程分析業(yè)務流程可以單純只反映活動,也可以同時反映流程中的數據變化;活動流轉和數據輸入輸出應分別用不同類型的箭頭線描述,以體現活動流程變化和數據轉換;假如依據收集的臺帳來進行業(yè)務流程建模,通常一種臺帳就是一個完整的業(yè)務。如多

35、聯(lián)的倉庫的入庫單、出庫單就分別針對入庫業(yè)務、出庫業(yè)務;商場的多聯(lián)銷售單針對的是銷售業(yè)務;銀行的存款單、取款單、掛失單分別對應不同的業(yè)務。業(yè)務流程模型通常也需要輔以文字描述。業(yè)務流程圖能夠直觀地描述組織內不同業(yè)務活動的流程,但應輔以更詳細的文字進行全面描述。3.2.2 業(yè)務流程分析 圖書館的客戶主要包括讀者和圖書館內部人員。業(yè)務流程分析應從現實系統(tǒng)的客戶角度出發(fā),可以找出圖書館針對讀者的服務是其主要業(yè)務,包括借還書、讀者管理;輔助業(yè)務是圖書館為保障主要業(yè)務的實施達成而進行的業(yè)務活動,輔助業(yè)務包括:圖書采購、圖書入庫、圖書分類、圖書編目、圖書加工、圖書上架、查詢、圖書剔除等等。3.2.2 業(yè)務流程

36、分析(實例)1.卡片管理業(yè)務卡片管理業(yè)務(1)業(yè)務流程圖(2)步驟:讀者服務部接受讀者的卡片管理申請(開卡、繳回、掛失、解掛、變更),簽署審核意見。網絡中心根據審核意見,完成卡片管理。3.2.2 業(yè)務流程分析(實例)2 圖書流通業(yè)務圖書流通業(yè)務(1)業(yè)務流程圖(2)步驟:圖書流通業(yè)務包括借書、預定、還書和圖書報失幾種基本形式,步驟基本相同:讀者填寫業(yè)務單(借書單、預定單、還書單或報失單)。管理人員審核;根據不同業(yè)務進行不同業(yè)務流程選擇逾期還書或丟失圖書,打印賠償單;讀者到辦公室繳費;交回確認繳費的賠償單;確認業(yè)務單;3.2.2 業(yè)務流程分析(實例) 項目初期的需求,來源于業(yè)務分析、與用戶的交流

37、以及合理的測算。 目標系統(tǒng)的需求收集,應該包括業(yè)務需求、用戶需求、功能需求和系統(tǒng)需求,以豐富有效的方式,與客戶、領域專家、技術專家進行交流溝通。其中特別要注意以下幾點。 (1)系統(tǒng)的功能需求,主要來源于用戶和組織內不同崗位的業(yè)務需要,可以無須羅列具體的功能,這些內容,將在粗略設計中的應用系統(tǒng)設計中做更詳細的描述。 (2)與硬件購置有關的數據需求,必須盡量以歷史數據為基礎,選擇合適的方法進行推算。 (3)非功能性需求,是用戶對軟件質量屬性、運行環(huán)境、資源約束、外部接口等方面的要求或期望。 (4)用戶需求和系統(tǒng)需求通常不要求特定模型進行描述,主要是以文字形式進行描述的。3.2.3 需求收集參見教材

38、3.2.3 需求收集(實例)體系結構主要以縱向分層的形式反映整個軟件系統(tǒng)不同組件和它所依賴的網絡硬件設施之間的關聯(lián)關系。在體系結構中,并不考慮具體的組件構成和設施,而是從抽象角度考慮不同功能層次的組件和硬件設施之間的關聯(lián)關系。3.2.4粗略設計-系統(tǒng)體系結構設計 繪制體系結構圖,應嚴格遵循建模原則,以保證獲得規(guī)范、統(tǒng)一的模型。此外應注意以下幾點: 體系結構圖是一種抽象的分層組件功能和關系圖,并不反映具體系統(tǒng)的組件構成。 安全保障體系、資源管理維護體系通常貫穿從底層硬件到高層軟件組件的各個層次。 應用接口通常位于體系結構的最上層,網絡硬件處于最低層,數據存儲(文件系統(tǒng)、數據庫系統(tǒng))位于網絡硬件之

39、上。 體系結構圖應輔以詳細的文字描述。體系結構圖直觀,但不夠詳細,應以更為詳細的文字對系統(tǒng)各層的功能、大致構成進行描述。3.2.4粗略設計-系統(tǒng)體系結構設計3.2.4粗略設計-系統(tǒng)體系結構設計(實例) 網絡拓撲圖的基本元素為:通用交換機、服務器、互聯(lián)網、有線網絡、客戶終端、防火墻等等。3.2.4粗略設計-硬件(網絡)系統(tǒng)設計名稱符號含義通用交換機用于電(光)信號轉發(fā)的網絡設備服務器提供計算服務的設備互聯(lián)網表示互聯(lián)網有線網絡表示采用有線網絡的連接方式客戶終端表示計算機的顯示終端防火墻表示信息采用的防護系統(tǒng) 繪制網絡拓撲圖,應嚴格遵循建模原則,以保證獲得規(guī)范、統(tǒng)一的模型。還應注意以下幾點: 網絡拓

40、撲圖是重要設備的連接圖,不是具體的布線圖,不反映實際的網絡布線。網絡布線可視為硬件的詳細設計。 網絡拓撲圖中盡量用不同外觀的結點來描述系統(tǒng)中的重要設備。拓撲圖中的連線反映設備之間的連接關系,而不是數據流關系或控制關系,通常以無箭頭線描繪。 設備標注可以是具體的設備型號、系統(tǒng)軟件或設備功能。 網絡構成模型因輔以更詳細的文字描述。3.2.4粗略設計-硬件(網絡)系統(tǒng)設計3.2.4粗略設計-硬件(網絡)系統(tǒng)設計(實例)應用系統(tǒng)設計要給出未來目標軟件系統(tǒng)的大致框架。包括系統(tǒng)構成、功能構成和系統(tǒng)配置。分別用系統(tǒng)流程圖、功能結構圖和系統(tǒng)架構圖進行描述。3.2.4粗略設計-應用系統(tǒng)設計A 系統(tǒng)流程圖 系統(tǒng)流

41、程圖的作用,就是在抽象的黑盒級上描述系統(tǒng)內部的主要構成成份(例如硬設備、程序、文字及各類人工過程等),以及表達信息在各個成份之間流動的情況。3.2.4粗略設計-應用系統(tǒng)設計名稱符號含義處理能改變數據值或數據位置的加工或部件輸入/輸出表示輸入或輸出連接指從圖的另一部分轉來或轉到圖的另一部分去數據流向指明數據流動方向文檔通常表示打印輸出,或表示用打印終端輸入數據磁盤磁盤輸入輸出,或者表示存儲在磁盤上的文件或數據庫系統(tǒng)流程圖的主要基本元素A 系統(tǒng)流程圖繪制系統(tǒng)流程圖,應注意以下幾點: 盡量根據業(yè)務流程優(yōu)化后的新系統(tǒng)的工作流程為依據,繪制系統(tǒng)流程圖。 復雜系統(tǒng)可以用分層方法來表示系統(tǒng)構成。 系統(tǒng)流程圖

42、應輔以文字描述。3.2.4粗略設計-應用系統(tǒng)設計3.2.4粗略設計-應用系統(tǒng)設計(實例)A 系統(tǒng)流程圖B.功能結構模型功能結構模型從系統(tǒng)的功能角度反映系統(tǒng)構成。 3.2.4粗略設計-應用系統(tǒng)設計名稱符號含義功能代表一個功能或功能模塊連接表示包含關系功能結構圖的基本元素B.功能結構模型建模應注意以下幾點: 功能結構圖組織機構模型是一個樹形的構成圖。 上層模塊與被包含的下層子模塊之間,是“包含關系”,不應以箭頭線連接。 可以對關系密切但又不是包含關系模塊進行合并描述。 功能結構圖應輔以文字描述。 3.2.4粗略設計-應用系統(tǒng)設計B.功能結構模型3.2.4粗略設計-應用系統(tǒng)設計(實例)C.系統(tǒng)配置模

43、型系統(tǒng)配置圖是用來顯示系統(tǒng)中軟件和硬件的物理架構。系統(tǒng)配置模型應注意以下幾點: 系統(tǒng)配置模型反映的是系統(tǒng)中重要軟件在網絡上的分布配置情況,因此應該和網絡拓撲圖結合在一起,可以加上,也可以省略網絡鏈接設備。 配置圖反映的是組件在網絡上的分布情況,并不反映調用或其他關系,因此設備之間的連接線依然是網絡拓撲中的物理鏈接。是無箭頭的連線。 為更詳細描述系統(tǒng)軟件或組件分布,模型應輔以文字描述。3.2.4粗略設計-應用系統(tǒng)設計C.系統(tǒng)配置模型3.2.4粗略設計-應用系統(tǒng)設計(實例)3.2.4粗略設計-安全設計(見附錄1)3.2.4粗略設計-軟件配套設計A.可行性分析(1)政策可行性(2)經濟可行性(3)技

44、術可行性(4)信息化基礎可行性(5)人力資源可行性分析B.社會效益分析C.經濟效益分析 3.2.5 可行性分析3.3.1 組織分析(略)3.3.2 業(yè)務流程分析3.3.3 需求收集3.3.4粗略設計3.3.5 可行性分析3.3 面向對象的項目前期實例3.3.1 組織分析(略) 面向對象方法下的業(yè)務流程分析,用業(yè)務用例圖反映現實系統(tǒng)為用戶提供的服務。業(yè)務用例圖從用戶的角度描述系統(tǒng),它匯聚了系統(tǒng)向外界提供的所有服務,由業(yè)務用例、業(yè)務角色、以及它們之間(業(yè)務角色與業(yè)務用例、業(yè)務角色之間、業(yè)務用例之間)的關系組成。一個業(yè)務用例圖可以反映組織向外界提供的所有服務;而業(yè)務用例圖中的業(yè)務角色就是各個業(yè)務流程

45、的服務接受對象。3.3.2 業(yè)務流程分析 每個業(yè)務用例是從用戶角度描述系統(tǒng)向外界提供的一個服務,它將服務描述成一系列跨越多個崗位的事務,這些事務最終滿足用戶需要。業(yè)務角色是接受服務的實體,未來他可能參與和系統(tǒng)的交互,也可能不參與和系統(tǒng)的交互。 在UML中,業(yè)務角色使用帶斜杠的人形符號表示,并且具有唯一性的名稱;用例用帶斜杠的橢圓表示,且具有唯一的名稱。業(yè)務角色和業(yè)務用例之間使用帶箭頭的實線連接,由業(yè)務角色指向業(yè)務用例,表示業(yè)務角色發(fā)起或獲得服務。3.3.2 業(yè)務流程分析 3.3.2 業(yè)務流程分析名稱符號含義業(yè)務角色指接受服務的實體或服務的發(fā)起者業(yè)務用例指業(yè)務本身關系表示業(yè)務角色發(fā)起或獲得服務業(yè)

46、務用例圖的基本元素如下表所示 每個業(yè)務用例的細節(jié),可以進一步用活動圖進行描述?;顒訄D中的活動是展示整個業(yè)務用例的控制流(及其操作數),執(zhí)行的步驟可以是并發(fā)的或順序的。業(yè)務用例的活動圖,就對應于結構化方法下的業(yè)務流程圖。 活動圖由實心圓表示的開始節(jié)點出發(fā),到外包實心圓的終止節(jié)點結束,中間是一系列的圓角矩形表示的動作系列。動作之間用箭頭線連接,表示動作的遷移,箭頭線上可以附加警戒條件、發(fā)送子句或動作表達式?;顒訄D可以根據活動發(fā)生位置的不同,劃分為若干個矩形區(qū)域,每個矩形區(qū)稱為泳道。 在業(yè)務用例的活動圖中,泳道對應于某個組織機構的崗位,反映該崗位在業(yè)務流程中承擔的責任;活動圖中的操作,不應過于細化,

47、最好體現為一個完整的事務操作。未來這個操作,將由一組關聯(lián)業(yè)務對象的一些方法來實現。3.3.2 業(yè)務流程分析 3.3.2 業(yè)務流程分析名稱符號含義初始節(jié)點表示活動的開始活動終點表示活動的結束活動節(jié)點表示一個活動轉換控制流的轉向分支表示一個轉換進入,有一個或多個轉換離開并發(fā)多個活動同時進行業(yè)務用例的活動圖的基本元素描述建模業(yè)務用例模型,應注意以下幾點: 每個業(yè)務用例是“業(yè)務用例類”的一個對象,每個業(yè)務角色是“業(yè)務角色類”的一個對象,因此業(yè)務用例圖從理論上來說是一個對象模型,是具體系統(tǒng)的業(yè)務呈現; 業(yè)務角色是接受業(yè)務服務的對象,可以是人,也可以是硬件設施或外部系統(tǒng)。業(yè)務角色可能與擬建的目標系統(tǒng)交互,

48、也可能不與目標系統(tǒng)交互; 以業(yè)務用例圖描述整個系統(tǒng)的業(yè)務概況;為每個業(yè)務用例描述單獨的流程,流程反映活動的開始到結束,業(yè)務角色是業(yè)務流程的服務對象,業(yè)務流程中的泳道是業(yè)務流程的操作者; 業(yè)務用例的流程不能過于細化。業(yè)務用例流程中的單元活動以對應于組織機構模型中特定部門或部門內的崗位職能,最好以崗位職能為宜;業(yè)務用例流程中未來每個需要自動化的單元活動,都由完成事務的某個模塊來實現。 業(yè)務用例流程反映的是正常情況下的活動流轉,通常不應出現循環(huán)控制結構。 假如依據收集的臺帳來進行業(yè)務用例流程建模,通常一種臺帳就是一個完整的業(yè)務用例。 業(yè)務用例模型通常也需要輔以文字描述。3.3.2 業(yè)務流程分析3.3.2 業(yè)務流程分析(實例)1.卡片管理業(yè)務(1)活動圖:(2)流程步驟: 讀者服務部接受讀者的卡片管理申請(開卡、繳回

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論