軟件

文章目錄 Pair Project (sample 2)Pair Project (sampe 3) 這是現代軟體工程課的作業結對項目 Pair Project: 一對同學用結對程式設計的方法完成 結對程式設計課件: 現代軟體工程講義 3 結對程式設計和兩人合作軟體工程講義 3 兩人合作(2) 要會做漢堡包 Pair Projecthttp://academic.research.microsoft.com/academicmap

文章目錄  Team homework #2: innovation in new application domains.   這是現代軟體工程課的作業列表, 老師可以根據情況選用, 建議要保證每周都有作業。 團隊作業 Team Homework: 適合團隊完成的作業 這些作業都要團隊的成員互相配合才能完成,  團隊可以選出一位同學完成作業的具體寫作和發部落格部分, 大家可以輪流完成。 一個團隊通常由 5-7名隊員組成,

文章目錄 這不是bug – 如果你輸入中文就沒問題了.使用者需要協助, 但是使用者沒有那麼蠢光dogfood 也不夠即使阿湯哥也受不了人命關天的改進學術搜尋的bug 說到使用者介面 (User Interface)，我們先看一個圖: [來源]有些同學認為UI 設計是充滿創意和非常瀟洒的工作，  另一些同學 (特別是有一定實際項目經驗的) 也許會抱怨,  UI 的工作就是在衣服後面夾夾子, 讓前面好看一些。 其實，電腦軟體的使用者介面

這是現代軟體工程課的作業個人作業 Individual Homework: 個人完成的作業 (讀書報告等), 著不同於 “個人項目 Individual Project”. Individual Homework #1a good question is 50% of a good solution, now let’s share your questions about the text book(s), and post them online. todo: pick a text

每個小組 (結對) 從下列產品中選一個, 按照下面的說明寫軟體測試報告, 分析並提出建議, 寫一篇部落格 (包括四部分)即可。    產品1. Bing 字典用戶端  (http://dict.bing.msn.cn/)    產品2. 必應繽紛案頭 (http://desktop.bing.msn.cn/)    產品3. 微軟學術搜尋 (http://academic.research.microsoft.com )    打分會以產品分類,

在一個神奇的國度裡生活著許多動物,  其中有豬, 雞, 和鸚鵡。它們每天搞頭腦風暴, 琢磨如何創業,  最後鸚鵡提議它們合夥開一個早餐店: 具體分工如下:豬: 提供豬肉, 做熏豬肉 (bacon)雞: 提供雞蛋, 做煎蛋鸚鵡: 提供諮詢, 它會每天閱讀大量部落格, 給其他團隊成員提供建議, 例如最新業界趨勢, 最新術語, SaaS, N-層架構, 創業明星當年的軼事, 等等。  這項創業對三個動物的負擔是一樣的麼?  它們應該各自佔多少股份?  一旦創業失敗, 豬, 雞, 和鸚鵡會各自失去什麼?

from: http://cid-ba6a52af193f301f.spaces.live.com/blog/cns!BA6A52AF193F301F!122.entry   Oh,my pair projectFrom new Pair(HuangShuo,WangGuan) 簽入代碼，發送郵件，關上Flex Builder。糾結了差不多兩周的Pair Project終於能夠有個了結了，此刻跑來碼碼字，感到甚為解脫。 我們Pair，Wang

互連網時代對於創新者來說, 既是一個偉大的時代, 又是一個糟糕的時代。 你有很多機會做出影響世界的產品,  但是, 似乎任何想法都被別人想到過了, 做出來了, 上市了, 移植到各種平台上去了…  那麼我們後來人除了羨慕別人生得早, 還有什麼機會呢?  但是往往不經意間, 在同學們熱衷於偷菜, 三國殺的時候,  又一批新的想法, 新的技術蜂擁而至, 別人又想出了新的點子, 新的商業模式.  我們的菜偷了不少, 三國殺玩了好幾個通宵,  但是想法還是沒有 …在《現代軟體工程》 這門課裡,

有同學問我這個問題：“你正在做一個項目，這個項目有一項關鍵的feature需要實現，這個feature有一定的技術難度，你調試了很久，都沒找到實現的途徑，這時你已經在這個feature上花了很多時間了，而且無法預期解決需要多長時間。在這種情況下，你會怎麼做？”  一種典型失敗的情況是：第一天：我正在做一個關鍵的feature, 看起來不難，做好了會很有面子。。。第三天：就是搞不通，就這樣過了三天，其中“murphy's

from http://cid-ba6a52af193f301f.spaces.live.com/   第一次把我們自己的寫的東西放在網上讓別人去用，今天過得非常有傳奇色彩，我決定講個長故事來紀念我們的發布第一天。 由於找不到能放軟體的地方，我們把軟體以附形式件放在了zol的論壇（http://q.zol.com.cn/bbs/thread-5739593-1-1.html），然後所有的推廣都指向這個下載連結。

在前一個部落格裡 (典型使用者), 我們講了怎麼收集, 分析和驗證使用者的需求。 這裡我們講 spec – specificationSpecification, 又叫spec, 有兩種:    a) functional spec, 軟體功能說明書, 主要用來說明軟體的外部功能, 和使用者的互動情況 (把軟體當作一個黑盒子)    b) technical spec, 軟體技術說明書, 又叫 design doc, 設計文檔, 主要用來說明軟體內部的設計 (把軟體當作一個透明的箱子)有同學說,

 專案管理的最高目標並不是要保證讓 “ideal” 和 “actual” 的線吻合,  因為項目中出現意外和需求的變化是很正常的事。 專案管理的目標是處理這些意外和變化, 讓軟體能如期發布, 盡量滿足客戶的要求。 例如: http://www.cnblogs.com/takeitandgo/archive/2011/05/26/2059363.html

