2007年4月5日
#
應用開發(fā)的思考2
我發(fā)現(xiàn)多數(shù)需求分析說明書編寫得毫無價值,多數(shù)公司的做法是寫完該需求說明書之后,就把它扔一邊,埋頭苦干寫程序了.一方面這和公司對需求分析的認識不夠有關,另一方面,也和需求分析編寫方式不盡合理,以至它的價值難以體現(xiàn)有關.
軟件程序,從最終的抽象意義而言,是計算機系統(tǒng)對自然語言的翻譯.而需求分析充當了翻譯任務的急先鋒.很難想象,如果沒有一份好的需求說明書,針對客戶含糊不清的自然語言描述,開發(fā)者能做出一個符合要求的優(yōu)秀軟件.然而,什么是好的需求說明書?應具備什么樣的特點?我認為好的需求說明書應有由如下三個階段,經多次循環(huán)反饋而逐漸形成:
1 調研階段:
客戶和需求分析師討論系統(tǒng)該具有的功能.客戶希望系統(tǒng)能做什么,達到什么樣的效果.需求分析師的責任是認真聽取客戶的原始言語,通過討論,語言的提煉和客戶達成共識,最終得到確切的需求--客戶希望系統(tǒng)能做什么.這一過程運用的是自然語言,需求分析師必須具備良好的溝通能力,文字表達能力,并且必須具備客戶領域內的相關業(yè)務知識,不使用用戶不懂的計算機專業(yè)詞匯.
參與人員:需求分析師,客戶,系統(tǒng)設計師.
運用工具:自然語言.
階段成果:調研記錄書.
2 確定功能結構和設計系統(tǒng)原型:
需求分析師和系統(tǒng)設計師討論客戶的需求.需求分析師針對調研階段的記錄,逐點提出客戶需求,并用uml的用例概念,和系統(tǒng)設計師進行討論.系統(tǒng)設計師根據這些需求,運用他的技術,知識和經驗,將之分解總結為系統(tǒng)的功能結構.(此處僅針對應用系統(tǒng)而言,對于其他系統(tǒng),可能還要總結進程結構或部署結構)得到功能結構之后,系統(tǒng)設計師還要構建系統(tǒng)原型,該原型用于和客戶進行更好的交流.
在這一階段之后,由于得到了功能分解表和系統(tǒng)原型,需求分析師和系統(tǒng)設計師已明白系統(tǒng)的雛形,該成果將作為開發(fā)者和客戶繼續(xù)進行討論的基礎.
參與人員:需求分析師,系統(tǒng)設計師(或該設計師領導的相關團隊).
運用工具:uml,構建原型的相關工具技術.
階段成果:功能分解表,系統(tǒng)原型.(大致的業(yè)務流程圖)
3 編寫需求分析說明書
在參照功能分解表和系統(tǒng)原型的基礎上,需求分析師和系統(tǒng)設計師編寫系統(tǒng)的需求分析說明書.該需求分析說明書作為客戶和系統(tǒng)開發(fā)者的橋梁,既表達了客戶想要系統(tǒng)做什么的愿望,又反映了系統(tǒng)開發(fā)者針對此需求得到的努力成果(功能分解表和系統(tǒng)原型).通過該說明書,對系統(tǒng)具有的功能和最終可能的形態(tài),客戶和開發(fā)者達成共識.
有可能經過多次的1,2階段的反復,最終才得到需求分析說明書.各階段的成果應妥善保存.
參與人員:需求分析師,系統(tǒng)設計師,客戶.
運用工具:自然語言,功能分解表,系統(tǒng)原型.
階段成果:改進的功能分解表,系統(tǒng)原型,(業(yè)務流程圖),需求分析說明書.
第1階段,是開發(fā)者得到自然語言需求的階段.該階段的重要性不言而喻.
第2階段,是需求分析編寫的核心階段.很多公司會有意無意忽略該階段.確實,該階段耗費的人力和時間挺多,但這個階段決不能馬虎的進行,甚至忽略.只有詳盡的將自然語言翻譯成功能需求表,并為此構建原型,開發(fā)者對系統(tǒng)究竟能做什么和未來該怎么做的認識才會逐漸加深.并且,對應的功能界面,能夠讓客戶大致認識到最終的系統(tǒng)會是什么樣子.他能夠據此提出自己的滿意度,修改或者增加需求.
我主張在構建功能分解表的時候,將界面的相關控件,字段,標簽都一一列出,并且和原型的界面相對應.這樣在功能分解表/需求分析說明書確定之后,開發(fā)者就有可能根據這些控件/字段/標簽確立業(yè)務層的接口和數(shù)據庫系統(tǒng)的表結構,減少了概要設計階段所作的工作量.
以下是一個分解功能的例子:
功能:修改我的資料
功能簡述:用戶可以更新個人資料
界面控件:姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本框(輸入確認密碼),所屬組別選擇框 (輸入所屬組別),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
界面:見圖(修改我的資料)
只有經過詳盡完備的1,2階段后,我們才可能進行第3階段,將1,2階段的成果綜合起來,和客戶進一步討論需求.客戶可能會對功能分解不滿意,對原型有異議.這樣我們必須返回到1,2階段,再次分解功能,修改原型.直到客戶滿意為止.
在這個基礎上,我們才可能編寫最終的需求說明分析書.我認為,嚴格按照上述流程進行編寫的需求說明書,就是好的.它的特點總結如下:
1)經歷過反復功能分解和原型構建.客戶因原型而清楚認識到自己想要系統(tǒng)的形態(tài),開發(fā)者經多次反饋明確了系統(tǒng)所具備的功能.
2)編寫良好的功能分解表,能夠幫助開發(fā)者進一步設計業(yè)務接口.
3)構建成型的原型,有助于開發(fā)者設計數(shù)據庫系統(tǒng).
4)*明確的業(yè)務流程圖,能夠協(xié)助開發(fā)者構建系統(tǒng)的業(yè)務流.
用戶的需求永遠在變化,沒錯.但如果我們按照上述步驟努力在分析階段弄清楚客戶的需求,以后的開發(fā)維護階段就能將需求變更的代價降到最低.只有對事物認識越深刻,才越有可能認識到事物可能存在的變化.這條哲學法則在需求分析階段同樣適用.
經過以上討論,我們就可以看到為什么多數(shù)公司的需求分析書難以達到預期要求.它們沒有功能分解階段,沒有原型構建階段,沒有反饋認識再加深的階段....這樣的需求分析書,僅僅為構建而構建,對系統(tǒng)的開發(fā)毫無幫助.(我還看到過有人用三天寫完一個系統(tǒng)的需求分析書)接踵下去的軟件開發(fā)階段,如何進行?這樣做出來的軟件,能好到哪里去?
一點淺見,貽笑方家. :-)
1 引言
1.1 編寫目的
本說明書是客戶與軟件系統(tǒng)開發(fā)者的溝通橋梁.客戶根據需求說明書提出需求,闡述系統(tǒng)能做什么.軟件系統(tǒng)開發(fā)者根據此需求,闡述需求實現(xiàn)的功能與界面,并將之清晰明白的反映到本說明書中,以供客戶審閱.
本說明書的預期讀者為客戶,業(yè)務需求分析人員,系統(tǒng)設計人員,項目管理人員,軟件開發(fā)人員等系統(tǒng)開發(fā)的相干參與者.
1.2 項目背景
軟件開發(fā)過程中無可避免的存在源碼缺陷(以下簡稱BUG).在軟件系統(tǒng)的開發(fā)維護階段階段,對BUG的修復管理工作必不可少.本系統(tǒng)提供了bug的管理功能.客戶可應用本系統(tǒng)簡單有效的管理BUG,以協(xié)助軟件系統(tǒng)的開發(fā)維護工作.
1.3 定義,縮寫詞和符號
BUG:軟件系統(tǒng)在功能或界面方面所產生的缺陷.
2 系統(tǒng)運行環(huán)境
2.1 硬件環(huán)境
2.1.1 一臺586微機,建議CPU主頻在500MHZ以上,內存大于512MB.
2.2 軟件環(huán)境
2.2.1 WINDOWS 或類 LINUX 操作系統(tǒng).該操作系統(tǒng)應能正常運行JAVA虛擬機.
2.2.2 安裝IE6或FIREFOX1.5瀏覽器
2.2.3 安裝J2SDK,要求版本在1.4以上.
2.2.4 安裝TOMCAT或其他支持SERVLET 2.3 的WEB 服務器.
2.2.5 安裝MYSQL數(shù)據庫.要求版本在5.0以上.
3 系統(tǒng)用例說明
3.1 系統(tǒng)用例說明
3.1.1 用例名稱:用戶查看BUG列表
用例編號:1
用例說明:用戶點擊"查看我的BUG"標簽,查看屬于自己的BUG列表.或者點擊"查看所有BUG"標簽,查看所有BUG列表.并能根據自定 義的條件過濾器,查看符合特定條件的BUG.
前置條件:用戶已登錄系統(tǒng).
3.1.2 用例名稱:用戶查看BUG詳情
用例編號:2
用例說明:在BUG列表上存在HTML鏈接,用戶點擊該鏈接,可以看到BUG的詳細情況.并且用戶可以修改BUG的狀態(tài),修改時間.
前置條件:用戶已登錄系統(tǒng)
3.1.3 用例名稱:用戶增加新BUG
用例編號:3
用例說明:用戶點擊"增加新的BUG"界面,進入增加新BUG界面.可以增加新的BUG到系統(tǒng).
前置條件:用戶已登錄系統(tǒng)
3.1.4 用例名稱:用戶管理BUG列表過濾器
用例編號:4
用例說明:用戶可以增刪改BUG條件過濾器.在BUG列表中,可以通過選取過濾器查看符合特定條件的BUG(請參照用例1).
前置條件:用戶已登錄系統(tǒng).
3.1.5 用例名稱:用戶修改個人資料
用例編號:5
用例說明:用戶可以修改個人資料,例如修改EMAIL,住址等.
前置條件:用戶已登錄系統(tǒng).
3.1.6 用例名稱:用戶管理帳號
用例編號:6
用例說明:系統(tǒng)管理員可以增刪改新的用戶.
前置條件:用戶已登錄系統(tǒng),且該用戶必須是系統(tǒng)管理員.
3.1.7 用例名稱:用戶管理開發(fā)組
用例編號:7
用例說明:系統(tǒng)管理員可以增刪改開發(fā)組.在增加新BUG界面,該組名用于劃分BUG的歸屬.
前置條件:用戶已登錄系統(tǒng),且該用戶必須是系統(tǒng)管理員.
3.2 簡單的用例圖
見圖:
4 系統(tǒng)功能分解
4.1 BUG管理
4.1.1 列出我的BUG
功能簡述:以分頁的列表方式列出指派給我的bug,可以選擇某條記錄進行修改,可以彈出框形式查看bug詳情.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改)
界面標簽(指Label):可選項,序號,概述,緊急程度,狀態(tài),所有人,發(fā)現(xiàn)時間.
HTML鏈接:序號
4.1.2 查看所有bug
功能簡述:以分頁的列表方式列出所有bug,可以選擇某條記錄進行修改,可以彈出框形式查看bug詳情.可以按過濾器查看符合該 過濾器條件的bug.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),過濾器選擇框(選擇某個過濾器).
界面標簽(指Label):可選項,序號,概述,緊急程度,狀態(tài),所有人,發(fā)現(xiàn)時間.
HTML鏈接:序號
4.1.3 增加新的bug
功能簡述:用戶可以增加新的bug
界面控件:所屬模塊選擇框(設定bug的所屬模塊),發(fā)現(xiàn)時間日期控件(確定bug的發(fā)現(xiàn)時間),發(fā)現(xiàn)者選擇框(確定bug的發(fā)現(xiàn)者),狀 態(tài)選擇框(確定bug的狀態(tài)),截止期限日期控件(確定bug的建議修改時間),指派給選擇框(選擇bug的所有人),描述文本域(輸入 bug的描述),附件一(文件選擇框),附件二(文件選擇框),附件三(文件選擇框).提交按鈕.
界面標簽(指Label):根據界面控件描述進行配對.如所屬模塊選擇框的標簽是"所屬模塊".不再贅述.
4.2 個人資料
4.2.1 修改我的資料
功能簡述:用戶可以更新個人資料
界面控件:姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本框(輸入確認密碼),所屬組別選 擇框(輸入所屬組別),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
4.3 過濾器配置
4.3.1 列出過濾器
功能簡述:列表方式列出該用戶所增加的過濾器,可以選擇某條記錄進行修改,可以彈出框形式查看過濾器詳情,可以刪除某條記 錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,序號,過濾器名稱.
4.3.2 增加新過濾器
功能簡述:用戶可以增加新的過濾器.每個用戶只能有最多10個過濾器.
界面控件:過濾器名稱文本框(輸入過濾器名稱),狀態(tài)選擇框(選擇狀態(tài)),所屬模塊選擇框(選擇模塊),發(fā)現(xiàn)者選擇框(選擇發(fā)現(xiàn)者 ),指派給選擇框(選擇bug的所有人),發(fā)現(xiàn)時間段時間選擇框(選擇發(fā)現(xiàn)起始時間),發(fā)現(xiàn)時間段時間選擇框(選擇發(fā)現(xiàn)終止時間 ),截止時間段時間選擇框(選擇截止起始時間),截止時間段時間選擇框(選擇截止終止時間).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如過濾器名稱文本框的標簽是"過濾器名稱".不再贅述.
4.4 系統(tǒng)管理
4.4.1 用戶列表
功能簡述:列表方式列出所有用戶,可以選擇某條記錄進行修改,可以彈出框形式查看某用戶詳情,可以刪除某條記錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,登錄ID,Email,電話,職位
4.4.2 增加新用戶
功能簡述:增加新用戶
界面控件:登錄ID文本框(輸入用戶帳號),姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本 框(輸入確認密碼),是否管理員選擇框(設定是否管理員),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
4.4.3 開發(fā)組列表
功能簡述:列表方式列出所有開發(fā)組,可以選擇某條記錄進行修改,可以彈出框形式查看某記錄詳情,可以刪除某條記錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,開發(fā)組名稱,描述.
4.4.4 增加新開發(fā)組
功能簡述:增加新開發(fā)組.
界面控件:組名稱文本框(輸入開發(fā)組名稱),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):組名稱,備注.
4.4.5 日志列表
功能簡述:分頁列出系統(tǒng)日志.用戶刪除某條記錄,可以彈出框形式查看某條記錄詳情.
界面控件:刪除按鈕.
界面標簽(Label):可選項,日志時間,用戶ID,操作概述.
2007年4月4日
#
Diego打算用html開發(fā)系統(tǒng)的原型,在開發(fā)期間,他發(fā)現(xiàn)經探討了解的需求信息還存在不足,而且,一些潛在的需求如果不經討論確定,下一步的開發(fā)工作就沒辦法進行.
他向自己提出了這些要求:
1.盡快開發(fā)系統(tǒng)原型并獲得客戶的通過.
BS程序通常通過開發(fā)html模型以確定用戶需求,演示系統(tǒng)功能.演示讓客戶能夠最快的看到"實際的系統(tǒng)".盡管系統(tǒng)的最終開發(fā)結果不可能和原型一模一樣,然而原型確實能最大限度的幫助系統(tǒng)開發(fā)工作.
2.盡快確定顯示界面所需的字段.
這些顯示字段能夠幫助數(shù)據庫系統(tǒng)設計師確定系統(tǒng)的表結構.
3.在開發(fā)原型時對系統(tǒng)進行初步的功能分解.
這步工作是系統(tǒng)架構設計的基礎,并且可以明確需求,協(xié)助需求分析設計書的編寫.經驗表明,精心劃分的功能需求能使開發(fā)人員和客戶更好的進行交流.
另外,Diego還問自己如下問題:
1.系統(tǒng)是否存在權限控制?如果存在,通過什么形式實現(xiàn)?
2.系統(tǒng)有哪些隱含而必不可少的功能(例如用戶管理等管理模塊)?這部分功能應該明確制定,并且和用戶進行討論.
Diego的原型和功能列表如下:
功能列表:
1 Bug管理
1.1 列出我的bug
功能簡述:以分頁的列表方式列出指派給我的bug,可以選擇某條記錄進行修改,可以彈出框形式查看bug詳情.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改)
界面標簽(指Label):可選項,序號,概述,緊急程度,狀態(tài),所有人,發(fā)現(xiàn)時間.
HTML鏈接:序號
界面:見圖(列出我的bug)
1.2 查看所有bug
功能簡述:以分頁的列表方式列出所有bug,可以選擇某條記錄進行修改,可以彈出框形式查看bug詳情.可以按過濾器查看符合該過濾器條件的bug.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),過濾器選擇框(選擇某個過濾器).
界面標簽(指Label):可選項,序號,概述,緊急程度,狀態(tài),所有人,發(fā)現(xiàn)時間.
HTML鏈接:序號
界面:見圖(查看所有bug)
1.3 增加新的bug
功能簡述:用戶可以增加新的bug
界面控件:所屬模塊選擇框(設定bug的所屬模塊),發(fā)現(xiàn)時間日期控件(確定bug的發(fā)現(xiàn)時間),發(fā)現(xiàn)者選擇框(確定bug的發(fā)現(xiàn)者),狀態(tài)選擇框(確定bug的狀態(tài)),截止期限日期控件(確定bug的建議修改時間),指派給選擇框(選擇bug的所有人),描述文本域(輸入bug的描述),附件一(文件選擇框),附件二(文件選擇框),附件三(文件選擇框).提交按鈕.
界面標簽(指Label):根據界面控件描述進行配對.如所屬模塊選擇框的標簽是"所屬模塊".不再贅述.
界面:見圖(增加新的bug)
2 個人資料
2.1 修改我的資料
功能簡述:用戶可以更新個人資料
界面控件:姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本框(輸入確認密碼),所屬組別選擇框(輸入所屬組別),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
界面:見圖(修改我的資料)
3 過濾器配置
3.1 列出過濾器
功能簡述:列表方式列出該用戶所增加的過濾器,可以選擇某條記錄進行修改,可以彈出框形式查看過濾器詳情,可以刪除某條記錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,序號,過濾器名稱.
界面:見圖(列出過濾器)
3.2 增加新過濾器
功能簡述:用戶可以增加新的過濾器.每個用戶只能有最多10個過濾器.
界面控件:過濾器名稱文本框(輸入過濾器名稱),狀態(tài)選擇框(選擇狀態(tài)),所屬模塊選擇框(選擇模塊),發(fā)現(xiàn)者選擇框(選擇發(fā)現(xiàn)者),指派給選擇框(選擇bug的所有人),發(fā)現(xiàn)時間段時間選擇框(選擇發(fā)現(xiàn)起始時間),發(fā)現(xiàn)時間段時間選擇框(選擇發(fā)現(xiàn)終止時間),截止時間段時間選擇框(選擇截止起始時間),截止時間段時間選擇框(選擇截止終止時間).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如過濾器名稱文本框的標簽是"過濾器名稱".不再贅述.
界面:見圖(增加新的過濾器)
權限體現(xiàn)的實現(xiàn):
系統(tǒng)權限:
1)用戶需要登錄到系統(tǒng),才能進行相關操作.
2)用戶存在"非活動時限",如果超過一個時間定值用戶不進行系統(tǒng)相應操作,則提示用戶重新登錄.
管理權限:
1)用戶必須是管理員用戶,才能進行系統(tǒng)的管理工作.
應用權限:
1)只有系統(tǒng)管理員能夠刪除bug.
在列出用戶要求的功能列表和參考權限實現(xiàn)方式之后,Diego將系統(tǒng)隱含必不可少的功能整理如下
4 系統(tǒng)管理 (只有管理員才能操作該模塊的所有功能)
4.1 用戶列表
功能簡述:列表方式列出所有用戶,可以選擇某條記錄進行修改,可以彈出框形式查看某用戶詳情,可以刪除某條記錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,登錄ID,Email,電話,職位
界面:見圖(用戶列表)
4.2 增加新用戶
功能簡述:增加新用戶
界面控件:登錄ID文本框(輸入用戶帳號),姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本框(輸入確認密碼),是否管理員選擇框(設定是否管理員),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
界面:見圖(增加新用戶)
4.3 開發(fā)組列表
功能簡述:列表方式列出所有開發(fā)組,可以選擇某條記錄進行修改,可以彈出框形式查看某記錄詳情,可以刪除某條記錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,開發(fā)組名稱,描述.
界面:見圖(開發(fā)組列表)
4.4 增加新開發(fā)組
功能簡述:增加新開發(fā)組.
界面控件:組名稱文本框(輸入開發(fā)組名稱),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):組名稱,備注.
界面:見圖(增加新開發(fā)組)
4.5 日志列表
功能簡述:分頁列出系統(tǒng)日志.用戶刪除某條記錄,可以彈出框形式查看某條記錄詳情.
界面控件:刪除按鈕.
界面標簽(Label):可選項,日志時間,用戶ID,操作概述.
界面:見圖(日志列表)
Diego將該原型交給烏有,烏有將據此編寫需求分析說明書,和子虛先生作進一步的交流.
烏有和Diego在討論需求
烏:Diego,對這個系統(tǒng)的看法怎樣?
D:嗯,我覺得我們遺漏了某些東西.查看bug列表時,是允許所有用戶查看呢?還是經過系統(tǒng)驗證的用戶?
烏:.... 我覺得應該是經過系統(tǒng)驗證的用戶吧.
D:不一定.如果用戶要登錄之后才能看到bug列表,不方便.理想狀況應該打開系統(tǒng)就能看到.
烏:但是你要考慮這么一個問題,假設bug按發(fā)現(xiàn)時間的順序分頁列出且bug的數(shù)量很多,很可能在第一頁該用戶看不到屬于自己的bug,他就以為沒有bug.假如我們要求他必須先登錄,那我們就可以根據他的登錄信息,列出他的bug的總數(shù),bug的列表...等等.
D:我上當當網購書的時候,發(fā)現(xiàn)他們可以在不登錄的情況下記下用戶的瀏覽歷史.我猜想這可以通過寫用戶的cookie實現(xiàn).
烏:但我們公司的技術人員對這項技術不熟.我可不能憑猜測確定這個需求.
(雖然Diego躍躍欲試,但看到烏有先生堅決的神色,也只有妥協(xié))
D:好吧,那我們就必須先登錄,再看列表.
(于是烏有先生編寫系統(tǒng)的用例如下:)
用例1:用戶查看bug列表
1.用戶點擊"bug列表"標簽,查看屬于自己的bug列表.
前置條件:用戶已登錄系統(tǒng).
(該用例獲得一致通過)
(烏有先生編寫系統(tǒng)用例2)
用例2:用戶查看bug詳細信息
1.用戶點擊bug列表中的某個bug,進入bug詳細信息頁面.
2.用戶可以修改bug的狀態(tài),修改時間.
前置條件:用戶已登錄系統(tǒng).
D:我發(fā)現(xiàn),如果系統(tǒng)要求用戶必須先登錄才能查看bug,那么此時系統(tǒng)列出的bug都是他的,列出其他人的bug好像沒什么必要.
烏:但是你要考慮,假設我是項目經理或者測試組組長,我想看到所有bug的列表.系統(tǒng)列出所有bug還是必要的.
D:解決辦法有兩種.1)訪問系統(tǒng)的時候,根據某種邏輯(如時間,模塊,bug性質)列出bug的列表.大家不用登錄就可以看到.我稱這個為"公共bug列表界面".用戶一訪問系統(tǒng)就能看到這個界面. 2)或者用戶登錄之后,點"列出所有bug"列表.當然,用戶還可以構造自己的過濾器,以決定列出bug的條件.
烏:那么其實"列出所有bug"和"列出自己的bug"功能可以合并到一起.只不過默認狀態(tài)列出屬于自己的bug,簡單的選取條件后又可以列出所有bug.
D:對,這種想法不錯.而且,各自選擇應該能匯總成一個名稱,姑且稱之為過濾器.用戶可以建幾個常用的過濾器以供快捷使用.
烏:好辦法!
(于是烏有先生修改用例1如下:)
用例1:用戶查看bug列表
1.用戶點擊"bug列表"標簽,查看bug列表. (此時列出的所有bug屬于該用戶).
2.用戶可以選擇某些條件,系統(tǒng)根據這些條件列出相應的bug.如果什么條件都不選,系統(tǒng)列出所有bug.
前置條件:用戶已登錄系統(tǒng).
(烏有先生繼續(xù)編寫用例如下)
用例3:用戶添加bug
1.用戶點選"添加bug"標簽,進入添加bug界面.
2.用戶可以添加bug,設定bug的簡單描述,詳細描述,bug的發(fā)現(xiàn)時間,建議修復時間,所屬模塊,添加人,所有人,修改人,狀態(tài).
用例4:用戶增刪改過濾器
1.用戶點擊"過濾器列表"標簽,查看當前過濾器列表和當前所采用的過濾器.
2.用戶可以增刪改新的過濾器.
(烏有滿意的伸伸懶腰)
烏:我想差不多了.這個系統(tǒng)確實不算太復雜.
D:我設計個原型,然后一起找子虛先生繼續(xù)討論.
烏:好的,加油!
2007年3月28日
#
??? 一 生活燦爛,望君多珍重
??? 寫下這篇牢騷小文之前,先簡略描述一番在下目前的生存狀態(tài):上班時間:基本沒事情做,在看各種自己感興趣的技術,理論,寫一些實踐的代碼,每天下午4點,必到樓下溜達15分鐘,順便喝杯咖啡;晚上,讀書,寫程序;周末,游玩,唱K,足球.
??? 很開心的日子,對不?
??? 美好和悲慘通常不分家.作為我們公司的軟件程序員,我體會更深.更多的時候我在出差,那時候我不可能還在這個匆忙的城市度過自己的悠閑時光.我會深入祖國大后方,老老實實的蹲在某個小城市政府部門某棟小樓的某個辦公室(有時候是機房),每天像銷售/商務人員一樣向官員了解他們需要的軟件功能,然后快速開發(fā)部署以供他們使用,然后等待他們的詰責再要求,然后蹲回機房老老實實再改程序再部署再接受審判......循環(huán)周而復始.沒有周末,沒有閑暇,沒有陽光,沒有足球.
??? 在一個備受對方刁難的項目實施過程中,我在某地過了四個月這樣的日子.連續(xù)120天啊!???
??? 所以,在沒有出差的日子(不出差也意味著我在公司會無所事事),我要盡情的享受生活!
???
??? 二
??? 這兩年大家對spring的贊美之聲一直不絕于耳,囿于工作性質和時間,我不能太深入的實踐這個框架,去年只是買那本<j2ee development without ejb>來翻翻.Johnson 的論點確實深得我心,很多時候,用戶其實不需要分布式,不需要更改數(shù)據庫,不需要太過笨重的事務管理...(這些對用戶來說都是透明的),他們關心的只是軟件如何滿足他們的需要,讓他們能盡快的展開工作.為此,我們設計的系統(tǒng)就要開發(fā)周期短,易維護,靈活易增加功能,還要足夠健壯......
??? 什么?高靈活性,高可靠性,高健壯性?不是我們一直追求的目標么?你也許會這么反駁我.
??? 問題是我們所鼓吹的跟我們所實際做的完全兩樣.在下早年曾對sun的pet store模型很感興趣,把相關文獻源碼基本看了幾遍.并以開發(fā)人員的身份實際參與了一個應用該模型進行開發(fā)的大型項目.該項目80-100人的規(guī)模,總歷時5年.我在項目快要接近成功的時候離開了這個公司,回首這段開發(fā)經歷,不勝其苦.應用這類模型進行開發(fā),根本不可能做到所謂的高靈活性,易于維護性,易于提高生產力.每測試一個ejb就要等待15-20分鐘啟動ejb容器的滋味,你嘗過嗎?
??? 這段時間寫了一些spring的代碼,很為spring的簡略而驚奇.但spring就是銀彈嗎?在我正要在公司內部寫一系列小文鼓吹spring之前,我這么問自己.我悲哀的回憶起,我的悲慘經歷完全和技術無關.對,spring采用ioc,程序易于測試;spring包裝了rmi,很方便的完成ejb的功能;spring提供了各著名持久框架的膠水,讓ibatis,hibernate,jdo都能輕易集成到其中...
??? 但是,我們原來的框架也不算太差啊?雖然由于前期規(guī)劃不好,代碼風格混亂不堪,水平參差不齊,但從架構組成,開發(fā)周期和運行性能而言,足以滿足用戶的實際需求了(系統(tǒng)的實際運行也證明了這點).那么,問題究竟在哪里?
???
??? 三
??? 我問自己.問題在于技術嗎?也許是,銷售和市場人員是這么抱怨的.但如果按照經典的軟件工程過程來分析,是誰在獲取需求?誰在編寫需求說明書?回答:可能是銷售人員和項目經理進行調研進而編寫需求.誰在編寫概要設計說明書?回答:沒有,時間很緊,來不及寫.誰在編寫詳細設計說明書?回答:沒有...誰在寫測試報告?回答:來不及寫...誰負責部署,反饋信息?回答:具體到每個程序員......
??? 別笑我.你也許認為,像我目前公司的這種情況,是很極端的例子,不可能公司不寫任何文檔,不進行任何測試的.好的,我告訴你,我們也有文檔.我從公司服務器雜亂無章的文檔中翻出了最初的需求文檔,它的內容證明了它是不折不扣的垃圾.我也翻出了某一兩個功能模塊的文檔(這還是我堅持要他們寫的),內容和實際程序設計不止差了十萬八千里.我找不到測試報告,也許這個系統(tǒng)真的沒有測試.就這么拿出去部署應用了.程序員又怎能不辛苦?
??? 一句老生常談的話概括:管理問題.這是小公司屢見不鮮的毛病.
???
??? 四
??? 如果說這個例子過于極端,那么看看管理良好的公司所開發(fā)的項目?前文所述應用pet store進行開發(fā)的公司,是某大公司在本地的子公司(簡稱S).S的項目開發(fā)流程非常規(guī)范.專門的需求分析員,專門的系統(tǒng)設計師,專門的開發(fā)人員,專門的測試小組,測試人員,測試流程.....可以說一切資源人員配置都按照大軟件工程的標準進行配置.結果呢?在開發(fā)那個80 * 5 * 12 人月的項目中,眾人一樣累得死去活來,晚上加班到12點是常有的事.
??? <人月神話>強調了一個問題:開發(fā)人員之間的交流成本非常昂貴.<人件>旗幟鮮明的論證(或憧憬):在軟件開發(fā)中,人是最重要的.然而這兩本書我認為理論性過強了,似乎也不符合我國的現(xiàn)實.我更喜歡這本小書:<軟件工藝> 它說:做軟件如打鐵,就是手藝.將系統(tǒng)交給好的程序員,他自然能做出好的軟件.好的程序員,應該需求分析,架構設計,編碼各方面都有很深的造詣.... 這本小書真讓我愛不釋手.
??? 我想,即使有銀彈,槍法不同的人使用,恐怕效果也不一樣.最好的小說,通常都反映了人本性最深邃的一面.同樣,要設計最好的程序,必須要由最好的程序員來進行.這里程序員的范疇很廣,在我的概念里,是把需求分析師,架構師,開發(fā)人員,測試人員都包含進去的.
??? 一個好的程序員應該善于與人溝通交流,邏輯思維能力要強.有一定的文史哲基礎,能將枯燥的事物用形象的比喻介紹給用戶.有一定的文筆,能簡潔流暢的編寫需求分析書.
??? 一個好的程序員應該精通系統(tǒng)架構.在了解需求之后能迅速將抽象的需求實際轉換為相對具體的東西(如程序原型,uml用例圖,甚至一些能說明情況的草圖),以充當需求和程序架構的橋梁.用戶根據這些成果表達/修改他們的需求,設計師根據這些成果進行框架的設計.
??? 一個好的程序員應該精通各種框架技術,熟悉相應數(shù)據庫(指應用開發(fā)而言),這樣他才能有選擇,有比較的確定用戶的功能如何做,如何做得好.
??? 一個好的程序員應該有一定的編碼水平.起碼不能寫出太離譜的代碼.
??? 一個好的程序員還要懂得如何去測試,如何發(fā)現(xiàn)系統(tǒng)漏洞,甚至如何去攻擊之.
??? ......
???
??? 我的水平也就到這里了,其他的我寫不出.雖然不能孤立的撇開管理談技術,但我覺得,假如一群好的程序員能夠做到了自己的最好,最后卻在公司窩囊的領導下搞砸了一個項目,那他們也足以問心無愧.
???
??? 五
??? 以下一系列小文是我在公司的無聊之作.剛開始我為了實際應用spring做了個小小的源碼缺陷跟蹤系統(tǒng)(Bug Tracking System),后來我發(fā)現(xiàn)這個程序雖然寫出來了,但我根本無從評估它是否易用,是否易維護,是否符合別人的使用準則.我不得不啟動界面讓別人實際的看程序,最后獲得"哦,這東西不適合我使用"的評價.老實說花了這么多時間獲得這樣的評價真讓人沮喪.于是我想寫幾篇需求和設計文檔,以使我和別人易于溝通,易于交流,而不用每次都要實際的啟動程序.
??? 原來,在經歷整年的出差/開發(fā)/部署生涯中,我極端懷疑文檔的意義.我想不可能在環(huán)境很緊迫的時候能做到一邊更改代碼一邊更改文檔.但我現(xiàn)在意識到,這是自己的認識偏差所導致,假如不把文檔作為程序開發(fā)的約束,而作為需求溝通,設計思想交流的橋梁,恐怕它的意義會大大提高.
??? 我很喜歡<理想國>,于是把下列小文盡量寫成對話的形式.并且借用了司馬相如作品的主人公,力求寫得生動有趣.
??? 我想和你交流的想法如下:
???
??? 1)需求分析師如何和用戶聊天以提煉需求.真實模擬國內調研時間短,需求難以明確的特點,并盡量少的在獲取需求過程中使用計算機術語.
??? 2)系統(tǒng)設計師如何和需求分析師分析需求,編寫需求說明書.
??? 3)系統(tǒng)設計師如何根據需求說明書撰寫概要設計,確立程序開發(fā)所采用的框架.
??? 4)實際開發(fā)的過程
??? 5)測試(也許會省略,^_^)
??? 6)其他......
???
??? 希望大家不吝賜教,我正在急需反省的時期,呵呵.謝了!
???
摘要: 以對話形式模擬如何確認和獲取需求
閱讀全文
【導讀】本文作者在現(xiàn)有UML現(xiàn)狀的基礎上，和我們探討了目前的UML熱潮是怎么產生的？為什么會存在形式主義？以及RUP之類的工具究竟存在哪些問題。作者根據自己的經驗，給出了解決的建議。
UML在國內不少地方獲得了應用。這應該說是個好事，然而背后我們也看到，這種應用大多屬于不夠冷靜的炒作和跟風，UML在很多時候已經變成了一種形式主義的東西。實際上，UML本身所倡導的主旨是很好的，它保證了程序員之間的交流語言，RUP之類的工具也保證了軟件開發(fā)過程的規(guī)范性，嚴格保證了先設計后開發(fā)，設計階段有翔實的規(guī)范化的文檔等。接下來，我們要看看目前的UML熱潮是怎么產生的？為什么會存在形式主義？以及RUP之類的工具究竟存在哪些問題。
第一是目前幾乎所有的UML工具都非常不好用，不美觀、不直觀、更不方便，在項目中進行同步維護也很困難。很多項目中用UML基本上可歸于形式主義的范疇。事實上，UML本身是一種規(guī)范，而規(guī)范本身的目的在于更好的交流溝通和更快更好的設計質量，事實上現(xiàn)在UML的發(fā)展已經背離了這些更基本的宗旨。我崇尚簡單就是美，最傳統(tǒng)的流程圖每個人都能看懂（甚至不是程序員也可以），現(xiàn)在的UML呢？太多不夠體貼和人性化的東西了，過于抽象化和公式化。我想未來會有新的更輕量級的類似的東西取代落后、冗腫和封閉的UML。我個人崇尚簡單就是美……
第二個問題是目前程序員的普遍素質不夠。UML本身基本是于面向對象的軟件設計思想的，沒有足夠優(yōu)良的OO設計能力，很難有真正需要UML類別設計工具去表達自己設計意圖的必要。這個觀點不算夸張，其實有的人OO理論很強，但真正在實踐中往往過度設計，或者設計本身極度不平衡，把項目開發(fā)改成了科研實驗和上機實驗。另外更多的一些人對自己的動手能力很信任，往往忽視設計環(huán)節(jié)，基本上項目的設計一直處于反復和動蕩中。這些程序員不給他們一段時間學習和實踐，是很難成為成熟的設計師的，在基本成熟之前，UML對他們將是一個形式化的東西，不會有很強的意義。Andrei曾經說程序員要到35歲才會成熟，而代碼員可能20多歲就可以了。這句話里大概也有“設計本身是個很需要經驗的工作”的意思。
第三個問題是少數(shù)社會層面的宣傳誤導。印度海歸派、外企員工、IT譯書作者和出版社、職業(yè)培訓機構等處于各自的經驗、目的和原因，大部分人完全背離現(xiàn)實的盲目鼓吹UML，甚至幾乎片面的認為UML就是軟件工程。外企應用UML其實也并不很成功，不過他們有成熟的培訓體系，所以一定程度的彌補了UML過于晦澀的弱點，作為已經掌握他們的外企員工有一些可能會比較片面的歡迎UML。而印度海歸派的目的就不用多說了，至于培訓和譯書的人很多都學者成分大于實戰(zhàn)成分，他們需要鼓吹UML，不過早晚他們會發(fā)現(xiàn)更好的東西而放棄對UML的鼓吹。事實上，現(xiàn)在已經有人開始考慮這樣作了。
第四個問題是少數(shù)程序員非常依賴自動代碼框架生成，而這其實根本不是UML的關鍵問題。他們?yōu)榱耸褂媚承┕ぞ呱傻囊稽c也不符合中國人閱讀習慣的代碼，情愿放棄其他的一切。對他們來說UML只是一個代碼生成工具而已，所以他們作的UML大都沒有多大價值，比較形式化。
第五個問題是項目資源的問題。國內大多數(shù)項目實際可支配的資源非常有限，如果給其他外國公司的開發(fā)人員看無論開發(fā)周期還是資金人力都基本是荒唐可笑的。UML實際上應該貫穿始終，而不是只在最初的設計階段，也應該貫穿整個項目組，包括設計、管理、開發(fā)、測試所有的人都應該應用它。
我想一般的公司如果沒有極大的把握不用太迷信UML/RUP，其實某些基于輕量級項目并不需要RUP或UML。現(xiàn)在正打算學習UML的同行們，也盡可以先放下它，將來一定會有更優(yōu)秀的技術取代它，現(xiàn)在不如多花點時間學習和實踐一下OO設計等更基礎的東西。其實僅僅熟悉一下工具軟件和交流范式，將來對你來說只是幾天到個把月的事情，不用那么在意。而對于那些現(xiàn)在已經決定了實戰(zhàn)UML的項目，要想獲得成功，我的建議如下：
第一，項目周期至少延長通常計劃的50%至100%。你必須跟所有人解釋說，只有這樣才能讓UML本身有意義，才能切實提高項目的設計質量。
第二，在項目開始集中提供一段時間的UML開發(fā)培訓。貫穿項目始終，都要經常進行全方位面向對象設計思想的交流（當然是結合UML的），力圖通過交流提高設計質量。
第三，頂住客戶和公司領導方面的壓力，堅持把盡可能多的設計問題在最初的設計階段解決，而不要被迫匆匆完成形式主義的UML設計，然后把設計丟在一邊，開始編碼。
第四，妥善處理部分“精英”程序員的抵觸情緒。能疏導就疏導，不能疏導應考慮壓服甚至將他徹底排除在項目組外。UML量級的團隊開發(fā)并不鼓勵個人英雄主義，不下狠心將根本沒機會推進下去。
第五，對項目的期望不要太高。無論是面對急于驗收向上級邀功的政府客戶，還是公司里不懂技術只懂蠻干的領導，都要保持低調，把它當做一個并不見得立竿見影的實驗……
好了，就寫這么多，祝大家好運。