2009年12月11日

切

其實你是個相當不討喜的人

只是你有一群不介意的朋友

也許是你的環境，也許是你極端的個性

也許你只是想跟別人不一樣而已

你很有你自己的想法

甚至

倔強到不承認自己倔強

這樣的確不是壞事

你的成功會源自於此

失敗亦然

總是把自己的觀念，套在別人身上

總是抱怨別人不依照那套你的想法來做事

你認為的最好，卻不是別人眼中的最好

而你掙扎著

再這兩者之間

究竟是事情完成就好

還是過程最重要

甚至是完成事情後的效益有多高

抑或過程花費的資源最少

大家都二十出頭了

個性鮮明

什麼樣的人，怎麼做事

大概就那樣了吧

遇到相左的意見

你總說不懂

是不願懂吧

你自己保護著自己的想法

不願意去聽

怎麼會懂？

非得要鐵一般的證據

你才願意屈服

好吧，你說了算

你，超難溝通

我也沒耐性了

你愛怎樣就怎樣吧

早認了我們沒未來

我認清了自己耐性的底限
On 1 則留言:

2009年12月1日

葬

鬥嘴久了

即使你說出來的話是多麼的有道理

到了我耳裡

還是刺得不舒服

那天你在淡水漁人碼頭問我

是因為不甘心嗎？

不甘心還會跟你承認嗎？，切

想著在那些日子裡的遺憾

想著在那些日子裡的任性

想兩個人的癥結點在哪

想找出原因

可惜感情的事情。無解

無論如何經營，逝去的東西

就是逝去了

即使解決問題，也不會回來

即使有心，也不一定能擁有

即使讓步，也不未有轉圜。

這是一個有百分之五十會撲空結果


在我對自己的認知裡

不會把時間浪費在沒有未來的事物上

我們，沒有未來

我想的一點都不久

早在，開學那一刻

只是想著，讓這段關係

平淡的結束，誰也不欠誰，誰也不怨誰

一個多月後，我不耐煩了

然後，葬送這段感情
On 沒有留言:

2009年11月28日

世界呢

成長的代價

也許是付出了，但不保證收的回來

根據質能守恆

即使是散失的能量也會變成熱

可是，

熱卻不是我們要的結果

天真的你不會去計較，究竟散失了多少變成熱

哪天不天真了呢。

才注意到，熱產生了雲

是烏雲

打著雷，就像剛分手那一瞬間

然後

下著雨

之後

雨過天晴

有些人，這一路，走了一個月

有些人，走了一年

有些人，走了一輩子

直到換了個心境

我的世界

還在下雨

。
On 沒有留言:

2009年11月17日

好冷

今天九點多。

外出

買宵夜，

剛好是到垃圾的時間。

靠。

有一個小孩拎著垃圾飄過來！

結果是個穿溜冰鞋的死小鬼

嚇死我了。

好冷，今天
On 3 則留言:

你還記得嗎？

今天，下著毛毛雨

剛下課，天就快黑了

冬季將至

擁有愛情的人們

有著另一份獨享的溫暖


在曾經屬於自己的愛情中全心投入

當愛情逝去

你會了解

愛究竟是怎麼一回事

不管遇上什麼樣的人

什麼樣的初戀

逝去後

總不會什麼都沒有

至少，了解了自己，也得承認自己

在愛中的模樣


在愛中學著與彼此

以不同的方式相處

不是控制，不是慾望

更不是接受與委屈

無論如何

固執沒辦法解決任何事情

生氣也只能排解情緒

委曲求全不見得長久

別失去了對彼此該有的尊重

On 沒有留言:
At：

2009年11月13日

放。尊重點。

關係再好。

還是卡著一層朋友。

放。尊重點。

放縱。不代表自由

保持。人與人的之間該有的基本禮貌

你。越界了

越的。誇張

我是你哥的話。也許不一定會不爽

偏偏。我是你朋友。

放。尊重點。
On 2 則留言:
At：

2009年11月11日

