[技術討論]業務建模和使用者業務的關係
本次對話討論了業務建模和使用者業務的關係以及我書中的方式為什麼更實用的原因。最後談到我的培訓和中國企業的無奈。
北京-FireSpider 男 11:42:09
老師,您好。
北京-FireSpider 男 11:43:42
我翻閱很多書,好像所有的“業務建模”階段都是針對“已經有資訊化需求”的。“業務建模”階段體現出了“系統”概念。
北京-FireSpider 男 11:44:49
所以,才有我之前所不能理解的“業務用例”。如此一來,“業務用例”一詞和“系統”有關就可以理解了。
青潤 11:45:03
嗯。
北京-FireSpider 男 11:46:34
呵呵,這樣看來確實可以理解了。我之前一直不能理解,是因為把“業務用例”放在“純粹描述客戶業務”的角度來看了。但現在看,不是這樣的。需求階段,就已經有需求輸入了。
青潤 11:48:48
業務建模是針對使用者業務的建模。
這個過程可以有過去的歷史系統的痕跡,也可以是全新建設的系統。
北京-FireSpider 男 11:50:50
但是,還像我在張老師哪個群裡說的,缺少“描述客戶業務”的環節,並且我買的這些書裡,都沒有描述階段。
青潤 11:52:05
我的書中對於業務用例的描述會用到狀態活動圖或者泳道圖,這兩種圖就是用來繪製使用者實際的手工業務操作或者現在的業務操作方式。
然後從這裡分離出來系統可以實現的,系統不能實現的,系統需要從外部獲取的,三個部分的元用例。
這三種元用例通過組合拼接,形成實際的用例。
青潤 11:53:15
這個描述在我的書中提到了,但是沒有寫的特別仔細,因為展開,會是一個很大的話題,而且我提出的元用例的概念並沒有得到業界的統一認可。
北京-FireSpider 男 11:53:26
嗯,您說中確實在需求這塊有狀態活動圖或者泳道圖,這個圖看上去與系統沒有任何關係,感覺是在描述客戶當前的業務。
其他的書也有,只不過和用例建模混在一起,看不出來一個獨立的階段。
青潤 11:54:28
這是我認為在rup中描述不清楚的,我把它用於對業務用例的細節描述,我認為這樣可以表述的更清楚。
青潤 11:55:32
另外對於用例,也就是元用例組合後需要在專案中實現的功能性用例和非功能性用例(也就是你說的系統用例),我也用狀態活動圖來替代用例闡述,實現完整的模型化開發,全面脫離文件。
北京-FireSpider 男 11:55:40
嗯,還得讀者根據自己的實際情況去靈活運用才行。
青潤 11:56:53
我只能把相對比較合適的全面地框架給你們,針對具體專案是需要具體考慮的。
北京-FireSpider 男 11:57:08
嗯,是的。
我現在特別希望有一個新的專案,小一點的,最好客戶什麼系統都沒有的,從頭做一遍。
北京-FireSpider 男 11:58:22
否則這樣思考,還是有很多問題無法弄明白。
青潤 11:58:36
我曾經的培訓,就是現場提出一個專案,我邊講邊做,培訓結束的時候可以看到部分程式碼的匯出效果。
北京-FireSpider 男 11:58:53
以前做的很多適合分析的專案,一直沒用過這種思路,可惜了。
青潤 11:59:03
呵呵。
北京-FireSpider 男 11:59:36
嗯,真希望您能給我們培訓一下。不過這個公司無望了,連一點培訓的錢都捨不得花。
很多企業搞不起來,也確實是上層思路有問題,“該花的錢不花,不該花的錢亂花”。
搞不清楚這些老闆是怎麼想的。
北京-FireSpider 男 12:01:27
這些年,我一直在小公司幹了,開發流程混亂,也沒學到什麼不標準,完全依靠自己的總結、經驗去發揮。
青潤 12:02:38
呵呵,沒辦法
中國的老闆都擔心自己培養的人跑了。因為培訓了,就要給高工資,不給就走。
也都想坐吃現成,覺得挖人最快,成本低,時間快。
北京-FireSpider 男 12:02:46
呵呵
牛人跑到新公司去,其實也是新公司用最低的成本招到人。
青潤 12:03:37
所以,都不想培訓或者通過諮詢的方式得到企業的發展。
加上國內的培訓魚龍混雜,泥沙俱下,誰也說不清楚為什麼好為什麼不好。
我這種靠信譽生存的,不懂得市場運營,所以,就比較艱難了。
北京-FireSpider 男 12:04:42
老師,您還是想想運營一下,在中國這個環境裡,得以賺錢為第一動力,以培養人為賺錢的工具。
呵呵
理念變味了,也是很無奈的。
北京-FireSpider 男 12:05:48
午休了,您也去吃午飯吧。回來再聊。
青潤 12:06:15
呵呵,我就是個做技術或者技術管理的人,讓我去做運營,雖然懂一些,但是卻是不想投放什麼經歷在那上面,不是自己感興趣的事情。
甚至一些我能做的培訓,因為覺得沒有技術含量,我都會拒絕。
我做培訓的文字你可以去看看,就明白我為什麼用我的這種完全例項化培訓方式來講課了。
Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE相關文章
- 關於業務元件相關架構的討論元件架構
- [全程建模]業務建模和用例模型以及需求規格說明書的關係模型
- [技術討論]某國外大型業務系統的前期分析對話
- [全程建模]系統用例和業務用例的區別以及用例粒度的討論
- [全程建模]元用例和需求與績效之間的關係討論
- [技術討論]關於低耦合開發的討論
- [技術討論]建模工具的使用到客觀評價
- ToC業務使用者彈窗的技術方案
- 業務資料分析和建模薦
- RUP大講堂(第四講)-業務建模技術實踐
- ORACLE技術中國使用者討論組Oracle
- [技術討論]多使用者(多公司)的資料庫設計討論資料庫
- 業務勝於技術
- 銀行支付的業務邏輯和各機構關係
- 關於 Service Worker 和 Web 應用對應關係的討論Web
- EA業務建模實踐之業務用例圖
- 理解「業務」與「技術」概念
- CRM客戶關係管理系統管理良好業務關係
- [技術討論]架構設計和程式碼之間的關係以及程式設計師任務安排架構程式設計師
- [技術討論]科學基礎的分析和探討對話
- 為什麼建模技術對業務分析師BA如此重要?- modernanalystNaN
- [技術討論]軟體工程之全程建模實現適合做教材麼?軟體工程
- 業務重要?還是技術重要?
- 設計「業務」與「技術」方案
- 和開發人員討論一個業務需求和簡單實現
- 論文涉及技術:使用 portlet 與業務流程引擎建立連線
- 職場 | 工作五年之後,對技術和業務的思考
- 資訊化技術討論組
- 關係建模ER建模-維度建模
- [技術討論]再談新概念的建立和應用
- [技術討論]資料許可權中的理論和實際
- 淺談使用者需求和技術創新:雞和蛋的關係?
- 業務建模:CQRS應用場景
- MySQL Binlog 技術原理和業務應用案例分析MySql
- 雲端計算實現了業務和技術分離
- 正在興起的角色:業務技術人員
- 關於國內技術類書籍的一次討論
- 和開發同學討論的一個技術問題