Can you summarize the following document?
        
  軟體工程包括兩種構面:軟體開發技術和軟體專案管理。

  1970年代和1980年代的軟體危機。在那個時代,許多軟體最後都得到了一個悲慘的結局,軟體專案開發時間大大超出了規劃的時間表。一些專案導致了財產的流失,甚至某些軟體導致了人員傷亡。同時軟體開發人員也發現軟體開發的難度越來越大。在軟體工程界被大量引用的案例是Therac-25的意外:在1985年六月到1987年一月之間,六個已知的醫療事故來自於Therac-25錯誤地超過劑量,導致患者死亡或嚴重輻射灼傷。

  鑑於軟體開發時所遭遇困境,北大西洋公約組織(NATO)在1968年舉辦了首次軟體工程學術會議,並於會中提出「軟體工程」來界定軟體開發所需相關知識,並建議「軟體開發應該是類似工程的活動」。軟體工程自1968年正式提出至今,這段時間累積了大量的研究成果,廣泛地進行大量的技術實踐,藉由學術界和產業界的共同努力,軟體工程正逐漸發展成為一門專業學科。

  關於軟體工程的定義,在GB/T11457-2006《資訊科技 軟體工程術語》中將其定義為"應用電腦科學理論和技術以及工程管理原則和方法,按預算和進度,實現滿足使用者要求的軟體產品的定義、開發、和維護的工程或進行研究的學科"。包括:

  ACM與IEEE Computer Society聯合修定的SWEBOK(Software Engineering Body of Knowledge)提到,軟體工程領域中的核心知識包括:

  軟體的開發到底是一門科學還是一門工程,這是一個被爭論了很久的問題。實際上,軟體開發兼有兩者的特點。但是這並不意味著它們可以被互相混淆。很多人認為軟體工程基於電腦科學和資訊科學就如傳統意義上的工程學之於物理和化學一樣。在美國,大約40%的軟體工程師具有電腦科學的學位。在世界其他地方,這個比例也差不多。他們並不一定會每天使用電腦科學方面的知識,但是他們每天都會使用軟體工程方面的知識。  例如Peter McBreen認為,軟體工程意味著更高程度的嚴謹性與經過驗證的流程,並不適合現階段各型別的軟體開發。Peter McBreen在著作《Software Craftsmanship: The New Imperative》提出了所謂「craftsmanship」的說法,認為現階段軟體開發成功的關鍵因素,是開發者的技能,而不是「manufacturing」軟體的流程。

  Capers Jones曾對美國軟體組織的績效做過評估,所得到結論是:軟體工程的專業分工不足,是造成品質低落、時程延誤、預算超支的最關鍵因素。  2003年,The Standish Group年度報告指出,在他們調查的13522個專案中,有66%的軟體專案失敗、82%超出時程、48%推出時缺乏必需的功能,總計約550億美元浪費在不良的計劃、預算或軟體估算上。

  在1986年,IBM大型電腦之父佛瑞德·布魯克斯發表了他的著名論文《沒有銀彈》,在這篇著名的論文中他斷言:“在10年內無法找到解決軟體危機的靈丹妙藥”。從軟體危機被提出以來。人們一直在尋找解決它的方法。於是一系列的方法被提出並且加以應用。比如結構化程式設計,物件導向的開發,CMM,UML等等。佛瑞德·布魯克斯著名作品還有《人月神話》。  布魯克斯在《人月神話:軟體專案管理之道(The Mythical Man-Month)》提到,將沒有靈丹妙藥(silver bullet)可以一蹴而就,開發軟體的困難是內生的,只能漸進式的改善。整體環境沒有改變以前,唯一可能的解,是依靠人的素質,培養優秀的工程師。

  軟體工程存在於各種應用中,存在於軟體開發的各個方面。而程式設計通常包含了程式設計和編碼的反覆迭代的過程,它是軟體開發的一個階段。  軟體工程力圖對軟體專案的各個方面作出指導,從軟體的可行性分析直到軟體完成以後的維護工作。軟體工程認為軟體開發與各種市場活動密切相關。比如軟體的銷售,使用者培訓,與之相關的軟體和硬體安裝等。軟體工程的方法學認為一個獨立的程式設計師不應當脫離團隊而進行開發,同時程式的編寫不能夠脫離軟體的需求,設計,以及客戶的利益。  軟體工程的發展是計算機程式設計工業化的體現。

  軟體開發過程是隨著開發技術的演化而隨之改進的。從早期的瀑布式(Waterfall)的開發模型到後來出現的螺旋式的迭代(Spiral)開發,以致最近開始興起的敏捷軟體開發(Agile),他們展示出了在不同的時代軟體產業對於開發過程的不同的認識,以及對於不同型別專案的理解方法。  注意區分軟體開發過程和軟體過程改進之間的重要區別。諸如像ISO 15504, ISO 9000, CMM, CMMI這樣的名詞闡述的是一些軟體過程改進框架,他們提供了一系列的標準和策略來指導軟體組織如何提升軟體開發過程的質量、軟體組織的能力,而不是給出具體的開發過程的定義。

  軟體工程的方法有很多方面的意義。包括專案管理,分析,設計,程式的編寫,測試和質量控制。  軟體設計方法可以區別為重量級的方法和輕量級的方法。重量級的方法中產生大量的正式文件。  著名的重量級開發方法包括ISO 9000,CMM,和統一軟體開發過程(RUP)。  輕量級的開發過程沒有對大量正式文件的要求。著名的輕量級開發方法包括極限程式設計(XP)和敏捷過程(Agile Processes)。  根據《新方法學》這篇文章的說法,重量級方法呈現的是一種“防禦型”的姿態。在應用“重量級方法”的軟體組織中,由於軟體專案經理不參與或者很少參與程式設計,無法從細節上把握專案進度,因而會對專案產生“恐懼感”,不得不要求程式設計師不斷撰寫很多“軟體開發文件”。而輕量級方法則呈現“進攻型”的姿態,這一點從XP方法特別強調的四個準則—“溝通、簡單、反饋和勇氣”上有所體現。目前有一些人認為,“重量級方法”適合於大型的軟體團隊(數十人以上)使用,而“輕量級方法”適合小型的軟體團隊(幾人、十幾人)使用。當然,關於重量級方法和輕量級方法的優劣存在很多爭論,而各種方法也在不斷進化中。  一些方法論者認為人們在開發中應當嚴格遵循並且實施這些方法。但是一些人並不具有實施這些方法的條件。實際上,採用何種方法開發軟體取決於很多因素,同時受到環境的制約。

  “敏捷開發”(Agile Development)被認為是軟體工程的一個重要的發展。它強調軟體開發應當是能夠對未來可能出現的變化和不確定性作出全面反應的。  敏捷開發被認為是一種“輕量級”的方法。在輕量級方法中最負盛名的應該是“極限程式設計”(Extreme Programming,簡稱為XP)。而與輕量級方法相對應的是“重量級方法”的存在。重量級方法強調以開發過程為中心,而不是以人為中心。重量級方法的例子比如CMM/PSP/TSP。  面向方面的程式設計(Aspect Oriented Programming,簡稱AOP)被認為是近年來軟體工程的另外一個重要發展。這裡的方面指的是完成一個功能的物件和函式的集合。在這一方面相關的內容有泛型程式設計(Generic Programming)和模板。

  

  系統工程師主要處理系統的整體需求和設計,包括硬體與人力問題。
軟體工程(英語:quote = 寫程式的難度愈來愈低,因為程式語言越來越高階,API 越來越多,開發工具越來越好用,寫程式的門檻自然就大大地降低了。想要開發出有價值的中大型系統,軟體工程就很重要了,以蓋房子來說,你可以隨便找一兩個工人用磚或木材來蓋一棟矮房,但是如果想蓋一百多層樓的101大樓,你非得有良好的工程規劃不可,軟體不也是如此?程式設計師名片上的頭銜都是工程師,雖然和建築工程師、機械工程師... 一樣都被稱為工程師,但比較起來,軟體產業的工程師卻是最不工程導向的。 }}),是軟體開發領域裡對工程方法的系統應用。