[杂谈]由某银行软件中心的软件工程发展史,看开发流程改进 - 第2页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

我的观点是一贯支持原创。替啊哩把一些人名和公司名字过滤了一下，避免不必要的麻烦。
加精与否，期待下文，再看看观众反应。
写得很好，很认同，
任何一个项目，都必须根据项目情况，人员情况等各方面因素进行合理的制定工作流程，项目的每个阶段应采用工作内容是否合适，取决于公司技术主管及相关的SQA的经验和积累
最初由 younggang 发布
[B]我的观点是一贯支持原创。替啊哩把一些人名和公司名字过滤了一下，避免不必要的麻烦。
加精与否，期待下文，再看看观众反应。 [/B]
呵，支持原创的同时，保证安全也是重要的！

我对于软件开发文档的理解是这样的，它起码应该起到两个作用：一是使项目组成员能够理顺思路，养成勤动手的习惯，同样的内容，当你记录下来时比口头说两句要费劲，迫使你去进一步思考，并且留下记录可备查；二是便于项目组内部成员以及和组外人员的交流，当然这个前提是文档写的有用。
RUP、CMM、ISO9000里都有一些模板，我们只能参考，不能简单照搬。根据项目大小采取不同的模板。基础性项目（如一个大型新系统的开发）加强文档管理是绝对有好处的；常规性项目（如同某个企业或某个部门开发一个新接口），可以大大简化文档，否则得不偿失，但留下一个基本的卷宗类的信息还是需要的吧。如果一个机构考虑长远发展的话，都得有自己的流程积累和文档积累。至于大量文档为应付检查而做，事后无人查看，只能说明写的没有实际价值。如果不是应付，动脑子了，在实际经验的基础上总结出符合自己机构的开发流程及其文档规格不是什么难事吧。
银行里帐务系统需求文档可以包含：基本概念，功能和业务流程描述，会计核算要素，交易描述（输入、输出、会计分录），操作组织体系，相关制度、办法的修改和制订这些内容。
概要设计说明书包括：业务概述（简述、业务流程、业务功能），体系结构，本系统与其它系统的关系，接口设计（内部接口，外部接口），模块划分，功能与模块的关系，数据库初步设计。
详细设计说明书可包括：程序清单，联机程序，批量程序，函数，SM程序。
总结出各自的文档规格不难，关键在实行上要调动大家的积极性。首先项目经理（或类似人员）要以身作则，再指定一个合格的文档管理和配置管理人员辅助实施。在小组成员全部动手之前，要先按模板写个范例（如果已经有那最好了），让大家参考，千万不要只把模板发布下去让大家写，那样十有八九是不知怎么写的，要么就五花八门了。即便是编写程序，也不要把一堆命名规范抛给大家就完事了，也要自己先写好范例，让大家根据范例和规范编程。这样写出来的程序可阅性很强。需求说明书和详细设计说明需要随不同的阶段补充完善。别指望一步到位，那不现实。比如，详细设计结束是一个版本，编程完毕是一个版本，系统测试完毕又是一个版本。不需要随时更改这些说明书，但是每个阶段结束时得该好。业务和技术人员互相参考更改自己的东西，互相启发。
还有一点就是变更管理要做到位，不要弄的太教条和复杂，但必须保证有东西记录下来。一个项目组中，项目经理和文档（配置）管理员要经常关注这些东西。
一点体会，供兄弟们参考。