公告版位

目前日期文章:200902 (6)

瀏覽方式: 標題列表 簡短摘要

院的資訊系統還算滿龐大複雜的,複雜的並不是軟體程式技術艱深,而是流程邏輯不簡單,單以程式碼規模來看,資訊室所維護的HIS、MIS系統居然高達630萬行上,這些程式都是經年累月,透過許許多多人員的建構,這些人包含了原始提出需求的使用者,也包含開發軟體的資訊人員,截至目前為止,伴隨著這些程式一路走來,仍然在職的原始需求使用者可能所剩無幾,資訊室所剩的程式設計師不到四分之一的人參與過最初的系統開發規劃,其他大部分的人都是承接前人的系統進行維護。

人員的流動是企業經營的常態,但流動對企業所帶來的有許多負面影響,其中一項就是經驗傳承的斷層。某些單位在早期進行資訊化時,由該單位資深人員與資訊人員進行資訊化發展規劃,資訊人員在合理、成本與技術的考量下都會盡其所能的將系統完成,系統從規劃、開發到上線,經歷了不少時間,也耗費了許多人力,系統上線後,如果是中小型系統也都必須3~6個月的修改與磨合才能讓使用者順暢使用,如果遇到大型系統,如住院醫囑、急診醫囑,從上線到穩定運作,都耗費近一年。

有人說,系統上線才是資訊人員的夢靨,因為使用者才會開始提出需求。提出需求?這不是規劃期所做的事情嗎?很不幸的,很多人都會在看到系統後才發揮想像力與創造力,另一方面,系統實際上線後也才能讓使用者或使用單位「用心體會」,提出各種功能「優化」、「個人化」、「人性化」的需求,這也是為什麼資訊室自行開發的資訊系統與委外購買的資訊系統導入時程有所差異,廠商對我們的責任,只需做到系統上線前的規劃承諾,資訊室除了達到規劃承諾外,還必須提供系統上線後的「優化」、「個人化」、「人性化」的需求。

從系統開發到上線到穩定,歷經許多人的創意與構思,穩定運作的系統在歷經數年的運作後,某些會漸漸出現異常,也開始有許多人提出了他們的疑問,最常聽到的是:這報表怎麼怪怪的?這金額是怎麼算出來的?這個功能我們從來沒使用過,這我不清楚,你要去問......,這些問題都是出現在系統上線後3~5年開始,提問題的人常常都不會是系統開發時的原始需求者,這些系的統報表、功能、使用方法、使用時機、注意事項經過幾手交接後早早已被人遺忘,電話那頭的資訊人員也被問的一頭霧水,因為他們大部分也沒參與原始開發。許多系統功能會因為環境與人員應適時調整,使用單位歷經幾次人員異動後,往往把很多的資訊作業的發展原始目的都給遺忘,也常常拿現在的思維去解讀前人的設計,忽略時空背景的不同,為何以前看起來對的東西現在卻有問題。

資訊人員的異動,也存在著這樣的問題,某些後進人員打開所承接前人的資訊系統,看的懂,能維護,卻無法清楚得知此系統在不同時空環境下應該有所修改,誤解為設計時期的瑕疵,為了避免這樣的問題,資訊人員花了不少的時間進行記錄,從系統開發文件、系統修改反應單、修改記錄、程式註解等等,嘗試著能由文件將系統發展歷程記錄下來,作為未來追蹤時的參考,系統建置所留下來的文件除了讓未來有跡可尋,另一個層面則是從中歸納出專業領域知識,增進工作效能,避免重複錯誤,因此,「看文件」與「做文件」一樣的重要。

lcjan 發表在 痞客邦 留言(1) 人氣()

工作環境資訊安全考量,需管制隨身碟使用,因此早在兩年前就開始尋覓禁用隨身碟技術文件,陸陸續續做了許多管制程式與機制,但始終不盡理想,終於在這星期,連續花了三天爬了很多網站,程式終於寫好了!

真是令人痛哭流涕,終於完成。程式不大,功能簡單,重點是"我自己寫的SourceCode",有完整程式碼,想怎麼改,想怎麼用都行,這才能未後續其他軟體的發展鋪路。

