面向目標方法的目標分析階段的主要任務是

1. 簡要介紹面向對象分析主要完成什麼任務

您好，很高興能幫助您
我覺得沒必要去深究他的意思。
按我的理解，面向對象編程，主要是將我們實際生活中的對象經過抽象，將它定義成為一個類，通過類的屬性和方法來模擬生活中的這個對象。這樣使得程序更容易結構化、抽象起來更方便。

面向對象技術最初是從面向對象的程序設計開始的， 面向對象編程並不困難
它的出現以60年代simula語言為標志。80年代中後期，面向對象程序設計逐漸成熟，被計算機界理解和接受，人們又開始進一步考慮面向對象的開發問題。這就是九十年代以Microsoft Visual系列OOP軟體的流行的背景。 傳統的結構化分析與設計開發方法是一個線性過程，因此，傳統的結構化分析與設計方法要求現實系統的業務管理規范，處理數據齊全，用戶能全面完整地其業務需求。 傳統的軟體結構和設計方法難以適應軟體生產自動化的要求，因為它以過程為中心進行功能組合，軟體的擴充和復用能力很差。 對象是對現實世界實體的模擬，因面能更容易地理解需求，即使用戶和分析者之間具有不同的教育背景和工作特點，也可很好地溝通。 區別面向對象的開發和傳統過程的開發的要素有：對象識別和抽象、封裝、多態性和繼承。 對象(Object)是一個現實實體的抽象，由現實實體的過程或信息牲來定義。一個對象可被認為是一個把數據（屬性）和程序（方法）封裝在一起的實體，這個程序產生該對象的動作或對它接受到的外界信號的反應。這些對象操作有時稱為方法。對象是個動態的概念,其中的屬性反映了對象當前的狀態。 類(Class)用來描述具有相同的屬性和方法的對象的集合。它定義了該集合中每個對象所共有的屬性和方法。對象是類的實例。 由上分析不難看出，盡管OOP技術更看中用戶的對象模型，但其目的都是以編程為目的的，而不是以用戶的信息為中心的，總想把用戶的信息納入到某個用戶不感興趣的「程序對象」中。

你的採納是我前進的動力，
記得好評和採納，答題不易，互相幫助，

2. 目標管理的基本程序是什麼

目標管理的具體做法分三個階段：第一階段為目標的設置;第二階段為實現目標過程的管理;第三階段為測定與評價所取得的成果。下面讓我帶你了解目標管理的基本程序是什麼。

目標管理的基本程序

1.目標的設置

這是目標管理最重要的階段，第一階段可以細分為四個步驟：

①高層管理預定目標，這是一個暫時的、可以改變的目標預案。即可以上級提出，再同下級討論;也可以由下級提出，上級批准。無論哪種方式，必須共同商量決定;其次，領導必須根據企業的使命和長遠戰略，估計客觀環境帶來的機會和挑戰，對本企業的優劣有清醒的認識。對組織應該和能夠完成的目標心中有數。

②重新審議組織結構和職責分工。目標管理要求每一個分目標都有確定的責任主體。因此預定目標之後，需要重新審查現有組織結構，根據新的目標分解要求進行調整，明確目標責任者和協調關系。

③確立下級的目標。首先下級明確組織的規劃和目標，然後商定下級的分目標。在討論中上級要尊重下級，平等待人，耐心傾聽下級意見，幫助下級發展一致性和支持性目標。分目標要具體量化，便於考核;分清輕重緩急，以免顧此失彼;既要有挑戰性，又要有實現可能。每個員工和部門的分目標要和其他的分目標協調一致，支持本單位和組織目標的實現。

④上級和下級就實現各項目標所需的條件以及實現目標後的獎懲事宜達成協議。分目標制定後，要授予下級相應的資源配置的權力，實現權責利的統一。由下級寫成書面協議，編制目標記錄卡片，整個組織匯總所有資料後，繪制出目標圖。

2.實現目標過程的管理

目標管理重視結果，強調自主，自治和自覺。並不等於領導可以放手不管，相反由於形成了目標體系，一環失誤，就會牽動全局。因此領導在目標實施過程中的管理是不可缺少的。首先進行定期檢查，利用雙方經常接觸的機會和信息反饋渠道自然地進行;其次要向下級通報進度，便於互相協調;再次要幫助下級解決工作中出現的困難問題，當出現意外、不可測事件嚴重影響組織目標實現時，也可以通過一定的手續，修改原定的目標。

