第三章 三思而後行 前期準備

2022-09-08 15:03:17 字數 4453 閱讀 1571

使用高質量的實踐方法是那些能創造高質量軟體的程式設計師的共性。這些高質量的實踐方法在專案初期、中期、末期都強調質量。

如果你在專案末期強調質量,那麼你會強調系統測試。如果你在專案中期強調質量,那麼你會強調構建實踐。如果你在專案開始階段強調質量,那麼你會計畫、要求並且設計乙個高質量的產品。

由於構建活動是軟體專案的中間階段,在你開始構建的時候,專案前期工作已經或多或少為這個專案的成功或者失敗打下了基礎。

程式設計師是軟體食物鏈的最後一環,架構師吃掉需求,設計師吃掉架構,而程式設計師則消化設計。

3種常見的軟體專案種類:商業系統(internet、遊戲)、使命攸關的系統(嵌入式、遊戲)、性命攸關的系統(嵌入式,航空,醫療)。

問題定義有時稱為「產品設想」、「設想陳述」、「任務陳述」、「產品定義」。問題定義在具體的需求分析之前,而需求分析是對所定義的問題的深入調查。

問題定義應該用客戶的語言來書寫,而且應該從客戶的角度來描述問題。通常不應該用計算機的專業術語敘述。

「需求」詳細描述系統軟體應該做什麼,這是達成解決方案的第一步。

明確的需求有助於

* 確保是使用者駕馭系統的功能。

* 避免爭論。

* 減少開始程式設計之後系統變更情況。

* 是專案成功的關鍵。

穩定的需求是軟體開發的聖杯。

在開始構建之前,用這份列表做一次「心智健全」檢查,看看你的地基到底有多堅固。

針對功能需求

- [ ] 是否詳細定義了系統的全部輸入,包括其**、精度、取值範圍、出現頻率等?

- [ ] 是否詳細定義了系統的全部輸出,包括其**、精度、取值範圍、出現頻率、格式等?

- [ ] 是否詳細定義了所有輸出格式(web頁面、報表、等等)?

- [ ] 是否詳細定義了所有的硬體和軟體外部介面?

- [ ] 是否詳細定義了全部外部介面,包括握手協議、糾錯協議、通訊協議等?

- [ ] 是否列出了使用者想要做的全部事情?

- [ ] 是否詳細定義了每個任務所用的資料,以及每個任務得到的資料?

針對非功能需求(質量需求)

- [ ] 是否為全部必要的操作,從使用者視角,詳細描述了期望響應時間?

- [ ] 是否詳細描述了其他與計時有關的考慮。例如處理時間、資料傳輸率、系統吞吐量?

- [ ] 是否詳細定義了安全級別?

- [ ] 是否詳細定義了可靠性,包括軟體失靈的後果、發生故障時需要保護的至關重要的資訊、錯誤檢測與恢復的策略等?

- [ ] 是否詳細定義了機器記憶體和剩餘磁碟空間的最小值?

- [ ] 是否詳細定義了系統的可維護性,包括適應特定功能的變更、操作環境的變更、與其他軟體的藉口變更能力?

- [ ] 是否包含對「成功」的定義?「失敗」的定義?

需求的質量

- [ ] 需求是使用者的語言書寫的嗎?使用者也這麼認為嗎?

- [ ] 每條需求都不與其他需求衝突嗎?

- [ ] 是否詳細定義了相互競爭的特性之間的權衡——例如,健壯性與正確性之間的權衡?

- [ ] 是否避免在需求中規定設計(方案)?

- [ ] 需求是否在詳細程度上保持相當一致的水平?有些需求應該更詳細地描述嗎?有些需求應該更粗略地描述嗎?

- [ ] 需求是否足夠清晰,及時轉交給乙個獨立的小組去構建,他們也能理解嗎?開發者也這麼想嗎?

- [ ] 每個條款都與待解決的問題及其解決方案相關嗎?能從每個條款上溯到它在問題域中對應的根源嗎?

- [ ] 是否每條需求都是可測試的?是否可能進行獨立的測試,以檢驗滿不滿足各項需求?

- [ ] 是否詳細描述了所有可能的對需求的改動,包括各項改動的可能性?

需求的完備性

- [ ] 對於在開發之前無法獲取的資訊,是否詳細描述了開發不完全的區域?

- [ ] 需求的完備是否能達到這種程度:如果產品滿足所有的需求,那麼它就是可接受的?

- [ ] 你對全部需求都感到很舒服嗎?你是否已經去掉了那些不可能實現的需求——那些只為了安撫客戶和老闆的東西?

軟體架構是軟體設計的高層部分,用於支撐更加細節的設計框架。通常會用乙份獨立的文件描述架構,這份文件稱為「架構規格書」或者「頂層設計」。

架構典型組成部分

程式組織、主要的類、資料設計、業務規則、使用者介面設計、資源管理、安全性、效能、可伸縮性、互用性、國際化/本地化、輸入/輸出、錯誤處理、容錯性、架構可行性、過度工程、復用的決策、變更策略、架構的總體質量。

