軟體工程理論的來源

A. 軟體工程

開發軟體並不簡單只是編編程序（如果是那樣，初、高中生就能完成了，要我們這些大學生幹嘛），就象做生意（比如開商店），你總不會認為開商店就是站那兒賣貨吧，你得先進行市場調研，再選店址，然後上貨，賣貨，當然還有售後服務），這是一個復雜的，系統的工程，一般包括以下幾項：客戶需求調查或市場調查、軟體的框架設計、各框架的進一步細分，編寫程序（內容很多，比如用什麼語言，面向什麼，設計模式等等），黑白盒測試，發布測試版，軟體的交付以及售後服務，還有各階段的文檔總結（包括軟體的幫助文件，注釋等等），總之，就是一個軟體從調研到最後發布的各中間過程，軟體工程就是對這各種階段的說明以及如何去實施各階段，學好了它，對你今後的軟體工程師之路是非常有用的，也是必需的。

B. 急需！簡述你對軟體工程理論的來源、作用和意義的認識。謝謝！

不知道是否正確
1995年,Standish
Group針對系統開發成功的研究表明,所有的開發項目中有32%的項目在它們結束之前被中止.此外多於一半的軟體項目花費的成本相當於原來預算的2倍，只有42%的軟體項目完成時達到了預期的范圍和功能,事實上,許多系統只完成了部分預期的需求.因此,軟體的開發是一個很困難的活動,要求很仔細的計劃和執行.軟體工程就是在這樣的背景下,由許多計算機科學家經過多方面的探索和總結而成形的.軟體工程是計算機專業的一門重要的專業基礎課,它對於培養學生的軟體素質,提高學生的軟體開發能力與軟體項目管理能力具有重要的意義. 近二十年來計算機軟體已經成為現代科學研究和解決工程問題的基礎,以及管理部門,生產部門,和服務行業中的關鍵因素,滲透到了各個領域,成為當今世界不可缺少的一部分.

C. 軟體工程的原理

自從1968年提出「軟體工程」這一術語以來，研究軟體工程的專家學者們陸續提出了100多條關於軟體工程的准則或信條。美國著名的軟體工程專家巴利·玻姆（Barry Boehm）綜合這些專家的意見，並總結了美國天合公司（TRW）多年的開發軟體的經驗，於1983年提出了軟體工程的七條基本原理。
玻姆認為，這七條原理是確保軟體產品質量和開發效率的原理的最小集合。它們是相互獨立的，是缺一不可的最小集合；同時，它們又是相當完備的。人們當然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明，在此之前已經提出的100多條軟體工程准則都可以有這七條原理的任意組合蘊含或派生。
下面簡要介紹軟體工程的七條原理：
用分階段的生命周期計劃嚴格管理
這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗項目是由於計劃不周而造成的。在軟體開發與維護的漫長生命周期中，需要完成許多性質各異的工作。這條原理意味著，應該把軟體生命周期分成若干階段，並相應制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發和維護進行管理。
玻姆認為，在整個軟體生命周期中應指定並嚴格執行6類計劃：
項目概要計劃、
里程碑計劃、
項目控制計劃、
產品控制計劃、
驗證計劃、
運行維護計劃。
堅持進行階段評審
統計結果顯示：大部分錯誤是在編碼之前造成的，大約佔63%錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。 因此，軟體的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便盡早發現錯誤。
實行嚴格的產品控制
開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要採用科學的產品控制技術來順應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟體的一致性。
採納現代程序設計技術
從六、七十年代的結構化軟體開發技術，到最近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大於氣力。採用先進的技術既可以提高軟體開發的效率，又可以減少軟體維護的成本。
結果應能清楚地審查
軟體是一種看不見、摸不著的邏輯產品。軟體開發小組的工作進展情況可見性差，難於評價和管理。為更好地進行管理，應根據軟體開發的總目標及完成期限，盡量明確地規定開發小組的責任和產品標准，從而使所得到的標准能清楚地審查。
開發小組的人員應少而精
開發人員的素質和數量是影響軟體質量和開發效率的重要因素，應該少而精。這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高幾倍到幾十倍，開發工作中犯的錯誤也要少的多；當開發小組為N人時，可能的通信信道為N(N-1)/2, 可見隨著人數N的增大，通訊開銷將急劇增大。
承認不斷改進軟體工程實踐的必要性
遵從上述六條基本原理，就能夠較好地實現軟體的工程化生產。但是，它們只是對現有的經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐。因此，玻姆提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條原理。根據這條原理，不僅要積極採納新的軟體開發技術，還要注意不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計。這些數據既可以用來評估新的軟體技術的效果，也可以用來指明必須著重注意的問題和應該優先進行研究的工具和技術。

