神马文学网软件工程培训纪要
来源：百度文库 编辑：神马文学网 时间：2024/04/25 17:15:13
软件工程培训纪要
今天下午参加了公司的 软件工程 培训。由于所在部门前不久过了CMMI 3 级，所以有些东西也是结合CMMI 3的原则来说的。由于才从学校出来，没有太多的经验，一些理论也是似懂非懂。不过还是记录了一些目前就觉得有些用处，可以为以后的一些软件开发活动提供参考的东西。
- 每一个活动都必须有明确的启动准则和离开（结束）准则。比如，必须明确的规定只有当《需求说明书》通过了客户的审核并签了字，才可以说目前需求的调研结束了。
- 对过程的剪裁。CMMI 对整个软件开发过程的每一个阶段都有着明确的规定。但是这样的规定对于规模比较小的项目可能就显得繁琐，没有必要了，这种情况就需要对模型进行必要的裁减，不能拘泥不变。
- 对于重复的活动一定要注重经验的积累。体现的最主要的地方是一些审查的地方，比如代码规范性审核，由于重复的错误总是屡屡犯过，所以可以形成一个CheckList，里面列举了所有常见的代码规范的条款。这样检查人员不必再绞尽脑汁的去想要检查哪些规范，而是可以全面的对代码的规范性进行检查。其实这种经验的积累和知识库的建立用的地方很多，我原来看到一篇关于提高ASP.NET应用程序的性能的文章，文章的最后就列举了所有可能提高系统性能的条目，供开发人员对自己的程序进行检查。效果非常的好。
- 对需求确定优先级别。不是所有的需求都是一样重要的，要对需求的重要性进行排序，甚至要理清需求之间的关系。因为有些需求之间的依赖性很强，要么就一起完成，要么就都不要做。然后针对优先级别高的需求进行开发优先开发工作。
- 原型的作用是用来直观的表达业务流程的。用户可能没有耐心去看你精心制作的需求说明书。用原型演示与客户进行交流，已确定开发人员和客户之间的理解是否存在偏差。
- 比较小的功能需求粒度。一般是页面级别一下，比如一个页面上有一个按钮，点击这个按钮可以把页面的信息保存到指定的数据库中。那么这个保存功能就应该单独的作为一个功能需求点。因为这样的语言更加的准确，为以后的开发，针对需求的集成测试都会带来便利。
- 设计系统时，系统所有实现的功能，在需求说明书中都应该有明确的“文字说明”来对应。
- 对于如同《需求跟踪矩阵》这样的文档，可能在不同的阶段，项目经理，系统设计工程师，系统开发工程师都会对其进行填写，那么这样就很可能产生不一致性。此时就需要设立专门的组织，或者有人兼职进行定期的检查，保证文档的一致性。
- 对于任何任务都必须有明确的责任人，而且这些责任的对应关系应该有专门的文档进行记录。这样可以在出现问题的时候，有明确的依据进行处理。
- 系统发布的时候，除了源代码，用户手册等部分外。还需要有一个《系统说明文档》，其中应该包含的内容是：此软件的版本信息，此版本较上一版本修正了哪些缺陷， 此版本较上一版本添加了哪些新的功能， 此版本的软件可能会有哪些局限（可能的解决方法）， 此版本的Q&A。我们看到很多软件都在安装的目录下有一个文本文件，里面列举了此软件所有版本的历史。其实就是《系统说明文档》