歡迎來到培訓(xùn)無憂網(wǎng)!

全國切換

咨詢熱線 400-001-5729

位置:培訓(xùn)無憂網(wǎng) > 新聞資訊 > 電腦/IT > 程序開發(fā) >  軟件研發(fā)中的N條原則

軟件研發(fā)中的N條原則

來源:m.universityresearchassociates.com 發(fā)布人:彭二胖

2022-01-09 10:38:48|已瀏覽:220次


       原則 1 質(zhì)量第一 

       QUALITY IS #1 

       無論如何定義質(zhì)量,客戶都不會容忍低質(zhì)量的產(chǎn)品。質(zhì)量必須被量化,并建立可落地實(shí)施的機(jī)制,以促進(jìn)和激勵質(zhì)量目標(biāo)的達(dá)成。即使質(zhì)量沒達(dá)到要求,也要按時交付產(chǎn)品,這似乎是政治正確的行為, 但這是短視的。從中長期來看,這樣做是自殺。質(zhì)量必須被放在首位,沒有可商量的余地。Edward Yourdon 建議,當(dāng)你被要求加快測試、 忽視剩余的少量 bug、在設(shè)計(jì)或需求達(dá)成一致前就開始編碼時,要直接說“不”。

       原則 2 質(zhì)量在每個人眼中都不同

       QUALITY IS IN THE EYES OF THE BEHOLDER 

       軟件質(zhì)量沒有唯一的定義。對開發(fā)者來說,質(zhì)量可能是優(yōu)雅的設(shè) 計(jì)或優(yōu)雅的代碼。對在緊張環(huán)境中工作的客戶來說,質(zhì)量可能是響應(yīng) 時間或高吞吐量。對成本敏感的項(xiàng)目來說,質(zhì)量可能是低開發(fā)成本。對一些客戶來說,質(zhì)量可能是滿足他們所有已知和未知的需求。這里 的難題是,以上要求可能無法完全兼顧。當(dāng)優(yōu)化某人關(guān)注的質(zhì)量時, 可能會影響其他人關(guān)注的質(zhì)量(這就是溫伯格的“政治困境”原則)。項(xiàng)目必須確定各因素的優(yōu)先級,并清晰地傳達(dá)給所有相關(guān)方。

       原則 3 高質(zhì)量軟件是可以實(shí)現(xiàn)的 

       HIGH-QUALITY SOFTWARE IS POSSIBLE 

       盡管我們的行業(yè)中有一些表現(xiàn)不佳、包含 bug,或者根本無法滿 足客戶需求的軟件系統(tǒng)的例子,但仍然有一些成功的例子。大型軟件 系統(tǒng)可以以非常高的質(zhì)量構(gòu)建,但價格昂貴:每行代碼高達(dá) 1000 美 元。例如,IBM 為美國宇航局的航天飛機(jī)開發(fā)的機(jī)載飛行軟件,總共 約 300 萬行代碼,源于嚴(yán)謹(jǐn)?shù)能浖_發(fā)過程,產(chǎn)品發(fā)布后每萬行代碼中發(fā)現(xiàn)的錯誤少于一個。作為軟件開發(fā)人員,應(yīng)該學(xué)習(xí)和了解已被驗(yàn)證、可以極大提高軟件質(zhì)量的方法。這些方法包括:讓客戶參與(見原則 8)、原型設(shè)計(jì) (在全面開發(fā)之前驗(yàn)證需求;見原則 11~13)、保持設(shè)計(jì)簡單(見原 則 67)、審查代碼(見原則 98)和雇用最優(yōu)秀的人(見原則 130 和 131)。作為客戶,在追求卓越的同時,要意識到隨之而來的高額成本。

       原則 4 不要試圖通過改進(jìn)軟件實(shí)現(xiàn)高質(zhì)量

       DON’T TRY TO RETROFIT QUALITY 

       質(zhì)量無法通過軟件的改進(jìn)來獲得。這適用于質(zhì)量的任何定義:可 維護(hù)性、可靠性、適應(yīng)性、可測試性、安全性等。即使我們在開發(fā)過 程中十分努力,使軟件具備高質(zhì)量也是十分不易的。如果我們不努力, 又怎么可能期望獲得高質(zhì)量呢?這就是絕不能將“一次性原型”轉(zhuǎn)換 成產(chǎn)品的主要原因(見原則 11)。

       原則 5 盡早把產(chǎn)品交給客戶

       GIVE PRODUCTS TO CUSTOMERS EARLY 

       在需求階段,無論你多么努力地試圖去了解客戶的需求,都不如 給他們一個產(chǎn)品,讓他們使用它,這是確定他們真實(shí)需求的最有效方 法。如果遵循傳統(tǒng)的瀑布式開發(fā)模型,那么在 99% 的開發(fā)資源已經(jīng) 耗盡之后,才會第一次向客戶交付產(chǎn)品。如此一來,大部分的客戶需 求反饋將發(fā)生在資源耗盡之后。和以上方法相反,可在開發(fā)過程的早期構(gòu)建一個快速而粗糙的原 型。將這個原型交付給客戶,收集反饋,然后編寫需求規(guī)格說明并進(jìn) 行正規(guī)的開發(fā)。使用這種方法,當(dāng)客戶體驗(yàn)到產(chǎn)品的第一個版本時, 只消耗了 5%~20% 的開發(fā)資源。如果原型包含合適的功能,就可以 更好地理解和把握最有風(fēng)險的客戶需求,最終產(chǎn)品也就更有可能讓客 戶滿意。這有助于確保將剩余的資源用于開發(fā)正確的系統(tǒng)。

       原則 6 促使開發(fā)者與客戶的目標(biāo)一致 

       ALIGN INCENTIVES FOR DEVELOPER AND CUSTOMER 

       項(xiàng)目經(jīng)常會因?yàn)榭蛻艉烷_發(fā)人員的目標(biāo)不同(或不兼容)而失敗。一個簡單的案例是,客戶希望在特定日期前獲得特性 1、2、3,而開 發(fā)人員希望最大化營收或利潤。為了最大化營收,開發(fā)人員可能會嘗 試完整地開發(fā)這三個特性,即使會導(dǎo)致項(xiàng)目延期。與此同時,客戶可 能寧愿放棄其中一個特性的一部分功能,只要能按時交付其他特性。為使雙方的目標(biāo)達(dá)成一致,有如下方法:(1) 按優(yōu)先級對需求排序(見原則 50),以便開發(fā)人員了解它 們的相對重要性。(2) 根據(jù)需求的優(yōu)先級獎勵開發(fā)人員(例如,所有高優(yōu)先級的 需求必須完成;每完成一個中優(yōu)先級的需求,開發(fā)人員可 獲得一些額外的小獎勵;每完成一個低優(yōu)先級的需求,可 獲得的獎勵非常。。(3) 對逾期交付實(shí)行嚴(yán)厲的處罰。

       原則 7 要快速地開發(fā)一次性原型 

       BUILD THROWAWAY PROTOTYPES QUICKLY 

       如果你已經(jīng)決定開發(fā)一次性原型,那么就要用最快的方式。不用擔(dān)心質(zhì)量?墒褂谩耙豁摷垺钡男枨笠(guī)格說明。不用擔(dān)心設(shè)計(jì)或編碼中的文檔?梢允褂萌魏喂ぞ?梢允褂萌魏尉幊陶Z言,只要能夠方 便程序的快速開發(fā)。不用擔(dān)心編程語言的可維護(hù)性。

       原則 8 看到越多,需要越多 

       THE MORE SEEN, THE MORE NEEDED 

       在軟件行業(yè),一次次見證了:提供給用戶的功能(或性能)越多, 用戶想要的功能(或性能)就越多。當(dāng)然,這與原則 7(盡早把產(chǎn)品 交給客戶)、原則 14(漸進(jìn)地?cái)U(kuò)展系統(tǒng))、原則 185(軟件會持續(xù)變化) 以及原則 201(系統(tǒng)的存在促進(jìn)了演變)互相支持。但更重要的是, 你必須為不可避免的情況做好準(zhǔn)備。在管理和工程處理流程的每個方 面都應(yīng)該做好準(zhǔn)備,一旦用戶看到產(chǎn)品,他們就會想要更多的東西。這意味著,所產(chǎn)生的每個文檔都應(yīng)該以有利于更改的方式進(jìn)行存 儲和組織。這意味著,配置管理流程(見原則 174)必須在距離交付很長時間之前就就位。這也意味著,在軟件部署后不久,你就應(yīng)該準(zhǔn)備好,以應(yīng)對用戶口頭或書面請求的沖擊。這還意味著,你選擇的設(shè)計(jì)方案應(yīng)使容量、輸入速率和功能都很容易變更。

       原則 9 只要可能,購買而非開發(fā)

       IF POSSIBLE, BUY INSTEAD OF BUILD 

       要降低不斷上漲的軟件開發(fā)成本和風(fēng)險,最有效的方法就是,購買現(xiàn)成的軟件,而不是自己從頭開發(fā)。確實(shí),現(xiàn)成的軟件也許只能解 決 75% 的問題。但考慮一下從頭開發(fā)的選擇吧:支付至少 10 倍于購買軟件的費(fèi)用,且要冒著超出預(yù)算 100% 且延期的風(fēng)險(如果最后能 夠完成。⑶易罱K發(fā)現(xiàn),它只能滿足 75% 的預(yù)期。對一個客戶來說,新的軟件開發(fā)項(xiàng)目似乎最初總是令人興奮的。開發(fā)團(tuán)隊(duì)也是“樂觀的”,對“最終”解決方案充滿了希望。但幾乎 很少有軟件開發(fā)項(xiàng)目能夠順利運(yùn)行。不斷增加的成本通常會導(dǎo)致需求 被縮減,最終研發(fā)出的軟件可以滿足的需求也許跟現(xiàn)成的軟件差不多。作為一個開發(fā)者,應(yīng)該復(fù)用盡可能多的軟件。復(fù)用是“購買而非開發(fā)” 原則在較小范圍內(nèi)的體現(xiàn)。可參考原則 84。

       原則 10 技術(shù)優(yōu)先于工具 

       TECHNIQUE BEFORE TOOLS 

       一個沒規(guī)矩的木匠使用了強(qiáng)大的工具,會變成一個危險的沒規(guī)矩 的木匠。一個沒規(guī)矩的軟件工程師使用了工具,會變成一個危險的沒 規(guī)矩的軟件工程師。在使用工具前,你應(yīng)該先要“有規(guī)矩”(即理解 并遵循適當(dāng)?shù)能浖_發(fā)方法)。當(dāng)然,你也要了解如何使用工具,但 這和“有規(guī)矩”相比是第二位的。我強(qiáng)烈建議,在投資于工具以對某項(xiàng)技術(shù)“自動化”之前,先 手工驗(yàn)證這項(xiàng)技術(shù),并說服自己和管理層:這項(xiàng)技術(shù)是可行的。在 大多數(shù)情況下,如果一項(xiàng)技術(shù)在手工操作時不靈,那么在自動操作 時也不靈。

       原則 11 跟風(fēng)要小心 

       FOLLOW THE LEMMINGS WITH CARE 

       即使有五千萬人說傻話,那仍然是傻話。 

       安那托爾·佛朗士(Anatole France) 

       大家都做的事情,對你來說也不一定是正確的。也許它是正確的, 但你也應(yīng)該評估它對你所處環(huán)境的適用性。這樣的例子包括:面向?qū)?象,軟件度量(見原則 142、143、149、150 和 151),軟件復(fù)用(見 原則 84),過程成熟度(見原則 163),計(jì)算機(jī)輔助軟件工程(CASE, 見原則 22 至 25),原型設(shè)計(jì)(見原則 11、12、13、42)。在所有案 例中,以上這些方法都提供了非常積極的幫助,體現(xiàn)在提高質(zhì)量、降 低成本、提高用戶滿意度等方面。然而,這些好處只在它們能發(fā)揮作 用的組織中才會顯現(xiàn)出來。盡管回報(bào)顯著,但是它們的作用常常被過 度宣傳,其實(shí)它們并不是那么必然或通用。當(dāng)你學(xué)習(xí)“新”技術(shù)時,不要輕易接受與之相關(guān)的不可避免的 炒作(見原則 129)。要仔細(xì)閱讀,理性考慮它的收益和風(fēng)險。在大 規(guī)模應(yīng)用之前要進(jìn)行試驗(yàn)。但同時也絕對不要忽略“新”技術(shù)(見 原則 31)。

       Davis, A., "Software Lemmingineering," IEEE Software, 10, 6 (September 1993), pp. 79-81, 84.

       類似的原則還有很多,以上內(nèi)容摘自《201 Principles of Software Development》中文版,書名是《軟件開發(fā)的201個原則》。

       給中國軟件工程師的寄語

       (節(jié)選)

       致我的兄弟姐妹們:

       和你們一樣,我的職業(yè)生涯始于軟件工程師,那是1975年,將近半個世紀(jì)之前。我認(rèn)為我們在時間和國家方面的差異相當(dāng)微不足道。所以,我像和我的朋友、我的同齡人一樣與你交談。

       26 年后的今天,當(dāng)我審視201 Principles of Software Development中的這201 條原則時,我很高興地宣告,幾乎所有的原則都經(jīng)受住了時間的考驗(yàn),就像物理學(xué)中的基本原理一樣。

       當(dāng)你做軟件架構(gòu)設(shè)計(jì)或“拋出代碼”時,不要忽視真正重要的事情。那是什么呢?是你的正直,這是你對自己的看法。如果有人要求你做一些你知道是錯誤的事情,你有義務(wù)阻止它。

       軟件工程是一個美妙的職業(yè),它使你能夠進(jìn)入數(shù)百個以軟件為支柱的專業(yè)領(lǐng)域。

        “生生不息,繁榮昌盛!焙煤孟硎!

       201 Principles of Software Development 作者   Alan M.Davis

       2021年9月

       全書共9 章,第1章為引言,后面8章將201個軟件工程的原則劃分為8個大的類別:一般原則、需求工程原則、設(shè)計(jì)原則、編碼原則、測試原則、管理原則、產(chǎn)品保證原則和演變原則。甚至你可以在空白處寫上簡單的,聰明的你認(rèn)為的“原則”。

       本文由培訓(xùn)無憂網(wǎng)長沙牛耳教育課程顧問老師整理發(fā)布,希望能夠?qū)ο朐陂L沙參加影視動漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信:15033336050

      注:尊重原創(chuàng)文章,轉(zhuǎn)載請注明出處和鏈接 http://m.universityresearchassociates.com/news-id-13962.html 違者必究!部分文章來源于網(wǎng)絡(luò)由培訓(xùn)無憂網(wǎng)編輯部人員整理發(fā)布,內(nèi)容真實(shí)性請自行核實(shí)或聯(lián)系我們,了解更多相關(guān)資訊請關(guān)注程序開發(fā)頻道查看更多,了解相關(guān)專業(yè)課程信息您可在線咨詢也可免費(fèi)申請?jiān)囌n。關(guān)注官方微信了解更多:150 3333 6050

留下你的信息,課程顧問老師會一對一幫助你規(guī)劃更適合你的專業(yè)課程!
  • 姓名:

  • 手機(jī):

  • 地區(qū):

  • 想學(xué)什么:

  • 培訓(xùn)無憂網(wǎng)
免 費(fèi) 申 請 試 聽
提交申請,《培訓(xùn)無憂網(wǎng)》課程顧問老師會一對一幫助你規(guī)劃更適合你的專業(yè)課程!