爬網站的過程中,我找到了一些相關工具,對禁用隨身碟這方面而言真的很棒,需要的人可以去下載:

USBDeview:
寫的功能非常完整,真的很厲害,能出報表,能接受外部命令

lcjan 發表在 痞客邦 留言(4) 人氣()

  話說我找管控USB隨身碟的技術已經找了一年多,一直沒找到滿意的解決方式,直到昨天,有些許進展,從阿兜仔的網站找到阿陸仔的網站,漸漸感受到,程式越寫越來越接近微軟。
 
昨天好不容易找的許多片段的Code,修修改改,從Delphi 6的Code改成Delphi 5可以Run,改了好久,終於Compile....Run!  哇終於!跑起來,正高高興的時候,進行第一次Debug分段執行:
TTT001.JPG 
在跑迴圈跑時F8(下一步)...F8(下一步)...F8(下一步)...一次一次按著

lcjan 發表在 痞客邦 留言(0) 人氣()

緣由
    出自一個奇怪的想法:「當磁碟代號被用完,插入一支隨身碟會如何?」。一直想找禁用隨身碟的原始碼,一直遍尋不著,今天瀏覽網站時突然有一個想法:『禁不了,就讓你沒磁碟機用!』,因此進行簡單實驗去驗證。
 
做法
    有兩個指令可以創造磁碟:Subst與Net 。

lcjan 發表在 痞客邦 留言(0) 人氣()

又是新的一年,期待這一年,系統能穩定,工作能快樂!最近在調整資料庫,從這一連串的事件中我看了一些事情,跟大家分享我的看法。

97年這一路走來在公司資料庫方面發生了幾件重要的事件,先是帳務主機過帳緩慢,導致許多高層想看的營運資訊無法即時呈現,因此我去跟長官報告過,我們資訊單位內部也組成了專案小組來討論與改善,這過程似乎不是一蹴可幾,花了幾個月,系統組、維護課、開發組都想辦法去找解決方案,更換Client端作業系統、研究過帳程式邏輯、進行效能實驗、追蹤SQL語法、資料庫效能分析、主機效能分析.......DBA找出了一些效能瓶頸,並提供了Full Scan Table,過帳程式負責人改了程式邏輯,最後獲得了改善,我鬆了一口氣,使用者終於不用愁眉苦臉。

下半年,開始出現Session不足(嚴格說該是主機資源不足),辛苦的同事開始接電話,電話那頭傳來的聲音當然不會是贊許,三不五時的電話持續了很久,大家都快耐不著性子,我也是,長官們也是,我看到許多同仁被電話那頭責罵,心有不忍,我又跟DBA們去研究如何改善,過程一樣,不是一蹴可幾,在許多資料的蒐集與分析,許多次的討論與交換心得,找出了很多解決方向,主機加記憶體、改變資料庫模式、切斷資料庫耦合性、改善既有程式、研發降低Session的機制.....有方法,也有在執行,執行的人需要時間,更需要承擔風險,我,身為主管,更要去思考如何對萬一負責。98年1月初,先從分公司改變資料庫模式,可以Work,但不見得有效能上的幫助,總公司電話還是一直來,我看到大家電話接到手軟,工作情緒一直被干擾,終於忍不住,在1/13請DBA改變了資料庫模式,因為不需停機,因此可以馬上調整,但卻驗證了這條路是行不通,又讓大家遭受到更多電話的責難,也讓DBA承受更大的壓力。過年前,在與維護廠商DBA討論下,從四台主機又挖出一兩百MB記憶體,當天緊急停機馬上調整,當然讓也同事措手不及,為的只想讓大家過完年後不要接到線上Session不足的電話,因此,我決定當天就調整!目前情況還不錯,觀察中,需要再一星期驗證。

lcjan 發表在 痞客邦 留言(2) 人氣()

來自朋友的E-Mail

 2009年聖嚴法師的祝福

 

lcjan 發表在 痞客邦 留言(0) 人氣()