相同階段

感冒好像。。

一直卡在一樣的階段

要好不好。

時而頭痛時而好

不會是被阿飄跟了吧＝＝

又要找廟公治感冒了。。。
On 沒有留言:
At：

2009年11月10日

Unhappy

今天的情緒

超載。

過去加諸了太多太多的夢

當夢無法被實現

剩下的只有殘留下來的遺憾

在這份遺憾發酵後

解開了那些被封存的記憶

那些。。。

摟著你的感覺

吻的感覺

牽手的感覺

相擁的感覺

午後。崩落

打了通電話給你

你飛也似的出現在在我面前

我把頭埋入你的外套裡

什麼話，都沒辦法說出口

至少

心情好了一些

16:16分

Back to work

草草解決了該解決的事情

看了一場電影

The Ugly Truth

其實我不知道為什麼

還要在重看一次

一模一樣的電影

只是

心裡這麼決定

就這麼做了而已

“愛與慾望的掌控”

是我喜歡的台詞

誰又能真正做到呢。

做到了，然後呢。

今天。很遭。

還是謝謝陪著我的人。
On 沒有留言:
At：

2009年11月9日

卡通，多多少少都在騙人

人生是一段

好漫長的歷程

而這漫長的歷程

又分成許多階段

能清晰形容每個階段嗎？

國小的時候

國中的時候

高中的時候

大學的時候

甚至是現在

每走過一個階段

就會有些許的改變

每個階段各帶來什麼

還記得什麼

小時候，

看著電視

兔寶寶手中的紅蘿蔔

咬在口中，脆的好吃

於是。

我也拿了一條。

咬了下去

然後我這一輩子

都怕那東西了。

紅蘿蔔。

On 沒有留言:
At：

2009年11月3日

Life is Varible

昨天花了一點時間，

看完了一整部的小說。

結局，跟大多數的結局都一樣。

過程，跟大部分小說的過程都一樣。

標準的。虐心文

Life is Varible

人生是一個變數

永遠不知道

你會遇到什麼人

跟你所遇到的人，能持續多久

以及

未來

很多事情都是淡淡的變化

轉變，不為人知

默默的習慣，新的習慣

把握

不是絕對的選擇

你還有你的生活，你的夢想

把握只是後悔的結論

So what ?

許多正面的思想來自負面

因為難過

才知道快樂的雛形



相信悲傷產生快樂

還是快樂產生悲傷

只是選擇不一樣罷了

Choice

無法經營，無法訓練

只能最佳化

沒有一個選擇，什麼都不會失去。

。

喜歡大陸小說。

在不同的文化結構裡

文章的表達方式也大相逕庭

Yes! I Love it.
 
On 1 則留言:
At：

Again...

又感冒了。。

搞什麼阿！

考試都沒辦法好好思考

上日文課的時候，頭痛欲裂

差點沒死在學校裡

捷運上的人應該都覺得我臉色超臭吧 Orz...

搭捷運中感冒的機率是跑步去上課的5倍！

切

大家都在密閉的車廂互相傳染

切

雖然

我昨天窗戶忘了關

雖然我醒來的時候

被子掉在地上

而且喉嚨還有點疼。。

路人：切。會感冒根本是自己搞出來的

On 1 則留言:
At：

2009年11月2日

For Giant!

雖然要期中考了～

仍然義無返顧

因為你值得

只要時間花的值得

又何仿

雖然你一直說我太愛管。。。

你有一些些不一樣了

你的生活，你的習慣，你的個性

你的食量真的是超大的。。。

早餐跟我吃同份量就算了。。居然還嗑掉半顆蛋糕

其實你不是愛騙人，只是習慣這麼說了

早上不知道幾點就起床去晨跑的你

早上聽著新聞廣播的你

還有新髮型的你

電腦疑似中毒慢到爆掉的你

看著你牆壁上貼著激勵自己的你

過的辛苦的你

其實有很多話，很想對你說

但是總是悶在心裡，沒有辦法表達