3.總結和評估

達到預定的期限後，下級首先進行自我評估，提交書面報告;然後上下級一起考核目標完成情況，決定獎懲;同時討論下一階段目標，開始新循環。如果目標沒有完成，應分析原因總結教訓，切忌相互指責，以保持相互信任的氣氛。

由於各個組織活動的性質不同，目標管理的步驟可以不完全一樣，但一般來說，可以分為以下四步[2]。

(一)建立一套完整的目標體系。實行目標管理，首先要建立一套完整的目標體系。這項工作總是從企業的最高主管部門開始的，然後由上而下地逐級確定目標。上下級的目標之間通常是一種 “目的一手段”的關系;某一級的目標，需要用一定的手段來實現，這些手段就成為下一級的次目標，按級順推下去，直到作業層的作業目標，從而構成一種鎖鏈式的目標體系。

制定目標的工作如同所有其他計劃工作一樣，非常需要事先擬定和宣傳前提條件。這是一些指導方針，如果指導方針不明確，就不可能希望下級主管人員會制定出合理的目標來。此外，制定目標應當採取協商的方式，應當鼓勵下級主管人員根據基本方針擬定自己的目標，然後由上級批准。

(二)明確責任。目標體系應與組織結構相吻合，從而使每個部門都有明確的目標，每個目標都有人明確負責。然而，組織結構往往不是按組織在一定時期的目標而建立的，因此，在按邏輯展開目標和按組織結構展開目標之間，時常會存在差異。其表現是，有時從邏輯上看，一個重要的分目標卻找不到對此負全面責任的管理部門，而組織中的有些部門卻很難為其確定重要的目標。這種情況的反復出現，可能最終導致對組織結構的調整。從這個意義上說，目標管理還有助於搞清組織機構的作用。

(三)組織實施。目標既定，主管人員就應放手把權力交給下級成員，而自己去抓重點的綜合性管理。完成目標主要靠執行者的自我控制。如果在明確了目標之後，作為上級主管人員還像從前那樣事必躬親，便違背了目標管理的主旨，不能獲得目標管理的效果。當然，這並不是說，上級在確定目標後就可以撒手不管了。上級的管理應主要表現在指導、協助。提出問題，提供情報以及創造良好的工作環境方面。

(四)檢查和評價。對各級目標的完成情況，要事先規定出期限，定期進行檢查。檢查的方法可靈活地採用自檢、互檢和責成專門的部門進行檢查。檢查的依據就是事先確定的目標。對於最終結果，應當根據目標進行評價，並根據評價結果進行獎罰。經過評價，使得目標管理進入下一輪循環過程。

目標管理的優點與不足

1、 目標管理的優點。

(1)形成激勵。當目標成為組織的每個層次、每個部門和每個成員自己未來時期內欲達到的一種結果，且實現的可能性相當大時，目標就成為組織成員們的內在激勵。特別當這種結果實現時，組織還有相應的報酬時，目標的激勵效用就更大。從目標成為激勵因素來看，這種目標最好是組織每個層次，每個部門及組織每個成員自己制訂的目標。

(2)有效管理。目標管理方式的實施可以切切實實地提高組織管理的效率。目標管理方式比計劃管理方式在推進組織工作進展，保證組織最終目標完成方面更勝一籌。因為目標管理是一種結果式管理，不僅僅是一種計劃的活動式工作。這種管理迫使組織的每一層次、每個部門及每個成員首先考慮目標的實現，盡力完成目標，因為這些目標是組織總目標的分解，故當組織的每個層次、每個部門及每個成員的目標完成時，也就是組織總目標的實現。在目標管理方式中，一旦分解目標確定，且不規定各個層次、各個部門及各個組織成員完成各自目標的方式、手段、反而給了大家在完成目標方面一個創新的空間，這就有效地提高了組織管理的效率。

(3)明確任務。目標管理的另一個優點就是使組織各級主管及成員都明確了組織的總目標、組織的結構體系、組織的分工與合作及各自的任務。這些方面職責的明確，使得主管人員也知道，為了完成目標必須給予下級相應的權力，而不是大權獨攬，小權也不分散。另一方面，許多著手實施目標管理方式的公司或其他組織，通常在目標管理實施的過程中會發現組織體系存在的缺陷，從而幫助組織對自己的體系進行改造。

