軟件設(shè)計是怎樣煉成的(2)——優(yōu)秀設(shè)計從分析需求開始

摘要:

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供虹口網(wǎng)站建設(shè)、虹口做網(wǎng)站、虹口網(wǎng)站設(shè)計、虹口網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、虹口企業(yè)網(wǎng)站模板建站服務(wù),十年虹口做網(wǎng)站經(jīng)驗(yàn),不只是建網(wǎng)站,更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

設(shè)計應(yīng)該針對需求來做,這個大道理似乎人人都懂,但實(shí)際操作時往往就不是這樣。所以我們也不說大道理,直接通過一個“很簡單”的案例來體驗(yàn)一下優(yōu)秀設(shè)計應(yīng)該如何從分析需求開始,體驗(yàn)架構(gòu)設(shè)計是如何全面考慮各種需求、項(xiàng)目的工期限制預(yù)算限制,還有項(xiàng)目組人員水平后做出來的。

大綱:

1.什么是優(yōu)秀的設(shè)計?
2.優(yōu)秀的設(shè)計能節(jié)省項(xiàng)目工作量
3.優(yōu)秀設(shè)計從分析需求開始
4.軟件系統(tǒng)不是木桶型的
5.軟件設(shè)計的“大道理”
6.規(guī)劃系統(tǒng)骨架——架構(gòu)設(shè)計
7.打造系統(tǒng)的底蘊(yùn)——數(shù)據(jù)庫設(shè)計
8.細(xì)節(jié)決定成敗——詳細(xì)設(shè)計
9.用戶感覺好才是真的好——用戶體驗(yàn)設(shè)計
10.持續(xù)提升設(shè)計水平

本文章是系列文章之一,如果你還沒有看過之前的文章,建議先看完前面的文章再看本篇,這樣效果更好。

3.優(yōu)秀設(shè)計從分析需求開始

設(shè)計應(yīng)該針對需求來做,這個大道理似乎人人都懂,但實(shí)際操作時往往就不是這樣。所以我們 也不說大道理,直接通過一個“很簡單”的案例來體驗(yàn)一下優(yōu)秀設(shè)計應(yīng)該如何從分析需求開始。

3.1 案例挑戰(zhàn):考勤系統(tǒng)的軟件設(shè)計

某公司要做一個內(nèi)部用的考勤系統(tǒng),希望達(dá)成以下目標(biāo):

1)規(guī)范員工的上下班、請假、外出工作等行為。
2)方便計算員工的薪金。
3)方便管理各種帶薪假期。

你如何考慮本系統(tǒng)的設(shè)計呢?

你可能會說:我靠,才三句話的需求,怎樣做設(shè)計呢?

說得太好了!我們做軟件設(shè)計的,第一步并不是直接去設(shè)計,而是分析需求!

3.2 如何分析需求?

當(dāng)你接受一個項(xiàng)目的設(shè)計任務(wù)時,可能會遇到比較尷尬的情況,那就是需求有問題!

具體的情況可能有:

a)需求很簡單,幾句話或者是一頁紙的需求。
b)需求很詳細(xì),可能有幾十頁甚至上百頁,這些需求是招標(biāo)書中提供的,或者是客戶直接提供的。不要以為有這么多需求是好事,這些需求通常是前后有點(diǎn)矛盾、邏輯有點(diǎn)混亂,甚至是不知所云滴!

c)你們有專門的部門或者專職完成了需求工作,提供了一份需求文檔。你也不要以為這是好事,因?yàn)楹芸赡軙霈F(xiàn)這樣的情況:需求文檔的提供者認(rèn)為自己寫的需求文檔很牛逼,水平很高;但負(fù)責(zé)實(shí)現(xiàn)的開發(fā)部門認(rèn)為該文檔質(zhì)量太差,比方說:不考慮實(shí)現(xiàn)的可能性和難度,沒有考慮到客戶的真正需求等等。有時候甚至出現(xiàn)開發(fā)部門忽略掉需求部門,直接找客戶重新調(diào)研,重新編寫需求文檔的情況。

上述三種情況一句話總結(jié)就是:需求的質(zhì)量有問題!