無仿

你會懂得，對吧


我能做的事情不多

一顆蛋糕，聊表心意

一張悠遊卡，要你多來台北玩


對我而言，

你是一個特別的存在

你在我心裡，佔據一個空間，一個角落


美味關係，

是一部出乎意料的，，好片

看的是演員的演技。一流

雖然導演搞的梗

只有外國人看得懂（畢竟導演是外國人。。）

整部片充斥著幸福。

這是最令我無法忘懷的一點


甜到爆炸的冰淇淋，絕對不要在去第二次。。

還是我對甜的抵抗力過低。。

回家的路上，差點錯過叫號

還在車上睡死了。

夢到了，奇奇怪怪的未來

總之

我沒有流口水（大賀）

就這樣吧～

期待下次見面。。
On 沒有留言:
At：

2009年10月31日

系統分析與設計筆記

目前筆記完成度100%

請大家幫忙除錯，感謝

老人家，難免打錯字。。。


章節大綱

第一章：

系統分析與設計 - Start -
The Systems Development Life Cycle(SDLC) 系統開發生命週期
SDLC 五階段 - 概觀
System Request - 系統需求申請書
Feasibility Analysis - 可行性分析
Cost - Benefit Analysis - 成本-效益分析圖

第二章：

Project Selection
Project Methodology Options 概觀
Waterfall Development - 瀑布式開發法
Parallel Development - 並行開發法
V-model - 軟體測試管理模型
Iterative Development - 反覆式開發法
System Prototyping - 雛形法
Throwaway Prototyping - 丟棄雛形法
Extreme programming(XP) - 終極程式
Criteria for Selecting a Methodology - 選擇開發模型的標準
Project Management - 專案管理

第三章：

System Analysis - 系統分析階段
系統分析策略 概觀
BPA - Problem Analysis - 問題分析
BPA - Root Cause Analysis(RCA) - 根本原因分析
BPI - Duration Analysis - 時間分析
BPI - Activity-Based Costing - ABC 分析
BPI - Informal Benchmarking - 非正式標竿法
BPR - Outcome Analysis - 結果分析
BPR - Technology Analysis - 技術分析
BPR - Activity Elimination - 作業消除
Comparing Analysis Techniques - 比較分析策略
Requirements-Gathering Techniques - 需求收集技術
Interviews - 訪談
Joint Application Development (JAD) - JAD 會談
Questionnaires - 問卷調查
Document Analysis - 文件分析
Observation - 觀察法
Comparison of Requirements-Gathering Techniques - 比較需求收集技術

On 1 則留言:
At：

2009年10月30日

適合

雖然看見閃光還是會心痛。

只是

自由適合目前的自己

暫時不想跨入愛情的牢籠

甜蜜又具有負擔

只想跟朋友好好過

沒有胡思亂想

沒有歇斯底里

沒有暴躁易怒

沒有情緒擺盪

至少，現在的樣子，是我自己喜歡的樣子

已經，沒有期望

那種東西，不會存在我的世界

不是一種絕望

而是，路不通往那個方向


重視人生的人，生活比較複雜一點

重視生命的人，生活比較簡單一點

我想我是重視生命的人

不在乎成就，在乎束縛與自由

存在。就是生命的本質

我在尋求。存在

存在需要做些什麼，抑或不應該做些什麼

不重要。。

就依照內心反映的情感生活吧

只做。想做的事

讓自己。放蕩不羈

On 沒有留言:
At：

2009年10月29日

Comparison of Requirements-Gathering Techniques - 比較需求收集技術

比較需求收集技術的六大角度

Type of information - 資訊的類型
Depth of information - 資訊的深度
Breadth of information - 資訊的廣度
Integration of information - 資訊的整合度
User involvement - 使用者涉入程度
Cost - 成本 

比較圖：





閱讀上一篇（Requirements-Gathering Techniques - 需求收集技術）

期中考到此

On 沒有留言:
At：

Observation - 觀察法

概觀：