(4)自我管理。目標管理實際上也是一種自我管理的方式，或者說是一種引導組織成員自我管理的方式。在實施目標管理過程中，組織成員不再只是做工作，執行指示，等待指導導和決策，組織成員此時已成為有明確規定目標的單位或個人。一方面組織成員們已參與了目標的制訂，並取得了組織的認可;另一方面，組織成員在努力工作實現自己的目標過程中，除目標已定以外，如何實現目標則是他們自己決定的事，從這個意義上看，目標管理至少可以算作自我管理的方式，是以人為本的管理的一種過渡性試驗。

(5)控制有效。目標管理方式本身也是一種控制的方式，即通過目標分解後的實現最終保證組織總目標實現的過程就是一種結果控制的方式。目標管理並不是目標分解下去便沒有事了，事實上組織高層在目標管理過程中要經常檢查、對比目標，進行評比，看誰做得好，如果有偏差就及時糾正。從另一個方面來看，一個組織如果有一套明確的可考核的目標體系，那麼其本身就是進行監督控制的最好依據。

2、目標管理的不足。

哈羅德·孔茨教授認為目標管理盡管的許多優點，但也有許多不足，對這樣的不足如果認識不清楚，那麼可能導致目標管理的不成功。下述幾點可能是目標管理最主要的不足：

(1)強調短期目標。大多數的目標管理中的目標通常是一些短期的目標：年度的、季度的、月度的等。短期目標比較具體易於分解，而長期目標比較抽象難以分解，另一方面短期目標易迅速見效，長期目標則不然。所以，在目標管理方式的這施中，組織似乎常常強調短期目標的實現而對長期目標不關心。這樣一種概念若深入組織的各個方面、組織所有所員的腦海中和行為中，將對組織發展沒有好處。

(2)目標設置困難。真正可用於考核的目標很難設定，尤其組織實際上是一處產出聯合體，它的產出是一種聯合的不易分解出誰的貢獻大小的產出，即目標的實現是大家共同合作的成果，這種合作中很難確定你已做多少，他應做多少，因此可度量的目標確定也就十分困難。一個組織的目標有時只能定性地描述，盡管我們希望目標可度量，但實際上定量是困難的，例如組織後勤部門有效服務於組織成員，雖然可以採取一些量化指標來度量，但完成了這些指標，可以肯定地說未必達成了"有效服務於組織成員"這一目標。

3. 想了解六西格瑪綠帶培訓和六西格瑪黑帶培訓中分析階段的主要任務是什麼啊

當實施六西格瑪確定了項目了解了流程的表現和能力後，進入到分析階段。簡單地說，....分析階段的主要任務就是：

分析階段是六西格瑪管理DMAIC流程各個階段中難度最大的階段。天行健咨詢指出該階段要先進行流程分析，即項目團隊應根據定義和測量階段所繪制的流程圖和所收集的數據進行詳細研究，增強對流程和問題的理解；然後通過團隊成員的頭腦風暴，發揮團隊智慧，畫出魚刺圖，系統地識別問題的可能原因，完成初步因果分析；接著，根據因果圖或因果矩陣分析，選取適當的因素，收集它們的數據；針對收集到的數據，團隊需要首先選擇適當的圖形方法定性分析數據的特點，分析數據的趨勢和分布；然後，進行假設檢驗分析，得到顯著性結果，為下一步分析指明方向；最後就是統計分析方法的回歸分析進行分析，確定真正的原因、尋找「問題根源」。

在分析階段，有時問題的根本原因是顯而易見的，團隊能很快通過分析找到。有時經過分析，找不到問題的根源，這就需要我們重新審視收集數據的過程是否符合要求，數據是否可信，必要時需要收集更多的數據(包括更多的因素)，進行假設，然後對這些推測或者假設作出進一步的判斷；各種假設不斷地被確認或被拒絕，直到真正的問題根源被數據分析明確識別出來。當這種情況發生時，團隊可能要花幾周或更長的時間，使用各種工具和試用各種不同的觀點去分析，才能得出正確的結果。

