關於軟體開發—反覆式開發法

      好久沒有更新自己的部落格了，感覺自己就是懶，不願意動手去寫東西，做更有意義的事。反省自己是該做些改變的時候了。
      四月十號聽說最近學校的SRTP項目要結項了，最近才趕緊的寫了一個版本，雖說有很多不足的地方，可是自我感覺還是蠻不錯的。雖然是短短的幾天，可是整個開發的過程還是有很多體會的，就此發表出來，希望和大家交流。
      軟體開發的整體流程基本是需求分析--資料庫分析--系統設計--編碼與重構的迴圈--項目結束了。不過比較傳統的瀑布式開發模式已經不適用潮流的發展了，敏捷開發的模式深入人心。在這個幾乎誰都認為可工作的軟體勝過面面具到的文檔的時代，大家都把與使用者的交流和反覆式開發法放在首位。只有與使用者充分的交流，才能夠得知使用者的需求，才能瞭解使用者需要的是什麼東西，只有知道了使用者需要的是什麼東西，開發出來的軟體才不會與使用者要求的差之千裡。
      需求是第一步的工作，雖然說使用者不能一次說出所有的需求，或者說使用者在看到最後的軟體之前其實並不知道他想要什麼，即使使用者知道這些，需求分析者和使用者之間的理解也是有差異的。然而在進行編碼之前設計是必要的，而且是必須的。雖然設計會在開發過程中會發生變化，會隨著細節的凸顯而演變，可是合理粒度、結構清晰的設計可以減少重構中的問題，使得開發過程出現的設計變更不會影響項目進度，甚至影響項目的成敗。而設計是建立在需求的基礎之上的，可見需求--設計--開發之間的任何一個環節出現問題，都會關係到項目成敗。
      怎樣才能夠合理把握三者之間的關係呢？“軟體開發中最不會改變的就是需求永遠是變化的”，還有一點就是“主要的功能需求變化最小”。所以首輪反覆式開發法實現需求中的最主要功能的設計和編碼，拿出可工作的軟體，然後和使用者交流，讓使用者看到工作的成果，一會讓使用者對他們想要什麼有更清晰的認識，二是對項目成員的工作的肯定，三能協助需求分析師得到更全面的需求，設計師更好的把握系統。第二輪迭代時實現第一次迭代過程確定的主要需求，以此類推。這樣整個的開發過程既有使用者的參與，又有開發設計人員的配合，最終的到的軟體必然是使用者想要的。
      反覆式開發法減少了使用者投入的風險，降低了項目失敗的風險，能夠增強使用者的競爭力，同時減少了開發的複雜度，增強了系統的易用可用性。