直接觀察企業運作流程
多用於了解舊的資訊系統
尤其用於「管理者」無法直接口述他的作業流程

觀察法常常與面談合併使用
  • 利用訪談的機會，到受訪者的辦公室，觀察其陳設，言談，以及行動（他如何做事情，發現怎麼樣可以幫助他做的更好） 



On 沒有留言:
At：

Document Analysis - 文件分析

概觀：

通常用來了解舊系統
分析舊系統所留下來的文件
缺點：舊系統沒有留下文件或文件維護不完整時，無法使用此方法
         （現在可以使用逆向工程的軟體輔助，了解舊系統）

文件種類：
  • 表格 
  • 報表 
  • 政策文件
  • 組織圖 
  •  用來描述公司正規化或沒正規化的系統



On 沒有留言:
At：

Questionnaires - 問卷調查

三種會使用問卷調查的時機：

* 當需要從很多人那邊收集資料的時候

* 當收集資料的來源是組織外的人的時候

* 當要從企業分散於各地的員工收集資料的時候

四步驟：

  (1) Selecting Participants - 選擇參加者

從母體裡抽取樣本（兩個方法：隨機抽樣，方便抽樣）

  (2) Designing the Questionnaire - 設計問卷

問卷的問題要文字簡潔，意思清楚
問卷所問的問題大多都是封閉式的問題
  • 原則：分清楚什麼是事實，什麼是意見 
  •          同一類的問題放在一起

  (3) Administering the Questionnaire - 管理問卷調查

選擇填答者，並確保問卷回答完可以回收的回來
所有的問題都要被回答（否則為無效問卷）
利用方法提高問卷回收的效率（Ex：催收，給小禮物）

  (4)  Questionnaire Follow-up - 問卷後續行動

完成問卷報告，送給填答者過目（統計過後的結果）



On 沒有留言:
At：

Joint Application Development (JAD) - JAD 會談

概觀：

1977年，由 IBM 公司所發明
三方會談：「MIS人員」＋「高階主管」＋「使用者」
被發明出來為了解決不同階層不同部門的人，資料不一致的情況
以使用者為核心，以管理者為主導，再由資訊人員提供技術支援的方法
E - JAD （JAD 視訊會談）
會談時間：幾個小時或幾天或幾週，直到達成共識，收集完整資料為止

IBM 建議：
  • 不要在公司舉行
  • 密集的開會
  • 閉門會議 

優點：讓彼此了解彼此立場

缺點：容易有人主導回答問題，而非全部的人都回答

五步驟： 

  (1) Selecting Participants - 選擇參加者

每個層級都要有人參加

  (2) Designing the JAD Session - 設計 JAD 會議

大部份的會議在三週中找 5 - 10 天來進行
E - JAD：一州內選擇 1 - 4 天完成
JAD 會議所問的問題都是開放式問題或追根究底式問題
JAD 會議的所問的問題結構都是由上而下的（簡略 -> 精確）

  (3) Preparing for the JAD Session - 準備 JAD 會議

要讓參與者了解，我們希望他們準備什麼樣的資料
MIS 人員也要根據此次 JAD 會議的目的，準備相關資料

  (4) Conducting the JAD Session - 進行 JAD 會議

JAD 會議的三個原則：
  • 尊重其他人的意見
  • 接受不同意的意見 
  • 確保同時間只有一個人發言 

JAD 會議主持人的三個主要功能 ：
  • 照議程進行
  • 幫助大家了解專業術語（包括商業的，技術的）
  • 紀錄所有討論的資訊 

  (5) Post-JAD Follow-up - JAD 的後續行動

完成 JAD 會談的會談報告（要有結論），傳給參加者確認



On 沒有留言:
At：

Interviews - 訪談

概觀：

面談是用來做資料收集最常用的方法
不一定是面對面，還有 E-Interviews  （視訊訪談）
不一定是一對一，也可能是一對多（同部門）

五大步驟：

(1) Selecting Interviewees - 選擇受訪者

