這週我讀了《構建之法》第七章實戰中的軟體工程
微軟解決方案框架（msf）是微軟推薦的軟體開發方法。
msf基本原則：
1.推動資訊共享與溝通（foster open communication）
2.為共同的遠景而工作（work toward a shared vision）
3.充分授權和信任（empower team members）
4.各司其職，對專案共同負責（establish clear accountability and shared resposibility）
5.交付增量的價值（deliver incremental value）
6.保持敏捷，預期和適應變化（stay agile，expect and adapt change）
7.投資質量（invest in quality）
8.學習所有的經驗（learn from all experiences）
9.與顧客合作（partner with internal and external customer）
就是所有資訊都保留並公開，討論要包括所有涉及的角色，決定要公開並告知所有的人。當然，對牽涉到機密技術、安全性等資訊要採取必要的保護措施
msf中各司其職，對專案負責
關鍵質量目標
msf小組角色
出口條件
按約束條件交付產品
程式管理
按產品規格說明交付產品
開發我們是否按照功能說明完成了各項功能
保證所有問題都得到處理
測試我們發現了所有的問題，而且我們都有處理方案嗎
產品部署和後續管理
發布管理
客戶是否能快速方便地部署產品和進行後續管理
讓產品更好用
使用者體驗
產品是否適應使用者的使用習慣？易學易用
讓客戶滿意
產品管理
客戶是否（在總體上）滿意我們的專案
在學習過去的經驗的同時，也要避免讓過去的經驗妨礙解決現在的問題。mfs在每乙個里程碑結束時都要做乙個「里程碑回顧」，這個回顧不必等到整個專案結束才做。這樣做的好處是，大家對最近的成敗都記憶猶新，能提供比較準確和全面的反饋；如果發現了錯誤，可以馬上研究解決辦法，在下乙個里程碑中通過實踐來驗證。另外，一些好的做法可以及時得到總結和推廣。msf強調產品團隊與顧客的交流與合作並不是產品團隊拿到合同之後，就閉門造車，直到專案完成才告訴告訴使用者，應該及時地與使用者溝通盡可能滿足他們的要求
這種方案很適合初學者的我們，我們應該盡早的按照這種方式來解決專案問題
構建之法閱讀筆記05
時隔多日，自己又重拾 構建之法 今天對需求分析這部分進行了閱讀。當我們程式設計師在編寫軟體之前要做的就是了解使用者的需求，準確而全面地找到需求主要有以下幾個步驟 1 獲取和引導需求 elicitation 我們需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，引導他們表達出對軟體的需求。很多時候...
構建之法閱讀筆記05
本次閱讀了第十三 軟體測試 十四章 質量保障 在軟體發布前基本沒有進行測試，直到上台講述的之前的一段時間才發現了一些問題，甚是著急 第十三章中excel計算1900閏年錯誤的例子給了我乙個全新的概念 要服務於最主要的功能.傳說中的拐點 小飛 我聽說在軟體專案中，有這樣乙個拐點存在 在這一點之前，新的...
構建之法閱讀筆記05
這是構建之法的最後一篇閱讀筆記 這幾天主要閱讀了it的創新這一章，創新在現代的社會中是乙個被說爛了的詞語，各行各業都在提倡創新，就連學校裡也在提倡什麼創新創業大賽 在 構建之法 的創新迷思一節，列舉出了七個迷思，接下來分別作出乙個簡要的概述。迷思之一 偉大的創新總是靈光一現。迷思之二 大家都喜歡創新...