其他

    ION（Input Output Network）是公司的物流系統的簡稱。一個佔用10個開發人員，耗時1年完成的系統，終於到了尾聲。偶有幸成為開發組長，和大家一起折騰了一年。這裡羅列工作失誤，一一分析。    中國的開發人員直到需求分析的後期才應邀加入系統開發。剛開始接手需求，自然是浩瀚的文檔，來來回回的溝通郵件，散落在四處。每次開會時都在找最新的版本，即缺乏效率又浪費時間。直到後期大家才把文檔遷入source safe裡統一管理。   

假如你是一個開發人員，假如你通過威客網站比如k68.cn來接一些單子，或者是通過朋友介紹或者個人魅力找到了一些小項目來做；假如你是一個Team

前一陣子和一位專案經理聊天，他說：“我在項目中很累，除了專案管理的事情外，還有好多事情要我去做，我覺得給自己分配的事情少了，乾的活少了，內心很愧疚，我是專案經理，我要以身作則。”我當時很吃驚，一個有5個人的項目，怎麼會這樣？於是我給他畫了一個下面這樣的矩陣：此主題相關圖片如下：我說：“你看看，你該幹什嗎？”他說：“是啊，我好像什麼也不該幹！真的是暈了！”如果一個4個以上項目成員的項目團隊，專案經理還在做具體的事情，寫具體的文檔，那我認為這個項目肯定存在問題了。因為你已經花了太多的經曆在具體細節上

在各種企業級系統開發的過程中難以避免都會遇到許可權處理的設計。好的許可權系統不但能為系統提供安全的解決方案，同時還能節約開發時間，提高系統的可維護性。許可權需求分為兩類：A、模組許可權    操作功能模組的許可權，或者訪問菜單的許可權。比如使用者U有沒有權利操作“發票介面”。B、資料許可權    資料許可權是對訪問資料範圍的控制。    比如有1000張發票使用者U有權利操作哪些發票的控制，是操作所有的發票還是自己建立的發票或者是自己部門的發票。C、欄位許可權    在有些時候我們會對特殊欄位設

上一講 系統前台結構圖下面是資料庫資料字典的設計：  a.選課表 table_course編    號字 段 名 稱數 據 結 構說    明1c_id數字選課編號，自動編號，pk2c_name文本選課名3d_id數字系別編號，fk系別表4c_max_number數字最大可選人數5c_now_number數字現在已選人數6c_eff_date文本有效日期，如2004-5-1

前幾天上過了自己學校的選修課系統，其爛之致，真的叫人心寒，於是想自己寫一個公用課選修課系統，不要求很複雜。於是看了一下浙大的和華南理工的，手工之一致如出自同一名家之手，功能是很強大，但很複雜，我的小院校用不到那麼多功能，於是我就自己亂設計啦。需求如下：使用者分為學生和管理員。學生可以選課、修改選課，查看選課情況，修改個人資訊。管理員可以查看、增刪改選課、學生，列印報表。系統使用案例圖管理部分使用案例圖選課部分使用案例圖下一講

XP作為一種還算年輕的軟體研發的方法論目前應該可以說開始普及了。作為一個軟體研發人員，我非常贊同XP理念，XP的理念中充滿了使項目成功的關鍵思想，而這些思想不僅僅是技術上的，而是很大一部分是管理與溝通方面的。XP整合了許多最佳實務，而這些串聯後的最佳實務使整個項目又變的有趣起來，這其中也包括了XP開發人員特有的積極向上的態度與責任心。這裡我想向大家描述一下我個人的XP實踐感受……下面我分別寫一下我對XP中其中12種最佳實務的感受：現場客戶(On-SiteCustomer)。客戶的需求不是一成不變

1、系統設計       在項目開始前的階段著重理解式樣書和需求，把握住項目整體架構（商務邏輯，程式流程）等大方向。然後根據式樣書的詳細程度確定是否需要詳細設計，詳細設計的製作可由進階程式員或專案經理參與設計，也可由程式員自身設計並整理形成文檔，一方面促使對系統的理解和商務邏輯的正確把握，另一方面便於他人閱讀。詳細設計要做的事情包括：商務邏輯、程式流程、資料表關係。設計完成之後需要通過項目組評審，之後方可編寫代碼。當然也可在編寫代碼的過程中完善此類設計文檔。 2、代碼品質     

什麼是極端編程? 　　　　極端編程(eXtreme Programming)是一種開發紀律，以簡單性、交流、反饋和勇氣為基本宗旨。它的做法是以有效實踐規則將整個團隊緊密聯絡起來，通過充分的反饋使團隊能隨時知道自己目前的狀況和恰當的調節規則以適應自己的特殊情況。 　　在極端編程中，每一個項目貢獻者都是“團隊”完整的一部分。這個隊伍是圍繞著一個每天和隊伍坐在一起共同工作的商業代表——“客戶”建立起來的。 核心實踐：整體團隊

         很感謝“加大碼”同志在上篇隨筆的恢複，讓我想起了許多問題。         常言道，千裡之堤，毀於蟻穴，軟體同樣如此。雖然軟體中的BUG本身不會像蟻穴那樣慢慢變大，但對使用者而言，它引起的錯誤/異常等的次數卻會越積越多，最終我們會失去使用者，造成不可挽回的損失，因此，這些品質的問題，我們必須注意，並制定相應的措施、計劃、方案去預防、測試、修正BUG的出現。         至於如何做測試計劃、如何寫測試案例等之類如何預防“蟲子”、如何尋找“蟲子”的文章比比皆是，但是發現“蟲子”

        每一個項目，不論成功還是失敗，都將是一筆寶貴的財富，我們都可以從中學到很多的東西。成功給我們的是成功的經驗，失敗給我們的是避免同樣失敗的教訓。不管怎麼樣，關鍵是進行項目總結，讓每一個項目都能給我們點什麼。         我就業後參加了一些項目，從小到大，從無序到有序。但每一個項目，不論大小，都會在項目結束進行總結，主要是限於設計和技術，找出在開發過程中的問題，每一次總結都感覺是一次收穫。（自我感覺）      