除了選擇受訪者外， 還要確定訪談的目的，時間，地點
訪談人員必須包括組織各層級的人（各層級可提供不同的資料）
不同層級的人員，會問他們不一樣的問題
  • 資深管理人員：策略性資料
  • 中階主管：廣泛的資料 （關於企業的流程） 
  • 低階主管以及工作人員：工作上的細節
詢問順序：高階 -> 中階 -> 低階 -> 中階 -> 高階（確認問題）

(2) Designing Interview Questions - 設計面談問題

三大類面談問題：

  • Closed-Ended Questions - 封閉式問題 
  •    必須要明確答案的問題（選擇題，是非題） 
  •    較常使用 
  •   優點：做統計分析很容易，比較能控制訪談的進行 
  •   缺點：訪談者無法暢所欲言，收集到的資料會有所失真，限制

  • Open-Ended Questions - 開放式問題 
  •    可以得到比較豐富的內容（填充題，簡答題） 
  •    優點：可以挖掘更多資料 
  •    缺點：統計分析困難（內容龐雜）

  • Probing Questions - 追根究底的問題 
  •    當對有些問題不太了解時，以及想要了解更多更詳細的時候，就會使用（問答題，申論題） 
  •    不常使用

問題深入的程度共分為三個

  • High-level ： Very General - 非常一般性的問題 
  • Medium-level：Moderately Specific - 介於一般與精確之間 
  •  Low-level：Very Specific - 非常精確特定的問題

架構訪談問題的兩個方法

  • Top-Down：由上而下的問題問法，適用於大部份的受訪者 
  •  Bottom-Up：由下而上方法適用於兩種情況 
  • (1) 當分析者已經收集到很多資訊，只是需要再補一些沒有收集到的資料細節的時候
  • (2) 低階人員無法回答高層事情的時候

(3) Preparing for the Interview - 準備面談事宜

一般來說，通常結構性的面談（定好目的） ，會用封閉式的問題

(4) Conducting the Interview - 進行面談

將所有受訪者所提供的資訊紀錄下來
一定要問清楚不了解，聽不懂的內容，不要怕問笨問題
最後要分清楚什麼是事實，什麼是意見
要讓受訪者有自由表達的時間
要說明接下來的步驟，不可以輕易承諾有什麼功能，什麼時候完成
要感謝受訪者，讓受訪者感覺對系統有幫助

(5) Post-interview Follow-up - 面談後續行動

要完成 Interview Report （訪談報告）
把訪談報告送給受訪者做確認


正在閱讀（Interviews - 訪談）

On 沒有留言:
At：

Requirements-Gathering Techniques - 需求收集技術

需求分析包括

收集資料
資料分析 （第四章）

收集資料的五種方法


1. Interviews - 訪談（最常使用）

2. Joint Application Development (JAD) - JAD 會談 （聯合應用系統發展方法）

3. Questionnaires - 問卷調查

4. Document Analysis - 文件分析

5. Observation - 觀察法



On 沒有留言:
At：

2009年10月27日

Rule

扮演自己的角色

如此，而已

人生正處於發現自己的階段

交雜樂觀與悲觀

交雜情感與理智

已經，不再單純了

不在。單純了

。＿。
On 沒有留言:
At：

2009年10月23日

Touch

因為人情

同一件事情

我們站在不同的角度

我的角度

我的觀點

我的想法

根據我的經歷


就像前任的前任

讓他傷的很深

就像前任

對我來說也是段不怎麼愉快的記憶

就是一股勁的

因為想要愛

因為想被愛

而互相傷害

不該這樣下去的


你會站在別人的角度

我的認知上，你就是個認真的人

在我遇過的人裡面

會這樣做的，都是認真的人

我也曾經想過你想過的

只是沒有這麼深入

因為我越想，越無法對自己解釋

是自己挖的坑，然後自己跳

是自己欺騙自己，然後再來嘲笑自己

直到自己說出的話，自己都無法承擔

所以我的立場很保留

