（個人學習筆記）
電腦科學與技術專業，在學校學習的時候，對於軟體工程並沒有太深的理解。當時想法很狹隘，乙個函式，乙個小小的acm程式就是我對於軟體最淺顯的理解。
並不是所有人都喜歡在條條框框限制下進行工作。個人且非大型化專案真的需要通過設計一系列軟體工程的指導來進行開發嗎？其實個人覺得是有必要的，軟體工程相當於寫作文時候列的提綱或者說是乙個計畫清單，當有了計畫清單，就會發現每一步走的無比從容，才不至於在開發過程中亂了陣腳，養成良好的開發習慣。
在編寫物件導向軟體之前，需要畫一些uml圖形，例如靜態模型：用例圖、類圖、時序圖；動態模型：狀態圖、時序圖；物理模型：構件圖、部署圖。這就是軟體工程裡面的非形式化方法：利用圖表，文字等描述軟體的系統架構。
傳統的軟體工程，則是一系列貫穿整個軟體生命週期一種科學的方法，指導軟體在計畫、開發、維護甚至到廢棄每個階段所需要幹什麼。避免了隨意開發所帶來的效率低下維護困難的問題。
1.選擇合適的軟體開發模型
在計畫階段的初期要選擇好所需要跟隨的軟體開發模型（software development model），這個模型相當於開發軟體的大綱形式，就類似於我是選擇英國的左邊行駛還是美國中國的右邊行駛，然後選擇好後再根據這些規則下的交通法規來行駛車輛「開發軟體」。常見的模型有：瀑布模型、快速原型模型、增量模型、螺旋模型以及其他的一些形式化模型和特殊模型。
圖1.瀑布模型
2.可行性分析
當選擇好了過程模型後，便需要對該軟體進行可行性分析（feasiblity study）的研究，就像是市場調研一樣，不調研就像在不是很富裕的村里開個星巴克，也不是不行，但是賺錢恐怕就困難了。可行性分析包括四個方面：經濟，技術，執行，法律這幾個層面。
3.結構化分析
當一切準備妥當之後，便可以進行結構化分析了，結構化分析（structured analysis）就是研究所需要開發的東西，給出這個專案的具體面貌，再根據這個面貌歸納出邏輯模型例如整個的資料結構設計、各個模組的聯絡、訊息傳遞等，匯出所需要的資料流圖、資料字典、實體聯絡（e-r）圖、狀態變換圖等，總結並完善最後做出系統需求規格說明書，最後再進行複審。
圖2.資料流圖
4.結構化設計
在結構化設計（structured design）階段,就相當於把在分析階段這些虛無縹緲的邏輯模型轉變成開發過程中實際軟體所需要的設計，比如介面的設計、資料的設計、體系架構的設計、過程的設計等，這些都是總體設計相當於程式的框架。然後再通過轉變好的設計架構逐步細化設計出程式的模組每個模組該怎麼寫，最終進行編碼。
以上就是傳統化軟體開發的所有內容。
軟工 初識軟工 《軟體工程導論》
剛開始軟工不知從何下手，然後找了一本書 軟體工程導論 通過讀這本書對軟工有了乙個大概的認識，了解了軟體工程各個階段的里程碑，以及在各個階段完成中採用相應的處理方法，使得各個階段的任務在完成過程中既有條有理，又方便通用。在各個階段完成過程中都需要文件的記錄，並成為各個階段進度的標誌和里程碑 下面簡單的...
軟工 軟體工程概論
軟體的發展受到硬體的影響，軟體發展階段包括程式設計階段，程式系統階段和軟體工程階段。程式設計階段，主要是機器語言和組合語言 程式系統階段，支援多人編寫，形成簡單的文件說明。軟體工程階段，必要的文件說明，讓軟體編寫產品化，標準化，規範化。在軟體開發過程中遇到的一系列的遺留問題，統稱為軟體危機。軟體危機...
軟體工程 軟工文件總結
於是就去找了四五個小夥伴交流，他們畢竟是寫過文件了，有一些經驗。經過和他們的交流，我漸漸覺得這個文件 也不是很難了，就開始查閱資料。找到了許多巨人，他們的經驗總結的很好，讓我學習了很多。開始寫的時候還是有些為難的，因為是第一次，萬事開頭難。寫著寫著，就有了一點眉目，然後寫的更多了，就 感受了文件中也...