2.經過必定的軟件流程,在預計的時間內發佈「足夠好」的軟件。git
看完這個要求後,個人疑問在於什麼樣的軟件纔可以成爲「足夠好」的軟件,查詢資料以後我認爲,「足夠好」的軟件應該知足這些條件:
·確保軟件完成了它所承諾或公佈的功能
·確保軟件知足了性能的要求
·確保軟件是健壯的和適應用戶環境的
那麼還有其它的評判標準嗎?又該由誰來評判呢?是負責測試的人員仍是客戶呢?數據庫
分析麻痹:一種極端狀況是想弄清楚全部細節,全部依賴關係以後再動手,心理上過於悲觀。分析太多,腿都麻了,無法起步前進。瀏覽器
我記得在完成OO做業的時候,在設計階段須要弄清楚每個類應該完成什麼事情,以及類之間的調用,依賴關係,完成這部分工做以後再去着手寫代碼會比較輕鬆。那麼在此處的依賴關係與單純的程序設計做業之間類的調用依賴關係區別在哪呢?分佈式
敏捷是一股思潮,它涵蓋了好幾種軟件開發的方法論,這些方法論又是創建在許多行之有效的最佳實踐方法之上的。工具
個人疑問點在於,面對不一樣的項目以及需求時,咱們究竟該何時選擇敏捷呢?可否給出幾個詳細的例子來講明敏捷的優點呢?性能
對於殺手功能,外圍功能的定義不太明白,不太能理解功能分析中四個象限的建議。學習
如何把我構建的典型用戶和場景轉換成個人規格說明書呢?又如何去寫好個人技術說明書呢?測試
運用CMMI模型管理項目,不只下降了項目的成本。並且提升了項目的質量和定期完成率。操作系統
我對CMMI的運行過程仍是以爲很疑惑,並不懂得該模型應該如何去達到其預期的效果。設計
軟件工程的概念是1968年第一次提出的。「軟件工程」是Margaret Hamilton在阿波羅計劃期間所提出來的。
60年代中期,大容量、高速度計算機的出現,使計算機的應用範圍迅速擴大,軟件開發急劇增加。高級語言開始出現;操做系統的發展引發了計算機應用方式的變化;大量數據處理致使第一代數據庫管理系統的誕生。軟件系統的規模愈來愈大,複雜程度愈來愈高,軟件可靠性問題也愈來愈突出。原來的我的設計、我的使用的方式再也不能知足要求,迫切須要改變軟件生產方式,提升軟件生產率,軟件危機開始爆發 。
項目管理軟件 | 優勢 | 缺點 |
---|---|---|
Microsoft TFS | 團隊工具,貫穿需求,開發,測試,發佈各個流程提供自動化工具 | 我的成本高,瀏覽器訪問速度較慢 |
GitHub | 可使用git來管理源代碼,從微型到超大規模的項目均可以高效處理 | 代碼保密性差,學習週期相對較長 |
Mercurial | 輕量級分佈式版本控制系統,易於學習和使用,擴展性強 | 用戶磁盤空間管理不當,產生了大量的多餘副本 |
Bugzilla | 強大的檢索功能,經過跟蹤和描述處理Bug | 只能管理缺陷 |