軟體為什麼要採用工程化的開發

⑴ 什麼是軟體生產工程化

軟體工程環境是軟體工程學科各方面研究發展的物化表現，具有以下特點：
（1）軟體工程環境強調支持軟體生產的全過程。實踐表明：軟體工具僅支持生命周期中某些特定活動，工具箱將一些相互關聯的工具組織到一起，使其相互通信，從而支持了生命周期中某些成組活動，自動化程序有所提高。軟體開發環境旨在通過環境信息庫和消息通信機制實現工具的集成，從而為軟體生命周期中某些過程的自動化提供了更有效的支持。不同的過程模型導致不同類型的軟體開發環境。然而，軟體過程領域的最新研究結果表明，軟體過程概念已不僅局限在軟體開發和軟體維護，而是發展到包括系統集成和軟體產品的製作與生產。SEE旨在解決軟體過程中各個過程和活動如何按照各條路徑並行完成。管理、支持、獲取、供應等過程貫穿於整個生存周期，特別是管理活動和支持活動，從合作觀點來看，對於軟體生產具有更為重要的地位。因此，促使人們在更高的層次上考慮如何運用「整體大於各部分之和」的系統工程，提高整個軟體過程的整體計算機輔助支持程度。
(2)軟體工程環境強調大型軟體的工業化生產。軟體發展已經形成了大規模的產品市場。因此，軟體產品的生產也必將走上工業化的道路。所請的工業化是指能夠形成規模經濟的生產形式。工程化注重軟體生產過程中軟體生產者具有一定的工程訓練，遵循一定的工程准則。工業化則更加強調軟體生產過程中生產資料的作用，表現為把大量的生產者的技能和經驗轉移到生產工具之中，從而減少生產過程中的勞動比例、減少生產工具的增值比例。SEE是為工業化生產提供一整套的支持設施。
(3)軟體工程環境以集成和剪裁作為主要技術路徑，實現軟體工業化生產的目標。SEE具有多維性，表現在不僅要集成與軟體開發技術相關的工具，還要集成與支持技術、管理技術相關的工具，並將它們有機地結合在一起。
(4)標准化。軟體生產走向工業化需要建立相應的工業標准。

⑵ 軟體工程就是用工程化的方法開發軟體同學們這句話是什麼意思呢

摘要 軟體工程就是用工程化的方法開發軟體

⑶ 軟體工程的目的是什麼

中國的軟體行業規模不是很大，有些軟體企業在軟體製作上，也只是採用了一些軟體工程的思想，距離大規模的工業化大生產比較還是有一定的差距；原因有管理體制的問題，市場問題，政策問題，也有軟體工程理論不全面和不完善的問題。所以軟體工程的研究和應用，以及中國軟體行業的進一步發展，都需要一定的既有軟體工程的理論基礎和研究能力，又有一定的實踐經驗的軟體工程科學技術人員來推動。軟體工程的前途是光明的。
軟體服務外包屬於智力人才密集型現代服務業。大量著名外包企業落戶寧波。主要就業去向包括軟體外包與服務企業、信息產品與服務企業，擔任程序員、軟體測試員、項目經理等工作崗位。
軟體工程專業是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及到程序設計語言，資料庫，軟體開發工具，系統平台，標准，設計模式等方面。在現代社會中，軟體應用於多個方面。典型的軟體比如有電子郵件，嵌入式系統，人機界面，辦公套件，操作系統，編譯器，資料庫，游戲等。同時，各個行業幾乎都有計算機軟體的應用，比如工業，農業，銀行，航空，政府部門等。這些應用促進了經濟和社會的發展，使得人們的工作更加高效，同時提高了生活質量。
相關學者、組織機構都分別給出了定義：
Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。
IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法。
Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。

⑷ 什麼事軟體開發的工程化，工程化的軟體開發方法與早期的程序設計方法的不同點在哪裡

