EEP 平台之前台工具SA/SD TOOLS |
|
查理葉
一般會員 發表:47 回覆:35 積分:16 註冊:2003-03-31 發送簡訊給我 |
前言:
發展SA/SD這個工具是訊光繼EEP開發平台之後推出的大作,其目標是為了要徹底解決軟體問題。在軟體開發的五個步驟中-需求蒐集、規格開立、系統架構發展、程式開發和上線測試。SA/SD這工具是為了解決規格開立及系統架構發展這兩個問題。 五個步驟所需的人才其實不大一樣。
『需求蒐集』:往往需對客戶產業要有相當程度了解才能理解、建議及改善客戶的工作流程。因此,人才的取得往往是該產業的從業人員或曾經為該產業發展過類似的軟體。
『規格開立』:其主要工作是將需求轉化成軟體規格,通常需具備軟體背景才能將達成。至於對使用工具是否熟悉便不是那麼重要。這裡軟體規格指的是軟體畫面、報表及資料流。但因對工具不熟常常藉由大量文件將需求仔細的呈現,以利後段工程的進行。
『系統架構發展』:其主要的責任是發展出軟體設計標準模板。因此,需要對軟體工具夠熟悉且對軟體發展流程掌握度夠高;例如Master/Detail畫面新增、修改及刪除如何標準化的設計,才能將設計速度、品質拉高,有些專案甚至連命名規則也會規範。
『程式開發』:則是將規格一行一行變成程式碼,如果專案是一步一步按步就班,此階段人員大致是專注程式開發即可,不過,實務上工程師還需兼具未知技術的研究,才能將專案所遇到各式各樣的問題解決。
『上線測試』:往往會面臨客戶需求的變更,未知Bug排除及效能不盡理想的交互影響,導致專案的上線需拖延不少時間。其間需要規格開立人員與較高程度工程師排除Bug。
總之一個專案需至少具備三種人才。SA/SD人才、系統架構發展者(俗稱功力較強的人)及程式師。但在台灣具備這三種要求的Team並不多,經常是軟體公司老闆一人身兼數職。所以,台灣軟體公司所發展的軟體往往不大,解決的問題有限。 要解決這困境便要找到一個針對以上所需的人才技能均融入在一起的工具,由SA/SD人員直接將客戶需求轉化成可上線的程式碼。如此一來,便可大幅降低各個步驟所需的人才大幅節省開發時程。順便也可解決軟體產業特殊情況,在別的產業待越久知識累積越深厚,但在軟體行業,過去所熟練的技術可能在明日變成一無是處。人生,在四十歲時本是蓄勢待發,但軟體這行業大概只能退下當個顧問師,扮演只能靠一張嘴無法真正動手解決問題的人。 但SA/SD工具在軟體發展史上,並不是一個新鮮的名詞。市場上也有幾個商品其設定目標應與訊光是大致一樣。根據與使用者近距離接觸談談這些產品的使用心聲發覺成效有限,勉強算的話大概只有文件交付上較為完備之外,如果進一步要根據Code Generation的程式碼上線大概是遙不可及。以台灣人的價值觀,如果花了錢只為了文件交付,大概認同的比例不高。那問題到底在哪裡?難道國內外產品都無法達成嗎?如果連國內外產品都無法達成那訊光又憑什麼能解決。 在回答這問題之前有必要將國內外軟體定位及其要達成目標進行了解。
以OOA/OOD為標準的SA/SD工具,一旦熟知或熟用OOA/OOD觀念之後,不禁要思考OOA與報價單之間關係如何建立?如何利用類別定義(Class Define)與報價單、出貨單之間拉上等號。就原理而言,利用類別定義是可以定義出報價單,但這如同利用組合語言寫報價單並非不可能,而是成本高到不像話。 再以一般Case Tool為例。大概只能滿足一般專案規格需求的二、三成,其理由是:如果仔細分析專案程式技術需求,大致可區分為五方面。畫面、報表、批次作業、權限及系統需求。其中『畫面』又可細分為表單式、計算式。表單式的畫面大致是設計表單然後將之存入資料庫。計算式畫面往往牽涉複雜過帳或複雜畫面呈現。『報表』大概可區分為清冊、交叉分析及複雜統計報表統計。『權限』一般分四層。(1)、功能表。(2)畫面新增、修改、刪除及查詢。(3)欄位控制。(4)資料層控制。『系統需求』例如多資料庫、與Mail結合…。至此,心中應該會有譜為何SA/SD工具只能有二、三成的實用性。原因是有太多的工作無法在SA/SD這工具上實作必須回歸開發工具。如此一來,SA/SD如何與開發工具達成雙向溝通或互相協助變的相當重要。但彷間的工具,有在這方面著墨嗎? 訊光SA/SD的工具定位相當清楚,只針對商業應用程式不包含低階軟體應用程式。將OOA/OOD包裝成規格分析人員熟知的DD及Schema設計、資料匯出匯入、表單設計、報表設計、批次設計。本工具所產生程式碼能讓EEP平台來執行,如此一來SA/SD工具的功能會被延伸至EEP平台,EEP所具備的功能同時也被SA/SD具備。例如,EEP的權限功能、EEP的效能控制及各式各樣的元件,均可在SA/SD中填參數,然後指揮EEP工作。這也是為什麼訊光SA/SD工具會比同類型的產品更實用的原因。 在經過仔細分析訊光SA/SD工具與市場上的工具主要差別之後。接下來是深入探討每個功能要解決的問題。 SA/SD工具分成下列幾大模組:
1. TABLE SCHEMA的維護
2. 資料的匯出匯入
3. 文件的產生
4. 畫面規格UI的輔助設計
5. 批次作業的輔助設計
6. 報表的輔助設計 TABLE SCHEMA 的維護:
在專案開發時期,專案控管人員需極小心維護TABLE SCHEMA之發展,任何TABLE SCHEMA之新增及異動需由工程人員彙報後,由專案控管人員維護,此種做法缺乏彈性及時效性,但若允許工程人員依程式開發需求先行異動再彙報專案控管人員,恐因疏失而造成SCHEMA實際版本與認知有差距,又因要找出其差異性往往需耗時耗力。
在系統上線維護時期,TABALE SCHEMA之異動更需審慎處理,不當且未察覺之異動恐導致現行系統無法運作。因此,在異動Schema時需先行備份,以防萬一。以筆者為例,客戶如果覺得之前的個案進行不錯,希望後續能進行,如果前後專案有橋接部分,需要異動到Schema往往須與客戶的MIS討論是否會影響原先資料庫。因此,需遞交變更文件及備份就資料庫耗時費力。
因此,為了要解決以上的困境。SA/SD工具需能自動診斷新舊資料庫版本差異,然後利用親和使用介面來協助設計者輕易Update Grade Schema版本。使用上,因為有了診斷功能,使用者能很輕易了解新舊資料庫版本差異所帶來的衝擊,能很精準的評估,免除了一大堆變更文件的交付及資料庫的備份。 資料的匯出匯入:
在二個時機上,軟體從業人員會花不少時間。(1)是將參數存在資料庫中,然後根據不同時機不同客戶調整參數。這想法本身沒有問題,如果系統參數數量少可以靠人員肉眼判動,如果數量一多勢必會容易犯錯誤把A客戶的參數覆蓋在B客戶上,或客戶願意採用較先版本時,原先客戶字行調動的參數如何不會被不小心覆蓋,便需有賴事先好好的規劃。(2)不同資料庫往往會需某種程度的資料整合。可能只是某些欄位根據某些條件將A資料庫的某幾個Table中某些欄位,匯入B資料庫的Tables中。這類問題往往需工程師寫所謂匯出匯入程式。花了不少時間,不少測試還不一定能將這類問題完整解決。最好的做法應該要有工具,能由使用者自行定義匯入關係,由系統根據鍵值診斷有幾筆資料將會覆蓋舊資料或新增入資料庫,然後再由使用這決定是否轉入,如此一來才控制資料轉入品質。
工具本身提供了診斷功能協助使用者了解資料覆蓋所影響的層面,讓使用使者不至於犯了不小心的資料誤蓋。但,工具本身更強勁的功能是一旦不小心誤蓋,系統會自行Log,可隨時回覆原先的資料狀態。 文件的產生:
一般有受過軟體工程訓練的人都知道良好的專案來自事先需求的蒐集,細部規格系統規劃及測試。這些過程需要完整文件建立,但以台灣人來說,要將專案完成又要有完整的文件並不容易。有可能受限於工程師的素質有可能受限於專案時程。再來是,軟體這行業有其獨特經營困境。往往懂客戶需求將之轉化為軟體規格人員其所熟悉的技術已經過時,經常需與技術人員搭配才能將系統完成。但規格開立人員與程式師的溝通有經驗的人都知道這成本是相當驚人。最好的做法是文件與程式碼的建立是一體兩面。如此一來,規格開立人員與程式師溝通成本才會大量降低。
一般文件的產生方向有二種。(1)利用使用者在SA/SD工具所填入參數產生。(2)是逆向由執行檔產生。各由理由也各有優點,因此訊光SA/AD工具能正向與逆向產生文件。 畫面規格UI的輔助設計:
此部份累積訊光長期在工具的努力經驗將之轉化為實用性頗高的模型。以下利用圖示來呈現: 一般SA/SD工具最容易呈現的部分在於UI設計模型部分。容易忽略『表單拋轉』及『資料過帳或表單過帳』,反而使用非常複雜的狀態關聯圖。要使用者花非常多的時間去歸納分析狀態變化,真是相當耗時。 仔細分細一般商業資料流程大致可由此三個步驟歸納而得。
『表單拋轉』:在實務上進貨單的資訊往往與報價單的資訊大致相同。因此,軟體系統會被要求進貨單的資訊可由報價單的資訊轉入。而這樣的案例,在整個軟體系統出現的頻率相當多。其實務的細節是進貨單必須保留欄位,記錄是由哪一類表單轉入,轉入報價單的單號。至於,報價單則必須保留欄位記錄,是否結案,轉出的進貨單的單號。有些更複雜的個案,必須設計挑選UI由系統使用者挑選哪幾筆單號中哪些明細項目,要被轉入。至於進貨單必須隱藏某些欄位,記錄已轉入數量,一旦轉入數量已超過報價單明細項目數量便控制不得再轉入。 『UI設計模型』:拋棄由使用者逐步慢慢分析,一個欄位一個欄位設計,還需注意狀態改變這種做法。改由模板設計內含新增、修改、刪除、查詢及列印等狀態。而且將新增、修改、刪除、查詢及列印等狀態,歸納程六大設計流程。省卻一個欄位一個欄位慢慢分析。
『新增流程』:系統會導引設計者逐步完成。自動編號,欄初始執值。
『修改流程』:系統會導引設計者逐步完成。如何控制某些資料(Reocrd)可修改。
『刪除流程』:系統會導引設計者逐步完成。此筆資料是否真正刪除或只是做Flag。
『查詢流程』:系統會導引設計者逐步完成。查詢畫面的設計及萬用查詢的UI設計。
『列印流程』:系統會導引設計者逐步完成。列印查詢畫面設計、資料結果預覽畫面。 每一個設計流程均會與欄位設計有關。這裡所謂欄位設計是一般由編號帶名稱、欄位不可空白、欄位輸入型態會影響後續欄位的輸入。 資料過帳或表單過帳:
一般工具大概只提供到Table欄位對Table欄位等級的過帳。而未提供表單對表單的過帳。Table對Table的過帳指的是某一個Table的異動(新增、修改及刪除)必須將數值根據鍵值累加、累減或取代別的Table的值。這樣的規劃遇到表單的過帳就顯的力有所未迨。表單過帳指的是一般拆單併單(如請購需根據供應商將請購單拆單成採購單)、自動轉單(例如庫存低於安全庫存自動新增採購單)。花掉程式師最多的時間上線及與SA/SD人員溝通成本是表單過帳。因此強化表單過帳是整套系統的最優先考量。 批次作業的輔助設計:
在一般的專案最挑戰的部分是批次作業,往往牽涉庫存量的結算、庫存成本的計算或帳務的統計。因此,不僅例外狀況特多,程式碼計算的時間也長,而且也牽涉資料庫Commit模式(一筆失敗整批取消、一筆失敗忽略跳下筆)。好的工程師會在某一恰當時機記錄Log,以記錄為何計算無法繼續。因此,協助助工程人員設計Log畫面及資料庫Commit模式。 報表的輔助設計:
一般工具在報表設計所能提供的輔助其實相當有限。因為報表設計其實有兩個層面的問題。一個是設計階段由開發者動手設計報表、另外是由使用單位動手調動報表此階段稱之為執行期。在設計期的需求往往是需要一個快速開的環境,至於執行期則是著重於彈性、簡易來開發。由於與EEP結合,在EEP功能強大的報表功能如清冊、交叉分析及套表均可在SA/SD使用。真正讓規格人員有能力利用本工具完成接近實務的專案。 最後,利用總表來表現SA/SD的功能。 功能模組 功能項目
TABLE SCHEMA的維護 Schema的設計。
Schema的版本更新。
同一欄位在不同Table的版本比較。
現成資料庫欄位匯入系統當成設計欄位。
資料的匯出匯入 M/D資料關係建立。
M/D資料的匯出
M/D資料的匯入。
M/D資料的匯入,可自行定義資料表及欄位。
匯入可自行Log隨時可回復不需先行備份。
文件的產生 正向文件產生
逆向文件產生
Schema、程式模組、畫面及欄位規格。
畫面規格UI的輔助設計 轉單設計
UI設計
資料過帳或表單過帳
ER Model設計
批次作業的輔助設計 資料庫Commit模式
Log的設計
報表的輔助設計 Design time設計
Run time設計
查詢畫面設計
查詢結果挑選畫面
往下追蹤
清冊
交叉分析 系統安裝環境:
1. 產生EEP For Dephi 7.0的程式碼。需有Delphi 7.0才能自動Compiler。
2. 利用ADO與後端資料庫連結。現有資料庫有MS SQL 7.0,MS SQL 2000,ORACLE,INFORMIX。
3. 需與Word 運作才能產生文件。
4. 每一個Client分別授權。 成果預估:
在發展週期上
一般專案大概分幾個時期。(1)是需求蒐集期。(2)是系統開發期。(3)是系統上線期。
可預期利用SA/SD工具之後,第(1)及(2)期的時間會大量下降。傳統需兩個人開發一年然後上線八個月的專案,開發一年這部分會被大幅下降至1~2個月。 在發展品質上
由於利用工具發展可確保每一個人開發流程大致一樣,上線的程式碼是依附在EEP平台。因此,工程師即便是缺乏經驗也很容易在辦公室寫出可資上線的 程式碼,進而確保每一個人產出的程式碼品質是可被確保。 教育訓練
由於工具已發展一系列標準設計流程,減少人員自行研發的過程。因此,新進人員比起傳統開發方式較易訓練。
|
Jasonwong
版主 發表:49 回覆:931 積分:581 註冊:2006-10-27 發送簡訊給我 |
|
查理葉
一般會員 發表:47 回覆:35 積分:16 註冊:2003-03-31 發送簡訊給我 |
|
Jasonwong
版主 發表:49 回覆:931 積分:581 註冊:2006-10-27 發送簡訊給我 |
引言: 目前訊光的sa/sd tool是與EEP 整個緊密結合..但可惜的是它沒有試用版. 如果您真的有興趣.我很誠摯的邀請您參加我們的研討會...甚至直接向我報名 也可以.我的E-MAIL ADD 是 charlie@infolight.com.tw MANY TKS N BEST REGARDS / CHARLIE YEH哦~~我還以為他是一個獨立的工具呢~~原來只是整個架構下的一環~~ -- 聰明的人,喜歡猜心;雖然每次都猜對了,卻失去了自己的心 傻氣的人,喜歡給心;雖然每次都被笑了,卻得到了別人的心
------
聰明的人,喜歡猜心;雖然每次都猜對了,卻失去了自己的心 傻氣的人,喜歡給心;雖然每次都被笑了,卻得到了別人的心 |
查理葉
一般會員 發表:47 回覆:35 積分:16 註冊:2003-03-31 發送簡訊給我 |
|
jackkcg
站務副站長 發表:891 回覆:1050 積分:848 註冊:2002-03-23 發送簡訊給我 |
查理葉 版主 你好 看來 訊光 專區不錯喔 庵也粉想知道 訊光 的產品 到底擁有多少功能能夠減少設計師的程序 (庵無惡意 可別想歪了 哈哈) 版主 有空可以貼貼相關資訊 給網友聞香一下 記的 訊光 的說明會資料滿多的 哈哈 使用 此產品的定位範圍 到底要多大的架構 看來無法參加的網友 還希望 版主 提供一下 謝謝 *********************************************************
哈哈&兵燹
最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好 Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知
K.表Knowlege 知識,就是本站的標語:Open our mind to make knowledge together!
希望能大家敞開心胸,將知識寶庫結合一起
------
********************************************************** 哈哈&兵燹 最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好 Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知 K.表Knowlege 知識,就是本站的標語:Open our mind |
查理葉
一般會員 發表:47 回覆:35 積分:16 註冊:2003-03-31 發送簡訊給我 |
|
Jasonwong
版主 發表:49 回覆:931 積分:581 註冊:2006-10-27 發送簡訊給我 |
引言: DEAR JASON, 非常遺憾,目前SA/SD 不是您所想像的.. 因為EEP 是解決PROGRAMER COADING 的繁瑣流程... 但由於在SA及SD 這邊並沒有完整解決.所以訊光才會發展這個前端工具. 去彌補EEP不足的地方. 但~~~~~~值得慶幸的是.....此次研討會主題是SA/SD 工具發表及兩岸 三地的解決方案....不知JASON 您想參加哪一場 ?? CHARLIE YEH什麼時候辦~~在那裡辦啊~~ -- 聰明的人,喜歡猜心;雖然每次都猜對了,卻失去了自己的心 傻氣的人,喜歡給心;雖然每次都被笑了,卻得到了別人的心
------
聰明的人,喜歡猜心;雖然每次都猜對了,卻失去了自己的心 傻氣的人,喜歡給心;雖然每次都被笑了,卻得到了別人的心 |
查理葉
一般會員 發表:47 回覆:35 積分:16 註冊:2003-03-31 發送簡訊給我 |
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |