瀑布模型式是最典型的預(yù)見(jiàn)性的方法,嚴(yán)格遵循預(yù)先計(jì)劃的需求、分析、設(shè)計(jì)、編碼、測(cè)試的步驟順序進(jìn)行。步驟成果作為衡量進(jìn)度的方法,例如需求規(guī)格,設(shè)計(jì)文檔,測(cè)試計(jì)劃和代碼審閱等等。
瀑布式的主要的問(wèn)題是它的嚴(yán)格分級(jí)導(dǎo)致的自由度降低,項(xiàng)目早期即作出承諾導(dǎo)致對(duì)后期需求的變化難以調(diào)整,代價(jià)高昂。瀑布式方法在需求不明并且在項(xiàng)目進(jìn)行過(guò)程中可能變化的情況下基本是不可行的。
有論文統(tǒng)計(jì)他是造成70%軟件開(kāi)發(fā)失敗的原因。
大體分為這幾個(gè)階段:需求分析、設(shè)計(jì)、編碼、測(cè)試、維護(hù)。
需求階段通常定義系統(tǒng)的需求,明白系統(tǒng)的目標(biāo)。
設(shè)計(jì)階段通常確定系統(tǒng)使用什么數(shù)據(jù)庫(kù),系統(tǒng)模塊的劃分,各個(gè)模塊的功能。
編碼階段用編程語(yǔ)言對(duì)設(shè)計(jì)階段的實(shí)現(xiàn)。
測(cè)試階段分黑盒測(cè)試,白盒測(cè)試。測(cè)試系統(tǒng)的功能是否實(shí)現(xiàn),是否準(zhǔn)確。
維護(hù)階段是根據(jù)用戶新的需要重新修改系統(tǒng),使系統(tǒng)更加穩(wěn)定,更符合用戶的要求。
需求階段的工作是否到位是整個(gè)系統(tǒng)開(kāi)發(fā)的關(guān)鍵,在需求階段有很多方式可以幫助自己完成工作,例如與客戶暢所欲言,跟隨客戶參與業(yè)務(wù)過(guò)程等等。不管任何一種方法,任何一種方式,在需求階段首先確定系統(tǒng)邊界,確定組織邊界,然后摸清企業(yè)為消費(fèi)者創(chuàng)造的價(jià)值,看清企業(yè)的價(jià)值鏈,摸清價(jià)值鏈上的實(shí)體。最后要平衡價(jià)值鏈上各個(gè)實(shí)體之間的利益,爭(zhēng)取系統(tǒng)做到大家都滿意這個(gè)理想的狀態(tài)。
敏捷式vs.瀑布式:都需要經(jīng)常,細(xì)致的交互
團(tuán)隊(duì)和利益相關(guān)者之間需要經(jīng)常并且細(xì)致的交互。建立互信,人們之間維持開(kāi)放并且忠誠(chéng)的關(guān)系非常重要。這樣的氛圍使得溝通更為有效,幫助大家構(gòu)建對(duì)于正確需求的一致理解。
對(duì)于我來(lái)說(shuō),價(jià)值比費(fèi)用更重要。如果你知道哪一個(gè)需求最為重要,那么開(kāi)發(fā)它所需的成本反而不那么要緊。對(duì)價(jià)值的理解也會(huì)激勵(lì)大家,幫助大家關(guān)注于持續(xù)選擇并開(kāi)發(fā)正確的需求。
使用敏捷項(xiàng)目框架,比如scrum、XP、SAFe或者LeSS并不會(huì)自動(dòng)保證項(xiàng)目的成功。需要以適合項(xiàng)目需求的方式使用這些框架。選擇合適的方式,在工作方法上達(dá)成一致。不用太擔(dān)心項(xiàng)目一開(kāi)始時(shí)達(dá)不到完美,反思之類的活動(dòng)會(huì)幫助大家持續(xù)學(xué)習(xí)并在過(guò)程中不斷改進(jìn)。 2100433B
濟(jì)南高新技術(shù)開(kāi)發(fā)區(qū)的介紹
濟(jì)南高新技術(shù)開(kāi)發(fā)區(qū)成立于1991年,是國(guó)務(wù)院批準(zhǔn)的首批國(guó)家級(jí)高新區(qū)之一。 是濟(jì)南市對(duì)外開(kāi)放的窗口和重要的高新技術(shù)產(chǎn)業(yè)基地。
技術(shù)服務(wù)合同和技術(shù)開(kāi)發(fā)合同的區(qū)別
技術(shù)服務(wù)合同是指當(dāng)事人一方以技術(shù)知識(shí)為另一方解決特定技術(shù)問(wèn)題所訂立的合同。技術(shù)服務(wù)合同中包括技術(shù)培訓(xùn)合同和技術(shù)中介合同。技術(shù)培訓(xùn)合同是指當(dāng)事人一方委托另一方對(duì)指定的專業(yè)技術(shù)人員進(jìn)行特定項(xiàng)目的技術(shù)指導(dǎo)和...
無(wú)所不在的嵌入式系統(tǒng) 多年前,比爾.蓋茨曾經(jīng)預(yù)言,隨著后PC時(shí)代的到來(lái),PC將無(wú)處不在。今天,伴隨著二十一世紀(jì)的曙光,嵌入式系統(tǒng)和3G移動(dòng)互聯(lián)網(wǎng)的迅猛發(fā)展正驗(yàn)證了比爾.蓋茨的預(yù)言,人類正迎來(lái)一個(gè)充滿希...
格式:pdf
大?。?span id="hdvhz2p" class="single-tag-height">130KB
頁(yè)數(shù): 3頁(yè)
評(píng)分: 4.8
在介紹瀑布溝水電站繼電保護(hù)工程的基礎(chǔ)上,結(jié)合瀑布溝水電站繼電保護(hù)工程建設(shè)管理過(guò)程中遇到的問(wèn)題及解決辦法,對(duì)水電站繼電保護(hù)工程設(shè)計(jì)、設(shè)備選型、安裝調(diào)試及保護(hù)裝置與機(jī)電設(shè)備的聯(lián)控技術(shù)等進(jìn)行了總結(jié)和探討。
瀑布開(kāi)發(fā)也有一些缺點(diǎn),但是,在你初履新職,剛剛接手管理一個(gè)新的團(tuán)隊(duì),同時(shí)獲得了一種支持瀑布開(kāi)發(fā)模式的解決方案的情況下,這種開(kāi)發(fā)模式可以令你很快進(jìn)入角色把工作開(kāi)展起來(lái),從而為將來(lái)采用更高級(jí)的開(kāi)發(fā)方式做好了準(zhǔn)備。
瀑布開(kāi)發(fā)過(guò)程在政府項(xiàng)目中特別受到歡迎,在這樣的軟件開(kāi)發(fā)項(xiàng)目中,其規(guī)劃階段超出了大多數(shù)企業(yè)部署階段的時(shí)間和力度。采用這種方式的其他用戶包括那些理解比較全面和深入的軟件項(xiàng)目,相關(guān)的解決方案對(duì)團(tuán)隊(duì)而言非常熟悉,或者只需要小小的改動(dòng)。
瀑布開(kāi)發(fā)方式的缺點(diǎn)也是明顯的。如果期間的每一階段沒(méi)有得到堅(jiān)決貫徹和實(shí)現(xiàn),那么隱藏的問(wèn)題最終會(huì)影響項(xiàng)目的成功。雖然瀑布管理方式對(duì)項(xiàng)目經(jīng)理而言非常方便,但是對(duì)開(kāi)發(fā)人員而言就可能顯得太嚴(yán)酷了。因?yàn)闇y(cè)試過(guò)程在開(kāi)發(fā)階段之后實(shí)施,子系統(tǒng)測(cè)試所暴露的問(wèn)題可能需要立即修改代碼,這樣就顯著增加了計(jì)劃架構(gòu)的成本。
調(diào)試過(guò)程可能非常復(fù)雜,原因在于,開(kāi)發(fā)人員在同一階段通常還可以從事其他項(xiàng)目的開(kāi)發(fā)工作,而所需要的軟件修改可能會(huì)降低開(kāi)發(fā)人員的生產(chǎn)率和工作質(zhì)量。有時(shí)工作區(qū)還必須集中到一個(gè)地方來(lái),從而威脅到解決方案的完整性。
另一可能的危險(xiǎn)是你只有到解決方案啟動(dòng)的時(shí)候才能知道當(dāng)初所預(yù)計(jì)的是否成功,所以余下用來(lái)改正問(wèn)題的時(shí)間和空間都非常有限。而設(shè)計(jì)工作上的疏漏和缺陷可能會(huì)嚴(yán)重地影響解決方案的啟動(dòng)日期。
這種模式的另一問(wèn)題在于,除了到階段終止之時(shí),其他時(shí)候幾乎沒(méi)有獲取反饋的時(shí)間,還有,一旦開(kāi)發(fā)工作開(kāi)始啟動(dòng)那么修改的空間也就沒(méi)有了。最后,假如系統(tǒng)測(cè)試表面功能或者性能沒(méi)有達(dá)到要求也許到這個(gè)時(shí)候已經(jīng)沒(méi)有糾正問(wèn)題的可能了。
在部署瀑布開(kāi)發(fā)模式之前你必須仔細(xì)評(píng)估自己所處的環(huán)境和條件。如果客戶希望在開(kāi)發(fā)工作開(kāi)始之后加入進(jìn)來(lái)或者你要處理很多未知的問(wèn)題,那么你或許最好采用一種更具重復(fù)性的開(kāi)發(fā)過(guò)程。2100433B
瀑布開(kāi)發(fā)也被稱作系統(tǒng)開(kāi)發(fā)生命期模式,簡(jiǎn)稱SDLC(Systems Development Lifecycle Model),這是一種軟件開(kāi)發(fā)途徑,它把項(xiàng)目分解為有限的階段。每一個(gè)階段都有序執(zhí)行,并且依賴于先前已完成的階段。在采用瀑布開(kāi)發(fā)方法的情況下,開(kāi)發(fā)工作的各個(gè)部分必須分別評(píng)估,而且通常由不同的開(kāi)發(fā)隊(duì)伍來(lái)實(shí)施。具體開(kāi)發(fā)階段的劃分存在一定的爭(zhēng)議,但各個(gè)階段基本上取決于任務(wù)相對(duì)繁重的預(yù)先規(guī)劃。以下就是瀑布開(kāi)發(fā)過(guò)程的常見(jiàn)階段劃分:
問(wèn)題評(píng)估—也就是概念形成階段。明確現(xiàn)有解決方案所存在的問(wèn)題同時(shí)收集相關(guān)信息。
計(jì)劃解決方案—提出解決方案的詳細(xì)說(shuō)明,包括軟件的優(yōu)點(diǎn)和缺點(diǎn)以及試圖解決的問(wèn)題。確定開(kāi)發(fā)時(shí)序,工作結(jié)構(gòu)分解以及其他支持文檔。最重要的是明確和分析軟件需求。
設(shè)計(jì)系統(tǒng)架構(gòu)—提案獲得接受之后即可創(chuàng)建解決方案模式,包括工作流和數(shù)據(jù)流圖、模塊和功能層次已經(jīng)其他由解決方案所需要的說(shuō)明。在這一階段通??偸前殡S一個(gè)有力度的檢查過(guò)程。
開(kāi)發(fā)代碼—用以上階段創(chuàng)建的藍(lán)圖編寫(xiě)、調(diào)試和單元測(cè)試軟件代碼。接著,集成系統(tǒng)的代碼和測(cè)試部分。最后測(cè)試整個(gè)系統(tǒng)。該階段要到測(cè)試完全通過(guò)才能結(jié)束。
部署和使用系統(tǒng)—部署最終功能,同時(shí)向用戶提供所需的培訓(xùn)和文檔。
維護(hù)解決方案—在必要的時(shí)候指出和升級(jí)軟件并且修補(bǔ)軟件錯(cuò)誤。
有時(shí)測(cè)試會(huì)成為單獨(dú)的一個(gè)階段,其中包括軟件調(diào)試而不是在開(kāi)發(fā)階段進(jìn)行代碼調(diào)試。此外,獲取軟件需求也可能成為獨(dú)立的階段。無(wú)論采取怎么樣的開(kāi)發(fā)路線,以上過(guò)程都是一次實(shí)施的,同時(shí)還要整合到整個(gè)解決方案中來(lái)。