軟體開發的工程化 是指將軟體的開發企圖變成工業化流水線一樣的加工，從而保證開發的進度與質量。強調分析與設計，與早期的程序設計方法比，程序員的重要性大為下降。
所以在印度，一個高中生經過短期培訓就能成為程序員。

⑸ 談一談對軟體工程專業的認識

對軟體工程的一點看法--希望能夠拋磚引玉
在這里看到很多網友的高論，很有啟發。而且目前市面上也涌現出一批面向不同方面的軟體過程的書籍，可是在這里，我一直沒找到真正對實踐有指導意義的，可操作的應用方法，所以現在這兒拋塊磚，望各位高手指正。
我個人的理解，軟體工程就是按照工程學的管理方式，有組織、有計劃的，在一定的質量基礎、時間限度和成本范圍內，實現功能明確的軟體系統。而且，軟體工程在企業范圍內運行，一定需要企業資源的支持，要與企業的經營、決策、管理體系聯系在一起，才能夠被踏踏實實的落實下來。
軟體業作為一個服務業，要想得到發展，首先必須形成一個對軟體服務有迫切需要的市場。其次，這個市場中的消費者必須具備足夠的購買力。軟體的消費群體簡單一點，可以分為個體消費和企業消費。中國的企業群體，數量龐大，但是質量不高。上規模的企業極少，因此，中國的企業對大型軟體的消費肯定是有限的，軟體的個人消費，至少目前在中國，還是不成氣候。因此，國內目前能夠形成比較大規模的獨立市場的，肯定是小規模的軟體系統。
此外，質量的好與壞也不能絕對而論。比如說，你花500元，買雙皮鞋，只穿了一個月就壞了，肯定是劣質產品。可是如果你只花了5元買這雙鞋，還是穿了一個月就壞了，他就是個優質產品了。軟體也是一樣。
還有一個，就是軟體生命周期問題。在國外，很多中、大型企業里，軟體系統已經作為企業的命脈在運行，這些企業當然需要長期、穩定的軟體服務、開發體系作為保障，因此相對來說，對於軟體的功能需求就比較明確，而國內的中小企業在運營方面本來就把靈活多變作為生存武器，當然不可能有比較長期的經營計劃，更不可能運用軟體系統進行全面企業管理。這就導致對軟體系統需求的短期行為，因此，他們更加希望一次性購買功能有限的軟體系統，而不是長期連續的軟體服務。
如果上面的分析有代表性的話，那就是說我們現在必須對開發這類軟體形成一套非常有效的工程方法：
1。規模小。
2。成本低
3。質量要求不高。
4。售後服務有限。
5。生命期短。
我想，對於這類系統，RUP未必是一套好的方法。另外，我還想談談對軟體人員素質的看法。
從我個人的經歷來說，我覺得我們對於軟體工程師的培養方法有問題。理論上說，軟體只要設計了一個好的結構，解決了所有的技術難點，剩下的代碼高中生就能做。實際上我們的很多名牌大學的計算機專業畢業生都不能很好的Coding。尤其是現在有了VB、PB、JAVA之後，大家似乎認為計算機的體系結構都不用關心了。我曾經經手的幾個軟體項目中，很多工程師對於用C語言開發Win32多線程、事件驅動、死鎖、內存分配等問題根本束手無策。我不相信這些問題可以靠很好的文檔解決。實際上，能夠用OO的工具工作，根本不代表能夠進行OO的系統分析與設計。
話又說回來，在中國，有10年以上軟體開發背景的人，又有幾個？而且他們在過去10年裡的經驗，更多的是小項目的Coding，而不是大項目的管理與系統分析。而一個好的系統分析師，需要的是實踐、實踐、再實踐。假如說我們的商業環境中根本沒有大型的軟體項目，怎麼可能有優異的系統分析師呢?
所以，我想，目前我們的問題，是工程師的技術水平、知識面與管理意識、管理方法同樣重要，在這樣的前提下，我們是不是要探索一下真正適合我們的軟體工程方法呢？

⑹ 軟體工程是什麼未來發展怎麼樣