我們需要重新分析一次需求,先從業(yè)務(wù)角度審視一次,然后再從軟件設(shè)計的視角審視一次。通常我們需要按順序思考以下問題:

1)什么人會使用這個系統(tǒng)?
2)不同的人將會使用這個系統(tǒng)的什么功能?

3)還有哪些不確定或不具體的需求點(diǎn)?
4)哪些需求對技術(shù)提出了怎樣的要求?
5)系統(tǒng)的大致架構(gòu)應(yīng)該如何考慮?

下面開始我們看幾個圖,按順序逐一思考一下上述的幾個問題。本小節(jié)回答問題1、2,后面的小節(jié)回答其他問題。

1)什么人會使用這個系統(tǒng)?

不少技術(shù)人員分析需求時往往是技術(shù)的視角,當(dāng)你問他系統(tǒng)有什么用戶時,你可能得到的結(jié)果有兩種:

a)沒有什么用戶啊,所有人都是用戶,因?yàn)橄到y(tǒng)只需要配置一下權(quán)限,誰都可以用。
b)系統(tǒng)有兩種用戶,就是:用戶和管理員。

我們從業(yè)務(wù)的角度來審視一下考勤系統(tǒng)的可能用戶,請看下圖:

軟件設(shè)計是怎樣煉成的(2)——優(yōu)秀設(shè)計從分析需求開始

圖2.1 系統(tǒng)可能用戶分析

此圖列出了如下可能用戶:

employee:員工
finance:財務(wù)
receptionist:前臺
manager:經(jīng)理
senior manager:高級經(jīng)理
administrator:管理員

而上述用戶還有這樣的關(guān)系:finanace(財務(wù))、receptionist(前臺)、manager(經(jīng)理)繼承employee(員工);senior manager(高級經(jīng)理)繼承manager(經(jīng)理)。

用戶之間的繼承關(guān)系,是什么意思呢?

我們都知道代碼中B類(子類)繼承A類(父類),子類就具備了父類的特點(diǎn)。用戶之間的繼承關(guān)系是相同的意思,我們繼續(xù)看看下圖你就可以理解了。

下圖將會回答這個問題:

2)不同的人將會使用這個系統(tǒng)的什么功能?

軟件設(shè)計是怎樣煉成的(2)——優(yōu)秀設(shè)計從分析需求開始

圖2.2 系統(tǒng)的需求分析

圖2.1和圖2.2都是UML的用例圖,兩個圖加在一起比較完整系統(tǒng)地表達(dá)了以下問題:

a)什么角色會用本系統(tǒng)?
b)這些角色通過本系統(tǒng)分別能干什么事情?
c)角色之間有可能會有繼承關(guān)系,請留意父類能干的事情,子類也能干,例如:employee可以打卡,manager也可以打卡,盡管圖2.2中manager沒有直接與”打卡“相連,但圖2.1中已經(jīng)說明了manager繼承employee。

UML是需求分析的有力工具,我的工作中很喜歡用UML。但你的工作中、你的需求文檔中可能會沒有UML圖,不管你們是否用UML圖,分析需求時都需要從業(yè)務(wù)的角度思考這些問題:

a)什么人(角色)會用這個系統(tǒng)?
b)這些人(角色)分別需要用系統(tǒng)的什么功能?

需求分析其實(shí)是一個負(fù)責(zé)的高難度的話題,回答上述兩個問題僅僅是需求分析的第一步而已,我們還需要深入分析業(yè)務(wù),包括業(yè)務(wù)流程、業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)等等。如果之前的需求工作不到位,就需要我們立馬開展軟件設(shè)計工作,其實(shí)將會埋下很多地雷,后患無窮。關(guān)于需求分析的更多分享,請留意我的其他文章,或者買一本我的書籍《火球——UML大戰(zhàn)需求分析》看看(廣告一下,哈哈)。

3.3 找出設(shè)計關(guān)注點(diǎn)

本小節(jié)我們回答這兩個問題:

3)還有哪些不確定或不具體的需求點(diǎn)?
4)哪些需求對技術(shù)提出了怎樣的要求?

