團隊有一些共同的特點：有一致的集體目標，成員之間有各自的分工，合作完成任務。團隊一開始可能是"一窩蜂模式"，都想寫出好的軟體，但是沒有各自的分工，一般不會這種模式不會存活太久。慢慢會演化成其他模式，比如"主治醫師模式"，本來是不錯的模式，但是在學生身上退化為了乙個學生幹活，其餘打醬油的情況。還有比如明星模式，社群模式，業餘劇團模式等，當然其中不乏一些好的模式，秘密團隊，交響樂團模式，功能團隊模式等。
學校裡面的軟體工程專業的學生可能是"寫了再改模式"，因為作業是這麼要求，但是這種開發方法的缺點特別大。
軟體行業一開始也會使用"瀑布模型"，即分析-設計-實現-銷售-維護的模式，但是對於軟體工程來說，需要做很多次的回溯。但是慢慢發現回溯很困難等等的其他問題，需要在生產出產品之後才能知道產品的實用性，這是很頭疼的問題。
後來提出了rational統一流程，即後面的統一建模，用精確的語言把使用者的活動描述出來。流程為：業務建模，需求，分析和設計，實現，測試，部署，配置和變更管理，專案管理和環境。rup分為四個階段：初始，細化，構造，交付。
在uml這門課中，我們學習了用例這一概念，用例包括標題、角色、主要成功場景、步驟、擴充套件場景這些元素。我們在使用用例時要遵守其使用規則。但同時，用例使用也有它的侷限性：不適合互動式之外的系統；故事的粒度沒有固定的標準，和具體的專案有關，初學者難以掌握；如果關鍵在於使用者體驗的細節，不能把ui的細節嵌入故事中，並保持故事的簡明性。
規格說明書包括軟體功能說明書和軟體技術說明書。功能說明書，主要用來說明軟體的外部功能和使用者的互動情況，從使用者的角度描述軟體產品的功能、輸入、輸出、介面、功能的邊界問題、功能的效率、國際化、本地化、異常情況等，不涉及軟體內部的實現細節。技術說明書又叫設計文件，它用於描述開發者如何去實現某一功能，或相互聯絡的一組功能。
把使用者的需求變成團隊可以直接操作等工作，這是功能驅動設計。要進行構建總體模型、構建功能列表、制定開發計畫、功能設計、實現具體功能五個步驟。
如果軟體團隊在軟體測試方面沒有足夠的投入，最終的系統會存在許多問題。
有一種流程為老闆驅動的流程，這種流程有好處也有壞處。好處是老闆比一般技術人員懂的市場和競爭；壞處是領導畢竟對於軟體開發是外行，並且不一定能管理好軟體團隊。
還有漸進交付的流程，重複開發-發布-聽取反饋-根據反饋做改進這個過程，直到完成迭代次數，或者客戶滿意。
構建之法讀書筆記
場景 故事 版權 版本 維護人 1.背景 a.典型使用者 姓名 性別 年齡 職業等 b.使用者需求 痛點 c.假設 2.場景 關於這個場景的文字描述角色 與軟體互動的角色，如使用者等其他實體，甚至時間 主要成功場景 一系列步驟 步驟 描述每一步的互動 擴充套件場景 描述一些意外情況 軟體功能說明書 ...
《構建之法》讀書筆記
乙個軟體除了穩定 功能強大，使用者體驗也很重要。程式開發人員和測試人員在強調其功能和效能的同時，還有一點很注重的就是使用者體驗。在我們學習的最初階段老師們就強調對於軟體開發來說使用者體驗的重要性，無論軟體還是硬體，都有很多功能部件，各個部件還要郵寄的結合起來，才能滿足使用者的需求。其中有一點特別，就...
構建之法讀書筆記
在上一次，我讀了大道至簡，在大道至簡中，我理解了軟體開發所需要的是簡化與便捷，這是軟體工程需要思考的地方。而在構建之法中，我學到了軟體開發中更符合我的問題的東西。書中說，軟體工程師的成長分為四個階段 玩具時期，愛好者時期，探索者時期，行業時期。在這四個時期中，我處於玩具時期。還沒有掌握最基本的東西。...