- [ ] 程式的整體組織結構是否清晰?是否包含乙個良好的架構全域性觀(及其理由)?

- [ ] 是否明確定了主要構造塊(包括每個構造塊的指責範圍及與其他構造塊的介面)?

- [ ] 是否明顯涵蓋了「需求」中列出的所有功能(每個功能對應的構造塊不太多也不太少)?

- [ ] 是否描述並論證了那些最關鍵的類?

- [ ] 是否描述並論證了資料設計?

- [ ] 是否詳細定義了資料庫的組織結構和內容?

- [ ] 是否指出了所用關鍵的業務規則,並描述其對系統的影響?

- [ ] 是否描述了使用者介面的設計策略?

- [ ] 是否將使用者介面模組化,是介面的變更不會影響程式的其餘部分?

- [ ] 是否描述並論證了處理i/o的策略?

- [ ] 是否估算了稀缺資源(如執行緒、資料庫連線、控制代碼、網路頻寬等)的使用量、是否描述並論證了資源管理的策略?

- [ ] 是否描述了架構的安全需求?

- [ ] 架構是否為每個類、每個子系統、或每個功能域提出空間與時間預算?

- [ ] 架構是否了如何達到可伸縮性?

- [ ] 是否描述了國際化/本地化的策略?

- [ ] 是否提供了一套內聚的錯誤處理策略?

- [ ] 是否規定了容錯的方法(如果需要)?

- [ ] 是否證實了系統各個部分的技術可行性?

- [ ] 是否詳細描述了過度工程的方法?

- [ ] 是否包含了必要的「買vs.造」的決策?

- [ ] 架構是否描述了如何加工被復用的**,使之符合其他架構目標?

- [ ] 是否將架構設計得能夠適應很可能出現的變更?

架構的總體質量

- [ ] 架構是否解決了全部需求?

- [ ] 有沒有那部分是「過渡架構」或「欠缺架構」?是否明確宣布了在這方面的預期目標?

- [ ] 整個架構是否在概念上協調一致?

- [ ] 頂層設計是否獨立於用作實現它的機器語言?

- [ ] 是否說明了所有主要的決策動機?

- [ ] 你。作為一名實現該系統的程式設計師,是否對這個架構感覺良好?

花費在問題定義、需求分析、軟體架構上的時間,依據專案的需要而變化。一般來說,乙個運作良好的專案會在需求、架構以及其他前期計畫方面投入10%~20%的工作量和20%~30%的時間。

- [ ] 你是否辨明了自己所從事的軟體型別,並對所用的開發方法做出對應的剪裁?

- [ ] 是否充分明確定義了需求?而且需求足夠穩定,能開始構建了?(詳見需求核對表)

- [ ] 是否充分明確定義了架構,一邊開始構建?(詳見架構核對表)

- [ ] 是否已經指出你的(當前)專案中獨有的風險(以避免構建活動面臨不必要的風險)?

professional software development,專業軟體開發

the psychology of computer programming,程式開發心理學

software requirements,軟體需求,描述需求活動的具體細節。

mastering the requirements process,掌握需求過程。面向更高階「需求」從業人員。

competitive engineering,涵蓋做需求工程、設計和設計演化、漸進式專案管理的方法。

ieee recommended practice for software requirements specifications,編寫軟體需求規格書的指南。

《swebok:guide to the software engineering body of knowledge》,詳細描述了軟體需求的主要知識。

《software project survival guide》

《the rational unified process:an introduction》

《the unified software development process》

《extreme programming explained:embrace change》

《principles of software engineering management》

《rapid development》

《balancing agility and discipline:a guide for the perplexed》

《agile and iterative development:a manager『s guide》

三思而後行 前期準備

看過的書,作乙個小結,總是記憶更加深刻,通過思考寫歸納書中的知識點,更有助於學習有效提高!在軟體的開發的過程中,前期的準備很重要,對需求的理解不到位,容易造成平台的選擇失誤,平台的失誤,會造成專案會半途而廢,不僅影響專案進度,而且浪費人力與物力等資源!不管做什麼專案,我們要有一種每次面對乙個新專案一...

03三思而後行 前期準備

1.軟體開發食物鏈 程式設計師是軟體食物鏈的最後一環。架構師吃掉需求,設計師吃掉架構,而程式設計師則消化設計。2.需求變更 一旦客戶接受了乙份需求文件,就再也不做更改 是乙個美好的願望。然而,對乙個典型的專案來說,在編寫 之前,客戶無法可靠地描述他們想要的是什麼。問題並不在於客戶是低階生物。就如同你...

買房子,三思而後行

從去年12月開始準備買房子看房子,然後借錢買房子,到今年裝修房子,前前後後一共要花整整半年的時間,在這半年的時間裡面,可以說我們是吃不香,睡不穩,看房子的時候要注意這個房子有沒有什麼問題,還要擔心有沒有潛在的問題,簽合同準備買的時候更是提心吊膽的,不知道會有什麼問題,過戶手續遞交到房產交易中心,但是...