[現代軟體工程講義 的一部分]軟體開發的過程, 就是 “使用者最需要的東西” 在下面這一鏈條中傳送，轉換，實現，扭曲或丟失的過程。使用者最需要的 >      使用者表達出來的 >        軟體團隊能理解的 (老闆/PM) + 團隊的商業目標 >            軟體團隊成員具體表達出來的 (PM 寫 spec) >                在各種約束條件下, 具體執行表達出來的 (dev 寫代碼) >                   

敏捷開發, 誰不會呀, 不就是沒文檔, 出活快, 使用者說啥都能改?下面是一個笑話,  王屋村的大牛說 - 我最近轉手接了一個活, 完事能掙四五萬, 我拿過圖紙一看, 不就是蓋一煙囪嗎? 我們是敏捷 (Agile) 的團隊，要文檔作甚? 馬上開始幹活！    都快蓋好了， 客戶來檢查，把我打了一頓！我冤枉啊！   原來, 圖紙看倒了，人家讓挖口井。不過, 我們是敏捷的團隊, 被客戶打了也要擁抱變化, 好不容易砌好的煙囪不能這麼廢了, 要不斷重構, 代碼重用。 於是我們在地上挖了一個大坑,

[這是 現代軟體工程講義 的一篇]一個軟體團隊經曆了計劃/設計/開發等階段, 達成程式碼完成 (Code Complete) 這一目標，似乎後面的事情就水到渠成了.  其實不然, 軟體生命週期的最後階段往往是最考驗團隊的，不但考驗Team 專案管理水平，應變能力，也考驗團隊的血型。 原計劃的軟體發布時間快到了，但是軟體還是有這樣那樣的bug，怎麼辦？優秀的軟體團隊會發布有已知缺陷的軟體麼?我覺得和人類血型類似，軟體團隊的“軟體血型”也可以分4種：    

[現代軟體工程講義]有舌尖上的美味, 也有微博上的軟工。舌尖上的美味各有千秋, 而微博上對軟工的抱怨都是相似的。  下面是我在新浪微博收集到大學生對軟體工程的反饋: 師生關係（不限於軟體工程）教材上課 & 老師 實踐 & 作業 考試 考完了 

很多大學裡是把軟體開發相關的專業劃入工科的，這給人一種錯覺，讓人認為軟體開發也是一個工程學科，就像土木建築，動力機械那樣。但這從根本上錯了，土木建築，動力機械的背後有確實的科學定律作為支撐，而軟體開發的背後基本上什麼都沒有，遠不是一種“科學”。也正因此，“軟體工程”的現實意義也就遠不如“土木工程”，“動力工程”。 每個人對“科學”的定義可能不同，但在這裡，我們可以做一個簡化版的定義：當有一組在限定條件下顛撲不破的定律做支撐時，相應的知識，我們可以稱之為科學，科學自身可以體現為一種確定性。比如說：

軟體自身是一種固化的思維，因此從本質上來看，軟體是不可度量的。但這並不意味著軟體不需要度量，而只是說軟體中的度量大多都有一定限度。應用各種度量資料的時候一旦跨過這種限度，結果就會適得其反。 在這篇文章裡，我們將考查一下現有的，對軟體進行度量的方法(注意：這篇裡主要考察別人的方法，不是我自己的)。可能不全面，不足的地方歡迎大家進行補充。對軟體“直觀可見的品質屬性”的度量比較簡單，比如：Bug率，效能等，這裡就不提了。這裡主要關注的是軟體的內在的，不直觀可見的品質屬性。 循環複雜度 循環複雜度主要用

我一直的觀點是要對“難”做一點分解。好比說航空母艦的彈射器，我們造不出來，很“難”與一台機器有一千個螺絲要擰，保證3年中所有螺絲都擰對了，很“難”，這兩種情境下“難”的含義是不同的。  軟體開發的難度更多的類似於後者，表現為繁雜，而不是類似於前者表現為“搞不定”或“做不出來”。總是有人喜歡把問題絕對化，所以這裡補充一句，軟體涵蓋的範疇可以很廣，因此確實有很難搞定的，類似於彈射器的領域，但應該不是主流。  以前的很多提法，在這樣一種大前提下就變的沒有什麼意義了，比如說：國產作業系統。當很多公司或組

我個人的經曆略有一點特別，本身學的專業並不是軟體，但在當年軟體熱的背景下，加入了這個行業。由於很多同學仍在原來的行業，時不時的溝通讓我反思軟體開發究竟和機械製造這類行業有啥區別。 老實講，對於畢業生而言，10年前做軟體收入要比做機械製造有明顯優勢，但10年後的今天這種優勢就不明顯了。這也是觸發我考慮這種問題的一個原因。 軟體行業與機械製造比一個很不同的特質：知識更迭頻度較快。 在考慮如何使自己升值時，這一特質有關鍵影響。 技術更迭較快說的是這樣一種現象：今天有價值的，明天可能會貶值為0。 這點與