醫患誠信系統——軟件項目的風險

【醫患誠信系統】

軟件項目的風險

小組成員：1759103李思佳、1759106黃宇星、1759107陶彥婷[組長]、1759112劉亞玲、1759135王怡飛

目錄

一、  文檔目的

二、  風險

2.1  人員風險

2.2  流程風險

2.3  技術風險

2.4  環境風險

2.5  需求風險

2.6  產品風險

2.7  設計和實現風險

 

 

一、    文檔目的

軟件在其生命週期內的各個環節都具備不肯定性和複雜性，存在必定的風險。隨着現代化科技技術的發展，各領域的須要日益增多，如何變被動爲主動，對軟件項目的風險進行識別，掌控軟件項目的風險具備十分重要的現實意義。

軟件項目風險控制應貫穿於整個軟件開發過程，重視風險、學會正確處理風險，合理規避風險，調整應變成本，可將風險發生的可能性減少到最低，也能將風險發生帶來的損失儘量降至最低。

此文檔着重介紹了軟件開發過程當中所涉及到的人員、流程、技術、環境、需求、產品以及設計和實現等方面所面臨的風險以及它們的規避方法。

二、    風險

2.1  人員風險

風險	解決方案
咱們組有五我的，其中編程能力較好的有兩人，因此軟件開發的主要代碼由他們二人負責編寫，任務較重、壓較大、完成時間難以掌握。	儘量將項目的核心工做分派給多人，培養和增強各成員的代碼編寫能力。
某些成員須要更多的時間適應還不熟悉的軟件工具和環境。	全部成員都要儘快熟悉的軟件工具和環境，基礎好的成員多幫助基礎較差的成員，你們共同進步，分擔壓力。
若是項目組成員之間發生衝突可能會致使溝通不順暢、設計欠佳、接口出現錯誤和額外的重複工做。	發生矛盾時要及時討論並解決問題，成員間要互相理解、理性分析，確保項目順利進展。
缺少適當的激勵措施，成員可能會由於長時間的工做（如：修改代碼錯誤）而情緒低下致使效率下降。	創建必定的鼓勵措施，分階段制訂幾個小目標。目標完成後對完成目標的主要人員進行必定的物質獎勵。
熟悉各類操做較慢的成員完成工做的時間以及任務比重，可能會影響項目組其餘成員的積極性。	根據各成員較爲擅長的項目決定項目分工，合理組織項目組成員，使他們有效地分工協做、共同完成項目建設。
文檔編寫與軟件開發雙方若溝通不良會影響項目順利進展。	項目組成員應明確溝通方式和溝通渠道，確保溝通暢通，信息及時互通。
因爲技術人員不足或技術人員水平或人員溝通等等緣由致使代碼編寫的完成時間難以掌握。	招募項目所需的技術人員，從而優化和提升代碼質量，縮短完成周期，使項目完成時間可控。

 

2.2  流程風險

風險	解決方案
開發過程當中每一個人負責板塊不一樣，編程風格不一樣,致使溝通不足,質量欠佳,甚至需從新開發	使用迭代開發，將開發過程分爲多個階段，將每一個階段的開發任務分給不一樣的組員，該開發階段中，開發人員專一開發，在模塊開發完成後未分到開發任務的組員進行測試和功能報告的撰寫保證雖然每一個人負責的板塊不一樣但對他人寫的模塊都有所瞭解
撰寫進程報告佔用開發人員的時間比預期的多

 

2.3  技術風險

風險	後果	解決方案
不理解三層架構，經驗不足過分使用某些技術（如xml,web webservice）、業務規則和邏輯混在一塊兒。	（１）按照２層經驗去設計三層架構，一個很差的經驗致使整個系統癱瘓 （２）過分使用xml,web service致使性能嚴重不佳   （３）一個頁面寫５,6千行代碼，沒法維護，缺少可伸縮性	將結構簡化，同時借鑑同行經驗，取其精華改進，明確需求和所需功能，防止算法邏輯混亂。
對主機沒有作好提早規劃，急於上線	運行一段時間後系統資源不足，必須從新規劃	對於主機提早作好全局規劃，預留維護空間。
業務（數據）架構不合理（查詢、插入操做放在一塊兒）	查詢、插入須要不一樣的優化方式	將查詢和插入操做分爲兩個模塊來實現。
測試不全面	用戶成了試驗田	在正式上線前進行嚴謹的軟件測試，尋找用戶參與測試，使得軟件更成熟。
陳舊的開發過程，沒有每日集成，未及時與客戶確認功能實現	上線臨近出現一大堆沒法解決的問題	採用W型開發，需求開發測試同步進行，增長容錯率，及時解決問題。
未作好集中壓力測試	併發時系統崩潰	作好壓力測試，防止系統奔潰，必要時進行服務器擴容。
沒有好的架構，缺少好的開發規範	程序bug重多，代碼很難維護，代碼水平依賴程序員水平。 解決方案：規範代碼格式，書寫編程日誌，在適合的框架下編寫代碼，減小工做量。	規範代碼格式，書寫編程日誌，在適合的框架下編寫代碼，減小工做量。
缺少數據庫規劃	噩夢般的熬夜調優、維護	創建數據庫前作好規劃，規範數據庫格式。
脫離現狀的設計	知足不了客戶要求	採用W型開發，需求開發測試同步進行，逐步知足客戶的需求，減小沒必要要的資源浪費。
沒有真正理解java多線程、對象、繼承、垃圾回收機制等等；沒有真正理解JDBC、沒有真正理解Ｊ２ＥＥ、sevelet、JSP、MVC	形成可靠性、可維護性、可伸縮性、性能問題。	提高自身實力，尋找精通的人才加入。
操做性、友好性很差	很難使用、業務員抱怨成堆、實施異常困難	很難使用、業務員抱怨成堆、實施異常困難 解決方案：作好用戶體驗報告，及時更新改善操做性友好性問題，進行屢次調試，多輪測試。

 

