小組團隊項目：風險分析

學校餐廳管理系統軟件項目風險

三大功能：

1.網上獲知每一個窗口的今日菜，可以更快地選擇排隊的地方。每一個菜品學生也能看到價格，以防工做人員算錯（from xxh）

2.更好地展現餐飲服務人員的信息，提供可匿名的服務舉報制以及點贊制。

完善舉報制，加入對服務人員的保護機制，防止有人惡意舉報。改善方法爲：大數據統計法，舉報者超過6人才舉報生效提供給管理者（from zxy）

同時能夠收錄除了對工做人員，同時對於環境衛生程度，食物安全衛生，或者餐廳管理上好比許多小窗口可是人多時，能夠添加幾個窗口等等的建設性意見的交流（from wxj）

3.提供人氣推薦的菜單一週一次（from ym），根據同窗買的熱銷度計算出的，也使得食堂管理人員獲悉增長哪些伙食的買入量，同時按熱銷度提供直接的套餐選擇，解決都喜歡吃又不知道今天該吃什麼的同窗需求。（from zcf）

 

 

1.1人員風險：（周衝）

風險：

1.核心測試人員的請假、離職
2.測試人員之間的溝通產生問題致使測試內容重複、缺漏
3.測試人員的測試技術不足，好比說產生測試的思惟定勢，有些有問題的地方始終測試不到位

4. 做爲先決條件的任務不能按時完成

5. 沒有找到項目急需的具備特定技能的人。
解決辦法：
1.對於核心的測試人員可能離職而延誤測試的狀況，做爲測試管理者能夠在平時給這些核心人員配置一些能夠候補的測試人員來向他們學習，以免這些核心人的請假、離職的時候，能夠當即補充上來。另外，對於一些關鍵的業務和技術必定要有文檔。

2.測試以前對測試工程師進行明確分工，測試過程當中的每一部分都備份記錄，並隨時注意重複缺漏。
3.每一個測試工程師的思惟方式確定有差異，因此測試管理者多讓這些工程師在測試每一輪後，在進行不一樣模塊的交叉測試。

4.嚴格明確先決條件的任務的處理期限，能夠適當寬鬆期限，可是要嚴格對沒有完成的處罰

5.一方面加快尋找這類人員的速度，可多撥經費，另外一方面也要注意內部人員對這方面的培養

 

1.2人員架構減小風險（張長鋒）

管理層人員：

工做內容：

一、平臺的正常運做；

二、其餘人員的調配；

三、業務及工做安排；

基金業務人員：
 工做內容：
一、負責平常監控平臺的運做，創建風險信息數據庫；
二、負責業務和管理部門風險限額、風險控制狀況的按期評估工做；
三、對異常狀況及潛在的風險提出質疑和核查，向風險控制委員會和管理層履行      風險報告職能。
銀行業務人員：

 工做內容：  

一、構建和完善風險分析和評估體系；

二、構建和完善風險限額管理體系；

三、按照風險限額管理的目標進行投資風險控制

四、對平常投資風險進行跟蹤和監控；

五、按時進行風險評估，提交風險評估報告，並保證報告質量；

六、分析宏觀經濟、微觀經濟和市場變化對投資風險的影響；

七、對重大投資項目和新業務進行風險評估，並提交評估報告。
 項目貸款人員：
 工做內容：

一、負責信貸額度控制工做

二、負責製做風險相關的報表；

三、負責辦理抵押登記等外勤工做；

四、其餘相關工做。

 

 

2.流程風險（王鑫君）

軟件開發流程主要有：需求調研分析----概要設計----詳細設計---編碼---測試---軟件交付準備---驗收

流程風險1：軟件開發組織在有限的任務時間的壓力下，每每放棄文檔的編寫與更新，結果在軟件項目的晚期大量須要經過文檔進行協調時，卻拖累軟件進度愈來愈慢。此外，因爲餐廳管理系統團隊編程的配合問題、資源調配等問題也可能使軟件項目不能在預約的時間內完成任務。

解決方法：在項目實施的時間進度管理上，須要充分考慮各類潛在因素，適當留有餘地;任務分解要詳細，便於考覈;在執行過程當中，應該強調項目按照進度執行的重要項，再考慮任何問題時，都要保持進度做爲先決條件。

應該避免：某方面的人員沒有到位，或者在多個項目的狀況下某方面的人員中途被抽到其餘項目，或身兼多個項目，或在別的項目中沒法抽身投入本項目。發生錯誤是在所不免的，所以必要的測試是項目漸近明細的方式之一，隨着項目的推動再進一步細化、調整、修正和完善。持續地監控，項目進度控制是隨着項目的進行而不斷進行的，是一個動態過程，也是一個循環進行的過程。從項目開始，實際進度就進入了進行軌跡，直到項目結束，這個過程的每個環節都必須徹底在監控之中。在計劃制定時就要肯定項目總進度目標與分進度目標;在項目進展的全過程當中，進行計劃進度與實際進度的比較，及時發現偏離，及時採起措施糾正或者預防，協調項目參與人員之間的進度關係。