對你很保留

我只能說我真正的感覺

其他的，我無能為力

我也承認我的無能，沒辦法走出來是我的懦弱

在愛裡我很認真

所以我向你坦承

過去還牽絆著我

因為我等待過，我也知道等待的感覺

我不想騙你，我不想讓你等

那太痛苦

別把自己困在愛情的小圈圈裡面


我說，你看

又有什麼意義，最後還是兩個認知不同的人在硬碰硬

你的固執，你的倔強

都有屬於你自己的理由

只是

別為了那理由把自己困住
On 沒有留言:
At：

2009年10月22日

Comparing Analysis Techniques - 比較分析策略

Potential Business Value - 潛在的商業價值

BPR > BPI > BPA

Project Cost - 計畫成本

BPR > BPI > BPA

Breadth of Analysis - 分析的幅度

BPR > BPI > BPA

Risk - 風險

BPR > BPI > BPA



On 沒有留言:
At：

BPR - Activity Elimination - 作業消除

定義：

找出多餘的活動或步驟，將之刪除，看看會有什麼影響

方法：

使用施壓配合的方式去測試所有的可能性

" force-fit " - 施壓配合

此為消極做法



On 沒有留言:
At：

BPR - Technology Analysis - 技術分析

定義：

在可用的新技術中找到可以為企業帶來利益的技術

做法：

列出一系列的新技術表單，包含重要的，和有利益的技術，然後一一分析，如果引用的話，可以為企業帶來什麼利益


On 沒有留言:
At：

BPR - Outcome Analysis - 結果分析

定義：

焦點在於提供價值給顧客的基本原則是什麼？包含明顯以及不明顯的

做法：

假裝是顧客，思考顧客所要的價值是什麼以及能為他們做什麼來提升價值




On 沒有留言:
At：

BPI - Informal Benchmarking - 非正式標竿法

先介紹標竿法


Benchmarking - 標竿法
定義：
找到榜樣，然後想辦法迎頭趕上

Informal Benchmarking - 
非正式標竿法

定義：
以企業管理角度：
  • 找非相同產業的標竿企業做比較

以系統分析角度：
  • 從顧客的角度來做標竿法

做法： 
假裝顧客，到選定的標竿企業拜訪，看他們是如何做的（偷學）




On 沒有留言:
At：

BPI - Activity-Based Costing - ABC 分析

定義：

以成本為單位，做流程的動作分析

做法：

(1) 計算流程中每一個步驟要多少成本
(2) 同時考慮直接和間接成本
(3) 將焦點放在最花錢的步驟，然後去改善它

「效益」提升 



On 沒有留言:
At：

BPI - Duration Analysis - 時間分析

定義：

仔細檢查舊資訊系統中每一段流程所需的時間
以時間為單位，做流程的動作分析

做法：

步驟整合（減少不必要多餘的動作）
步驟並行（同時處理）

「效率」提升



On 沒有留言:
At：

BPA - Root Cause Analysis(RCA) - 根本原因分析

定義：

將焦點放在問題，而不是解決方法，請使用者將舊資訊系統的問題列出來，並依重要性排列，然後針對最重要的問題，將其所有可能的根本原因列出來

以倒推方式找出問題所在以改善系統

又稱回溯性成因分析

Ex：






On 沒有留言:
At：

BPA - Problem Analysis - 問題分析

定義：

詢問使用者舊的資訊統有什麼問題，以及在新系統如何解決或改進這些問題

適用：

改善「系統效率」
以及「系統易用性」


正在閱讀（Problem Analysis - 問題分析 ）


On 沒有留言:
At：

系統分析策略 概觀

Business Process Automation (BPA) - 企業流程自動化


小的改變，追求「效率」
包含：

Business Process Improvement (BPI) - 企業流程改善

因為新的技術帶來新的機會
模仿競爭對手的行為
中等改變，追求「效率」與「效益」
包含：

Business Process Reengineering (BPR) - 企業流程再造