2.4  環境風險

 

風險	解決方案
工做環境（包括辦公環境和人文環境）	工做環境（包括辦公環境和人文環境）的好壞直接影響項目成員的工做情緒和工做效率。 預防這種風險的辦法是在項目建設以前就選擇和建設好適合項目特色財務管理和知足項目成員指望的辦公環境、在項目的建設過程當中不斷培育和調整出和諧的人文環境。
系統運行環境風險	目前，大部分項目系統集成和軟件開發是分開進行的（甚至由不一樣公司承接）。所以，軟件系統賴以運行的硬件環境和網絡環境的建設進度對軟件系統是否能順利實施具備至關大的影響。 預防這種風險的辦法是和用戶簽訂相關的協議、跟進系統集成部分的實施進度、及時提醒用戶等。

 

2.5  需求風險

   產品開發過程當中，因爲產品需求自己的隱含性、用戶與開發者之間的溝通障礙，以及需求隨着時間、用戶的變化而變動等緣由，可能使需求分析偏離實際需求而最終致使產品開發的失敗，這種可能性稱爲需求風險。軟件開發項目風險是指在軟件生命週期中所遇到的全部的預算、進度和控制等各方面的問題，以及由這些問題而產生的對軟件項目的影響。需求分析是軟件開發過程當中最初始、最基礎的工做，也是最重要的工做之一，其成敗將直接並最終決定軟件開發的成敗，而且呈倍增效應。需求分析的關鍵是使隱含的需求明確，使變動的需求可控，採用座談會、需求調查表、需求啓發、角色扮演等方法可使需求明確化；採用面向對象的方法及UML工具、領域專家的全程參與、需求分級、二次開發接口等方法可使需求變動處於可控範圍內。實踐證實，這些都是控制需求風險的有效方法。

風險	解決方案
沒有足夠用戶參與	對系統用戶及用戶的替代源等相關涉衆進行準確的分析；採用問卷調查等簡單的需求獲取方式或對於參與用戶提供必定的獎勵政策。
需求已經成爲項目基準，但需求還在繼續變化	對於合理的用戶需求能夠將新需求放到後續版本中；對於不可理的用戶需求，須要開發人員保持業務領域的專業性。
模棱兩可的市場需求	經過多用戶或瞭解用戶背景的方式來分析用戶的深層目的，明確隱藏在背後的需求
沒必要要的特性	對於沒必要要的特性要摒棄
過於精簡的規格說明	同時使用模型語言和天然語言兩種表達方式，同時保證信息傳遞的準確行和文檔的可讀性。
被忽略的用戶分類	召開屢次頭腦風暴或集體會議明確全部的用戶分類。
不許確的產品開發計劃	召開屢次集體會議明確全部的產品開發計劃書。

 

2.6  產品風險

 

風險	解決方案
開發額外的不須要的功能(鍍金),延長了計劃進度	使用迭代開發，將開發過程分爲多個階段，每一個階段開始以前聯繫用戶，讓用戶參與需求分析，結合用戶的想法進行修改，刪除用戶認爲無用的功能
要求與其餘系統或不受本項目組控制的系統相連,致使沒法預料的設計、實現和測試工做	在作系統的整體設計方案時，先把好相關產品的選型關，確保網絡、主機、系統軟件與應用軟件之間不要存在較大的技術兼容性問題，肯定相關設備的技術參數和配置要求。
在不熟悉或未經檢驗的軟件和硬件環境中運行所產生的未預料到的問題
開發一種全新的模塊將比預期花費更長的時間	在項目開發早期，創建系統的架構，對系統所須要應用的技術作深度探索。讓小組裏編程能力較強的組員優先解決關鍵技術難題，編程能力較差的組員負責較基礎的功能編寫，必要時刻利用網絡解決問題

 

2.7  設計和實現風險

 

風險	解決方案
設計質量低下,致使重複設計	使用迭代開發，將開發過程分爲多個階段，每一個階段完成以後聯繫用戶，讓用戶參與測試，結合用戶的使用感想進行階段性修改， 將每一個階段的開發任務分給不一樣的組員，該開發階段中，開發人員專一開發，未分到開發任務的組員進行測試和報告的撰寫，同時對代碼進行監督，若代碼質量低則及時反饋， 保證每一個人負責的板塊不一樣但對他人寫的模塊都有所瞭解
代碼和庫的質量低下,致使須要進行額外的測試,修正錯誤,或從新制做
分別開發的模塊沒法有效集成,須要從新設計或製做
一些必要的功能沒法使用現有的代碼和庫來實現,開發人員必須使用新的庫或者自行開發新的功能	在項目開發早期，創建系統的架構，對系統所須要應用的技術作深度探索。讓小組裏編程能力較強的組員優先解決關鍵技術難題，編程能力較差的組員負責較基礎的功能編寫，必要時刻利用網絡解決問題，若實在沒法解決則求助老師