軟件設(shè)計師需要有敏銳的需求及設(shè)計觸覺,看著圖2.1和圖2.2 嗅出一些問題,你能嗅出一些問題嗎?

請看下圖:

軟件設(shè)計是怎樣煉成的(2)——優(yōu)秀設(shè)計從分析需求開始

圖2.3 系統(tǒng)的設(shè)計點(diǎn)分析

圖2.3主要從設(shè)計的視角對需求再進(jìn)行一次審視,以下是一些建議:

a)你需要更加深入思考需求,考慮到各種不同的業(yè)務(wù)場景和特殊情況,例如:領(lǐng)導(dǎo)不在公司時如何審批請假?
b)你需要思考需求的細(xì)節(jié),例如:報表的具體形式?
c)你需要思考各種技術(shù)方案,例如:打卡數(shù)據(jù)的同步方案,財務(wù)軟件是否要對接等等?
d)你要做出平衡,用合適的方案和盡量少的工作量來滿足需求。

3.4 針對需求做初步的架構(gòu)設(shè)計

本小節(jié)將會回答這個問題:

5)系統(tǒng)的大致架構(gòu)應(yīng)該如何考慮?

接下來你要做初步的架構(gòu)設(shè)計了,架構(gòu)設(shè)計是難度很高的事情,需要你全面考慮需求,考慮工期限制預(yù)算限制,考慮項(xiàng)目組人員的水平,而做出的一種平衡。請看下圖:

軟件設(shè)計是怎樣煉成的(2)——優(yōu)秀設(shè)計從分析需求開始

圖2.4 系統(tǒng)架構(gòu)的考慮

圖2.4是UML的部署圖,這個圖比較粗糙,而且為了降低大家閱讀難度,我僅僅是用了部署圖的最基本最少的語法來表達(dá)。

圖2.4中的每一個立體的矩形,表示的就是物理上或者是邏輯上的一臺設(shè)備,設(shè)備之間 有物理連接的話就用線條連接,每臺設(shè)備中”{ }“括起來的文字是對該設(shè)備的進(jìn)一步說明。

圖可能是表達(dá)設(shè)計的最好方式,建議大家用UML,表達(dá)系統(tǒng)架構(gòu)時,用UML的部署圖、組件圖和包圖是比較合適的。我們設(shè)計的系統(tǒng)多數(shù)是分布式系統(tǒng),不是單機(jī)系統(tǒng),用部署圖來表達(dá)分布式系統(tǒng)的架構(gòu)設(shè)計可能是比較合適的。

圖2.4針對圖2.3中提出的問題進(jìn)行了初步的回應(yīng),圖2.4 就是一個初步的架構(gòu)設(shè)計,當(dāng)然后續(xù)我們還需要繼續(xù)細(xì)化這個設(shè)計。

3.5 小結(jié):如何需求驅(qū)動設(shè)計?

本篇的例子告訴我們:

1)優(yōu)秀的設(shè)計是需要從分析需求開始的。
2)需求的質(zhì)量可能有問題,那么我們需要從業(yè)務(wù)的角度重新審視一次。
3)從設(shè)計的角度審視需求,我們會提出很多需求細(xì)化及設(shè)計方案的問題。
4)架構(gòu)設(shè)計是全面考慮各種需求、項(xiàng)目的工期限制預(yù)算限制,還有項(xiàng)目組人員水平后綜合做出來的一種平衡。

本文是系列文章的第2篇,要做軟件設(shè)計師一點(diǎn)都不簡單啊,請留意后續(xù)文章!


作者:張傳波

創(chuàng)新工場創(chuàng)業(yè)課堂(敏捷課程)講師

軟件研發(fā)管理資深顧問

CMMI首席專家

《火球——UML大戰(zhàn)需求分析》作者

www.umlonline.org創(chuàng)辦人

網(wǎng)頁名稱:軟件設(shè)計是怎樣煉成的(2)——優(yōu)秀設(shè)計從分析需求開始
分享地址:http://muchs.cn/article18/ijdjdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供靜態(tài)網(wǎng)站、微信小程序App開發(fā)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈面包屑導(dǎo)航

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

商城網(wǎng)站建設(shè)