軟體工程學的主要內容是軟體開發技術和軟體工程管理。 軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。 專業簡介是計算機領域發展最快的學科分支之一，國家非常重視軟體行業的發展，對軟體人才的培養給予了非常優惠的政策。本專業培養掌握計算機軟體基本理論知識，熟悉軟體開發和管理技術、能夠在計算機軟體領域中從事軟體設計、開發和管理的高級人才。 主修課程該專業除了學習公共基礎課外，還將系統學習離散數學、數據結構、演算法分析、面向對象程序設計、現代操作系統、資料庫原理與實現技術、編譯原理、軟體工程、軟體項目管理、計算機安全等課程，根據學生的興趣還可以選修一些其它選修課。 畢業去向除考取國內外名牌大學研究生外，主要畢業去向是計算機軟體專業公司﹑信息咨詢公司﹑以及金融等其它獨資、合資企業。 培養目標本專業培養適應社會發展需求，德、智、體、美全面發展，具有扎實的計算機應用理論和知識基礎，掌握軟體工程領域的前沿技術和軟體開發方法，具有較強的實踐能力和創新精神，具備較強的軟體項目的系統分析、設計、開發和測試能力，能夠按照工程化的原則和方法從事軟體項目開發和管理的應用型人才。

⑺ 為什麼要進行軟體工程標准化,軟體工程標准可以分為幾個級別

CMM,可分為5級。華為公司目前是5級。

⑻ 什麼叫做軟體工程為什麼要採用軟體工程方法開發大型軟體

軟體工程包括兩方面內容：軟體開發技術和軟體項目管理。 軟體開發技術包括軟體開發方法學、軟體工具和軟體工程環境。 軟體項目管理包括軟體度量、項目估算、進度控制、人員組織、配置管理、項目計劃等。 軟體工程是六十年代末為了解決軟體危機而出現的一門學科，一般來講它包含開發技術與管理技術。而軟體過程是隨作軟體工程的開展，特別是近年來系ISO900系列與CMM方法的實踐而逐漸時髦的一個概念。它基於質量是做出來的，而非檢查出來的現代質量理論。在規范化的軟體生產中，離開了軟體過程是不可思議的。 區別在於「工程」和「過程」的不同，軟體工程是指將系統化的、規范的、可度量的方法應用於軟體的開發、運行和維護的過程，即將工程化應用於軟體過程。工程著重應用，軟體工程一定是軟體過程的一個「產出」，一個個性化的實例！工程也是由過程組成的。 硬體的一些功能一目瞭然,形象化,就在那兒,更容易理解,比如蓋房子的磚,賽車的輪子,數字電路中的介面電路,以某種方式連結在一塊就好了 軟體工程的結構開發思想,是在你對語言又很深理解的基礎上,實現一些功能模塊,使這些模塊的使用者以某種方式把它們放在一塊就安全高效的實現了所要求的功能 補充： 隨著企業信息化的深入，對軟體項目的需求日益復雜，並會產生頻繁的變更， 傳統的個人英雄主義的開發方式已經越來越不能適應發展的需要。從軟體企業的發展戰略來說，如何在技術日新月異和人員流動頻繁的情況下，建立本公司的知識庫及經驗庫，把企業中分散的隱性的財富，即個人的知識及經驗，轉變為企業的知識和經驗，以便提高工作效率，縮短產品周期，加強企業的競爭力，具有至關重要的作用。採用科學的管理思想，輔之以先進的管理工具，已經成為企業未來發展必不可少的手段。 如果軟體開發機構不能有效地控制和使用軟體資源，則在面對風險時就可能導致軟體開發活動出現各種問題。由於不能很好地管理軟體過程，會使得一些好的開發方法和技術沒有起到預期的作用。項目的成功往往是通過工作組的傑出努力來達到的，這種僅僅建立在依賴特定高素質開發人員基礎上的成功，不能保證全組織的持續穩定的軟體生產和質量的長期提高。因此，要降低軟體開發過程的風險、保證軟體產品質量，就必須加強管理，而 軟體工程方法開發大型軟體是企業過程改善和能力提升的基礎。 梵谷的左耳 的感言： 謝謝你幫了我大忙！