4. 六西格瑪管理培訓中分析階段的含義,內容,目標及步驟是什麼

六西格瑪分析階段的含義、內容、目標及步驟：

一、分析階段的含義、內容、目標

分析階段是流程改進過程中最重要的一環，其目標旨在確和驗證原問題的根源。在對流程中出現問題和缺陷的原因進行析之前，項目團隊已經憑經驗和直覺猜測和判斷出問題存的原因，即便如此，經驗和直覺也不能取代分析階段的工作。實上，真正發現問題存在的原因是在分析階段完成的。這一階段主要任務就是運用各種有效的工具和方法，對已有的數據積流進行分析，辨明影響績效改進的根本原因，選擇改進的優先項目，把握潛力最大的改進機會。

二、分析階段的步驟

對影響績效改進的根本原因的分析是一個不斷循環的過程，對於流程改進小組來說，在分析中應盡量避免的問題有：

①將循環縮短使其不完整，認為推測的原因是不成立的，從而在沒足夠理由的情況下提出解決方案；

②在循環中遇到障礙，從不信自己有足夠的數據，從來沒有信心認為自己能夠對最有可能原因採取對策。

1、進行數據和流程分析

要找出問題的根源，首先要對評估階段牧集到的數據積流程本身進行分析，即進行數據分析和流程分析。數據分析的目的是檢測評估階段收集到的數據，以幫助團隊尋找待改進問題成因的相關線索。當項目團隊的首要目標是圍繞效能指標展開時，可以優先採用數據分析；流程分析是深入調查流程的運轉情況，從辨明與改進目標不一致的、不相關的或可能引起問題或缺陷的領域。如果項目團隊關注的是效率指標，則可議優先採用流程分析。無論是數據分析還是流程分析，每一種方法都可以幫助團隊清楚地發現哪些原因才是根本原因，但是只有將數據分析和過程分析所發現的結論放在一起，相互補充，才能夠更加准確地界問題產生的根本原因。

2、建立問題發生原因的假設或模型

經過數據分析和流程分析，就可以對改進流程中出現的問題進行詳細地描述。接下來，團隊成員就要根據對問題的詳細描述，盡可能提出所有可能導致問題發生的原因。在短時間內產生眾多主意的團隊方法是頭腦風暴法。作為六西格瑪管理法的標准工作，頭腦風暴法有效避免了傳統會議那種與會人員由於害，怕別人評論而約束自己，因而不能產生有創意的提議的弊端，人為創造出一種氣氛，讓與會人員感到無拘無束，自由自在，從而提出很多在平時認為不可行的解決方案，並收到意想不到的效果。

在運用頭腦風暴怯時，為達到預期效果，要堅持以下原則：

①記錄所有的觀點，即使認為某個觀點荒誕離奇。因為在看似離奇的想法中也許就蘊含著解決方案；

②確保團隊是在提出觀點，而不是在篩選觀點。不要批評任何觀點，因為批評會打擊提案人員的熱情和積極姓，大家都噤若寒蟬，頭腦風暴法就不會達到預期的理想結果；

③不評價觀點。提案期間不要對任何人的觀點加以討論和評論，因為此時的討論可能會使會議偏離主題，並可能壓抑後續提案人員的自信；

④鼓勵大膽聯想，不怕出錯。在提案階段想得越多，提案內容的涉及面就越廣，最佳方案出現的可能性就越高。

⑤引每個人都參與，要求人人都發言。頭腦風暴法是集思益的會議，不希望與會者只帶著耳朵來，多一份發言、就多一份思路、多一份解塊方案。

3、再次進行數據和流程分析

這一階段的工作與第一階段的工作相似，但不是簡單重復。通過頭腦風暴法列出產生問題的各種可能原因之後，團隊要利用評估階段已經收集的數據和在分析階段收集的新數據，對問題的發展趨勢和其他相關因素進行重新分析。在擁有各種各樣的數據之後，就可以利用這些數據和另外一些可獲得的有關事實，對前面提出的假設進行檢驗，或是提出新的原因假設。在調數據時，要充分掌握邏輯分析方法，確定所觀察到的事實或收集到的數據是否與假設相符。邏輯分析方法以邏輯為根據，以問題中心，強調客觀事實。運用邏輯分析方法，就可以知道哪些類型種類的問題最普遍，哪些流程的問題較為嚴重，哪些因素與問題產生具有相關性，從而縮小問題范圍，排除一些可能的原因，證實假設來支持分析循環過程。

