軟體系統是收集使用者需求建構而成的嗎?

軟體公司的 PM(Project Manager)一向重視的是如何在不合理的開發時程下完成專案的開發。許多 PM 也認為他們認同物件導向及如 RUP/XP 的開發流程模式,認為如此他們可以縮短開發的時程。

個人最常與 PM 們討論的一個話題是:軟體應用系統是否係由使用者的需求收集而來所建構而成的?
絕大部分的 PM 的回答是:Yes!

為何問這個問題?個人發現到 PM 一定會先請 SA 訪談客戶的需求,並記錄在 Use Case 敘述內。再由 SD 針對 Use Case 敘述來找出領域物件(Domain Objects)。

在這樣的開發流程下,顯然使用者需求(Use Requirements)是重於軟體結構(Classes)的。所以,Use Case 是目的;Classes 是手段。

有沒有道理?在某種觀點及假設下,可能有道理!

只是,讓我們回想 RUP 所建議的最佳實務作法:”Use Case Driven;Architecture Centric”。

那麼,PM 既然認同 RUP 的開發模式,但是是否有仔細分辨倒底系統開發的方式是 “Use Case Driven” 或者是 “Use Case First” 呢?

有趣的問題,留待各位一起討論!

文章導覽

   

共有 7 則迴響

  1. 以”Use Case Driven;Architecture Centric”這句話來分析。
    是不是有一些既定的Architectures是良好的設計,是general的
    在不同的user requirement下,選擇一個適當的Architectures
    以此為基礎開發軟體。
    簡而言之 就是在user requirements(變化的)和Architectures(不便的)之間作一個mapping

  2. 不妨如此說,「使用者需求」是用來”驗證”系統的完整性。

    骨架,即系統的內部結構設計,結構設計需考量到許多的構面。您所問的 “如何被建立?”,可能要先反思,擔任結構設計的 “Architect” 應具備那些素養?

    軟體產業,目前還屬於非常不成熟的階段期,目前絕大部分的專案,均一味地從需求功能面來建構系統,完全沒有重視系統內部的結構設計。
    現今系統是越來越複雜,脆弱的架構是很容易瓦解的。

    如何被重視呢?當人們記取諸多教訓之後,自然而然,也就懂得如何從中學習得以成長了。

  3. “這有一個極大的風險,系統的 “骨架” 沒有被重視到”
    是沒錯…

    所以你的會建議怎麼樣讓系統骨幹被重視,
    以及建立起來… 系統骨幹跟使用者需求又有什麼關係….

  4. Hi zobeide:

    Use Case 是手段;UI Prototyping 也是手段;甚至 OO、RUP 等都是手段。
    若是能達成 “正確而迅速地捕捉使用者需求”,其實,沒有必要強求使用哪一種手段。

    有一點您說得很有道理,SA 不只是錄音機,記錄下使用者的需求而已。再則,是否有訪談到真正的 “Domain 專家”,懂得如何與專家溝通,以得到重要的需求線索,這才是重點。

    之前寫這一篇文章的主要用意,是提醒軟體設計人員不要以為只是收集使用者的需求(需求均偏向功能性的),然後再據此就可以完成系統的開發。

    因為,這有一個極大的風險,系統的 “骨架” 沒有被重視到,相對地,系統的架構會變得很脆弱:因為建基在使用者的需求上,而需求又是善變的。

  5. 記得早期學OO時, 學得很多技巧是在從User身邊的各種資料, 線索,
    蒐集整理出Domain Knowledge.
    再收集整理時 OO就已經扮演很重要的角色. 哪時覺得OO很棒

    後來上課老師教Use Case, 也覺得蠻好用的,
    工作上自己在用, 也還順手.

    某個工作後, 用RUP, 用Use Driven, 正式的開發軟體專案,
    工作同伴只學過Use Case Driven.
    不知道是不是因為不習慣,
    總覺得這種 Use Case Driven (Limited) 的Requirement Gathering 所
    找出的需求, 品質不好(不是真正的需求,易變動, context information 太少, OOA 很難做, 訪談次數變多,…), 到最後大家還是喜歡用UI prototyping.

    品質不好當然有很多原因, SA 對Use Case 不夠熟 (如不了解Goal對Use Case的重要), User不是對Domain不了解就是沒時間認真思考所要的系統.
    只是這些都是客觀的現實.
    User 不用功的情況下 SA就應該多用功, 不是當書記官一樣紀錄下需求後丟給SD.

    早期的OO的書都很強調Domain Expert的重要,現在好像都很少在被強調…
    🙁

    “在這樣的開發流程下,顯然使用者需求(Use Requirements)是重於軟體結構(Classes)的。” 我有近似的感覺. 我的感覺是這樣收集到的軟體需求不足以供設計好的軟體架構.

  6. 您已經提到了重點:有前提及其假設環境。

    所以相對地,蓋茅草屋、四合院的技術與蓋高樓大廈所使用的技術與人才就會不盡相同。
    反映至軟體系統的開發,也是類似的情形。 🙂

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *