(esp. of an argument, story, or sentence) Extremely complex and difficult to follow
- its convoluted narrative encompasses all manner of digressions
Intricately folded, twisted, or coiled
- walnuts come in hard and convoluted shells
Wednesday, November 21, 2012
Sunday, November 18, 2012
sluggish GUI
Slow-moving or inactive
- a sluggish stream
Lacking energy or alertness
- Alex woke late feeling tired and sluggish
Slow to respond or make progress
- the car had been sluggish all morning
very sluggish GUI response time
- a sluggish stream
Lacking energy or alertness
- Alex woke late feeling tired and sluggish
Slow to respond or make progress
- the car had been sluggish all morning
very sluggish GUI response time
Tuesday, November 13, 2012
demonstrably
Clearly and undeniably
- the situation is demonstrably unfair
@STATUS_ACCESS_DENIED I'm not arguing with the idea of making money with software, nor with using RDP as an alternative. I'm arguing with Teamviewer's assumption that everyone who is using Windows Server is doing so for commercial purposes, as well as your assumption that everyone who is using Windows Server paid for the full retail licence and thus can afford <software x="x">. Both assumptions are demonstrably wrong. – Indrek May 19 at 19:06
http://superuser.com/questions/377140/teamviewer-on-windows-server-machines
- the situation is demonstrably unfair
@STATUS_ACCESS_DENIED I'm not arguing with the idea of making money with software, nor with using RDP as an alternative. I'm arguing with Teamviewer's assumption that everyone who is using Windows Server is doing so for commercial purposes, as well as your assumption that everyone who is using Windows Server paid for the full retail licence and thus can afford <software x="x">. Both assumptions are demonstrably wrong. – Indrek May 19 at 19:06
http://superuser.com/questions/377140/teamviewer-on-windows-server-machines
neglect
Fail to care for properly
- the old churchyard has been sadly neglected
Not pay proper attention to; disregard
- you neglect our advice at your peril
Fail to do something
- he neglected to write to her
- the old churchyard has been sadly neglected
Not pay proper attention to; disregard
- you neglect our advice at your peril
Fail to do something
- he neglected to write to her
quirk
A peculiar behavioral habit
- his distaste for travel is an endearing quirk
A strange chance occurrence
- a strange quirk of fate had led her to working for Nathan
A sudden twist, turn, or curve
- wry humor put a slight quirk in his mouth
An acute hollow between convex or other moldings
- his distaste for travel is an endearing quirk
A strange chance occurrence
- a strange quirk of fate had led her to working for Nathan
A sudden twist, turn, or curve
- wry humor put a slight quirk in his mouth
An acute hollow between convex or other moldings
glitch
A sudden, usually temporary malfunction or irregularity of equipment
- a draft version was lost in a computer glitch
An unexpected setback in a plan
- this has been the first real glitch they've encountered in a three months' tour
A brief irregularity in the rotation of a pulsar
- a draft version was lost in a computer glitch
An unexpected setback in a plan
- this has been the first real glitch they've encountered in a three months' tour
A brief irregularity in the rotation of a pulsar
Sunday, November 11, 2012
創新力與執行力必須以專業為基礎
這幾天看一齣韓國的連續劇,內容是描寫一個非常喜歡做皮鞋設計的女主角,因為不是科班出身,設計出來的圖樣基礎非常不好,但是社長看到他的設計創意十足,因此請他進來在打樣室做粗重的工作,從基礎做起--《蕃茄》。
姑且不論這齣戲有多八股或是劇情的發展有多惡毒,我們往往只看到成功的人光鮮亮麗的一面,看不到他被後打拼階段的基礎,這一點在所有事情都是網路的時代更是明顯,我們往往會想到很多很多的創意,但是等到後續要執行的階段,不是發現資源不足就是策略方法錯誤。
在軟體設計的領域裡面,我們往往會聽到業務單位說,為什麼軟體設計單位花了這麼多時間開發我們不需要的功能呢?這除了是溝通不良之外,往往是兩個單位的人彼此的專業性不夠,軟體設計單位要充分的了解市場競爭者的現況,綜合客戶的需求等等,我們並不是一昧的聽單一客戶的訊息來修改,而是要走在客戶的前端,產品市場的前端,服務需求的前端。
在一個工作領域要培養專業能力並不是非常容易的,第一個是部門單位的專業分工,使得一個人經常只能在自己的工作領域上努力,而且犯了當局者迷的錯誤,除了自己在工作上要找出自己的專業能力外,我們也要了解別的單位的專業能力,更要了解公司整體的專業能力,如果在軟體設計的領域裡面,雖然現在的開發工具非常的容易使用,但是舉凡作業系統、資料結構、物件導向概念、主從架構(Client/Server)等等,就是最基礎最基礎的專業,無論是經驗法則苦練出身的軟體研發工程師,或是本科系出身的工程師,我想基礎打好是最重要的,十倍速的網路時代,其實是可以邊做邊學的。
前幾天跟同事討論,軟體操作功能表的演進,從Windows 3.1 時代的標準功能表(檔案、編輯、檢視...) 到工具列(Tool bar)的發展,到現在瀏覽器上面大大小小的組合下拉式選單(ComboBox),或彈出式(Popup)選單我們是否已經被微軟牽著鼻子走呢?如果我們能創新出更好的操作介面,是否更要考慮到讓客戶更好用呢?
Reference:
http://next.writers.idv.tw/1999/12/blog-post.html
撰寫規格文件的重點
一個好的系統除了要有良好的架構之外,他的價值有一大部分是不斷的維護系統而符合需求,貼進客戶的實際需要,這個中間修改的過程除了人的因素之外還有設備的更新,作業平台的轉變所造成的種種變因,所以留下規格文件供未來的人來參考改進非常的重要。
文件撰寫的重點並不是要寫的通順或是像寫小說文章一樣來湊字數,所有的開發文件林林總總,我們這一次討論的重點放在軟體系統規格的部分,由於程式設計師總是覺得寫程式看程式碼就好了,但是如果過了一年之後,你回去看你的程式碼你還會有印象嗎?更何況是別人要看你的程式碼了,其實規格文件的重點只有幾項,就是系統平台、程式碼架構、傳輸協定、檔案(資料庫)架構、模組流程等五大項,有了這些文件,往後的人員只要花個幾分鐘看一下,就可以很容易的維護別人的程式及系統了。
系統平台:其實是最好描述的,只要說明作業系統是Windows95/98或者是Linux、AS/400等等,然後使用的開發工具是VB/ASP或者是Visual C++,BCB 等等,最好要把版本號碼或是一些比較特殊的程式庫也要列上去。
程式碼架構:這一項通常會被大部分的人所遺漏,很多人是靠開發工具所提供的整合環境來分類,固然是很好,但是每個人應用的專案檔案(*.DSW,*.DSP,*.IDE 等等)並不會相同,也就是說你好不容易整理好的專案檔,也寫了一大堆說明文件,但是只是給你自己用而已,這部分最好還是要寫辦法製成文件分享給所有的人。
傳輸協定:無論是區域網路、網際網路的協定,或是單機自己內部傳遞資料一定有傳輸的協定,最普通的當然是TCP/IP了,而現在WEB Server或是EMail Server 的普及很多系統都應用網路七層協定的更高層來傳遞資料,這些都應該說明清楚,如果系統出來問題才知道如何查詢,而Windows系統內的訊息傳輸,也算是傳輸協定的一種,而兩個模組之間的Function傳遞也是,如果是重要且獨立的元件模組,應該要特別的強調才是。
檔案(資料庫)架構:除了關聯式資料庫比較容易寫出規格之外我們經常應用到的設定檔(Config),例如*.INI的檔案,還有為了系統效能或是儲存資料、交換資料所儲存的資料檔案,應該都要有格式的說明,以及生成時間版本號碼的資訊,有了這一個規格表,即時是程式碼不見了,我們都可以很容易的重寫出部分的模組,而不用經常得去猜去破解一些資料檔的格式。
模組流程:是最早最早結構化資料分析的時候必須具備的流程圖,但是在物件導向的程式開發,我們經常會把流程圖隨著物件化而簡化,但是也僅僅是改良罷了,他的精神就是輸入與輸出的前後順序一定要清楚的表達出來,雖然現在的程式系統應用了很多訊息是觸發的事件來處理或是多執行緒的程式處理,一個良好的流程圖也可以表現出一個系統的邏輯性,有助於找出系統需要改進的地方,與如何維護的方向。
做文件並不是主管或者是某一些人的責任,應該是所有的程式設計師應該培養要定期製作的能力,除了可以有良好的溝通方法之外,也可以重新檢視一下自己的系統架構,把自己的能力向上提昇。
Reference:
http://next.writers.idv.tw/2001/01/blog-post.html
文件撰寫的重點並不是要寫的通順或是像寫小說文章一樣來湊字數,所有的開發文件林林總總,我們這一次討論的重點放在軟體系統規格的部分,由於程式設計師總是覺得寫程式看程式碼就好了,但是如果過了一年之後,你回去看你的程式碼你還會有印象嗎?更何況是別人要看你的程式碼了,其實規格文件的重點只有幾項,就是系統平台、程式碼架構、傳輸協定、檔案(資料庫)架構、模組流程等五大項,有了這些文件,往後的人員只要花個幾分鐘看一下,就可以很容易的維護別人的程式及系統了。
系統平台:其實是最好描述的,只要說明作業系統是Windows95/98或者是Linux、AS/400等等,然後使用的開發工具是VB/ASP或者是Visual C++,BCB 等等,最好要把版本號碼或是一些比較特殊的程式庫也要列上去。
程式碼架構:這一項通常會被大部分的人所遺漏,很多人是靠開發工具所提供的整合環境來分類,固然是很好,但是每個人應用的專案檔案(*.DSW,*.DSP,*.IDE 等等)並不會相同,也就是說你好不容易整理好的專案檔,也寫了一大堆說明文件,但是只是給你自己用而已,這部分最好還是要寫辦法製成文件分享給所有的人。
傳輸協定:無論是區域網路、網際網路的協定,或是單機自己內部傳遞資料一定有傳輸的協定,最普通的當然是TCP/IP了,而現在WEB Server或是EMail Server 的普及很多系統都應用網路七層協定的更高層來傳遞資料,這些都應該說明清楚,如果系統出來問題才知道如何查詢,而Windows系統內的訊息傳輸,也算是傳輸協定的一種,而兩個模組之間的Function傳遞也是,如果是重要且獨立的元件模組,應該要特別的強調才是。
檔案(資料庫)架構:除了關聯式資料庫比較容易寫出規格之外我們經常應用到的設定檔(Config),例如*.INI的檔案,還有為了系統效能或是儲存資料、交換資料所儲存的資料檔案,應該都要有格式的說明,以及生成時間版本號碼的資訊,有了這一個規格表,即時是程式碼不見了,我們都可以很容易的重寫出部分的模組,而不用經常得去猜去破解一些資料檔的格式。
模組流程:是最早最早結構化資料分析的時候必須具備的流程圖,但是在物件導向的程式開發,我們經常會把流程圖隨著物件化而簡化,但是也僅僅是改良罷了,他的精神就是輸入與輸出的前後順序一定要清楚的表達出來,雖然現在的程式系統應用了很多訊息是觸發的事件來處理或是多執行緒的程式處理,一個良好的流程圖也可以表現出一個系統的邏輯性,有助於找出系統需要改進的地方,與如何維護的方向。
做文件並不是主管或者是某一些人的責任,應該是所有的程式設計師應該培養要定期製作的能力,除了可以有良好的溝通方法之外,也可以重新檢視一下自己的系統架構,把自己的能力向上提昇。
Reference:
http://next.writers.idv.tw/2001/01/blog-post.html
寫程式一定要先寫規格文件嗎?
寫程式一定要先寫規格文件嗎?
2009/9/13 下午 11:24:03
很慚愧寫了七八年程式從沒有好好寫過文件,最近開始認真思考”程式無錯就優” 和”文件的重要性”,每當上頭交代下來一個功能或模組,了解需求後就開始直接寫,所有的架構和流程都在頭腦裡,兩個小時就可以交差了,程式也可以跑,正常情況下也都不會有錯。
但仔細思考下面幾個問題,
這個程式有哪些狀況,會導致致命的錯誤?
如果發生錯誤,程式會有哪些狀況?
如果發生錯誤,程式還會繼續跑嗎?
要增加新功能或功能不堪使用!!
使用者反應程式越跑越慢!!
使用者反應程式有漏資料!!
還有過一段時間後,你還記得程式怎麼寫的嗎?
為了應付上面問題,肯定會把程式翻出來看,然後再重寫,過不了多久明明是一個簡單的程式,變成不是異常龐大就是怪獸,然後改了這個壞了那個。有研究指出因為修改需求,而導致其他錯誤發生的機會有20%~50%。
而上面的還只是一個小模組或小功能,如果是一個專案呢?那真是很難想像,在一個怪獸級專案上面維護和加功能需求,每天除不完的Bug,加不完的班。
因為沒有像樣的文件,連要找人來寫,都要解釋半天,最後只好自己寫比較快。
因此多年後的現在,我開始思考規格文件的重要,要如何寫?軟體工程很多理論,到底那一套才是有效的?我應該要學哪一種理論?那一種理論適合我現在的工作,並且可以馬上適用?
最後我領悟與歸納出下面的方式,來應付小專案或小模組的開發模式
1. 採用物件導向開發,但一定要研究過物件設計模式,因為如果沒有研究過設計模式,寫出來的程式充其量只能說是物件化的模組,對於這個我最近有深切體會。
2. 善用活動圖,物件圖與循序圖,著手開發前一定要至少畫出物件圖,不過一定要研究過設計模式,並且有深刻研究過物件導向的特色,這樣畫出來的圖才可以真正的表現出物件導向的特點。
3. 時時重構,每開發完一個功能後,必須審視您的物件圖與程式是否一致,並思考程式是否有符合物件導向最高原則,開放封閉原則,一旦發現可以調整的地方就要重構。
4. 自動化單元測試,因為採物件導向的開發,所以可以很容易的撰寫單元測試的程式,這樣往後的每次修改,只要將單元測試拿出來跑一次,就知道這次的修改是否有影響到其他的程式,至少可以保證一定的程式品質。所以單元測試程式隨著功能的增加,會越累積越多。
有一種軟體開發方式XP敏捷式開發,就是講究開發之前要先寫單元測試,叫做測試驅動,透過先撰寫測試程式來引發需求功能,不過個人認為開發前最好要先劃出物件圖。
當然上面的方式只是用來開發小型功能或模組適用,要開發大型專案,就這點當然不夠,專案開發包含了時程人力規劃,時程追蹤,測試規劃,系統架構規劃,系統整合等…。
2009/9/14 上午 01:19:48
測試驅動跟你的「開發前最好要先劃出物件圖」並沒有直接的衝突。
測試驅動講求的是feedback,由另一個完全不同的角度下去思考程試的架構。你可以先有一個想法(比如你所謂的先劃出物件圖),用測試驅動來看看這個架構好不好,利用這個測試得到的feedback來不斷修改。或者,你也可以直接使用測試驅動來引導出理想的設計。測試驅動也會使你往後的自動化單元測試更容易撰寫。
我不知道物件導有所謂的「最高原則」。不過Uncle Bob提出他對OOD的想法,簡稱SOLID principle。Open Closed principle只是其中一個。
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
使用測試驅動後,都會很自然的得到符合SOLID的設計。也許你可以參考看看。
2009/9/14 上午 08:53:50
感謝您的糾正~~
我再補充依下,物件導向的確是有很多其他觀點,
我用錯了描述,不應該用最高指導原則,我想表達
的是,不管是依賴到轉、里氏替換...等,其實應該
都是要達到"開放封閉"的原則,當然這只是我的體
會。
另外關於您說的透過"測試驅動",來驗證"物件圖",
並找出需要修正的地方,我認為非常有道理,有機會
我會來試試看。
2009/11/16 上午 12:55:19
文件是一定要的. 我當PM的經驗和做法是 必須文件交出後, 才可以算是完成 一項里程(Milestone), 文件交付客戶前, 專案經理及主要規劃人員要簽字, 表示負責的態度. 然後, 要求客戶簽字.
當然, 文件必須依雙方談妥的內容記載 要求客戶簽字前, 也要有合理的時間讓客戶詳閱,.客戶簽字逾期, 下個里程會順延.
以客戶簽字的憑證 證明客戶同意我們幫他們所規劃或設計的內容. 這樣的憑證有下列的作用:
1. 證明專案進度已經完成一個里程, 可以請領這個里程的工程款.
2. 我方保證依文件的內容作為下 一階段的基礎, 專案進度往下一個里程前進.
3. 組員與客戶或下包商都以文件作為溝通的憑據. 當然, 各個參與專案的成員所規劃或設計的內容的必須符合文件規範.
4. 客戶如果要變更先前同意的事項, 必須負擔因變更所產生的費用.
文件的名稱與里程之對照如下:
里程名稱 文件名稱
---------------- ----------------------------------------
開工會議 專案計畫書
需求訪查 需求規範書
高階設計 功能規範書
細部設計 細部設計文件
品質保證 品質保證計畫書
程式設計 程式及Release Note.
整合測試 整合測試報告書
系統導入 導入計畫書
客戶驗收 結案報告書與系統保固書
有些合約是完成幾個里程, 才請領一次工程款.
以上的做法在中大型的專案是絕對必要. 就開發成本來說, 好像是高出許多, 但實際上, 會減少失誤的機率與後續的維護成本. 總成本不會增加.
樓主所言軟體工程的方法, 也要在專案計畫書中述明. 因為軟體工程的方法不同, 因為文件的交付項目或交付的時間會依方法不同而異. 例如採用測試驅動設計方法時品質保證計畫書應在功能規範書出來後不久就要完成, 而且測試的程式也必須列入清單或交付項目. 如何規範則是合約內容而定.
2009/11/16 上午 10:57:35
market requirement document from project manager , then software manager will follow it and discuss with project manager and other related staffs to design a software requirement specification or software requirement document.
this doc is an engineering specification , of course , you may refere to some industrial standards , such as IEEE or dod and so forth. In this doc , software manager uses some modeling languages , e.g. UML or SSADM , DFD to describe those features and floows those principles which were proposed by IEEE.
Once SRS has been completed , software architect starts designing software arcitectures . Software architecture has no any specified principles , he or she designs it alternatively.
When the softwre architecture has been completed , software engineers or programmers start coding or programming those modules which they own in some high level programming languages , such as C/C++, java, C#,
vb, delphi and so forth , meanwhile , they should design those docs - SDD ( software description documents) in
some pesudo languages , such as PDL or english-like programming languages.
this process belongs to the verification phase of V&V model. Of course , in this model still exists a problem , that is ,
when your customers want to the result of design in early stage, this model will face some difficultities.
because engineering team spends a lot of time to design documentations , customers will see their products in later stages. All processes were well-defined.
Reference:
http://www.programmer-club.com/showSameTitleN/exp/13992.html
2009/9/13 下午 11:24:03
很慚愧寫了七八年程式從沒有好好寫過文件,最近開始認真思考”程式無錯就優” 和”文件的重要性”,每當上頭交代下來一個功能或模組,了解需求後就開始直接寫,所有的架構和流程都在頭腦裡,兩個小時就可以交差了,程式也可以跑,正常情況下也都不會有錯。
但仔細思考下面幾個問題,
這個程式有哪些狀況,會導致致命的錯誤?
如果發生錯誤,程式會有哪些狀況?
如果發生錯誤,程式還會繼續跑嗎?
要增加新功能或功能不堪使用!!
使用者反應程式越跑越慢!!
使用者反應程式有漏資料!!
還有過一段時間後,你還記得程式怎麼寫的嗎?
為了應付上面問題,肯定會把程式翻出來看,然後再重寫,過不了多久明明是一個簡單的程式,變成不是異常龐大就是怪獸,然後改了這個壞了那個。有研究指出因為修改需求,而導致其他錯誤發生的機會有20%~50%。
而上面的還只是一個小模組或小功能,如果是一個專案呢?那真是很難想像,在一個怪獸級專案上面維護和加功能需求,每天除不完的Bug,加不完的班。
因為沒有像樣的文件,連要找人來寫,都要解釋半天,最後只好自己寫比較快。
因此多年後的現在,我開始思考規格文件的重要,要如何寫?軟體工程很多理論,到底那一套才是有效的?我應該要學哪一種理論?那一種理論適合我現在的工作,並且可以馬上適用?
最後我領悟與歸納出下面的方式,來應付小專案或小模組的開發模式
1. 採用物件導向開發,但一定要研究過物件設計模式,因為如果沒有研究過設計模式,寫出來的程式充其量只能說是物件化的模組,對於這個我最近有深切體會。
2. 善用活動圖,物件圖與循序圖,著手開發前一定要至少畫出物件圖,不過一定要研究過設計模式,並且有深刻研究過物件導向的特色,這樣畫出來的圖才可以真正的表現出物件導向的特點。
3. 時時重構,每開發完一個功能後,必須審視您的物件圖與程式是否一致,並思考程式是否有符合物件導向最高原則,開放封閉原則,一旦發現可以調整的地方就要重構。
4. 自動化單元測試,因為採物件導向的開發,所以可以很容易的撰寫單元測試的程式,這樣往後的每次修改,只要將單元測試拿出來跑一次,就知道這次的修改是否有影響到其他的程式,至少可以保證一定的程式品質。所以單元測試程式隨著功能的增加,會越累積越多。
有一種軟體開發方式XP敏捷式開發,就是講究開發之前要先寫單元測試,叫做測試驅動,透過先撰寫測試程式來引發需求功能,不過個人認為開發前最好要先劃出物件圖。
當然上面的方式只是用來開發小型功能或模組適用,要開發大型專案,就這點當然不夠,專案開發包含了時程人力規劃,時程追蹤,測試規劃,系統架構規劃,系統整合等…。
2009/9/14 上午 01:19:48
測試驅動跟你的「開發前最好要先劃出物件圖」並沒有直接的衝突。
測試驅動講求的是feedback,由另一個完全不同的角度下去思考程試的架構。你可以先有一個想法(比如你所謂的先劃出物件圖),用測試驅動來看看這個架構好不好,利用這個測試得到的feedback來不斷修改。或者,你也可以直接使用測試驅動來引導出理想的設計。測試驅動也會使你往後的自動化單元測試更容易撰寫。
我不知道物件導有所謂的「最高原則」。不過Uncle Bob提出他對OOD的想法,簡稱SOLID principle。Open Closed principle只是其中一個。
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
使用測試驅動後,都會很自然的得到符合SOLID的設計。也許你可以參考看看。
2009/9/14 上午 08:53:50
感謝您的糾正~~
我再補充依下,物件導向的確是有很多其他觀點,
我用錯了描述,不應該用最高指導原則,我想表達
的是,不管是依賴到轉、里氏替換...等,其實應該
都是要達到"開放封閉"的原則,當然這只是我的體
會。
另外關於您說的透過"測試驅動",來驗證"物件圖",
並找出需要修正的地方,我認為非常有道理,有機會
我會來試試看。
2009/11/16 上午 12:55:19
文件是一定要的. 我當PM的經驗和做法是 必須文件交出後, 才可以算是完成 一項里程(Milestone), 文件交付客戶前, 專案經理及主要規劃人員要簽字, 表示負責的態度. 然後, 要求客戶簽字.
當然, 文件必須依雙方談妥的內容記載 要求客戶簽字前, 也要有合理的時間讓客戶詳閱,.客戶簽字逾期, 下個里程會順延.
以客戶簽字的憑證 證明客戶同意我們幫他們所規劃或設計的內容. 這樣的憑證有下列的作用:
1. 證明專案進度已經完成一個里程, 可以請領這個里程的工程款.
2. 我方保證依文件的內容作為下 一階段的基礎, 專案進度往下一個里程前進.
3. 組員與客戶或下包商都以文件作為溝通的憑據. 當然, 各個參與專案的成員所規劃或設計的內容的必須符合文件規範.
4. 客戶如果要變更先前同意的事項, 必須負擔因變更所產生的費用.
文件的名稱與里程之對照如下:
里程名稱 文件名稱
---------------- ----------------------------------------
開工會議 專案計畫書
需求訪查 需求規範書
高階設計 功能規範書
細部設計 細部設計文件
品質保證 品質保證計畫書
程式設計 程式及Release Note.
整合測試 整合測試報告書
系統導入 導入計畫書
客戶驗收 結案報告書與系統保固書
有些合約是完成幾個里程, 才請領一次工程款.
以上的做法在中大型的專案是絕對必要. 就開發成本來說, 好像是高出許多, 但實際上, 會減少失誤的機率與後續的維護成本. 總成本不會增加.
樓主所言軟體工程的方法, 也要在專案計畫書中述明. 因為軟體工程的方法不同, 因為文件的交付項目或交付的時間會依方法不同而異. 例如採用測試驅動設計方法時品質保證計畫書應在功能規範書出來後不久就要完成, 而且測試的程式也必須列入清單或交付項目. 如何規範則是合約內容而定.
2009/11/16 上午 10:57:35
market requirement document from project manager , then software manager will follow it and discuss with project manager and other related staffs to design a software requirement specification or software requirement document.
this doc is an engineering specification , of course , you may refere to some industrial standards , such as IEEE or dod and so forth. In this doc , software manager uses some modeling languages , e.g. UML or SSADM , DFD to describe those features and floows those principles which were proposed by IEEE.
Once SRS has been completed , software architect starts designing software arcitectures . Software architecture has no any specified principles , he or she designs it alternatively.
When the softwre architecture has been completed , software engineers or programmers start coding or programming those modules which they own in some high level programming languages , such as C/C++, java, C#,
vb, delphi and so forth , meanwhile , they should design those docs - SDD ( software description documents) in
some pesudo languages , such as PDL or english-like programming languages.
this process belongs to the verification phase of V&V model. Of course , in this model still exists a problem , that is ,
when your customers want to the result of design in early stage, this model will face some difficultities.
because engineering team spends a lot of time to design documentations , customers will see their products in later stages. All processes were well-defined.
Reference:
http://www.programmer-club.com/showSameTitleN/exp/13992.html
Thursday, November 8, 2012
PHPExcel read open write Microsoft Excel
PHPExcel is a library written in pure PHP and providing a set of classes that allow you to write to and read from different spreadsheet file formats, like Excel (BIFF) .xls, Excel 2007 (OfficeOpenXML) .xlsx, CSV, Libre/OpenOffice Calc .ods, Gnumeric, PDF, HTML, ... This project is built around Microsoft's OpenXML standard and PHP.
Reference:
https://github.com/PHPOffice/PHPExcel
Reference:
https://github.com/PHPOffice/PHPExcel
Tuesday, November 6, 2012
Problem Steps Recorder take screenshot start > run > psr
Problem Steps Recorder
take screenshot
start > run > psr
another built-in tool:
start > run > SnippingTool
take screenshot
start > run > psr
another built-in tool:
start > run > SnippingTool
Subscribe to:
Posts (Atom)