4、修正假設或模型

經過再一次的數據分析和流程分析之後，這一階段的目標把在頭腦風暴中產生的大量原因縮減或剔除到一個更易管理內數量。根據上一步的分析結果，團隊要檢查大家提出的各種觀點是否重復，並鑒別這些觀點中的主要類別。在這一階段，每一位隊成員都應清楚地了解其他成員提出的觀點，同時當其他成員理解自己的觀點時，要向他們明確解釋自己的觀點。團隊要將重復的觀點剔除，並經過下一輪的討論確定是否增加其他的原因，最後列出能夠代表團隊觀點的所有原因。

5、確認並選擇幾個關鍵原因

經過上一步修正工作，團隊就縮小潛在原因的范圍。分析階段的最後一步就是要確認選擇幾個影響流程改進的關鍵因，即進行根本原因的分析。團隊成員要利用已有的數據檢驗假設的原因，甚至可以親自到假設的原因發生的地點或流程現觀察，以核實所假設的原因與實際情況是否相符。團隊成員還可以與了解情況的其他非團隊成員如顧客、供應商或問題專家進交流，從而進一步修正假設，在分析階段的最後，根據已有的數和觀察到的事實，確認問題產生的真正原因，以便在下一階段的工作中尋找減少問題根源造成的影響或消除產生問題根源的決方案。

5. 軟體工程中需要分析階段的主要工作有哪些

1問題定義

問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。

通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。

問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的時間。

2可行性研究

這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。

可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。

在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。

可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。

3需求分析

這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。

用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。

在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於著手進行具體設計的傾向。

4總體設計

這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」

首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：

低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。

中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。

高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。

系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。

上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。

5詳細設計

總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」

這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。

6編碼和單元測試

這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。

程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。

7綜合測試

這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟體達到預定的要求。

最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。

必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。

為了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。

通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。

應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做為軟體配置的一個組成成分。

8軟體維護

維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。

通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做准備。

雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

6. 需求分析階段的主要任務是什麼為了完成這些任務，你都做了哪些工作

確定系統需求，分析用戶對系統的業務需求和功能需求，在進行系統的開發計劃。
了解用戶的真實想法和系統運行環境，對功能進行一些兼容和優化。

7. 簡述系統分析階段主要有哪些活動以及這些活動的內容和目的

1、內容：對研究的對象和需要解決的問題進行系統的說明。目的：在於確定目標和說明該問題的重點和范圍。

2、內容：收集資料 目的：在系統分析基礎上，通過資料分析各種因素之間的相互關系，尋求解決問題的可行方案。

3、內容：依系統的性質和要求，建立模型。 目的：建立各種數學模型，提供分析依據。

4、內容：運用數學模型對比。 目的：權衡各種方案的利弊得失。

5、內容：確定最優方案。目的：通過分析，若不滿意所選方案，則可按原步驟重新分析。一項成功的系統分析需要對各方案進行多次反復循環與比較，方可找到最優方案。

(7)面向目標方法的目標分析階段的主要任務是擴展閱讀

系統分析的實質

(1)應用科學的推理步驟，使系統中一切問題的剖析均能符合邏輯原則，順乎事物發展規律，盡力避免其中的主觀臆斷性和純經驗性。

(2)藉助於數學方法和計算手段，使各種方案的分析比較定量化，以具體的數量概念來顯示各方案的差異。

(3)根據系統分析的結論，設計出在一定條件下達到人盡其才、物盡其用的最優系統方案。

系統分析要素是作系統分析時必須加以考慮的基本因素。

主要包括：

(1) 系統目的 (或目標)。系統分析主要是為了幫助決策者選擇策略及行動方案。因此，首要的任務應了解決策者的目標是什麼，並確定實現該目標的指標體系。明確的目標是系統分析的出發點和依據。

(2) 可行方案。為達到系統預期目的的可供選擇的替代方案，是實現系統目的的手段。它可以通過不同的途徑及方式來實現同一系統的目的。可選擇的替代方案應是多種多樣的。

參考資料來源網路-系統分析