軟件項目管理在小軟件項目中的應(yīng)用(編輯修改稿)
2025-05-09 00:48 本頁面
【文章內(nèi)容簡介】 慮，調(diào)查產(chǎn)品的潛在市場有多大，另一方面是從技術(shù)的角度，必須了解清楚潛在用戶對軟件的各種技術(shù)上的要求，例如，用戶現(xiàn)有硬件配置如何，軟件配置如何，使用什么網(wǎng)絡(luò)，使用什么數(shù)據(jù)庫等等，根據(jù)調(diào)查的統(tǒng)計結(jié)果決定即將開發(fā)的軟件的一些技術(shù)指標。 5 為了比較好地與用戶進行交流，使用一些工具是很有好處的。為了討論用戶界面，可以用 VB, delphi 等做一個原型，根據(jù)原型有針對性地與用戶討論需求。(原型開發(fā)不僅僅可以用于準確獲取用戶的需求，開發(fā)出來的原型本身可以作為下一步開發(fā)的基礎(chǔ)，增量式地完成開發(fā) ) 為了討論軟件運行的流程，可以采用 UML③ 的 Use Case 圖 ④ 。 需求分析 在了解用戶的需求之后，將需求用一種模型來表示，就是需求分析，目前比較流行的 分析方法是面向?qū)ο蟮姆椒?，通過分析用戶需求，用類、類之間的各種關(guān)系來表示整個系統(tǒng)。 這部分涉及到具體的方法，在此不詳細討論，但是原則上是提取類 類之間關(guān)系 ,可能需要不斷修改而形成一份分析文檔。 設(shè)計過程 設(shè)計階段的工作包括 ： 對分析模型必要的修改?？赡苄枰獙δ承╊惤Y(jié)構(gòu)進行一些修改，這些修改的原因可能是編程環(huán)境的要求，或者為了重用 以前的某些工作。定義界面部分、數(shù)據(jù)訪問 (數(shù)據(jù)庫 )部分。 由于目前很多編程語言都可以可視化地設(shè)計界面，所以界面部分工作往往留到了編碼階段來完成。于是設(shè)計階段的工作量并不大。 編碼 進入編碼工作之后，可能會發(fā)現(xiàn)前面分析或設(shè)計階段的某些錯誤，這時應(yīng)返回到前面的階段進行必要的修改。 測試 如前所述，即使是小項目，也應(yīng)該嚴格地進行測試。 24 需要強調(diào)幾個問題 一、是要分清問題域與系統(tǒng)責(zé)任。 系統(tǒng)責(zé)任是指所要開發(fā)的軟件應(yīng)該完成的功能，而問題域是包含所有相關(guān)的部分。例如你要開發(fā)一個程控機計費程序，程控機已經(jīng)是現(xiàn)成，輸出的數(shù)據(jù)格式也已經(jīng)是固定的，你的程序僅僅需要從程控機中讀取相應(yīng)的信息，那么，程控機在你的系統(tǒng)里只是一個外部的東西，把它作為一個類也許就是不必要的，僅僅需 6 要一個類來完成讀數(shù)據(jù)的操作。又如，你需要在一個已經(jīng)存在的數(shù)據(jù)庫上開發(fā)一些應(yīng)用，數(shù)據(jù)庫的格式已經(jīng)固定，并且已經(jīng)有一個后臺程序在運行，你需要開發(fā)一個新的前臺程序，這時，服務(wù)器程序?qū)δ銇碚f就是一個外部的東西。但是，象這種外部的內(nèi)容必須在分析文 檔中有一些說明，作為系統(tǒng)的外在約束。 二、是需求獲取與需求分析的關(guān)系。 用什么方法來完成需求的獲取，在很大程度上影響了需求分析的做法。例如當初采用 Use Case 來表示用戶需求，那么從各種序列圖中選出相互交互的各個實體，就是一個個類。 三、是分析與設(shè)計過程的銜接。 分析過程的內(nèi)容是用類的結(jié)構(gòu)來表示目標系統(tǒng)，并不設(shè)計具體實現(xiàn)，如采用什么編程 語言，在什么操作系統(tǒng)平臺上運行等等。這些具體實現(xiàn)是在設(shè)計階段來完成的。面向?qū)ο蠓椒ǖ膬?yōu)點是分析、設(shè)計、編碼過程表示法統(tǒng)一，能比較好的銜接。但是，是把分析和設(shè) 計階段 分開，采用瀑布式開發(fā)，還是采用其他方式，要看具體的情況。 對于需求潛在變化不大的項目，可以采用瀑布模型，有一個很明顯的設(shè)計階段，這樣做的好處是有一份比較完整的分析文檔，這樣以后如果需要采用不同的編程語言、或者采 用其他的平臺時，便可以以這份分析文檔作為開發(fā)的基礎(chǔ)。 對于需求變化頻繁的項目，可能采用少量分析 。少量設(shè)計少量編碼測試的方式更合適，而且隨時可能要返回到前面某個一階段去進行修改。但是這意味著可能沒有一份完整的分析文檔。 現(xiàn)在很多 CASE
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1