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