[技術討論]某國外大型業務系統的前期分析對話
Tony 22:36:10
好啊!
Tony 22:36:13
還沒有睡?
Tony 22:37:13
系統規格說明書中一般要不要體現流程?
Tony 22:40:03
我們這裡一般將系統規格說明書變成流程分析與表單分析了,我覺得不是很妥,那流程分析又放在哪裡呢?一般來說流程分析對公司還是很重要的,是核心部分
Tony 22:41:57
是可以把它放在使用者需求規格說明書中?
青潤 22:47:05
流程分析應該分成兩個部分,一個是業務流程描述,然後才是資訊系統流程分析。
青潤 22:47:22
也就是說,你的系統地流程分析應該是基於使用者原始業務流程的。
Tony 22:48:08
是的!但是我們經常要幫助使用者構建系統,分析和改進原有流程
Tony 22:48:31
有些需要和IE配合,不完全是IT的事情
青潤 22:48:45
是的,不完全是it的事情,但是,在一般的情況下,至少國內,是必須it人員來引導的。
青潤 22:49:41
否則,客戶不清楚需要如何配合的,因為國內的客戶在這方面的知識和經驗還是十分欠缺的,另外,他們想象不到真正的資訊系統應該是什麼樣子的,所以,必須it人員來做出適當的引導。
Tony 22:49:54
但這些流程的資訊是否應該體現在系統規格說明書中呢?還是專門出一份關於流程分析及規劃的文件?一般你處理過的案例是怎樣的?
青潤 22:50:09
流程資訊,正常來說應該是在需求分析說明書,或者說需求規格說明書中的。
青潤 22:50:35
系統規格說明書,應該是描述系統整體實現的技術/業務規格和目標的。
青潤 22:50:54
這裡的業務是整體的概述,而不是具體的業務資訊或者流程。
Tony 22:52:38
嗯,昨天看了你的文章,對這一點還是比較贊同的,我們這裡是由單獨一個部門來處理,大多由會計,經管,IE人員組成
青潤 22:54:43
過程必須清晰,權責必須明確,不過,這也要看客戶的實際情況進行考慮。呵呵。
尤其是國內的專案,更多的是客戶在技術和實現上的無知,使得it人員不得不完成更多的事情。
青潤 22:55:18
對國外的情況我不是很瞭解。
Tony 22:56:00
呵呵,這裡的更簡單,兩個文件全部搞定
青潤 22:56:29
哪兩個文件?
Tony 22:58:49
一個需求分析的,另一個從設計到測試的(測試用例)
青潤 22:58:50
哦。
青潤 22:58:56
這樣的組合是可以的。
Tony 22:59:18
他們原來過了CMM3,沿襲原來Moto的做法
青潤 22:59:37
我一般建議也是兩個文件:
1、需求規格說明書
2、用例闡述文件
青潤 22:59:49
對於大專案而言,還需要一個:
使用者業務模型
青潤 23:00:07
應該是:使用者業務建模
Tony 23:00:19
把流程分析直接放入需求規格說明書裡。
Tony 23:00:38
使用者業務建模具體是指什麼樣式的?
青潤 23:00:39
流程分析部分應該是在用例闡述文件中,這是我的建議,我的方法論的基礎來自booch的。
青潤 23:01:26
需求部分應該是來自ivar。
Tony 23:01:38
這次處理的專案比較大,光流程就有200多個,如果成功,全球十幾個地區都會使用
青潤 23:01:32
ivar的內容我也做了一些修訂。
青潤 23:01:35
哦。
青潤 23:01:41
那是個很大的專案。不錯。
青潤 23:01:57
如果是這樣,我建議考慮使用者業務建模。
Tony 23:02:08
呵呵,我的想法也是把流程與用例結合起來
青潤 23:02:32
也就是,通過使用者業務建模把使用者業務流程進行重現,然後對他進行優化重組。
Tony 23:03:03
有什麼業務建模好的資料嗎?業務建模我已經建立出來了,資料流程也分析了一下,但現在在考慮文件如何組織會更好一點
青潤 23:03:03
因為這個系統很大,所以,需要更多的在需求方面的投入。
Tony 23:03:35
是啊,我們分階段也模組的,還要與SAP配合
青潤 23:03:28
呵呵,你可以去看看我那本書。書上有一些建議,但是做的並不是很詳細,因為這個過程十分複雜。
Tony 23:03:57
不知道在哪裡可以下載嗎?現在在國外,沒辦法買到
青潤 23:04:02
呵呵,沒辦法下載,沒有電子版本提供分發。
Tony 23:04:53
哦。。哪有沒有一些關鍵章節的介紹呢?是否可以分享一下。
青潤 23:05:04
呵呵,版權問題,我無法公開。否則,第一個版本的出版社會找我麻煩的。
青潤 23:05:27
我現在在準備出第二版,正在重新找出版社。
Tony 23:06:16
呵呵,沒關係,寫書的感覺不錯吧,很有成就感哦。我大學時幫導師寫過一些章節。
青潤 23:06:10
應該有一部分內容在我的blog上有釋出。
青潤 23:06:37
我從來不是專門寫書的,當年那本書,也是因為寫多了,才作為書出版的,本來只是打算給雜誌投稿用的。
Tony 23:07:12
嗯,好的,我會再去你Blog仔細閱讀一下
青潤 23:07:26
ok,大概至少有一半內容在blog上都有,只是沒有整理。
Tony 23:08:07
好的,我要去開會了,有機會再聊
Tony 23:08:09
88
青潤 23:08:03
ok,88
好啊!
Tony 22:36:13
還沒有睡?
Tony 22:37:13
系統規格說明書中一般要不要體現流程?
Tony 22:40:03
我們這裡一般將系統規格說明書變成流程分析與表單分析了,我覺得不是很妥,那流程分析又放在哪裡呢?一般來說流程分析對公司還是很重要的,是核心部分
Tony 22:41:57
是可以把它放在使用者需求規格說明書中?
青潤 22:47:05
流程分析應該分成兩個部分,一個是業務流程描述,然後才是資訊系統流程分析。
青潤 22:47:22
也就是說,你的系統地流程分析應該是基於使用者原始業務流程的。
Tony 22:48:08
是的!但是我們經常要幫助使用者構建系統,分析和改進原有流程
Tony 22:48:31
有些需要和IE配合,不完全是IT的事情
青潤 22:48:45
是的,不完全是it的事情,但是,在一般的情況下,至少國內,是必須it人員來引導的。
青潤 22:49:41
否則,客戶不清楚需要如何配合的,因為國內的客戶在這方面的知識和經驗還是十分欠缺的,另外,他們想象不到真正的資訊系統應該是什麼樣子的,所以,必須it人員來做出適當的引導。
Tony 22:49:54
但這些流程的資訊是否應該體現在系統規格說明書中呢?還是專門出一份關於流程分析及規劃的文件?一般你處理過的案例是怎樣的?
青潤 22:50:09
流程資訊,正常來說應該是在需求分析說明書,或者說需求規格說明書中的。
青潤 22:50:35
系統規格說明書,應該是描述系統整體實現的技術/業務規格和目標的。
青潤 22:50:54
這裡的業務是整體的概述,而不是具體的業務資訊或者流程。
Tony 22:52:38
嗯,昨天看了你的文章,對這一點還是比較贊同的,我們這裡是由單獨一個部門來處理,大多由會計,經管,IE人員組成
青潤 22:54:43
過程必須清晰,權責必須明確,不過,這也要看客戶的實際情況進行考慮。呵呵。
尤其是國內的專案,更多的是客戶在技術和實現上的無知,使得it人員不得不完成更多的事情。
青潤 22:55:18
對國外的情況我不是很瞭解。
Tony 22:56:00
呵呵,這裡的更簡單,兩個文件全部搞定
青潤 22:56:29
哪兩個文件?
Tony 22:58:49
一個需求分析的,另一個從設計到測試的(測試用例)
青潤 22:58:50
哦。
青潤 22:58:56
這樣的組合是可以的。
Tony 22:59:18
他們原來過了CMM3,沿襲原來Moto的做法
青潤 22:59:37
我一般建議也是兩個文件:
1、需求規格說明書
2、用例闡述文件
青潤 22:59:49
對於大專案而言,還需要一個:
使用者業務模型
青潤 23:00:07
應該是:使用者業務建模
Tony 23:00:19
把流程分析直接放入需求規格說明書裡。
Tony 23:00:38
使用者業務建模具體是指什麼樣式的?
青潤 23:00:39
流程分析部分應該是在用例闡述文件中,這是我的建議,我的方法論的基礎來自booch的。
青潤 23:01:26
需求部分應該是來自ivar。
Tony 23:01:38
這次處理的專案比較大,光流程就有200多個,如果成功,全球十幾個地區都會使用
青潤 23:01:32
ivar的內容我也做了一些修訂。
青潤 23:01:35
哦。
青潤 23:01:41
那是個很大的專案。不錯。
青潤 23:01:57
如果是這樣,我建議考慮使用者業務建模。
Tony 23:02:08
呵呵,我的想法也是把流程與用例結合起來
青潤 23:02:32
也就是,通過使用者業務建模把使用者業務流程進行重現,然後對他進行優化重組。
Tony 23:03:03
有什麼業務建模好的資料嗎?業務建模我已經建立出來了,資料流程也分析了一下,但現在在考慮文件如何組織會更好一點
青潤 23:03:03
因為這個系統很大,所以,需要更多的在需求方面的投入。
Tony 23:03:35
是啊,我們分階段也模組的,還要與SAP配合
青潤 23:03:28
呵呵,你可以去看看我那本書。書上有一些建議,但是做的並不是很詳細,因為這個過程十分複雜。
Tony 23:03:57
不知道在哪裡可以下載嗎?現在在國外,沒辦法買到
青潤 23:04:02
呵呵,沒辦法下載,沒有電子版本提供分發。
Tony 23:04:53
哦。。哪有沒有一些關鍵章節的介紹呢?是否可以分享一下。
青潤 23:05:04
呵呵,版權問題,我無法公開。否則,第一個版本的出版社會找我麻煩的。
青潤 23:05:27
我現在在準備出第二版,正在重新找出版社。
Tony 23:06:16
呵呵,沒關係,寫書的感覺不錯吧,很有成就感哦。我大學時幫導師寫過一些章節。
青潤 23:06:10
應該有一部分內容在我的blog上有釋出。
青潤 23:06:37
我從來不是專門寫書的,當年那本書,也是因為寫多了,才作為書出版的,本來只是打算給雜誌投稿用的。
Tony 23:07:12
嗯,好的,我會再去你Blog仔細閱讀一下
青潤 23:07:26
ok,大概至少有一半內容在blog上都有,只是沒有整理。
Tony 23:08:07
好的,我要去開會了,有機會再聊
Tony 23:08:09
88
青潤 23:08:03
ok,88
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/257598/viewspace-368893/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [技術討論]科學基礎的分析和探討對話
- [技術討論]軟體的產品、技術、標準對話
- [技術分析]探討大世界遊戲的製作流程及技術——前期流程篇遊戲
- [技術討論]業務建模和使用者業務的關係
- [技術討論]iTSP組04年關於知識庫構建的對話
- [技術討論]06年12月結對程式設計與交換程式設計的對話程式設計
- [技術討論]關於低耦合開發的討論
- 日記8(對外api討論)API
- 歷史對話整理:古代戰爭討論
- 關於國內技術類書籍的一次討論
- 資訊化技術討論組
- 跨平臺socket通訊系統橋接技術的討論橋接
- [技術討論]06年12月11日關於結對程式設計實踐的一段對話程式設計
- 某財稅集團:使用進步的技術,對業務降本提效
- 關於系統對外介面應該採用的技術?
- [技術討論]國內企業軟體的狀況和瓶頸
- 討論一下秒殺系統的技術難點與解決方案
- 【話題討論】漫談生產系統升級的一點思考
- [技術討論]OO原則中鬆耦合與高內聚的分析
- 今日技術誰當家?——ThoughtWorks技術雷達討論
- [技術討論]多使用者(多公司)的資料庫設計討論資料庫
- [話題討論]Exadata技術淺析 Exadata到底可以作什麼?
- [技術討論]Uml工具哪個更好
- [技術討論]務實與務虛
- 大家討論一下國內那些公司的JAVA技術比較牛把Java
- [技術討論]系統間呼叫與邊界類的差別——被混淆的兩個概念
- 記一次 .NET 某藥廠業務系統 CPU爆高分析
- Oracle QQ群討論系統效能Tuning話題總結(1)Oracle
- 記一次 .NET 某券商論壇系統 卡死分析
- 有沒有一些大廠的高階架構技術討論討論架構
- 《Oracle大型資料庫系統在AIX/UNIX上的實戰詳解》集中討論21Oracle資料庫AI
- ORACLE技術中國使用者討論組Oracle
- 需求分析:將技術語言和業務語言統一
- IT系統的業務模型分析與系統建模模型
- 可以對任何網址進行留言討論的Chrome外掛Chrome
- [全程建模]績效管理模型在itsp組內的對話討論模型
- 話裡話外:從純技術顧問到業務諮詢顧問的能力發展路徑(上) 薦
- laravel 事件系統 問題討論Laravel事件