A. 軟體工程問題定義,什麼是軟體工程它可以解決什麼問題
軟體工程是指導計算機軟體開發和維護的工程學科。採用工程的概念、原理、
技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠
得到的最好的技術方法結合起來，這就是軟體工程。
軟體工程(SoftWare
Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。
B. 關於軟體工程師的市場需求問題
.NET現在可以看成微軟的一個品牌。微軟有兩個非常成功的品牌，那就是Windows和Office。.NET會成為微軟的另一個品牌。它不僅僅是一組技術，產品，或服務（微軟的服務包括MSN, Passport， MSDN訂閱，等等）。一個品牌具有一些特徵。比如，Rolex是一個手錶品牌，它代表了高質量，時尚，昂貴，成功，等等。那麼.NET代表了什麼呢？
.NET代表著聯通性，敏捷性，和成功。讓我分別對這幾點來解釋一下。
1、聯通性。.NET的遠景是讓所有的事物都連接起來。不管是人，信息，系統，還是設備；不管是一個企業的內部員工，外部合作夥伴，還是客戶；不管是Unix, Windows, 還是 Mainframe；不管是SAP, Siebel, 還是 Oracle ERP套件；不管是桌面PC，手機，還是手錶。在一個異構的IT環境里，.NET技術能夠將不同的系統連接起來。
2、敏捷性。商務敏捷性和IT敏捷性。面向服務的商務體系結構跟面向服務的IT體系結構很好的配合在一起。SOA (Service-Oriented Architecture)能夠給一個企業帶來IT敏捷性和商務敏捷性。.NET技術是基於SOA思想和原則設計的，並且採用了像XML和Web Services這些支持應用整合和系統互操作的開放標准。這樣，採用.NET技術開發應用，能夠帶來靈活性和敏捷性。.NET是一個非常合適的技術平台來創建支持SOA體系結構的IT系統並通過這些系統的開發和部署運行達到IT和商務的敏捷性。
3、成功。GE的前主席Jack Welch曾經說過一句話，「在GE，我們只有兩個競爭優勢：第一，比競爭對手更快的洞悉更多有關客戶的信息的能力；第二，比競爭對手更快的將這種理解轉化為行動的能力。」最終，IT都是為業務服務的。敏捷帶來商務上的成功。.NET可以幫您創建一個敏捷的系統，既容易去洞悉市場，作出戰略上的調整，也容易將新的計劃付之實行。
這些聽上去像是在做市場宣傳。但事實確是如此。其它的IT廠商也在談論這些東西：XML, Web Services, SOA, 敏捷性，聯通性，等等。他們可能會使用不同名詞，但這些名詞後面的含意應該都是非常相似的。
所以你可以發現一個有趣的現象，所有IT廠商都支持同樣一組開放標准，即XML和Web Services，我們都認可企業應該做SOA，我們都認為敏捷性非常重要。那這些IT廠商之間有什麼不同呢？不同之處就在各自的技術實現上。XML, Web Services, 和SOA只是技術規范和技術理念，需要採用一種技術平台才在應用系統中實現這些技術規范和技術理念。各個IT廠商的技術平台有很大的不同。
.NET就是微軟的用來實現XML，Web Services, SOA和敏捷性的技術。
對技術人員，想真正了解什麼是.NET，必須先了解.NET技術出現的原因和它想解決的問題，必須先了解為什麼他們需要XML, Web Services 和 SOA。
技術人員一般將微軟看成一個平台廠商。微軟通過技術平台，而技術人員在這個技術平台之上創建應用系統。從這個角度，.NET也可以如下來定義：
.NET是微軟的新一代技術平台，為敏捷商務構建互聯互通的應用系統，這些系統是基於標準的，聯通的，適應變化的，穩定的和高性能的。
從技術的角度，一個.NET應用是一個運行於.NET Framework之上的應用程序。（更精確的說，一個.NET應用是一個使用.NET Framework類庫來編寫，並運行於公共語言運行時 Common Language Runtime之上的應用程序。）如果一個應用程序跟.NET Framework無關，它就不能叫做.NET程序。比如，僅僅使用了XML並不就是.NET應用，僅僅使用SOAP SDK調用一個Web Service也不是.NET應用。
微軟.NET技術包括哪些東西？核心的東西當然是.NET Framework。 Visual Studio.NET 2002和Visual Studio.NET 2003是創建.NET應用的集成開發環境。Visual Studio For Office (VSTO)可以用來創建基於Word和Excel等文檔的.NET解決方案。Web Service Extensions (WSE)是一組支持高級Web Services 標準的.NET類，這些標准包括WS-Security, WS-Policy, WS-ReliableMessaging 和 WS-Attachments，等等。Enterprise Library是一組支持企業級.NET應用程序開發的可重用的應用程序模塊，它提供了應用程序開發中需要解決的共性的問題，比如配置管理，數據訪問，異常處理，日誌管理，等等。
.NET僅僅是跟Web Services相關嗎？當然不是。它是微軟的新一代技術平台，你可以在這個平台上面創建任何類型的應用系統：傳統的Windows桌面應用,Web應用,Office 應用，移動應用，智能設備應用，等等。在一個Pocket PC (Phone Edition)上面，你可以使用.NET Compact Framework （.NET Framework在設備上的一個簡化版）創建一個.NET客戶端應用程序。或者你可以開發一個.NET移動Web應用，部署在一個IIS Web 伺服器上面，然後用戶就可以使用Pocket PC (Phone Edition)上面的Internet Explorer 瀏覽器去訪問這個網站，這個網站的頁面都是專門為這種設備的小屏幕設計的。
C. 求解軟體工程方面問題：怎麼樣理解需求分析，請從需求分析的本質，和需求分析的過程兩方面回答！
需求分析目標就是讓軟體做成用戶真正想要的東西。作為業務和技術的紐帶，確認一個項目或者產品的目標、范圍、功能、要求、約束等內容。
需求分析的過程包括，需求初期調研、原型製作、需求規格編寫、需求確認（與用戶）、代表用戶確認設計方案、確認最終實現等。
D. 軟體工程：怎樣消除項目組成員對需求與項目文檔理解的不一致
對商業用戶來說，他們後面是成百上千個供應商，前面是成千上萬個消費顧客。怎樣利用軟體管理錯綜復雜的供應商和消費顧客，如何做好精細到一個
小小調料包的進、銷、調、存的商品流通工作，這些都是商業企業需要信息管理系統的理由。軟體開發的意義也就在於此。而弄清商業用戶如此復雜需求的真面目，
正是軟體開發成功的關鍵所在。
---經理：「我們要建立一套完整的商業管理軟體系統，
包括商品的進、銷、調、存管理，是總部-門店的連鎖經營模式。通過通信手段門店自動訂貨，供應商自動結算，賣場通過掃條碼實現銷售，管理人員能夠隨時查詢
門店商品銷售和庫存情況。另外，我們也得為政府部門提供關於商品營運的報告。」
---分析員：「我已經明白這個項目的大體結構框架，這非常重要，但在制定計劃之前，我們必須收集一些需求。」
---經理覺得奇怪：「我不是剛告訴你我的需求了嗎？」
--
-分析員：「實際上，您只說明了整個項目的概念和目標。這些高層次的業務需求不足以提供開發的內容和時間。我需要與實際將要使用系統的業務人員進行討
論，然後才能真正明白達到業務目標所需功能和用戶要求，了解清楚後，才可以發現哪些是現有組件即可實現的，哪些是需要開發的，這樣可節省很多時間。」
---經理：「業務人員都在招商。他們非常忙，沒有時間與你們詳細討論各種細節。你能不能說明一下你們現有的系統？」
---
分析員盡量解釋從用戶處收集需求的合理性：「如果我們只是憑空猜想用戶的要求，結果不會令人滿意。我們只是軟體開發人員，而不是采購專家、營運專家或
是財務專家，我們並不真正明白您這個企業內部運營需要做些什麼。我曾經嘗試過，未真正明白這些問題就開始編碼，結果沒有人對產品滿意。」
---經理堅持道：「行了，行了，我們沒有那麼多的時間。讓我來告訴您我們的需求。實際上我也很忙。請馬上開始開發，並隨時將你們的進展情況告訴我。」
---風險躲在需求的迷霧之後
-
--以上我們看到的是某客戶項目經理與系統開發小組的分析人員討論業務需求。在項目開發中，所有的項目風險承擔者都對需求分析階段備感興趣。這里所指
的風險承擔者包括客戶方面的項目負責人和用戶，開發方面的需求分析人員和項目管理者。這部分工作做得到位，能開發出很優秀的軟體產品，同時也會令客戶滿
意。若處理不好，則會導致誤解、挫折、障礙以及潛在的質量和業務價值上的威脅。因此可見——需求分析奠定了軟體工程和項目管理的基礎。
---撥開需求分析的迷霧
---像這樣的對話經常出現在軟體開發的過程中。客戶項目經理的需求對分析人員來講，像「霧里看花」般模糊並令開發者感到困惑。那麼，我們就撥開霧影，分析一下需求的具體內容：
---·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在項目定義與范圍文檔中予以說明。
---·用戶需求——描述了用戶使用產品必須要完成的任務，這在使用實例或方案腳本中予以說明。
---·功能需求——定義了開發人員必須實現的軟體功能，使用戶利用系統能夠完成他們的任務，從而滿足了業務需求。
---·非功能性的需求——描述了系統展現給用戶的行為和執行的操作等，它包括產品必須遵從的標准、規范和約束，操作界面的具體細節和構造上的限制。
---·需求分析報告——報告所說明的功能需求充分描述了軟體系統所應具有的外部行為。「需求分析報告」在開發、測試、質量保證、項目管理以及相關項目功能中起著重要作用。
---前面提到的客戶項目經理通常闡明產品的高層次概念和主要業務內容，為後繼工作建立了一個指導性的框架。其他任何說明都應遵循「業務需求」的規定，然而「業務需求」並不能為開發人員提供開發所需的許多細節說明。
---下一層次需求——用戶需求，必須從使用產品的用戶處收集。因此，這些用戶構成了另一種軟體客戶，他們清楚要使用該產品完成什麼任務和一些非功能性的特性需求。例如：程序的易用性、健壯性和可靠性，而這些特性將會使用戶很好地接受具有該特點的軟體產品。
E. 大家幫幫忙，我求一個軟體工程的問題定義和需求分析的文檔，
暈死......那麼難怎麼會有人懂呢？我看我是幫不上忙了哈！不過我剛才從網站上復制了一些，你看看吧？
需求獲取
1用戶的權利與義務
2制定調研計劃
3准備調研的資料
4訪談用戶
填寫調研表（那本書里有很好的例子）
5編寫調研報告
6需求的其他來源
7需求分析
8編寫需求文檔
比如數據流程，軟體結構，數據字典等
9需求管理
開發背景，客戶需求，開發工具，項目細節
開發環境，開發語言，還有你的開發流程等等
你自己看看吧？我想你用一個金山快譯也許能幫上忙？試試吧？
F. 軟體工程 測試應考慮的問題有哪些
所有的測試都是基於需求的！因此，最主要的還是得詳細的了解需求。
當然，軟體工程測試時需要考慮的問題包括：
1、需求是否是正確的，易於理解的，確保項目所有的人員對需求有一個正確的、一致的理解。
2、軟體設計時，需要考慮到軟體、硬體的各種不同的情況。我看您這個問題是在硬體類別的，特別需要考慮到硬體的兼容性、硬體的特殊功能測試等。
3、測試時，需要考慮到功能、性能、可用性、可靠性、穩定性等多個方面。當然，這個是得分階段的，可能一開始不會考慮這么多，但是還是最好一開始就能夠全部考慮進行。從整體上著手，這樣規劃出來會比較詳細，也更能從測試方面來保證軟體的質量。
G. 在軟體工程的各環節中，最容易出現缺陷的環節是什麼
軟體工程及時，最容易出錯的還是在前期，特別是在概要設計和詳細設計裡面，因為如果和用戶的需求背離太多，那麼到後期進行修改的過程中就會非常的費事，希望可以幫到你
H. 軟體工程開發過程中應注意的問題
需求調研分析、概要設計、詳細設計、編碼、測試、軟體交付准備、驗收