需求工程

作者：
已經是好久以前的事了…

我們到一個部門跟他們談office automation，問他們需要什麼。他們竟然很訝異的說『電腦不是什麼都會嗎？』（雖然過了好多年，這好像仍然是一些人會問的問題）

拿出我們軟工的本領，就開始『需求工程』了，可是問題不太像我以前所碰到的CASE容易，更不像課本裡所說的那麼單純。我們問他們如何作業，沒有人講得清楚，甚至有許多不同版本。結果變成我們替他們釐清問題，替他們定義一些作業方式，就像我們替他們定一堆SOP一樣，結果還被批評一番。經果許多討論與翻修，終於完成。這中間有多少時候我常想，為什麼不是他們，而是我在替他們定需求呢？難道我以前碰過得人，就那麼的合作嗎？

好不容易prototype出來了，他們開始使用好像不太熟悉，可是試用一段時間後，他們終於瞭解原來電腦不是什麼都會，可是同時看到他們可以藉著軟體系統作更多的事。

以後幾年的合作，他們從被動不合作的『使用者』，變成主動且很聰明的『需求提供者』。他們的胃口也變大，可以想出一大堆非常有創意的應用。真的很難想像當初那不太甘願合作的樣子。

不知大家有沒有，相似的經驗？假如以為需求分析，只是問問東西，或是定一些定義出來，那就好像不是這麼一回事了。
在台灣的學歷：幼稚園中班肄業 （所受的教育都在國外）

留言

  1. 匿名2009年2月2日 下午4:46

    胃口也變大，可以想出一大堆非常有創意的應用
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    但是常常情況是領了之前case的錢，而常常被凹
    之後的應用，自己以前遇到的情況是這樣
    因為在台灣贈送好像是裡所當然，當然
    這種情況，"學生" 遇到的情況更為明顯

    回覆刪除
  2. 匿名2009年2月2日 晚上7:12

    我想胃口變大是可以接受的，只要需求提供者變得更成熟，漸漸的知道電腦能做什麼、不能做什麼。更棒的使用者會幫開發者想到時程、經費、甚至於幫忙做寫文件、作系統分析。我想就是合作的默契吧。

    所以作軟體專案一定要看長遠的，第一次的案子通常會虧錢，但是做下來了，以後所有的維護案幾乎都跑不掉。

    『魔鬼都藏在細節中』，許多系統一開始看的時候都覺得很簡單，真的下去作才知道有許多的『眉角』（台語）。以前作過一個社區管理的系統，一開始雙方都說的簡單，『僅』提供部分小功能，想不到需求越作越大，還好後來及時縮小範圍才能將案子順利的結案。真的不要小看任何的系統。

    回覆刪除
  3. Steve2009年5月25日 中午12:13

    個人現在也卡在一個"小小"的使用者管理系統,
    本來只是處理一個報名系統, 但是後來發現,
    他們所定義的使用者有好幾種不同群組,
    每個群組又不是 exclusive, 但是所對應到的行為卻又更複雜,
    所以越寫越亂, 詢問對方的需求的細節,
    得到的回答卻是完全不同的另外一套系統,
    照著他們新的想法去寫, 做了一些修改,
    正要把系統上線的時候, 卻發現檔案系統被客戶的一個半美工/半網頁設計師全部大搬風,
    自己都找不到原來的檔案放在哪裡,
    更別提新的程式碼要上傳到哪個路徑...

    真的, 雖然說程式設計的時候要保留擴展的空間,
    不知道是我資歷太淺, 還是這根本是需要"突變"或是"完全變態"的空間? (泣)

    回覆刪除
  4. 薛念林2009年6月6日 上午8:56

    通常我們一開始接觸一個系統的時候，使用者都會講他最重要的功能，而開發者也只會去想技術上有沒有什麼困難，所以就開始動工了。都忽略的系統分析的重要性，沒有透過系統分析去把相關的需求找出來，就很容易發生後續作不完的窘況。

    或許我們會說，當初都已經簽約了，需求就是這些，使用者怎麼可以改？使用者也很無辜，必經他不是資訊專長，domain 有時候也不是很清楚，所以這時候去吵 RFP 或是合約的內容已經沒有什麼用了。

    系統分析真的要注意。

    回覆刪除
  5. 黃為德2009年6月6日 上午10:57

    我不知以下說法是否對處理需求變動有用！

    1. The Agile Manifesto第3項："Customer
    collaboration over contract negotiation"

    2. The Agile Principles第1項："Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"

    如果大家覺得有用，可以另文討論。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

課程改進

作者：
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容