，这里只列出部分风险作为示意）。这种结构相对于全息风险层次结构分类，引入了时间维，一来可以使项目成员更加聚焦于当前可能发生的风险，减少工作量从而加快风险识别及处理的速度；二来同一种风险可能出现在不同的项目时期且发生概率和带来的后果也不尽相同，按照时间维划分，既比较符合其本质特点又利于自动处理。同时，我们同样使用了全息层次分类结构，方便根据不同的风险类别来制定不同的管理策略（比如开发环境类中有关需求的风险就可以交由需求分析师来处理），这样可以加快风险的识别、处理速度。随着不同项目各个迭代的进行，风险清单被不断地更新和维护。
（3）针对风险采用了一种计算机可理解、可执行的形式化方法来描述，我们称之为风险模式结构（RPS,Risk Pattern Structure）：<P，C，R，L，E，其中表示风险发生的生命周期阶段的并集合，表示风险可能出现在项目生命周期或迭代的哪些阶段；表示风险发生的前置条件并集合，包含可能导致风险发生的各种最低触发条件（如项目或模块的复杂性大于15、客户参与度低于60%等）；是风险名称及其描述；是风险等级，这里我们将风险分为非受控级和受控级，前者表示该风险级别不高，不一定必须进入风险控制流程，可依据项目实施者的具体情况而定；而后者就表示风险的级别较高，必须进入风险控制流程，否则可能会给项目带来极大的灾难；是风险的代价集合，代价是一个三元组结构，分别表示不利的结果、发生概率及代价；是风险的解决方案。这有点类似于软件设计中设计模式的表示方法。举例如下：
:{初始阶段，细化阶段}；:{客户参与度低于60%}；:偏离业务目标；:受控级；:{<错误的需求，80%，此需求所需的人天>}；:
上面的风险是软件项目中最常见的风险：偏离业务目标。它可能发生在初始阶段和细化阶段；当客户对需求分析活动的参与度低于60%时，满足风险触发条件，此时应给出风险预警；该风险导致的后果是错误的需求，发生的概率是80%；针对风险结果（错误的需求）的解决方案分别是再次讨论、让客户确认签字、不闻不问、让客户全程参与需求分析或者查找类似系统的需求。
（4）对于风险评估，则可以使用现有的各种技术。但为了通用性和可复用性（可形成行业标准），推荐使用统一的技术，如GERT技术或者BBNs方法。
（5）风险的监控与跟踪引入了触发器机制，实现对风险的实时响应。利用程序监控项目的当前状态（如处于生命周期的哪一个阶段、项目模块的大小、代码测试的覆盖率等等），可以根据前面所定义的风险所处的生命周期阶段和前置条件进行自动的风险匹配和风险预警，预警结果可按发生的概率或后果的代价排序，提供给项目开发团队。
（6）风险控制则直接与风险模式结构中的项进行描述，项目管理人员可以直接选择可行的已知风险控制方案使用。
上面提到，该模型的信息基础是一个初始的风险模式清单，随着项目的不断进行更新。这里的更新一般说来可能有两种：一种是识别出新的风险模式，一种是对原有风险模式进行某些条件的修改。处理前者时需要注意将新的风险模式结构与原有的风险模式列表进行对比，以避免重复。处理后者时则相对比较简单，将新条件直接与原风险模式进行归并处理即可。
Web软件项目风险的控制
广义地讲，一切项目管理行为都属于风险控制行动，比如遵从开发方法，因为它能够降低过程风险；选用某种特定的编程语言，是为降低技术风险等。风险控制并不是要对所有辨识出的风险进行控制，因为控制风险同样是有成本的。一般来说。
在前面第三节的描述中，我们使用了RPS结构来描述风险，其中的项是风险解决方案，