今天一個負責需求的同事，很自信的答應了客戶一個修改，說起來也確實簡單。將報表添加一個按一定條件分組排序。 初一聽，很簡單吧？我就跟他講了一段話：這個讓我聯想到或者可以作為一個比喻的例子：如果是在一個空地上規劃建房子，在建之前，任意的創意和修改都是很容易的。但一旦房子已經建好了，即使你只是想要在房頂的四個角加點裝飾，負責施工的人員報給你的價格和時間可能超出你的預估。在其他很多情況下我們也有類似的經驗。 因為事實上，這個報表的需求從phase 1到現在phase4 修改了很多細節，誰讓客戶都是

                      項目考慮因素及解決方案         在項目開發過程中，我們會考慮很多相同的問題，比如在設計過程中的技術選型，開發過程中的多語言、介面客戶自訂問題，使用過程中的系統遠程更新問題。在此，僅列出一些常見的解決方案，知識所限並非最優方法，只作為參考。  多語言支援  

        昨天下午總結了一下項目值得注意的地方，記錄在《項目做完了，總結一下（上）》，時間倉促，也沒有總結完全。等有時間，還要細細總結。今天，我主要總結一下項目成功的可能因素，比較膚淺。   雖然項目受很多不利的因素的困擾，但最終還是交付給使用者使用，不管怎麼樣，這中間還是有很多值得思考的方面。1． 

今天借了一本《UML精粹－－標準對象建模語言簡明教程》（Uml Distilled: A Brief Guide to the Standard Object Modeling Language）。徐家福先生譯過來的。總體上感覺：把一本好書糟蹋了。之乎者也的序自不待言。諸如“如果萬一有人不小心面陷入我的陷阱，控制器對象終止，於是我就需要把兔子關入籠內，擦擦地板，重新啟動系統。”之類的翻譯（我查了下原著，if someone should be so careless as to fall

昨天上午和一個同事爭吵了差不多一個上午，為了一個項目上的決策問題。項目本身並不複雜，是為客戶做3套2.4G無線導遊的樣機，樣機結果會影響訂單。前面已經就器件選型，採購，定外殼等基本完成，而且也有2套已經完成了，我們承諾給客戶的也是2套樣機，但因為只是做樣，我們就大部分組件都是從其他公司購買半成品然我們後組裝改造改進的，中間有幾次波折影響樣機的穩定性。所有我就很擔憂在送給客戶樣機的穩定問題會很出問題。在已完成的2套樣機使用的核心材料也不同，可認為是2個版本的（A，B），A版本就在距離和敏感性上表現

 在連續封閉N個月以及再後來的N個月的加班後，項目終於以延期N個月的結果結束了。不管曾經發生過什麼，不管項目是否延期，重要的是項目結束了，所有的項目成員都可以鬆一口氣了。曾經和同事開玩笑說：在我經過過的失敗項目中多了一個項目，以後就能避免同樣類型的失敗了。同事們聽了，都笑了。在那段時間裡，很久沒有聽到過同事們暢快的笑了。現在，我以我目前的知識水平，總結一下項目中存在的問題，這些問題的出現也不是一兩個因素造成的。當然，專業水平太低，也總結不出什麼高深的內容。不管怎麼樣，也算是對項目的總結吧。這裡先

1. 軟體需求：軟體需求分為三大部分：　　1)、功能需求：指系統需要完成那些事情，即向使用者提供那些功能。　　2)、非功能需求：指產品所具備的品質和屬性，比如可靠性、擴充性、回應時間、效能等等。。。　　3)、設計約束：也稱條件約束、補充規則。比如使用者要安裝該產品他需要有什麼樣的必備條件。（系統對作業系統的要求、硬體環境的要求等等…..）2. 需求調查與問題定義：在做需求調查時需要做到兩W一H即 What、Where、How　　1)、What-----應該收集什麼資訊　　2)、Where----

waitu在blog上提出了幾個問題，有許多朋友回答了，包括我。我認為他的問題挺有代表性的，大部分人都會遇到，所以在這裡我再一次貼了我的回答。這隻是我的個人觀點。 不知其他朋友對這些問題如何看待？ 這是他的貼子:http://www.cnblogs.com/waitu/archive/2005/02/01/100214.html    1  軟體工程就意味著無休止的會議嗎?怎麼樣才能更好的將任務布置給每一個人,保證進度,並且在其遇到難題的時候能夠更好的溝通呢?    2