When to Reject the Customers/Users from Participating Your SDP ?
在 Software Development Project ( SDP ) 中, 理論上在哪個時間點之後, 絕對不能再有 Users ( Customers ) 的參與 ? 這是約莫一年半以前, 我的 Advisor 問所有 Lab. 同仁的問題, 但是直到現在, 我也依舊沒有肯定的答案 ^^b
先來看看手邊幾本的說法. 當然, 這是依我的解讀做的時間點判斷及說明, 同時內容以及最後我自己的想法都侷限在 Conventional Object-Orientation Paradigm. 同時只考量 General Customer, General Software ( to-be-built ), 以及 No Changing Requirements ( during development process ).
[1] Dean Leffingwell and Don Widrig, Managing Software Requirements: A Use Case Approach, second edition, Addison Wesley, 2003
我的理解 :
- 書中分為六個階段的 Team Skill, 我認為在 Team Skill 2 結束時也同時代表 customer 的參與告一段落.
- 在 software GUI 部份, 書中傾向於使用 Use Case 以及 Storyboarding 解決. 鑒於內容是以 Storyboarding 方式, graphically 呈現 Use Case, 因此我還是認定為 Storyboarding 的應用, 屬於 Team Skill 2 的範圍內.
- After Requirement Elicitation, Feature Listing, Interviewing, Brainstorming, and Storyboarding
- Before Use Case Diagram
我的理解 :
- 書中於 Requirement Phase 到 Object-Oriented Analysis Phase 之間, 特別分出了一個 Specification Phase. 在 Specification Phase 中提到 :
...this document must be clear and intelligible to the client, who probably is not a computer specialist. After all, the client is paying for the product, and unless the client believes that he or she really understands what the new product will be like...
- 因此我認為以書中的觀點, customer 至少會參與到 specification 的制定.
- 書中所指的 Specification Phase 事實上等同於一般說的 Analysis Phase[2], 而 Object-Oriented Analysis Phase 是作為 counterpart 存在.
- 同時書中也提到, 在 specification 訂立之後才能進行較準確的 project time and cost estimation, 而 customer 會根據評估結果決定是否繼續委託開發. 從 project 角度來說, customer 在此時仍影響 project 的進行, 但是從 software development 的角度來說, 並未影響 software development 的各種 decisions.
- End of Specification Phase
- Right after Project Time and Cost Estimation and Evaluation
我的理解 :
- 書中把 Requirement 分為 C-Requirement ( Customer Requirement ), 以及 D-Requirement ( Detailed Requirement ) 兩部份. 其中 C-Requirement 包含了 Use Case 的建立與撰寫, 以及 Draft User Interface Design. 此階段仍有 customer 參與.
- D-Requirement 的撰寫雖然主要是提供 software developers 一個之後進行 design 以及 implementation 的共同基礎,但是書中也提到 D-Requirement 需要 customer 參與 validation 的工作. 但是由於書中對於 D-Requirement 的內容敘述, 甚至包含了 Classes / Objects 的辨認, 因此 customer 協助確認的應該不是全部的 D-Requirement 內容.
- Right after D-Requirement ( Detailed Requirement ) is released
- Very close to the end of Object-Oriented Analysis Phase
我的理解 :
- 書中提到 :
A review of the Software Requirement Specification ( and / or prototype ) is conducted by both the software developer and customer.
- 而依據書中所述, Software Requirement Specification 是 Requirement Analysis 的產物, 因此在此 customer 的參與應該是到 Requirement Analysis 結束之後, 或是 Software Requirement Specification 的 review
- End of Requirement Analysis
- Review of Software Requirement Specification
[5] 我的想法
由於我對於 OO Paradigm 底下的 Software Development， 主要的認識來自於 [1][2][3] ， 因此以這些書中所提的觀點以及方法 ( Techniques ) 來回答此時間點。
我所 prefer 的時間點為， Use Case Diagram 的建立。
但此時間點僅包含 Use Case Diagram 的建立， 不包含 Use Case 的 Pre-Condition， Post-Condition， 以及中間的 Event Flow， Alternative Flow 的撰寫。
我所持的理由為， Use Cases 能夠將 Scenarios 化為數個合理大小的 User Action Sets。 雖然 Use Cases 本身仍然用 nature language 描述居多， 但是比起一般的 Scenarios 描述， Use Cases 提供一個更適切的 granularity， 讓 customer 認識自己與 software 之間的互動。 而適切的 granularity 也是此時間點僅止於 Use Case Diagram 的理由。 我認為 Use Case 的內容又過於仔細， 對於一般的 Customer 來說反而可能造成困擾， 如果要求 Customer 參與 Use Case 內容的撰寫， 對 Developer 來說也會是一種困擾。
但是在 Customer 參與 Use Case Diagram 的制定時， 所提出的一些意外的要求或是 Concerns， 有可能會影響到 Developer 對於 Use Cases 內容的撰寫。
另外我認為要特別考量的一個問題是 Software GUI。 鑒於我所知道的， 在 OO Software Development， 並沒有公認的時間點來決定 customer 所 prefer 的 GUI 樣式， 但是 software GUI 又是影響 software usability 甚鉅的部份， 因此大部份情況下， 與 customer 針對 GUI 作溝通是免不了的。 因此在 software 有 GUI 的設計考量下， customer 能參與的 software development 的時間點我認為就會受到 software GUI 要在何時與 customer 取得共識的影響。 不過此時間點僅與 GUI 設計有關， 與其他部份無關。
OpenOffice.org : 自訂頁碼起始值 ( self-defind initial page number )
雖然主要編輯軟體改成 OpenOffice.org 有一段時間了, 不過遇到某些狀況還是跟 OOo 白痴沒兩樣, 就跟以前使用 Word 一樣.
雖然說身為唸 software engineering 的人, 覺得責任也不全在我身上, 編輯軟體的 user interface design 應該是很典型的, 遵守 "讓使用者專心在他該花心思的事" 去設計, 而不是當使用者想要什麼效果時, 還需要抱著一兩本厚厚的書在翻找, 或是找有深厚使用經驗的 "高手" 求救 (通常這情形發生的越多, 表示這 software 的 user interface 設計越有改進的空間). 過去 Word / Office 每次出新版, 市面上的相關書籍就琳琅滿目, 該說 M$ 跟這些書的作者也算是某種共犯結構嗎 ?
回到 OOo 的自訂頁碼起始值好了, 如何插入頁碼在 OOo 的基本操作手冊文件裡已經有說明, 但是當我要自訂文件的頁碼起始值, 也就是希望頁碼不見得要從 1 開始, 可以從 15, 43, 或是任何數字開始呢 ?
(以下方法適用於 OOo 2.1, 也就是我現在使用的版本.)
有兩個方法, 第一個是在頁碼上按滑鼠右鍵進入欄位設定,
在欄位設定的格式選項下方, 有一個叫做修改的可修改欄位. 但問題是, "修改" 是什麼意思 ? 要修改什麼 ?
實際試了之後才會發現, 這裡的修改意思是對於目前頁碼的修改, 而且是加減的修改, 而不是直接替換掉原本的頁碼. 舉例來說, 如果把這裡填 10,
確定之後就可以看到原本頁碼是 32, 變成了 42, 同時上下相連的頁面, 其頁碼也會跟著改變. 換句話說, 原本的 32 + 修改的 10 = 最後的 42.
第二種方法就更神奇了, 你必須要把游標移到要改頁碼的該頁, 比如說剛剛的 page 32, 頁面內容的第一段上, 然後右鍵進入段落設定中. 請注意要是第一段, 否則改變的頁碼會從下一頁開始產生影響.
進入段落設定中, 在中間的位置有換行與分頁的設定, 需要把插入以及使用頁面樣式都勾選, 然後才能對右邊的頁碼進行調整, 一樣把他改到 42.
按下確定之後, 一樣可以看到 page 32 變成了 page 42. 但是請注意, 這種方法所造成的頁碼改變, 僅限於 page 32 及其以下的頁面, 換句話說 page 33 會變成 page 42, 但是 page 31 仍舊只會是 page 31, 跟第一種方法的影響不同.
Well, 回過頭來說 user interface design, 像是這種 design, 一來在使用者想要某項功能時, 很難以選擇施行(因為根本不知道可以這樣改阿), 二來對於究竟會造成什麼效果 (post-conditions), 也難以掌握. 今天只是改個頁碼就可能出現兩種不同的結果, 要是改其他的東西, 使用者如何放心文件的其他不相關部分不會被偷偷的進行什麼變動 ? 如果每次作設定的改變都需要使用者重新檢查文件一次, 這未免太累人了 :(
從這個 case 其實可以深入探討三個議題,
1. use case consistency : 如果上述兩個方法其實是同一個 use case, 或是相似的 use cases, 那麼他們的 post-conditions 是否應該保持一致 ?
2. use case understandability : 如何讓使用者事先意識到在他所使用的 use cases 中, 最終會對文件帶來什麼改變, 而不是等到 use cases 執行完了, 才讓使用者去找尋造成了什麼改變. 畢竟 use case 在 forward engineering 中本來就是給 customer 看的東西, 沒道理在真正使用 software 時反而不能從 use case 裡得到應該知道的訊息.
3. document-preserving activity : 這是從 refactoring 的 behavior-preserving 借用過來的, 以編輯軟體來說, 是否部分 activity 應該可以視為對 document 作了 refactoring, 同時這些 activity 也必須具備某種 document-preserving 的特性. 舉例來說, 上述的兩種頁碼變更方式, 第一種會維持頁碼的連續性, 第二種則是會打斷頁碼的連續性, 這可能是兩種不同的編輯功能, 但是顯然地他們造成的效果是不一樣的, 換句話說這兩個 activity 對於 document 的改變事實上就是具有不同的特性.
阿...越扯越遠了, 就此打住, 有機會再深入討論這些想法吧 :)
The Different Forms of Use Cases
前一陣子計畫工作需要, 對不同的 use cases 寫法作了 survey.
A. Cockburn 著名的 Writing Effective Use Cases [Cockburn01] 其實已經歸納了好一部分, 然而牽涉到 user interface design 相關的部分時, 有些 use case 的寫法也不在他的歸納內.
底下就我 survey 的, 自行整理數個類別, 請注意下面的許多 diagram 名稱在 UML 中也出現, 但內涵並不完全相同.
- Scenario Style (Continuous Narrative Style) [Constantine01]
- Numbered Sentences [Constantine01]
- Mainstream Use Case Writing Style [Cockburn01][Overgaard04][Rosenberg01][Rosenberg07]
- Partitioned Narratives [Constantine01]
- Essential Use Cases [Constantine01]
- Activity Diagram [Almendros-Jim´enez05]
- Collaboration Diagram [Elkoutbi99]
- Use Case Maps [UCM07]
- Sequence Chart [Cockburn01]
比較有意思的是在 [Constantine01] 中使用的 Partitioned Narratives style, 為了方便 user interface design, 建議把 flow of events 分為 actor 以及 system 兩邊分開論述, 這樣彼此的 action/reaction 就會比較清楚. 在目前主流的寫法中尚未有此慣例, 但是似乎也有人開始建議應該在主流的寫法中加上此 style 限制, 讓 use case 轉換成為 object & associations 的過程中, 可以更順利, 減少不必要的 iterations.
另外 Use Case Map [UCM07] 是我一直很感興趣的項目. 第一次接觸 Use Case Map 大約是兩年前的事情了, 但是直到現在相關的 research papers 還是差不多兩年前的量, 頂級的研究成果更是缺乏, 但我始終覺得 UCM 很有潛力說, 可能只是時候未到吧, 還沒有遇到適合的 application context.
References
[Cockburn01] Alistair Cockburn, "Writing Effective Use Cases," Addison-Wesley, 2001
[Overgaard04] Gunnar Overgaard, Karin Palmkvist, "Use Cases: Patterns and Blueprints," Addison-Wesley, 2004
[Rosenberg01] Doug Rosenberg, Kendall Scott, "Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example," Addison-Wesley, 2001
[Rosenberg07] Doug Rosenberg, Matt Stephens, "Use Case Driven Object Modeling with UML: Theory and Practice," Apress, 2007
[Constantine01] Larry L. Constantine, Lucy A. D. Lockwood, Structure and Style in Use Cases for User Interface Design, URL : http://www.foruse.com/Files/Papers/structurestyle2.pdf
[Almendros-Jim´enez05] Jes´us M. Almendros-Jim´enez and Luis Iribarne, "Designing GUI components from UML Use Cases," Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS’05), 2005.
[Elkoutbi99] M. Elkoutbi, I. Khriss, and R. K. Keller, "Generating User interface Prototypes from Scenarios", PRocs of RE'99, 1999.
[UCM07] Use Case Maps, URL : http://www.usecasemaps.org/