>>>>>>>>>>点击进入2016年系统分析师考试网络课堂

  >>>>>>>>>>点击进入系统分析师历年考试真题题库

  >>>>>>>>>>点击进入2016年系统分析师考试大纲和教程

1. 随意性大
   
   每次需求立项刚开始就成了“实验田”，做与不做，什么时候做等多凭个人的主观意愿，没有参考以往经验，也没有充分考虑有效的利用资源，“打补丁”现象较多，业务使用不方便，导致后期维护困难。
   
   2.个人智慧多以前因为时间紧，很多需求都是交给具有相当才干的骨干人员处理，但由于他们的经验没有被很好地总结、归纳，且处理过的事件没有统一形成文档，一段时间后，就忘记了曾处理的事件和如何处理的过程。当再次遇到类似问题的时候，还要凭记忆去处理，如果该人员走了，类似的问题再发生的时候，处理人员还要从头摸索，这样不但浪费了大量的人力和物力，同时由于解决问题不及时，也给我中心造成了一些不良的影响，致使整体的维护质量下降，这说明原维护工作多依赖个人智慧而不是整个团队。
   
   3.版本不规范
   
   在早期的软件维护过程中，由于我们对软件的版本控制不严格，完全由开发人员手工进行操作，在这种情况下，版本控制经常出现问题，有时同一模块被不同的人员同时修改，有时将本应该发给甲用户的程序发给了乙用户，又或者开发人员自以为手上的代码是最新的，而出现已改过的BUG又重复出现的现象。这样做的另一个问题是版本的历史很难追踪，由什么人在什么时候做了什么样的修改完全没法掌握。
   
   　　将CMM引入维护工作
   
   为了避免在以后的维护工作中继续出现上述问题，我们考虑引入CMM，试图把个人的脑
   
   力劳动结果规范为有纪律有智力的产品。
   
   首先，我们先自行培训了CMM的基础理论，重点围绕软件维护这部分进行深入的学习和讨论，力争把每一次的维护需求都当成一个项目来进行处理。
   
   其次我们建立一个软件维护项目数据库，内容包括:申请人、申请时间、申请单位、申请科室、需求或问题、领导意见、分析评审结果（如是否可行，为什么，由谁负责等）、处理过程（如涉及到的模块，对哪些项目进行修改，修改的前后差异，处理结束时间，此改动是否影响业务前台操作流程，如果有都有哪些变动等）在改动中的心得，是否涉及版本控制，验收人，验收意见，是否有新的变更要求等。
   
   在需求管理方面，我们努力地贯彻CMM需求管理的精神。每一次的需求提出，我们都让业务人员详细填写需求单（如表所示）。

   
   

   

>>>>>>>>>>点击继续阅读

  相关链接：

  软考中常考的标准化知识汇编（新版）

  软考大纲（软考考试大纲汇编，新版）

  系统分析师考试历年试题分析与解答（案例分析与论文篇）