因為引進新的技術和科技，對組織做根本性的改變
根本性改變，從劇烈改變中獲得大的利益
包含：

On 沒有留言:
At：

System Analysis - 系統分析階段

The system development life cycle (SDLC) 的過程之一，讓組織
Moves From 
As-Is system - 舊系統（不一定電腦化）
To
To-Be system - 正打算要做的系統（基於現在的需求）
and Have
System Proposal - 系統計劃書（系統分析階段所要做出來的文件，就是系統計劃書）（用來表達系統需求是什麼）

什麼是需求！？

(1) 系統一定要做什麼

(2) 焦點：使用者需求什麼

(3) Change over time - 過段時間就改變需求

Functional Requirement - 功能性需求（與資訊處理相關的需求）

(1) 此系統應包含哪些流程

(2) 此系統應包含哪些資訊

Nonfunctional  Requirement - 非功能性需求

(1) Operational - 操作性

(2)  Performance - 效率

(3) Security - 安全性

(4) Cultural and Political - 文化和政治

Requirements Definition - 需求定義書 

用文字敘述來定義系統範圍

系統分析階段的三個步驟 

(1) Understand the "As-Is" system - 了解現在系統

(2) Identify improvement opportunities - 找出待改進的地方

(3) Develop the "To-Be" system concept - 定義新系統的需求


系統分析階段可採用的三種策略


節省人力，時間


 把有問題的或錯誤的流程進行改善


整個系統翻新重做 
可能與原本系統幾乎完全不同




On 沒有留言:
At：

2009年10月21日

科技始終來至於人性

歷經了一段開始

才發現

自己開始害怕戀愛

平淡的結束

並不代表

一切都平淡帶過

多多少少了解你當時無法捨去的原因

卻無法原諒

那份自私與心態

這份矛盾要持續到什麼時候

無法敞開心懷的喜歡一個人

深深害怕陷入愛情的感覺

我得想想

我要的

是什麼



謝謝/抱歉 小雷

你為我帶來了很多

我卻什麼也沒辦法給你
On 沒有留言:
At：

2009年10月15日

Project Management - 專案管理

Case Tools

Computer-aided software engineering

是一種軟體，用來幫助系統開發過程可以自動化的軟體

* I - CASE ( Integrated - CASE ) 整合行系統開發輔助工具
        整合了： Upper - CASE （分析階段用的輔助工具）
                      Lower - CASE （設計階段用的輔助工具）



On 沒有留言:
At：

Criteria for Selecting a Methodology - 選擇開發模型的標準

選擇開發模型的標準

(1) Clarity of User Requirements - 清晰的使用者需求
(2) Familiarity with Technology - 使用技術的嫻熟
(3) System Complexity -  系統複雜度
(4) System Reliability - 系統可靠度
(5) Short Time Schedules - 短暫的開發時程
(6) Schedules Visibility - 計畫表的可見度（計畫是否按照時程進行）



*1 系統分析與設計的同時，就要發展測試計畫，藉由每個階段的測試，獲得較高的系統可靠度
*2 藉由系統雛形做溝通，因此獲得較清楚的使用者需求
*3 因缺乏系統基礎性的考量 （Ex：系統架構，安全，控制上的考量）
*4 因最後會重新撰寫程式，較其他模型適合引進不成熟的技術
*5 系統建立之前，可確定問題，產生比較可靠的系統，而且不忽略基本的基礎架構，安全，控制的需求
*6 因最後需重新撰寫程式，因此耗時較多
*7 因此方法需要使用者，在發展系統時一起工作 ，因此獲得較清楚的使用者需求
*8 因其適用於小專案，複雜度通常不高
*9 因此方法需要使用者，在發展系統時一起工作，客戶需與程式設計師一起定義需求，測試，而這一點常常很難遵守



On 沒有留言:
At：

Extreme programming(XP) - 終極程式


定義：

強調使用者滿意，分工合作
XP 的核心價值：溝通，簡化，回饋，勇氣
三個進行步驟
      (1) 做出 User Stories （使用者故事：用來描述系統該如何做）
      (2) Coding （寫程式）
      (3) Test （測試）