D. 什麼是軟體工程的核心思想

軟體工程的核心思想是：在給定成本、進度的前提下，開發出具有適用性、有效性、可修改性、可靠性、可理解性、可追蹤性、可互操作性和滿足用戶需求的軟體產品。

軟體工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。

它涉及到程序設計語言、資料庫、軟體開發工具、系統平台、標准、設計模式等方面。

但是軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：

BarryBoehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。

FritzBauer：在NATO會議上給出的定義：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。

(4)軟體工程理論的來源擴展閱讀：

軟體工程有以下四項基本原則：

1、選取適宜開發范型。

在系統設計中，軟體需求、硬體需求以及其他因素之間是相互制約、相互影響的，經常需要權衡。因此，必須認識需求定義的易變性，採用適宜的開發范型予以控制，以保證軟體產品滿足用戶的要求。

2、採用合適的設計方法。

在軟體設計中，通常要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。

3、提供高質量的工程支持。

在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。

4、重視開發過程的管理。

軟體工程的管理，直接影響可用資源的有效利用，生產滿足目標的軟體產品，提高軟體組織的生產能力等問題。因此，僅當軟體過程得以有效管理時，才能實現有效的軟體工程。

E. 軟體工程 計算機軟體與理論

你好，我念的是軟體工程。事實上，樓上說的對，計算機科學與技術其實和軟體工程開的課基本都是一樣的（大多數課都一樣，但是用的教材不同，我們院就是有些課軟工是國外教材，計科是國內教材），出來找工作也是一樣的。只是軟體工程從大二就有實習，所以學費比計科貴的多。總的來說，都是一樣的，不影響考研的。計科學的面會廣些，軟工實習多些。

F. 軟體工程學科涉及哪些理論和方法

