軟件開發(fā)流程的短板(開發(fā)軟件的重點和難點)
本篇文章給大家談談軟件開發(fā)流程的短板,以及開發(fā)軟件的重點和難點對應的知識點,希望對各位有所幫助,不要忘了收藏本站喔。
軟件開發(fā)過程中會有哪些風險?
1、未經(jīng)權威部門確認的功能標準、開發(fā)規(guī)范以及質量技術標準,均可能導致軟件無法達到預期標準,從而引起質量風險。
2、在理解項目標準及范圍等問題上,企業(yè)管理層、項目組以及技術性人員的接不一致,導致計劃與資金安排有所改變,因而極易引發(fā)風險。
3、潛在的維護、驗證、接口、實現(xiàn)以及設計等環(huán)節(jié)出現(xiàn)的問題,存在技術空白及未知領域,為軟件開發(fā)工作帶來較大的風險。
4、來自于外包項目組、客戶、國家政策以及市場等方面的變化及壓力,這類風險具有明顯的不可控特點,一旦遭遇,應謹慎對待,及時制定解決策略。
風險防范與控制措施
1、出臺合理的軟件開發(fā)模式與相關規(guī)程,確保開發(fā)工作合理、有序進行,并符合國家出臺的相關標準及要求。
2、對于項目組全體成員的開發(fā)行為進行嚴格規(guī)范,加強小組成員之間的交流與互動,以免由于溝通與交流不當,引發(fā)軟件開發(fā)風險。
3、定期開展業(yè)務和技術交流大會,引導技術人員摒除過于落后、陳舊的工作思想,通過引進先進的技術、設備與驗證方式,明確技術人員的預期發(fā)展目標,令其不斷的改進自我、完善自我,提升技術及設備的質量及效果。
4、對開發(fā)所用的方法及技術進行客觀、合理的評價,避免由于無法把握技術而引發(fā)風險。
5、建立完善的風險應對程序與管理計劃,如此一來,才能確保在發(fā)生風險的時候,能夠快速、合理、技術的作出反映,并通過制定適宜的策略,對風險進行專業(yè)性處理。
軟件開發(fā)過程中會遇到哪些問題
手機app開發(fā)過程中所遇到的9大注意事項:
一、沒有規(guī)劃的開始
很多App項目在開發(fā)之前,都沒有規(guī)劃好,這就比如,寫作文沒有大綱,做房子沒有建筑圖,到最后做出來的app和客戶需要的效果大相庭徑。所以在開始 之前就要做好一份書面規(guī)劃,包括app開發(fā)的目的、需要實現(xiàn)的功能,以及預期每個階段需要完善哪些功能等等,然后根據(jù)規(guī)劃,設計出用戶需求的流程圖。
二、盲目的創(chuàng)建跨平臺app
跨平臺app在一定程度上,能從用戶的實際使用中獲得反饋,有利于改善在其他平臺發(fā)布的版本。然而跨平臺app一般情況下沒有全面的功能,對于多個獨 立的平臺來說,則需要更多的編碼。所以在設計app之前,要展開用戶調查,包括不同的年齡、生活方式、教育環(huán)境等等,再判斷使用安卓和ios的比例,確定 好開發(fā)平臺。
三、不重視開發(fā)人員建議
通常產(chǎn)品設計師在得到一些靈感的時候,就會在產(chǎn)品中加入一些其他元素,然而站在開發(fā)者的角度去考慮問題,有時候會覺得加進來的這個東西比較多余,而且 和移動設備的操作體驗也不匹配,或者這些元素會產(chǎn)生一些不必要的數(shù)據(jù)。藍海匯app開發(fā)技術人員介紹:這時如果產(chǎn)品設計師一意孤行的話,很可能會導致產(chǎn)品 變殘,或者因此而讓用戶在使用過程中產(chǎn)生了多余的數(shù)據(jù),而放棄此應用。所以比較好的辦法就是,在技術可行,并不影響用戶體驗的情況下,可以實施這種想法。
四、將app設計成網(wǎng)站模式
用戶愿意用你的App,主要原因有兩種,一是有用;二是精簡、快速,兩者缺一不可。如果將app設置成網(wǎng)站形式,不僅打開緩慢,容易閃退,花了大量時間還找不到想要的重點在哪里。另外,如果用戶想要打開網(wǎng)頁版,他們還會用手機嗎,只有在特別需要的情況下才會使用吧。
五、手機屏幕尺寸不兼容
其實這種情況很常見,同一個app在不同手機上排版不同、格式不同,比如說在某些小屏幕的手機上,看到的內容就比較凌亂,給人非常不專業(yè)的感覺。所以開發(fā)者需要注意手機屏幕尺寸的兼容性。
六、觸發(fā)后臺程序
使用app時,移動設備上也會運行其他后臺服務,過多的系統(tǒng)需求會導致設備崩潰,這是常見的大忌。
七、忽視操作系統(tǒng)集成
Android和iOS風格、布局和導航都大不相同,這需要匹配創(chuàng)建項目的每一個操作系統(tǒng)來滿足用戶。同時,對蘋果app而言,它需要專為操作系統(tǒng)而設計的應用。
八、節(jié)省測試
一個人的思維引導他做的事情,是一個自然過程,所以開發(fā)者或設計程序人員對自己開發(fā)的或者設計的產(chǎn)品是沒法公正判斷的,因為他們開發(fā)出來的產(chǎn)品正是他 們了解到的樣子。那么就不能由開發(fā)者或設計程序人員自己來測試。作為測試人群,他們應該是目標用戶,或者是沒有參與開發(fā)的人員,但最好不要是家人,因為比 較不客觀。
九、迷失最終目的
在規(guī)劃好app開發(fā)項目流程以后,不要輕易改變,如果在開發(fā)過程中,不斷加入新的需求,就會逐漸遠離最初的開發(fā)目的,這是不能讓客戶滿意的。那么在有新的 需求或者想法時,要及時在產(chǎn)品開發(fā)前,與客戶開會討論并確認,盡量確保開發(fā)出來的產(chǎn)品與最初規(guī)劃的樣子相符合。
軟件開發(fā)過程中的常見問題有哪些?
1.前言應用軟件系統(tǒng)是事件驅動的軟件系統(tǒng),系統(tǒng)通過接口接受事件后,交由系統(tǒng)業(yè)務層處理,業(yè)務層處理完事件后將需要的信息存入數(shù)據(jù)庫,整個應用軟件系統(tǒng)分為三個子系統(tǒng):接口子系統(tǒng),業(yè)務子系統(tǒng),數(shù)據(jù)庫子系統(tǒng),業(yè)務子系統(tǒng)進一步分為三個子系統(tǒng):表示層,業(yè)務層,數(shù)據(jù)接入層。其中業(yè)務層是整個系統(tǒng)的核心,表示層負責通過接口子系統(tǒng)接收系統(tǒng)事件交給業(yè)務層處理,數(shù)據(jù)接入層供業(yè)務層使用完成數(shù)據(jù)的持久化。每個層對編程人員的技術要求是不同的,表示層需要了解的技術根據(jù)接口子系統(tǒng)選擇的不同而不同:如windows界面,需要對MFC有比較深入的了解,web界面則要求對asp,asp.net,或jsp有比較深入的了解。數(shù)據(jù)訪問層需要的技術則由數(shù)據(jù)庫子系統(tǒng)的選擇決定,另外還需要了解:ODBC,JDBC等。接口子系統(tǒng)的選擇:windows界面,java界面,web界面,命令行接口,CTI, API等 數(shù)據(jù)庫子系統(tǒng)的選擇:關系數(shù)據(jù)庫,普通文件等基于以上對應用軟件系統(tǒng)的理解,軟件開發(fā)流程的輸入是用戶的業(yè)務需求,輸出就是系統(tǒng)的業(yè)務層、表示層、數(shù)據(jù)接入層的代碼,以及接口和數(shù)據(jù)庫,以及各種文檔。因此得到比較理想化的軟件開發(fā)流程圖,該圖使用uml中的活動圖描述。2.需求分析階段需求分析階段的常見問題是:需求分析不夠深入,對問題域沒有仔細研究,急于進入設計階段。造成這種問題一方面是因為項目管目趕進度以及存在于管理人員頭腦中的根深蒂固的想法:任何時候不能讓任何人員閑著,另外很大的原因是很多人不知道如何進一步深入研究問題域。需求分析階段不僅要列出系統(tǒng)的use case,更重要的是要列出use case的輸入輸出和例外情況等,以及問題域中的對象之間的靜態(tài)關系和動態(tài)關系,如對象間的包含關系,繼承關系,調用關系等。需求分析階段另外一個常見的問題是常常將需求分析等同于數(shù)據(jù)庫設計,需求分析階段定義的是系統(tǒng)作什么,而不是怎么做,需求分析的結果應該與具體的技術實現(xiàn)無關。數(shù)據(jù)庫設計是技術實現(xiàn)的細節(jié),應該盡可能的推遲技術細節(jié)的決策,不應該使技術細節(jié)束縛了我們對系統(tǒng)需求的理解。需求分析階段應該從用戶的角度對系統(tǒng)建模,不應將大量的技術細節(jié)暴露給用戶,導致系統(tǒng)易用性差。需求分析階段可以進一步細分為業(yè)務需求分析階段和系統(tǒng)功能需求分析階段。在很多研發(fā)性質的系統(tǒng)中,不注重業(yè)務需求分析,只有系統(tǒng)功能需求分析,導致開發(fā)人員知其然不知其所以然。系統(tǒng)功能規(guī)范文檔與業(yè)務需求文檔的重要區(qū)別有以下幾點:內容不同:系統(tǒng)需求分為功能需求和非功能需求,功能需求進一步分為業(yè)務功能需求和非業(yè)務功能需求。系統(tǒng)需求規(guī)范文檔除了包括業(yè)務需求文檔中的業(yè)務功能需求,功能規(guī)范文檔需要增加以下內容:系統(tǒng)的非業(yè)務功能需求,由于業(yè)務需求由計算機系統(tǒng)實現(xiàn)而產(chǎn)生的功能需求,如系統(tǒng)需要系統(tǒng)管理員管理,系統(tǒng)管理員的角度產(chǎn)生一些非業(yè)務功能需求,另外需要描述系統(tǒng)非功能需求:數(shù)據(jù)量,性能要求,響應速度,可用性要求,可靠性要求,界面語言要求等等。 閱讀的對象不同:業(yè)務需求文檔是用來與業(yè)務人員交流,功能規(guī)范文檔是開發(fā)人員開發(fā)的依據(jù) 使用的語言不同:業(yè)務需求文檔使用自然語言書寫,而功能規(guī)范文檔使用比較嚴謹?shù)恼Z言,如:uml書寫 對編寫人的要求不一樣:業(yè)務需求編寫人員只需要對業(yè)務系統(tǒng)熟悉,系統(tǒng)規(guī)范由系統(tǒng)架構師完成 體現(xiàn)系統(tǒng)架構師價值的地方是編寫系統(tǒng)規(guī)范文檔和業(yè)務層設計, 系統(tǒng)規(guī)范文檔是下一步界面設計,業(yè)務層設計和數(shù)據(jù)庫設計的依據(jù),表示層,業(yè)務層,數(shù)據(jù)訪問層之間是相互聯(lián)系的,它們之間的關系應該在系統(tǒng)規(guī)范文檔中找到。3.架構設計階段架構設計階段的常見問題是將架構設計理解為技術架構設計,實際上架構設計分為技術架構設計和業(yè)務架構設計。技術架構一般由系統(tǒng)軟件商提供,可以在不同的應用軟件系統(tǒng)中使用,例如:微軟的MFC, SUN的J2EE等。對于一個應用軟件系統(tǒng),更重要的是業(yè)務架構的設計,也就是將需求分析階段中得到的各種關系,根據(jù)系統(tǒng)的非功能需求將需求分析轉變?yōu)榇a。其實沒有業(yè)務架構的設計也是可以的,很多項目中直接將對象之間的各種關系以數(shù)據(jù)庫的方式實現(xiàn),這樣的系統(tǒng)不是面向對象的,因此面向對象設計的很多好處不能體現(xiàn)。由于在架構設計階段中沒有進一步細分,通常會導致不能準確估計任務量,造成項目計劃變成擺設。4.詳細設計階段詳細設計階段一個重要的任務是系統(tǒng)持久化設計。對應用系統(tǒng)而言,持久化設計只是管理存儲的機制,有多種技術手段可以選擇:可以是面向對象數(shù)據(jù)庫管理系統(tǒng),簡單的文件,或者是關系數(shù)據(jù)庫,也可以是使用ORM工具等??傊畱摪阉舻阶詈笞鳛榧毠?jié)處理。我們不應該將我們的系統(tǒng)和任何特定的技術綁定在一起。我們可以根據(jù)需求自由選擇需要的持久化技術,并且保留在將來需要時更改持久化技術的自由。5.編碼階段編碼階段還處于小農(nóng)經(jīng)濟,自給自足,沒有分工合作。編碼階段以use case為粒度安排工作,這樣的安排方式要求每一個開發(fā)人員必須對表示層,業(yè)務層,數(shù)據(jù)接入層的所有技術都要有比較深入的了解,由于每個開發(fā)人員各自只對自己的use case負責,對別人的use case不了解,但是每一個use case會有功能重復的地方,導致大量的重復工作。編碼階段工作安排的粒度應該是類,編碼階段工作的安排原則是先分層,再分割,按照表示層,業(yè)務層,數(shù)據(jù)訪問層分開后,每一層內可以進一步分為不同類,使用測試驅動的編程方法,每個編程人員單獨編寫代碼,并進行單元測試。每個層次的編程人員只需要對某一種技術有比較深入的了解。6.測試階段很多人分不清什么是單元測試,什么是集成測試,什么是系統(tǒng)測試?測試的順序是先單元測試,然后是集成測試,最后是系統(tǒng)測試。單元測試是源代碼級的測試,一般由編程人員自己使用各種unit工具測試,是白盒測試。集成測試是在單元測試結束后,將一個或若干個單元作為一個子系統(tǒng)的黑盒測試,測試子系統(tǒng)內的所有組件可以正確的交互,集成測試通過對子系統(tǒng)不斷增加新的單元最后完成整個系統(tǒng)的測試,集成測試不應由開發(fā)人員完成。7.結束軟件開發(fā)過程中,各種輔助工具以及process很重要,但是使用工具和process的最終目的是為了更高效的在開發(fā)人員之間溝通交流,記錄存在開發(fā)人員腦子里的想法,不要為了process而process。不能以為會使用MS word,就認為可以成為作家。最后引用Robert Martin的《敏捷軟件開發(fā):原則、模式與實踐》中的一句話作為本文的結束:過渡信賴工具和過程以及低估智力和經(jīng)驗都是軟件開發(fā)災難的源泉。 注: 本文摘自網(wǎng)絡 臺州極速網(wǎng)絡有限公司愿以雄厚的技術實力基礎
關于軟件開發(fā)流程的短板和開發(fā)軟件的重點和難點的介紹到此就結束了,不知道你從中找到你需要的信息了嗎 ?如果你還想了解更多這方面的信息,記得收藏關注本站。