⑼ 什麼是軟體工程化時代

本文譯自著名IT顧問和評論員David M Williams的博客，在這里，他提出了關於軟體開發的全新理念。
Tom DeMarco是著名的Peopleware: Proctive Projects and Teams一書的合著者，然而在這個月，DeMarco向IEEE的計算機協會提出個人意見：軟體工程時代結束了。

大多數計算機軟體開發者必讀書目中都包含Peopleware一書，它於1987年首次出版，1999年再版。

盡管出版多年，Peopleware依然具有重要參考價值，因為它並不注重軟體技術本身，而是關注人的因素。

因此，DeMarco給這本書起了一個帶People的名字。也許並不像Steve Ballmer，Steve Jobs或者Linus Torvalds這些大師們演講時擁有那麼多粉絲聽眾，但DeMarco依然是全世界高質量軟體開發從業者們執著追隨的對象。

一個類似的公告出現在今年7月Computing Now雜志（IEEE計算機協會的出版物）的DeMarco視角專欄，標題為《軟體工程：一個過時的概念？》。

這在很多層面上都是很吸引眼球的，除了DeMarco的作者身份以外，標題還蘊含著出人意料的觀點：軟體工程是一個正在消失的概念。

實際上，DeMarco本人就一直引領著軟體工程的現代觀念，在Peopleware之前，他寫了Controlling Software Projects: Management, Measurement and Estimation（《控制軟體開發項目：管理，測算和評價》）一書。

這本1982年銷量冠軍的第一行文字在接下來的27年中被廣泛引用，DeMarco在其中寫道：一個人無法控制他不能測算的東西。為了解決這個問題，軟體工程師們克服重重困難，勇敢地一次次去分析和揭示一切軟體里可能的規律。

可是，隨著時間的推移，DeMarco現在顯露出對其原先所持觀點的不安。

那句引文中（書名也是）暗示了控制是一個重要的方面，他說，也許對任何軟體項目來說都是最重要的方面。

但現在不是了。他說，接著舉了Google Earth和Wikipedia這兩個典型例子，它們都是在發展中不進行多少控制的軟體。

為了說明他已改變了的推理，DeMarco引用了兩個假定的項目：最後都要花費大約100萬美元，但項目A將產生大約110萬美元的效益，項目B將產生超過5000萬美元的效益。

很明顯項目A會有更嚴格的控制，如果預算超支或軟體發布推遲或質量不達標，項目會冒很大的虧損風險。

相比之下，項目B由於投入和產出差異巨大，控制可以很松。很明顯的是，在這裡面成本、期限和質量問題依然存在，但項目最終會賺錢。如果不賺錢的話，一切都會亂掉。

由此，DeMarco沉思自語道：實際上一位主管越是注重控制，他的團隊越是可能在開發一個只能艱難盈利的項目。

接著他說，管理軟體開發的問題應該不是關於嚴格的控制和軟體工程所規定的規律，相反，開發團隊應當開發產生真正效益的項目，主管應當降低對項目控制的期望。

這是在假設DeMarco以上第一個建議更關注企業領導者或分析師，因為是由他們確定一個軟體解決方案是必要的，而不是開發者被指派去編寫這些代碼。

普通公司里的程序員並沒有選擇他們開發項目的權利，但顯而易見，主管們應該在投入資源開發之前確定一個項目數量上的效益和質量上的效益，他們得在這方面多下功夫。

一個軟體工程之父，不停地在告訴人們要放鬆，不要整天盯著開發項目的成本和時間要求，這聽起來讓人感到困惑。

為了給他的觀點進行辯護，DeMarco拿青少年來做類比。對於青少年，你怎樣在他們身上找到一個人無法控制他不能測算的東西的理論依據？例如，一位稱職的家長會如何客觀地評價他子女的道德水平、教養和同情心？