流程風險2：菜單的內容是否會因特殊緣由要求修改，如何修改

解決方法：在發佈下次菜單前容許修改，一旦發佈不容許更改

避免：讀者——寫者問題

流程風險3：舉報超過6人制度按時間來講，每一個服務人員都會在將來一個時間點達到6人以上舉報，是否引發服務人員的抵觸

解決方法：舉報超過6人是按月制的，在將來可能會按現實狀況進行調整；同時與管理人員商議，可否點贊制給予被點讚的服務人員必定獎賞；明確被舉報服務人員的各個層次懲罰制度，舉報制只是提醒，要給予服務人員工做的安心

 

3.1技術風險（程雯麗）

風險一：用戶參與少或與用戶溝通少

解決方案：學生信息平臺上宣傳，創建平臺供用戶提意見

風險二：軟件測試風險好比軟件測試中的缺陷風險，難以重視，容易被遺漏。

好比測試用例風險：測試用例設計不完整，忽視了邊界條件、異常處理等狀況，用例沒有徹底覆蓋需求；測試用例沒有獲得所有執行，有些用例被有意或者無疑地遺漏。

解決方案：測試中的風險難以免，有的風險從理論上能夠避免，但實際操做過程當中出於時間和成本的考慮，也難以迴避。因此團隊會留出部分紅員專門進行測試，儘可能減少風險。

風險三：技術風險。項目團隊可能會由於技巧的緣由影響項目的成功。好比舉報制熱銷度的算法。

解決方案：團隊成員培訓，聘請顧問

風險四：相關性風險。一開始參與軟件使用的用戶少，舉報制和人氣菜單樣本少。

解決方案：先關閉這兩項功能，等採集足夠樣本數再開放

 

3.2技術風險（奚曉宏）

風險五：採用的技術路線可能實現不了代碼的設計

解決方案：轉移方案，將風險交給真正有能力應對風險的團隊負責。或者選擇規避，將項目範圍縮小。

風險六：在網上可能沒法及時悉知各個窗口的今日菜

解決方案：制定應急計劃，如與學校食堂菜品負責人進行商談，提前獲知當天的菜品菜單。

風險七：是否存在有人惡意建立帳號進行對餐廳工做人員進行惡意舉報？

解決方案：接受，而且在帳號註冊時採用實名制。

 

 

4.1環境風險：（袁銘）

1.設施未及時到位；

應對方法：避免，在項目的啓動階段就落實好各項工具的來源或可能的替代工具。

2.設施雖到位，但不配套，如沒有電話、網線、辦公用品等；

應對方法：減輕，在作需求分析的同時提早準備好可能所需開發項目的設施配套的網線、辦公用品等，在這些工具須要使用以前(通常須要提早一個月左右)跟蹤並落實工具的到位事宜。

3.  開發設施和工具的選擇不是基於技術需求，不能提供計劃要求的功能。

應對方法：減輕，在進行項目開發以前先設計和搭建出系統的基礎架構並進行性能測試，確保架構符合性能指標後再進行後續工做。

4.開發工具不如指望的那樣有效，開發人員須要時間建立工做環境或者切換新的工具；

應對方法：減輕，在項目開發以前，應該作好工具的功能測試，並瞭解到團隊成員的技術是偏向該種工具的。

5.新的開發工具的學習期比預期的長，內容繁多。

 應對方法：接受，多去學習一些新的開發工具，爲之後可以應對該風險作好準備。

 

 

4.2環境風險（張心玥）

 

分如下兩個方面進行闡述：

(1)工做環境風險

採用的應對策略：避免。經過分析找出發生風險事件的緣由，消除這些緣由來避免一些特定風險事件的發生。

分析：工做環境(包括辦公環境和人文環境)的好壞直接影響項目成員的工做情緒和工做效率。

應對方法：在項目建設以前，就選擇和建設好適合項目特色和知足項目成員指望的辦公環境; 在項目的建設過程當中不斷培育和調整出和諧的人文環境。

(2)系統運行環境風險

採用的應對策略：避免。經過分析找出發生風險事件的緣由，消除這些緣由來避免一些特定風險事件的發生。

分析：目前，大部分項目系統集成和軟件開發是分開進行的(甚至由不一樣公司承接)。所以，軟件系統賴以運行的硬件環境和網絡環境的建設進度對軟件系統是否能順利實施具備至關大的影響。

應對方法：避免這種風險的辦法是和用戶簽訂相關的協議，跟進系統集成部分的實施進度，及時提醒用戶等。