小组团队项目：风险分析

学校餐厅管理系统软件项目风险

三大功能：

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)系统运行环境风险

采用的应对策略：避免。经过分析找出发生风险事件的缘由，消除这些缘由来避免一些特定风险事件的发生。

分析：目前，大部分项目系统集成和软件开发是分开进行的(甚至由不一样公司承接)。所以，软件系统赖以运行的硬件环境和网络环境的建设进度对软件系统是否能顺利实施具备至关大的影响。

应对方法：避免这种风险的办法是和用户签订相关的协议，跟进系统集成部分的实施进度，及时提醒用户等。