在這種情況下，你無法控制一個撫養對社會有益成員的育人項目，相反，在軟體項目中你管理的是員工，控制的是時間和成本，從根本上說，在這過程中你得盡可能在擁有極少反饋信息的情況下掌控大局。

用同樣的方法，一支軟體開發團隊應當在開發過程中按照相關價值大小、文檔和測試結果不斷向項目中增加程序塊，在項目主管宣布項目完成的任何可能時候都能立刻將產品打包並發布。

DeMarco說，去設計規劃一套軟體依然有其意義，但那並不是軟體工程這個術語所要真正表達的意思，設計策劃軟體是一整套規則，過程，檢視，度量，規劃，追蹤以及許多其他元素的總和。

幾十年來，開發團隊們都在成本預算和時間限制上痛苦地掙扎著，但這不該是他們追求的至上目標。

更重要的目標是要轉變。DeMarco現在說，去切實改變這個世界或一家公司或它運作的模式才是更重要的。

幾乎是為了向自己推行了幾十年將工程化原則應用於軟體開發的想法表示懺悔，DeMarco說這場轉變是我們一向應該關注實施的。

在我個人看來，DeMarco說設計規劃一套軟體的做法與詞語軟體開發是不同的，這毫無疑問，的確，有很多人開始懷疑開發軟體到底是不是一種包含度
量控制和管理控制的工程化實務，而事實卻是，軟體本身並不像物理學那樣有著堅實的科學理論基礎，而是充滿了抽象的概念，虛幻的構想甚至是一次次的試驗研
究。

我職業生涯的美好回憶中就有自己提出的解決方案幫助公司進行重大轉變的一系列例子，其實謙虛地說，我的這些方案在技術層面上一點也不特別，但它們對公司起到的效果卻是立竿見影。這些直到現在我還能如數家珍般列出。

之前我說過這樣一個例子，在這個例子中我給那個老闆設計了使公司的毛利率報表自動化生成的方案，這確確實實改變了整個公司的文化。現在，這是一個有著巨大甚至是無限價值的軟體項目。

具有諷刺意味的是，DeMarco的新式哲學有可能很早以前就存在了。2003年我讀了Ed
Yourden所著的第二版《Deathmarch》（Deathmarch預示失敗的開發項目），驚異於其中一部分內容，在那裡面，Yourden試圖
界定適用於類似Microsoft Word這樣巨型開發項目的度量標准。

Yourden詳細敘述了他打電話給微軟，詢問軟體有多少行代碼的事，結果微軟技術服務人員在電話另一頭說不知道，他又問這個項目有多少開發人員，
答復依然是不知道。Yourden繼續問著這些叫人無法回答的問題，最後那個技術服務人員火了：你難道不知道嗎？我們賣出了數千萬套軟體，誰管開發成本是
多少？

當然，隨著今年早些時候的裁員，微軟也許現在會計算成本，但Yourden之類的作者們在最近十年早些時候肯定有證據表明項目的成本和可度量性會隨著回報率的升高而重要性降低。

我認為沒有人去超越這個觀點的原因是眾所周知的將軟體與已確定的工程化原則相關聯的必要性，盡管二者之間存在著明顯不同，比方說建造一幢建築與開發一款文字處理軟體。

確實，有人經常說相比一門科學來說，開發軟體可能更是一門藝術，我越來越傾向於這種說法。我把它看成是一種工藝，一項技巧，一個創造過程。當編程理
論能被教授時，它更像是一套音樂或繪畫的理論，除非你有天生的創造表現力，否則你不可能立志要成為有史以來最偉大的程序員或音樂家或藝術家。

與Agile Development嚴格的瀑布方法論和在它之前的應用程序快速開發（RAD）漸行漸遠的當代趨勢同樣支持了DeMarco的說法：實際上，他發現的事實已在我們身邊存在了很多年。
現在的問題是，沒人敢站出來大聲說：我們不再需要軟體工程這個概念！