(一軟體工程學科已發展為計算機科學與技術、數學、工程學、管理學等相關學科的交 叉性學科。傳統的計算機科學與技術學科已經涵蓋不了軟體工程可歸屬的二級學科問題, 不適應軟體產業對軟體工程人才培養的需要。

(二軟體工程學科已形成較完整的理論與工程技術體系,課程體系基本明確,高端人才 培養能力基本形成,創新型復合型人才的社會需求不斷提高。

(三軟體工程涉及軟體產業、信息產業和現代服務業,代表未來社會產業發展方向。

(四現有軟體工程人才培養體系不完整,需要通過進一步學科建設方能適應產業發展對 高端人才的需求。

G. 為什麼需要軟體工程理論

�匭路⑾秩砑�こ痰謀局省�acobson等撰寫了三篇文章詳細闡述Semat思想，本刊將陸續刊載，本文是其中第二篇。
這種行為可以從很多地方看出來，很多團隊草率地丟棄昂貴的過程和工具的投資，甚至在嘗試它們之前。每個項目都採用新方法。每次工作發生變化，在手頭真正的工作取得進展前，他們必須學習新方法。這是沒有效率的，人們不能從經驗中學習，因為他們永遠從頭開始。底線是，沒有什麼新事物能夠被適當地固定下來即使經過幾種現代軟體開發趨勢，最流行的軟體開發方法仍然是規范型的瀑布開發或自由hacking。作為一個行業，我們沒有什麼真正可以堅守的東西，而且一切似乎沒有什麼變化。
最新橫掃行業的趨勢是敏捷。現在，我們可以很明確地說，敏捷運動對軟體產業做出了非常積極的 [1] 貢獻。它提醒我們，軟體開發中，人是第一位的，也是最重要的。事實上，這不是什麼新觀念，但這是重要的，而且這一點似乎被以前更加技術導向的趨勢所忽視，比如說面向對象和Java編程。通過展現一系列優點，敏捷宣言創造了某種強健和適應力強的東西，可以抵擋下一次趨勢帶來的變革風浪。[2]許多聲稱支持敏捷哲學的敏捷方法，卻沒能做到這一點，這是非常讓人遺憾的。對一項將人的價值放在過程和工具之上的運動來說，這確實帶給了我們很多新的過程和工具。其中的大部分已經顯示出效率，通過將團隊帶回到之前完成的開發軟體工作。但在重新聚焦到這上面之前，許多人已經迷失或迷茫，因為將新術語引入舊事物後，讓人覺得這一切似乎是全新的。這個對舊思想的不斷重新包裝和品牌重樹讓軟體開發團隊的工作方式劇烈搖擺。對他們的工作和產品任意命名，而不是讓人們遠離浪費時間的工作，將精力重新聚焦在對高質量軟體的開發上。
即使有些方法能夠像敏捷哲學一樣正確、有益，但相關的信息可能會在搖擺和炒作中丟失。我們已經開始看到對敏捷的反彈，我們擔心的是利益將會丟失，當早期使用者投入下一個趨勢，而晚期大眾則重新主張自己的權利，拒絕採納這些顯然不再流行的東西。
有可能會發生的事情是，我們增加更多時髦的詞彙和相互沖突的名詞，最終為這一切喧囂所累!
很顯然，我們需要停止對流行和永遠令人失望的簡單答案的追逐，同時不能阻礙創新和新想法。為了做到這一點，人們需要停止對舊思想不斷重新包裝和品牌重樹。相反，他們應側重於幫助人們了解如何建立優秀的軟體。但我們如何才能重點推動這一變化?我們認為，這個理論就在眼前我們要做的只是抓住它。首先，我們應該從所有流行的方法、過程和實踐開始，並從中提煉出軟體工程的真理。然後，我們可以描述和捕捉一個最小集合的基本概念，以最小獨立過程的形式我們將這個本質物的最小集合稱之為內核。
然後以這個內核為出發點，我們可以分析現有的過程和方法，並確定它們所包含的實踐。從內核開始，我們可以找到一種描述實踐的方式，使它們能夠進行比較和結合。
現在所說的這種創造理論的方法本身並不是理論。這是我們已經做過的事情。通過研究一些方法，包括XP、Scrum和統一過程，我們的團隊已經確定了20多個內核元素，我們總是做的事情或產生的東西。從表面上看，在這些被研究的方法和我們的工作方式中，有可能會出現很大差異;但在實質上，它們有相同的DNA。舉例來說，你可以捕捉功能或用例或用戶故事的條件，你可以在沒有生命周期與統一過程的生命周期，甚至瀑布生命周期(就像有些人仍然在堅持的那樣)的情況下使用這些條件。這些方法肯定有一個共同基礎，能夠以小的簡單的內核要素集的形式被捕獲。
現在，還不能冒失地聲稱，我們的內核提供了必要的理論。需要有比我們更多、更大的頭腦來做到這一點。但是，我們會將它作為一項證據，證明它的能力和我們需要的理論就近在眼前。
許多大公司都有自己的方法或過程，也就是一系列標准方法，搭配自己對更具體業務的想法。這些過程通常要用一本厚書或網站來介紹，大量資金被投入到歸檔工作中。有時，人們被訓練使用這些過程，有時只是被簡單告知它們在哪兒。在現實中，過程常常被忽視;僅有的被實際使用的部分是，組織中形成了口頭傳統的那些。這被解釋成重新發現的自然法則：人們不看過程的書籍。新的思路引入到組織中，舊過程退出流行，而有關它們的書成為擺設。
在某些大公司甚至會出現多個過程。例如，大型系統集成商可能有十個或二十個不同的過程。有時它們很相似，但相似性背後隱藏著差異。
如果貴公司採用這種實踐觀，你就不需要因為一些新的性感的東西正成為流行，而拋棄整個工作方式。相反，你只需要對現有的工作方式進行改進，一次改進一個實踐。你甚至可以採取那些被其他公司使用的實踐，而不用丟掉似乎運作良好的現有實踐。作為開始，你需要將現在的工作方式看作一個實踐集合。然後尋找你的痛點，然後修補目前的工作方式，通過刪除沒用的實踐，代之以解決這些薄弱環節的實踐。一旦你理解了內核和它的使用，就很容易做到這一點。在具有多種不同工作方式的大型組織，你可以使用此方法先後改進每個工作方式，而不必強迫大家使用相同的方法或過程。
這種做法將使新實踐更容易被採納，而無須改變其他實踐。想像一下，幾年前，你已經引入了內核，並描述你的實踐。然後，你將能夠輕松引入Scrum，通過用Scrum取代項目管理中現有的實踐，而無須對其他實踐進行任何重大修改。展望未來，Scrum將很有可能被新的實踐代替，你將能夠很容易地做到這一點了。
如果我們的技術學院或大學教授學生軟體工程基礎知識，然後訓練學生在一系列良好的實踐中使用該基礎，那將是非常棒的。教育將會更合乎邏輯，因為它著重以獨特的想法，而不是特定的思想，來形成每個方法、過程或方法論。我相信學生們會喜歡的。這里也為相關研究留下了很多空間。記住Kurt Lewin的話：沒有什麼比一個好的理論更實用了。一個好的理論使得學習和開發你的知識更容易，而不會帶來過分的崇拜。這將是聰明的。大多數大學教授們在學術生涯中，從來沒有真正的機會來實踐大規模的軟體開發。但是他們仍然不得不教授軟體工程，這當然是不容易或者只是依葫蘆畫瓢。他們只能這樣做，因為這門課在課程表上，而不是因為他們確實有什麼可教的。他們沒有傳授理論，只是一套想法或一個特定的方法。當被問及此事時，一名成功的計算機科學家、教授軟體工程課程的教授說：令人驚訝的是，學生們喜歡沐浴在我們交給他們的爛泥塘里。我知道這么說並不嚴肅，但是可以肯定這位老師並不為他做的事情而感到自豪。
一個理論，將從根本上改變這種局面。學生將學習軟體的基礎知識。他們將得到一種語言，來溝通軟體過程、實踐、模式，等等。可以想像，他們將會得到一種以內核為語法的語言和描述過程構成成分的時間的語言結構。這樣的語言需要是可執行的，這樣實踐才會變得生動。我說這些是為了表明這些實踐不僅是規范，而且也可執行。當一個項目進行時，這些實踐將開始運行，而且活動實例、工作產物，實例、技能角色將被真實物創造和填充。這些方面似乎能與實踐模式很好地吻合，有非常有趣的語義規則需要確定和定義。向學生打開了一個全新的世界，可以幫助他們了解軟體工程的基本原理。更不用說，為對實踐和理論感興趣的研究人員打開了一個全新的世界。
回顧自己1987年後的職業生涯，許多人建議我寫一本有關方法論的書。當時Objectory有一些新的想法，比如說用例、用例驅動的開發(這是一個測試驅動設計、合作、序列圖、組件和基於組件的開發)。其餘的大部分內容都沒什麼特別的。實施、單元測試、系統測試、性能測試、配置、規劃都是相當傳統的。當然，我有整個生命周期的經驗，但我不是所有事情的世界級專家。然而，為了寫書，我不得不包含整個生命周期的內容，即使其中很多不是我的專長。隨著我們尋找的新理論，沒有任何必要再說明不包含創新的內容。你不需要寫一本書來發布新想法，然後把軟體開發團隊需要做的一切都放進去，而只需要描述你的新實踐或新模式，也許第二天你就能向全世界發布了。全世界的任何好點子都可以貢獻出來並獲得成功。
終於，軟體團隊將能夠擺脫亦步亦趨地追隨潮流所造成的無休止的搖擺，成為嚴格意義上的軟體工程團隊。團隊在堅實的基礎上通過優秀的軟體開發實踐建設和擴展知識。這個基礎不會頻繁變化，不會強迫你一遍又一遍學習同樣的事情。它可以讓你通過自己的總結，而不是出席的課程來展示專業。它可以讓你輕松和無縫地引進新思路和新隊友，而不會造成性能驟降或精力浪費。團隊最終能夠不斷改進和適應他們的工作方式，迎接他們每天面對的挑戰。他們將能夠開發自己的知識和技能，以一種能夠讓他們順利地和來自不同背景、團隊和組織的其他人合作的方式，而不必一遍又一遍地重復學習同樣的事情了。
最後的話我們對軟體工程的了解缺乏一個基本理論。因此，我們不斷用略有不同的詞再造舊方法，掩蓋了真正的創新，同時讓拋棄舊的不好的部分，利用新的好的部分變得困難。該理論將幫助我們大大改進軟體工程教育。這將幫助我們在面對身邊涌現的新想法時的反應不那麼天真。最後，它也將幫助我們更快地接受新的思想。這一理論的真正受益者將是軟體行業，這一點已經在許多公司得到證明。我們將能夠方便地教育我們的人員，讓他們加快速度;改進我們生產產品的方式;系統地重新設計(比重構程度更強)我們的產品;不斷改進我們的工作方式。其結果將是更好的軟體、更快的速度和大幅降低的成本。正如上面提到的，我們需要齊心協力才能做到這一點。從Scott Ambler最近的一篇文章理論需要戰略中可以看到這種勢頭已經開始，但仍有許多工作要做。
我們已經證明它的有效性，但我們仍然要做許多工作才能建立一個公認的標准，必須在一組專家和權威之間建立共識才能完成這點。我們期待著與這些專家的合作。

H. 軟體工程三要素是什麼

三要素是方法、工具、過程。

方法是完成軟體開發的各項任務的技術方法，為軟體開發提供「如何做」的技術。工具為運用方法而提供的自動的或半自動的軟體工程的支撐環境。

過程是為了獲得高質量的軟體所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟，如何將軟體工程方法與軟體工具相結合，合理、及時地進行軟體開發。

(8)軟體工程理論的來源擴展閱讀：

軟體工程的目標：

1、可修改性：允許對系統進行修改而不增加原系統的復雜性。它支持軟體的調試和維護，是一個難以達到的目標。

2、可靠性：能防止因概念、設計和結構等方面的不完善造成的軟體系統失效，具有挽回因操作不當造成軟體系統失效的能力。

3、可理解性：系統具有清晰的結構，能直接反映問題的需求。可理解性有助於控制系統軟體復雜性，並支持軟體的維護、移植或重用。

4、可維護性：軟體交付使用後，能夠對它進行修改，以改正潛伏的錯誤，改進性能和其它屬性，使軟體產品適應環境的變化等。軟體維護費用在軟體開發費用中佔有很大的比重。可維護性是軟體工程中一項十分重要的目標。

5、可重用性：把概念或功能相對獨立的一個或一組相關模塊定義為一個軟部件。可組裝在系統的任何位置，降低工作量。

6、可移植性：軟體從一個計算機系統或環境搬到另一個計算機系統或環境的難易程度。

7、可追蹤性：根據軟體需求對軟體設計、程序進行正向追蹤，或根據軟體設計、程序對軟體需求的逆向追蹤的能力。

I. 軟體工程產生的背景

軟體工程誕生背景：
幾十年前，軟體行業很不規范，小程序雖然個人能很好完成，但缺乏良好的代碼管理；大程序設計人員多，工程復雜，由於缺乏相關理論知識和經驗，導致很多失敗的大項目產生，為了解決這種情況誕生了軟體工程。建議你去讀《人月神話》，能管窺一二。

軟體工程專業誕生背景：
當年中國這片神奇的大地上缺少計算機方面剛畢業就能很好與企業接軌的人，因為高校供給企業的生源往往只知道理論知識，卻不能又快又好地上手工作，企業又往往不願意花費太多精力去培養這樣的人，所以為了解決這種蛋疼的狀況，中國的軟體工程專業誕生了，更重視計算機實踐方面的教學！

J. 軟體工程的基本原理有哪些

軟體工程的七條基本原理
1、用分階段的生命周期計劃嚴格管理有人經統計發現，在不成功的軟體項目中有一半左右是由於計劃不周造成的，可見把建立完善的計劃作為第一條基本原理是吸取了前人的教訓而提出來的。
在軟體開發與維護的漫長的生命周期中，需要完成許多性質各異的工作。這條基本原理意味著，應該把軟體生命周期劃分成若干個階段，並相應地制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發與維護工作進行管理。Boehm 認為，在軟體的整個生命周期中應該制定並嚴格執行六類計劃，它們是項目概要計劃，里程碑計劃，項目控制計劃，產品控制計劃，驗證計劃，運行維護計劃。

不同層次的管理人員都必須嚴格按照計劃各盡其職地管理軟體開發與維護工作，絕不能受客戶或上級人員的影響而擅自背離預定計劃。

2、堅持進行階段評審

當時已經認識到，軟體的質量保證工作不能等到編碼階段結束之後再進行。這樣說至少有兩個理由：第一，大部分錯誤是在編碼之前造成的，例如，根據Boehm 等人的統計，設計錯誤占軟體錯誤的63%，編碼僅佔37%；第二，錯誤發現與改正得越晚，所需付出的代價也越高。因此，在每個階段都進行嚴格的評審，以便盡早發現在軟體開發過程中所犯的錯誤，是一條必須遵循的重要原則。

3、實行嚴格的產品控制
在軟體開發過程中不應隨意改變需求，因為改變一項需求往往需要付出較高的代價，但是，
在軟體開發過程中改變需求又是難免的，由於外部環境的變化，相應地改變用戶需求是一種客觀需要，顯然不能硬性禁止客戶提出改變需求的要求，而只能依靠科學的產品控制技術來順應這種要求。也就是說，當改變需求時，為了保持軟體各個配置成分的一致性，
必須實行嚴格的產品控制，其中主要是實行基準配置管理。所謂基準配置又稱基線配置，它們是經過階段評審後的軟體配置成分（各個階段產生的文檔或程序代碼）。基準配置管理也稱為變
動控制：
一切有關修改軟體的建議，
特別是涉及到對基準配置的修改建議，必須按照嚴格的規程進行評審，獲得批准以後才能實施修改。絕對不能誰想修改軟體（包括尚在開發過程中的軟體），就隨意進行修改。

4、採用現代程序設計技術
從提出軟體工程的概念開始，人們一直把主要精力用於研究各種新的程序設計技術。
60年代末提出的結構程序設計技術，已經成為絕大多數人公認的先進的程序設計技術。以後又進一步發展出各種結構分析（SA）與結構設計（SD）技術。實踐表明，採用先進的技術既可
提高軟體開發的效率，又可提高軟體維護的效率。

5、結果應能清楚地審查

軟體產品不同於一般的物理產品，它是看不崢摸不著的邏輯產品。軟體開發人員
（或開發小組）
的工作進展情況可見性差，難以准確度量，從而使得軟體產品的開發過程比一般產品的
開發過程更難於評價和管理。為了提高軟體開發過程的可見性，更好地進行管理，應該根據
軟體開發項目的總目標及完成期限，規定開發組織的責任和產品標准，從而使得所得到的結
果能夠清楚地審查。

6、開發小組的人員應該少而精
這條基本原理的含義是，軟體開發小組的組成人員的素質應該好，而人數則不宜過多。
開發小組人員的素質和數量是影響軟體產品質量和開發效率的重要因素。
素質高的人員的開發效率比素質低的人員的開發效率可能高幾倍至幾十倍，而且素質高的人員所開發的軟體中的錯誤明顯少於素質低的人員所開發的軟體中的錯誤。此外，隨著開發小組人員數目的增加，因為交流情況討論問題而造成的通信開銷也急劇增加。當開發小組人員數為N時，可能的通信路徑有N（N?/FONT>1）/2條，可見隨著人數N的增大，通信開銷將急劇增加。因此，
組成少而精的開發小組是軟體工程的一條基本原理。

7、承認不斷改進軟體工程實踐的必要性遵循上述六條基本原理，就能夠按照當代軟體工程基本原理實現軟體的工程化生產，但是，僅有上述六條原理並不能保證軟體開發與維護的過程能趕上時代前進的步伐，能跟上技術的不斷進步。
l
因此，Boehm提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條基本原理。按照這條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗，例如，收集進度和資源耗費數據，收集出錯類型和問題報告數據等等。這些數據不僅可以用來評價新的軟體技術的效果，而且可以用來指明必須著重開發的軟體工具和應該優先研究的技術