作者 主題: Visual Studio 2005 & Software Management 整理分享  (閱讀 4434 次)

0 會員 與 1 訪客 正在閱讀本文。

小徒兒

  • 鑽研的研究生
  • *****
  • 文章數: 622
    • 檢視個人資料
https://www.dir.state.tx.us/pubs/framework/gate2/sdlc/sydd/instructions.pdf#search=%22sa%20system%20design%20db%20table%20diagram%22

企業軟體工程高峰會 研討會後分享


研討會後感,軟體工程是一條黑暗的摸索道路,很多成功軟體公司或是企業內的MIS部門也是憑著想要改善軟體品質,自我成長的期許下,在其中摸索學習,最後才成功。


成功軟體公司或是企業內的MIS部門在研討會時分享他們的成功故事。聽了以後,我分析他們大部份會成功的原因是:

(1)   先在PMP,CMMI, ISO 9000方面有概念上的暸解,暸解後再自行開發量化管理軟體,是否使用特定軟體並不是成功的因素。

(2)   推行時難免也有管理階層的不支持或同仁的反彈,但仍能透過溝通讓同仁有自發性的配合並堅持下去。

 小徒
--------------------

「開發軟體系統最困難的一個部份,就是準確地決定要開發什麼。」1
──Frederick Brooks, 《人月神話》(The Mythical Man-Month)



它們不只從職稱、功能的角度,同時也從人物的性格、工作或環境、教育、電腦相關的經驗、以及其他特性來描述使用者,讓憑空想像的人物變成跟真的一樣。為了更容易記住它們,你可以為每個人物代表指定一個名字和一張圖片。微軟有些開發小組會把海報掛在牆上,並且大量分送名條磁鐵(fridge magnets)來強化大家對人物代表的的印象。


如果你熟悉極致編程(XP),那麼你一定知道使用者故事(user stories)13。
XP的使用者故事等同於前面提過的情節的目標──寫在3x5 吋的卡片上的簡短陳
述。XP並未要求你詳細描述情節,而是要求一位駐點的客戶隨時在旁邊提供實作
的流程說明。如果你的客戶願意到你那裡駐點,你也不需要尋找替代的設計方案,
而且設計的結果不需要有人簽核的話,那麼XP的開發流程就可以運作得很好。


卡諾分析
有一種很有用的分析技術,叫做「卡諾分析」(Kano Analysis),它是以原
創者的姓氏來命名。卡諾分析是把興奮因子、滿意因子、和不滿因子都放在相同
的軸線上29。X軸代表某個情節或服務品質已經完成了多少,Y軸則是客戶的滿意



情節所關注的,是如何讓使用者喜歡這個產品,並且達成其目標的功能需求,
你可以把這些需求想成所謂的滿意因子(satisfiers)。有些目標和情節對使用者
特別重要或設計得很棒,棒到讓使用者喊出「哇!」的一聲,我們把這種情節稱
為興奮因子(exciters)。

另外還有一些潛在的因素會讓使用者覺得懊惱或擾亂他們的工作習慣,這些
就是不滿因子(dissatifiers)14。在蒐集需求時我們必須考慮這些情況。由於服務品質常常被忽略,因此不滿因子經常會出現。例如使用者可能會抱怨:「程式的速度很慢」、「間諜軟體偷了我的帳號」、「我最常用的功能不能執行了」、以及「系統的延展性很差」等,這些都是由於沒有考慮到對應的服務品質所產生的不滿因子。

客戶和使用者很少會提出這些不滿因子──他們通常假設不會發生這些狀
況。這令人想到了Monty Python 的一齣搞笑劇:「寵物店(The Pet Shoppe)」,這齣戲的劇情是,有一個人到寵物店退還他剛剛買的鸚鵡,由於他在買鸚鵡時並沒有指定要活的,所以店員就賣給他一隻死的鸚鵡。這齣戲之所以好笑,在於它揭露了我們平日經常會發生的誤會。一些像是「你當初又沒有告訴我X」、「客戶並沒有指明要X」、和「我們的研究結果並沒有顯示X」之類的話,都是因為沒有考慮到要避免不滿因子而產生的後果。

圖3.7:寵物店(The Pet Shoppe)
顧客:「我要申訴,我半小時以前在你的店裡面買了這隻鸚鵡。」
店家:「喔好的,這個,啊……有……有什麼問題嗎?」
顧客:「我告訴你怎麼了,小老弟。牠是死的,這就是問題!」15

情節的確非常有用,但它們並不是唯一的需求。情節也必須考慮到服務品質
(Quality of Service,簡稱QoS)。(服務品質一度被稱為「非功能需求」,但我不用這個術語,因為它不大貼切。也有人叫它們是「’ilities」,這倒是既貼切又簡潔)68 | Software Engineering with Microsoft Visual Studio Team System「‘ilities」之所以成為服務品質的代名詞,是因為許多服務品質的單字都是以「ilitiy」結尾,例如:usability(易用性)、compatibility(相容性)、maintainability(可維護性)……等等。

其實只要定義適當的服務品質項目,就能避免大部分的不滿因子。服務品質
可能代表了系統整體的特性,也可能是針對特定情節的特殊限制。例如,「未授
權的使用者不能存取系統或任何資料」就是系統整體安全的服務品質。「當有1000名使用者同時執行下訂單的功能時,95% 的訂單必須在三秒內傳回結果」則是跟下訂單情節有關的效能服務品質。

---------------------------------
resource from Software Engineering
with Microsoft Visual Studio Team System




***範例程式
101 Samples for Visual Studio 2005
http://msdn.microsoft.com/vstudio/downloads/101samples/default.aspx



***用vs 2005 畫 class diagram
http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/ClassDesign.htm

***deployment diagram ,Logical datacenter diagrams ,system diagram
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsent/html/vsts-arch.asp

***建立process template
http://msdn.microsoft.com/vstudio/tour/scenario%5Fshowcase/scenarios/Increase_Predictability_and_Reduce_Variability.htm