最近進入乙個軟體專案的二期開發小組，每天都在看一期的需求分析、概要設計、詳細設計等等文件。結果越看越困惑，每個子系統的文件模版都不一樣，而且認認真真的看了幾遍文件，大體輪廓是明白了，可是一些具體的問題寫得非常含混不清，甚至是不知所云，看的次數越多問題越多。為了看懂文件，我決定不再糾纏於文字描述，重點理解文件內部的一些生產工藝圖、流程圖等等圖表，可是圖表給我的資訊卻非常有限。於是我不禁想找出按照軟體工程的規定都缺少了一些什麼圖表，最後我發現軟體工程裡的流程圖等圖跟我們平常用到的圖根本就不一樣。這時，我回過頭來一想，其實我門平時用到的圖很多是來自於oo，而不是軟體工程。這些圖在軟體工程裡是找不到的（目前了解的情況是這樣）。我入行不久，但對規範卻是在不斷的最求。
所以我想問這麼幾個問題：
1、軟體工程跟oo的聯絡與區別是怎麼樣的？
2、應該怎樣來編寫用oo分析實現的文件？
3、uml裡的圖應該怎樣組織到文件當中？
4、反映軟體應用領域內各單位如何協調工作的業務流程圖應該歸向哪個文件？
1:反問一句，以前沒有oo的時候，只有面向過程的時候，有沒有軟體工程呢？
2023年，ieee（institute of electrical & electronic engineers，電氣與電子工程師協會）給出了乙個更為全面的定義：
軟體工程 是研究和應用如何以系統化的、規範的、可度量的方法去開發、執行和維護軟體，即把工程化應用到軟體上。
當然有很多這樣類似的概念，但我們可以看出來，這個概念中沒有任何關於oo的東西．
但為什麼ｏｏ和軟體工程經常會混遙呢？我想有這樣的乙個原因：
軟體工程無非包括
過程、方法和工具三個要素
１、其中方法指導「如何做」，涵蓋軟體開發的整個生命週期如需求分析，設計，實現，測試等。比如用use case方法進行需求分析，用junit方法進行測試
２、過程是進行一系列有組織的活動，定義了技術方法的採用、工程產品（包括模型、文件、資料、報告、**等）的產生、里程碑的建立、質量的保證和變更的管理。
比如rup, xp等
３、工具就更好理解了，就是一些輔助工具，提供自動的或半自動的支援。
處了上面三者外，我還要提出乙個＂方**＂的概念，方**是方法的集合，包括語言和過程兩個部分．我們經常接觸到的uml是ｏｏ建模語言，過程有rup，xp等．
所以語言是方**的組成部分，可以有不同的語言（比如ｏｏ，面向過程等），而方**是軟體工程的組成部分。
因為我們經常接觸uml, oo, 但他和軟體工程的概念還是很有區別的．
2、應該怎樣來編寫用oo分析實現的文件？
3、uml裡的圖應該怎樣組織到文件當中？
4、反映軟體應用領域內各單位如何協調工作的業務流程圖應該歸向哪個文件？
我認為不同的軟體過程有不同的方式，指導專案應該包括哪些工程產品（包括模型、文件、資料、報告、**等）。參考一下具體的應用。舉個例子，use case diagram應該組織進需求文件中．
你的問題是否可以細化，讓大家可以進行討論．
部落格應該怎麼寫
雖然我們大部分在機房都呆了一年了，但是還是很多人對於部落格還是望而生畏，不能說是應付差事，但是總有一點一些部落格就頭疼的感覺，更有甚者，冥思苦想，最終寫出來的總是不敬人意。今天 大話 基本上都要看完了，其實對於這本書還是深有感觸的，以 大話 為題，說說部落格我們應該怎麼寫。與其抱怨需求總是在變化，不...
投標方案應該怎麼寫？
我寫這個可不是為了傳授或布道哦，我寫過一些投標方案，但是總想聽聽大家是怎麼寫的，都注意些什麼。所以，兄弟我先扔塊磚，大夥兒有玉的砸過來 前面幾天在寫乙份投標方案。連續幾天搞到晚上10 00以後，週末還搞了個通宵，昨天去投了。總算乙個包袱卸了下來，結果怎麼樣也顧不上了，大家都說 盡人事，聽天命吧。呵呵...
標頭檔案應該怎麼寫
因為乙個物件只能定義一次，能夠宣告多次，所以標頭檔案最重要的規則是只宣告，不定義 除少數物件外 而且只宣告其他檔案需要用到的物件，其他檔案不需要用到的物件沒必要在標頭檔案中宣告。當其他檔案需要用到本檔案定義的一些物件時，我們可以將這些物件寫到頭檔案中，其他檔案只要include這個標頭檔案即可使用相...