適用小專案（程式設計師 10 人以內）
最後整合所有小系統 -> 完成
沒有回溯線

優點：

XP projects deliver results sooner than even the RAD approaches
比 RAD 的方法更快能產生系統

缺點：

1.  It is not advised for mission-critical
重要的資訊系統多會長時間使用，因此使用 XP 方法的效用受到質疑


2. Since little analysis and design documentation is produced with XP, there is only code documentation
在分析與設計階段，使用 XP 方法，產生的文件很少，只有程式文件而已，因此要維護 XP 所建構的資訊系統幾乎不可能


3. Methodology requires considerable on-site user input, something that is frequently difficult to obtain
此方法需要使用者，在發展系統時一起工作
(1) 定義需求
(2) 客戶測試
這一點常常很難遵守



On 沒有留言:
At：

Throwaway Prototyping - 丟棄雛形法


定義：

當用來做系統雛形的軟體與最系統完成的軟體不一樣時，就要用丟棄雛形法
多了一個整體性分析與整體性的設計可以兼顧系統基礎架構，安全，控制上的問題
Design Prototype 只是一個工作系統而不是最後可執行的系統
此系統雛形可能有很多個（子系統），此多個系統雛形的目的除了與使用者溝通外，主要目的是用來降低風險（確保使用者的需求有被執行）

優點：

1. Using prototypes to refine key issues before a system is built
系統建立之前，可確定問題，產生比較可靠的系統


2. 不忽略基本的基礎架構，安全，控制的需求

缺點：

It may take longer to deliver the final system compared with system prototyping
會比雛形法花更多的時間（因為要做整體性的分析與設計，而且要重新撰寫程式，所以花費較多間）



On 沒有留言:
At：

System Prototyping - 雛形法


定義：

透過系統雛形使使用者初步了解系統
透過軟體工具的幫忙，讓系統分析師與使用者可以在系統分析與設計階段，藉由系統雛形做溝通，以便直接快速的了解使用者的需求
最後的系統是由系統雛形直接寫程式產生的
System Prototype 與 System 的系統軟體通常差不多

優點：

1. Very quickly provides a system for users to evaluate
使用者可以很快拿到一個可以評估的系統，透過此系統雛形使用者可以了解此系統是否為需要的，以便做修正


2. Reassures users that progress is being made
讓使用者可以放心，系統是根據其意見來做改進的

缺點：

1. Is the lack of careful, methodical analysis prior to making design and implementation decisions
缺少系統化的方法來進行分析工作


2. Fundamental deign limitations that are a direct result of an inadequate understanding of the system's true requirements early in the project
缺乏系統基礎性的考量（Ex：系統架構，安全，控制上的考量）



On 1 則留言:
At：

2009年10月9日

。 & Free Life

&


Free


Life
On 沒有留言:
At：

2009年10月8日

Iterative Development - 反覆式開發法


定義：

Version 可直接給使用者測試，系統可先上線
功能累加 Version 1 （基本基礎功能） -> Version 2 （功能增加） -> Version 3 （功能完整）
外面的整合分析階段，要分析出哪些是基本需求，以便在第一個版本中包含進去
第一個版本的系統要包含最重要及最基本的需求

優點：

1. To the user quickly so that business value is provided
使用者可以比較快速拿到一個可用的系統


2. Since user are working with the system, important additional requirements may be identified and incorporated into subsequent versions
使用者比較容易找到額外的重要需求，以便在下一個版本中實現

缺點：

1. The chief disadvantage of iterative development is that users begin to work with a system that is intentionally incomplete
使用者在中間階段拿到的不是完整的系統


2. Most critical requirements of the system will be available in the early versions and must be patient with the repeated introduction of new system versions
如果不能在第一版本中包含最基本與最重要的功能，系統會發生問題



On 沒有留言:
At：
訂閱： 文章 (Atom)