根據現代軟體產業的要求，乙個軟體由乙個人單槍匹馬完成是不可能的呢？那麼就要求我們在相互合作中完成，合作的最小單位是倆個人，兩個工程師在一起最多的就是看**，每個人都會看別人的**，並發表意見，但是每個人對於好**的評判是不一致的，這時我們很有必要給出乙個基準線——什麼是好的**規範與設計規範。
編碼原則：
應盡量避免在系統初始化時執行過多的**。（此處加入詳細原則）
（1）選用控制結構只准許乙個入口和乙個出口。
（2）程式語句組成容易識別的塊，每塊只有乙個入口和乙個出口。 （3）複雜的結構應該用基本控制結構進行組合巢狀來實現。
（4）語句中沒有的控制結構，可用一段等價的程式段模擬，但要求該程式段在整個系
統應前後一致。
（5）嚴格控制goto語句，僅在下列情形才可使用。
用乙個非結構化的程式語言去實現乙個結構化的構造。 在某種可以改善而不是損害程式可讀性的情況下。
物件命名約定
公式：物件名稱=物件字首+自定義名稱（自定義名稱要有一定的意義且第乙個字母大寫）
說明：如果是不需要對其編碼的物件，那麼物件名用預設物件名。 應該用一致的字首來命名物件，使人們容易識別物件的型別。下面列出了 delphi 支援的一些推薦使用的物件約定。
（1）推薦使用的專案字首
（2）推薦使用的選單字首 應用程式頻繁使用許多選單控制項，對於這些控制項具備一組唯一的命名約定很實用。除了最前面 "mnu" 標記以外，選單控制項的字首應該被擴充套件：對每一級巢狀增加乙個附加字首，將最終的選單的標題放在名稱字串的最後。下表列出了一些例子。
選單標題序列 選單處理器名稱。
當使用這種命名約定時，乙個特定的選單組的所有成員乙個接乙個地列在 visual basic 的「屬性」視窗中。而且，選單控制項的名字清楚地表示出它們所屬的選單項。
（3）為其它控制項選擇字首 對於上面沒有列出的控制項，應該用唯一的由兩個或三個字元組成的字首使它們標準化，以保持一致性。只有當需要澄清時，才使用多於三個字元的字首。
常量和變數命名約定
公式：常量或變數名稱=常量或變數範圍字首+常量或變數型別字首+自定義名稱（自定義名稱要有一定的意義且第乙個字母大寫）
除了物件之外，常量和變數也需要良好格式的命名約定。本節列出了（此處加入變數列表）。
變數應該總是被定義在盡可能小的範圍內。全域性 (public) 變數可以導致極其複雜的狀態機構，並且使乙個應用程式的邏輯非常難於理解。全域性變數也使**的重用和維護更加困難。
delphi中的變數可以有下列範圍： 範圍 宣告位置 可見位置 過程級（此處加入名稱） 模組級（此處加入名稱） 全域性（此處加入名稱）。
較好的編碼習慣是盡可能寫模組化的**。例如，如果應用程式顯示乙個對話方塊，就把要完成這一對話任務所需要的所有控制項和**放在單一的窗體中。這有助於將應用程式的**組織在有用的元件中，並減小它執行時的開銷。
除了全域性變數（應該是不被傳遞的），過程和函式應該僅對傳遞給它們的物件操作。在過程中使用的全域性變數應該在過程起始處的宣告部分中標識出來。 變數範圍字首
隨著工程大小的增長，劃分變數範圍的工作也迅速增加。在型別字首的前面放置單字母範圍字首標明了這種增長，但變數名的長度並沒有增加很多。 範圍 字首 例子 全域性 g gstrusername 模組級 m mblncalcinprogress 本地到過程 無 dblvelocity
（此處加入說明） 變數
宣告所有的變數將會（此處加入說明）。
應該給變數加字首來指明它們的資料型別。而且字首可以被擴充套件，用來指明變數範圍，特別是對大型程式。
變數資料型別
用下列字首來指明乙個變數的資料型別。 （此處加入說明） 描述變數和過程名
變數或過程名的主體應該使用大小寫混合形式，並且應該足夠長以描述它的作用。而且，函式名。
對於頻繁使用的或長的項，推薦使用標準縮略語以使名稱的長度合理化。一般來說，（此處加入特例說明）就困難了。
當使用縮略語時，要確保它們在整個應用程式中的一致性。在乙個工程中，如果一會兒使用（此處加入說明問題），將導致不必要的混淆。
簽入
若要將已修改的源**管理檔案用於其他使用者，必須將這些檔案簽入到源**管理中。簽入檔案時，所簽入的版本將寫入源**管理提供程式，並成為檔案的最新版本。
可以使用「簽入」命令簽入檔案。如果使用該命令簽入解決方案或專案，將同時簽入該解決方案或專案中的所有檔案。但是，簽入單個源**檔案則不會將其所屬的專案或解決方案一起簽入。
**複審
團隊需要認識到**審查是為了提高整個團隊的能力，而不是針對個體設定的檢查「關卡」。「a的**有個bug被b發現，所以a能力不行，b能力更好」，這一類的陷阱很容易被擴散從而影響團隊內部的協作，因此需要避免。另外，**審查本身可以提高開發者的能力，讓其從自身犯過的錯誤中學習，從他人的思路中學習。如果開發者對這個流程有牴觸或者反感，這個目的就達不到。
提交**前自我審查，新增對**的說明所有團隊成員在提交**給其他成員審查前，必須先進行一次審查。這次自我修正形式的審查除了檢查**的正確性以外，還可以完成如下的工作：
(1)對**新增注釋，說明本次修改背後的原因，方便其他人進行審查。
(2)修正編碼風格，尤其是一些關鍵資料結構和方法的命名，提高**的可讀性。
(3)從全域性審視設計，是否完整的考慮了所有情景。在實現之前做的設計如果存在考慮不周的情況，這個階段可以很好的進行補救。
我們在實踐中發現，即使只有原作者進行**審查，仍然可以很好的提高**質量。
第三次軟工
軟工實驗報告三 點歌系統的詳細設計和實現 使用者介面設計2系統實現3總結與展望 一使用者介面設計 三總結和展望 總結展望 課程班級 學 號 姓 名 實驗時間 軟體工程導論 12電信1 120705118 章朧朧2013.12.22 本系統的設計思路主要是實用 簡便 靈活 穩定。整個系統有完整的組織框...
軟工第三次作業
031702523 psp2.1 personal software process stages 預估耗時 分鐘 實際耗時 分鐘 planning 計畫30 45estimate 估計這個任務需要多少時間 2020 development 開發1500 1650 analysis 需求分析 包括學...
軟工實踐第三次作業
原部落格 隊友部落格 嶽冠宇 051601135 陳思孝 051604103 axure rp 8 對爬取的資訊進行結構化處理，分析top10個熱門領域或熱門研究方向 可對多年間 不同頂會的熱詞呈現熱度走勢對比 這裡將範疇限定在計算機視覺的三大頂會cvpr iccv eccv內 匯入 列表篩選 搜尋...