一\序言
• 93-99年,那时,软件中心所有的项目,几乎没有文档化,-----
• 2000-至今,开始引入ISO9000,制订一套标准.流程,模板--------要求所有的人: “将自己的所做文档化”
• 今天 ,我们的文档柜开始有些积累,但是,我们也同时发现了它带来的必然副产品-----我们让项目组的骨干,浪费在大量无用的文档工作中
以前,我在写这些文档时，一般我会清楚：哪些是为了应付工委会评审?哪些是为了应付产品控制部的?哪些是为了给自己将来维护\给组员看的?-----------对于提交给工委会和产品部的文档通常最终消失在他们的桌面上或者文件柜里,因为没有人再去查阅!而往往只有本来写给自己或组员看的文档才是真正有价值的.
我们大可不必去对工委会,产品部发牢骚.想想这是企业发展的比经之路,CMM不同阶段的思想,工作中心很值得我们参考:
• CMM/2,工作重心:文档化,流程化;
• CMM/3, 工作重心:过程数据量化;
• CMM/4,CMM/5, 工作重心:流程改进,流程精简
任何事物发展都需要一个过程.
如果,2年前,我们跟产品部发牢骚: “你的模板,我用起来很别扭” “需求规格书与详细设计书有很多重叠,很多无谓工作”,PP, “我都快繁死了,现在我只想你们多写文档,然后把文档提交给我,现在,一切按标准来执行”----------那时我的工资不到4000,我在想: “哪一天,我的工资到10000,老周你是否还敢白养我?”
我们的总经理室,有两种选择:
• 把我解雇;(剩下10000,再去请4000的);
• 改革流程,提高效益
所以, ,为了饭碗, 我必须跟总经理室说: “让我们稍微改进一下吧!”
这里,我也并不认为,现在软件中心已经达到流程精简的阶段了(这还不现实,我的在我的工资也还没到10000),
我们是讲:这只是我们将来的趋势.而目前,我们对文档流程的要求是:要尽量有用!与我们的工作实际结合.
下面,我们希望广泛参考IDEF0，IDEF1X，RUP，甚至对于敏捷开发的思想，微软一些成功的做法，然后探讨一些能很好结合软件中心实际的一套软件开发流程！
本文仅起抛砖引玉的作用,希望大家广泛讨论,并最终对目前需求部,总体部的流程制订起一些参考作用!
曾经接触过一个项目组:
他们在一个多月里,需求分析与概要设计阶段,抽调了包括项目经理和刚进公司几天新人的所有组员,全部精力做一件事情-----用VISIO赶画DFD图,.
开始用DFD来写文档,-----------这是中心的一大进步,但是我不知道:
• 他们有多少人知道,DFD应该如何正确地画;
• 为何要画这些图,它们最终目的是什么(难道仅仅因为现在总中心的流程要求吗?)
• 这些图最终起了什么作用?
• 是否有人对这些图进一步使用,进一步交流,进一步分析,提炼?
这些问题不得而知.但是最后他们以提交了数百页得概要设计书为里程碑--------结果似乎是皆大欢喜的.
• 总中心和产品部都很满意;
• 杂音微弱:项目经理或成本控制部门: “一方面要求我们下月整个项目,一方面且要求我们提交这么多过渡产品”
而整个项目的最终结果----------工期延期了.不过,问题不大------- “你们项目组每一步都已经很严格按照流程标准来走了,所有组员也都在加班.作为项目经理你是没有责任的,责任只在于我们低估了工期和成本!”
我们的产品成本真的偏低吗?----------不,我们在与外面企业竞标事,成本报价从来不占优势.
因此,现在的问题是:
• 花费了这么多 “人月”的中间工作产品,到底谁在乎?(可悲的是:连项目组内也没有多少人将数百页的文档全部阅读完)
• 这些中间工作产品起了什么作用,是否确实对系统的质量\架构起了作用.
想法一：（交流）
需求分析，概要设计书必须有用，务实！，不要过分追求语言润色、排版美观。我们的文档不是为了给老师评分，给工委会好评，不是为了在报刊发表！ ----我们所有的行为应该 是企业行为，必须考虑有效性，必须考虑效益，成本。
“我不愿意再去写一些，很少人看，并且进了产品控制部，就再也没人去查看的文档！”
但是,在需求分析，概要设计阶段中,什么工作才是有用的,什么中间产物是需要保存的---------- 这是我们讨论的重点!
需求分析，概要设计书的要素：（这些规格书，需要包括哪些必要产物？）
决定要素的因素：
• 写这些规格书的目的，它是为了下一阶段的哪些目的而写的？本阶段的产物对下一阶段的工作有帮助？
• 谁将来要看这些规格书？（谁会需要该阶段的产品？）
想法二：（交流）
作者在写各个阶段产品的文档时,必须很明确读者对象是谁,然后,只表述该对象能理解的内容;
第一章核心工作流程
核心工作流程简介
核心工作流程显示生成特定的工件集可能要经历的所有活动。我们概括地描述了一下这些工作流程 - 涵盖了所有涉及的角色、活动和工件。同时还更详细地展示角色如何协作、使用并生成工件。对这些步骤的详细说明称为“工作流程明细”。
每个核心工作流程说明如下：
简介
该工作流程的目的以及和其他工作流程的关系。
概念
对理解核心工作流程十分重要的核心概念。
工作流程明细
实施工作流程典型的事件顺序，以工作流程明细表示。工作流程明细是一组“同时”完成的活动，与输入和结果工件一起介绍。
活动概述
工作流程中的活动和角色。
工件概述
工作流程中生成的工件和负责的角色。
指南概述
有关如何使用和生成流程的工件的详细解释。
需求调研与整理
简述
概念
流程明细---需求调研与整理
需求分析
1. 事物与事件列表
2. 确定实体
3. 用例与参与者Use Case 图\系统边界图\\类图(系统关联图(则0级DFD)+ERD)
4. 场景图(DFD)
5. Seq图\状态图\协作图(DFD)
6. 设计类图(数据元素定义)
7. 包图\ (结构图)
8. 类行为定义(过程定义IPO\伪码描述)
9. 关系数据库
10. 用户界面\对话框\表格\报表
11.
业务需求分析到系统分析阶段： 各阶段可建议使用技术和工具。
使用bpwin做业务核心和数据流图的建模（idef0 + idef3 + dfd）；或者使用业务调查，直接用PowerDesigner 6 ProcessAnalyst做数据流图的建模(dfd)；用visio做相关的硬件、网络系统、部署等的设计建模；
可以把数据流图转变成uml的usecase和sequence；
概要设计阶段：
使用PowerDesigner(或者erwin，推荐pd)做数据库结构逻辑设计；
用visio做系统结构图；
用PowerDesigner做类图设计；或者使用rose 2001继续以下的过程；
详细设计阶段：
重要的流程可以使用visio做流程图
整个过程建议项目经理采用Project控制跟踪
erwin支持idef1x即信息建模，就是我们常说的er图、实体关系图，也就是数据库结构图。
bpwin支持idef0/idef3/dfd，是功能与流程建模，主要用来描述企业的业务流程，比uml的usecase/sequence更适合描述复杂逻辑
• 93-99年,那时,软件中心所有的项目,几乎没有文档化,-----
• 2000-至今,开始引入ISO9000,制订一套标准.流程,模板--------要求所有的人: “将自己的所做文档化”
• 今天 ,我们的文档柜开始有些积累,但是,我们也同时发现了它带来的必然副产品-----我们让项目组的骨干,浪费在大量无用的文档工作中
以前,我在写这些文档时，一般我会清楚：哪些是为了应付工委会评审?哪些是为了应付产品控制部的?哪些是为了给自己将来维护\给组员看的?-----------对于提交给工委会和产品部的文档通常最终消失在他们的桌面上或者文件柜里,因为没有人再去查阅!而往往只有本来写给自己或组员看的文档才是真正有价值的.
我们大可不必去对工委会,产品部发牢骚.想想这是企业发展的比经之路,CMM不同阶段的思想,工作中心很值得我们参考:
• CMM/2,工作重心:文档化,流程化;
• CMM/3, 工作重心:过程数据量化;
• CMM/4,CMM/5, 工作重心:流程改进,流程精简
任何事物发展都需要一个过程.
如果,2年前,我们跟产品部发牢骚: “你的模板,我用起来很别扭” “需求规格书与详细设计书有很多重叠,很多无谓工作”,PP, “我都快繁死了,现在我只想你们多写文档,然后把文档提交给我,现在,一切按标准来执行”----------那时我的工资不到4000,我在想: “哪一天,我的工资到10000,老周你是否还敢白养我?”
我们的总经理室,有两种选择:
• 把我解雇;(剩下10000,再去请4000的);
• 改革流程,提高效益
所以, ,为了饭碗, 我必须跟总经理室说: “让我们稍微改进一下吧!”
这里,我也并不认为,现在软件中心已经达到流程精简的阶段了(这还不现实,我的在我的工资也还没到10000),
我们是讲:这只是我们将来的趋势.而目前,我们对文档流程的要求是:要尽量有用!与我们的工作实际结合.
下面,我们希望广泛参考IDEF0，IDEF1X，RUP，甚至对于敏捷开发的思想，微软一些成功的做法，然后探讨一些能很好结合软件中心实际的一套软件开发流程！
本文仅起抛砖引玉的作用,希望大家广泛讨论,并最终对目前需求部,总体部的流程制订起一些参考作用!
曾经接触过一个项目组:
他们在一个多月里,需求分析与概要设计阶段,抽调了包括项目经理和刚进公司几天新人的所有组员,全部精力做一件事情-----用VISIO赶画DFD图,.
开始用DFD来写文档,-----------这是中心的一大进步,但是我不知道:
• 他们有多少人知道,DFD应该如何正确地画;
• 为何要画这些图,它们最终目的是什么(难道仅仅因为现在总中心的流程要求吗?)
• 这些图最终起了什么作用?
• 是否有人对这些图进一步使用,进一步交流,进一步分析,提炼?
这些问题不得而知.但是最后他们以提交了数百页得概要设计书为里程碑--------结果似乎是皆大欢喜的.
• 总中心和产品部都很满意;
• 杂音微弱:项目经理或成本控制部门: “一方面要求我们下月整个项目,一方面且要求我们提交这么多过渡产品”
而整个项目的最终结果----------工期延期了.不过,问题不大------- “你们项目组每一步都已经很严格按照流程标准来走了,所有组员也都在加班.作为项目经理你是没有责任的,责任只在于我们低估了工期和成本!”
我们的产品成本真的偏低吗?----------不,我们在与外面企业竞标事,成本报价从来不占优势.
因此,现在的问题是:
• 花费了这么多 “人月”的中间工作产品,到底谁在乎?(可悲的是:连项目组内也没有多少人将数百页的文档全部阅读完)
• 这些中间工作产品起了什么作用,是否确实对系统的质量\架构起了作用.
想法一：（交流）
需求分析，概要设计书必须有用，务实！，不要过分追求语言润色、排版美观。我们的文档不是为了给老师评分，给工委会好评，不是为了在报刊发表！ ----我们所有的行为应该 是企业行为，必须考虑有效性，必须考虑效益，成本。
“我不愿意再去写一些，很少人看，并且进了产品控制部，就再也没人去查看的文档！”
但是,在需求分析，概要设计阶段中,什么工作才是有用的,什么中间产物是需要保存的---------- 这是我们讨论的重点!
需求分析，概要设计书的要素：（这些规格书，需要包括哪些必要产物？）
决定要素的因素：
• 写这些规格书的目的，它是为了下一阶段的哪些目的而写的？本阶段的产物对下一阶段的工作有帮助？
• 谁将来要看这些规格书？（谁会需要该阶段的产品？）
想法二：（交流）
作者在写各个阶段产品的文档时,必须很明确读者对象是谁,然后,只表述该对象能理解的内容;
第一章核心工作流程
核心工作流程简介
核心工作流程显示生成特定的工件集可能要经历的所有活动。我们概括地描述了一下这些工作流程 - 涵盖了所有涉及的角色、活动和工件。同时还更详细地展示角色如何协作、使用并生成工件。对这些步骤的详细说明称为“工作流程明细”。
每个核心工作流程说明如下：
简介
该工作流程的目的以及和其他工作流程的关系。
概念
对理解核心工作流程十分重要的核心概念。
工作流程明细
实施工作流程典型的事件顺序，以工作流程明细表示。工作流程明细是一组“同时”完成的活动，与输入和结果工件一起介绍。
活动概述
工作流程中的活动和角色。
工件概述
工作流程中生成的工件和负责的角色。
指南概述
有关如何使用和生成流程的工件的详细解释。
需求调研与整理
简述
概念
流程明细---需求调研与整理
需求分析
1. 事物与事件列表
2. 确定实体
3. 用例与参与者Use Case 图\系统边界图\\类图(系统关联图(则0级DFD)+ERD)
4. 场景图(DFD)
5. Seq图\状态图\协作图(DFD)
6. 设计类图(数据元素定义)
7. 包图\ (结构图)
8. 类行为定义(过程定义IPO\伪码描述)
9. 关系数据库
10. 用户界面\对话框\表格\报表
11.
业务需求分析到系统分析阶段： 各阶段可建议使用技术和工具。
使用bpwin做业务核心和数据流图的建模（idef0 + idef3 + dfd）；或者使用业务调查，直接用PowerDesigner 6 ProcessAnalyst做数据流图的建模(dfd)；用visio做相关的硬件、网络系统、部署等的设计建模；
可以把数据流图转变成uml的usecase和sequence；
概要设计阶段：
使用PowerDesigner(或者erwin，推荐pd)做数据库结构逻辑设计；
用visio做系统结构图；
用PowerDesigner做类图设计；或者使用rose 2001继续以下的过程；
详细设计阶段：
重要的流程可以使用visio做流程图
整个过程建议项目经理采用Project控制跟踪
erwin支持idef1x即信息建模，就是我们常说的er图、实体关系图，也就是数据库结构图。
bpwin支持idef0/idef3/dfd，是功能与流程建模，主要用来描述企业的业务流程，比uml的usecase/sequence更适合描述复杂逻辑
#日志日期：2004-11-19 星期五(Friday) 晴
这是关于CMM的文章：
CMM是什么？
CMM是能力成熟度模型（Capability Maturity Model）的缩写，是一种用于评价软件承包能力并帮助其改善软件质量的方法，也就是评估软件能力与成熟度的一套标准，它侧重于软件开发过程的管理及工程能力的提高与评估。
CMM标准共分五个等级，从第一级到第五级分别为：初始级、可重复级、定义级、管理级和优化级，从低到高，软件开发生产的计划精度越来越高，每单位工程的生产周期越来越短，每单位工程的成本也越来越低。
CMM是一种管理方法
CMM的意义不仅仅是对软件开发的过程管理，最关键的它还是一种高效的管理方法，有助于企业最大程度的降低成本，提高质量和用户满意度，而这正是中国软件业与美国、印度软件业最大的差距之处。
据<<软件战略>>杂志发表的报告看，美国软件业发达很重要的一个原因就是：无论规模大小，绝大多数企业都按照规范化的工作方法管理软件循环过程，始终把最终用户放在软件产品供应优化和质量控制的中心，把达到认证标准放在很重要的位置上。
印度在近几年一跃成为除美国以外最大软件出口国的原因也是他们从一开始就非常重视软件业的国际化管理。目前已获得全球最高级即第四或第五级认证的只有7%的软件企业，其中印度就占了其中的大多数。
中国的情况怎样呢？据调查，现在有相当一部分软件企业的经营者还根本不知道CMM是什么。如果不把摩托罗拉算在内，中国到去年才有第一家通过CMM认证的软件企业，而且是二级，这不能不引起人们的思考。
CMM，门槛有多高？
为什么中国软件企业在实施CMM方面落后美国、印度如此之多？是不是CMM的门槛很高？
其实，CMM本身只是一项标准，并不是企业最终的目标，每个企业不管大小都可以向这个标准靠近。追究中国在CMM认证方面的落后，其中有两点最为重要：一是观念和意义问题，一是人才问题。
中国的软件企业大多数仍然处于一种手工作坊式运营阶段，质量和效率观念都不强，在技术和产品本身与国际市场接轨方面更是一片空白。这些对软件企业而言，是一个致命的弱点。软件产业的游戏规则就是技术及其标准，全球软件产业其实处于一个非常开放的价值链中，因此如果你落后了这些技术和标准，就可能被抛出游戏中。另外，软件企业是一个技术密集型企业，获取竞争力的关键就在于提高开发应用效率，降低成本，同时提高产品的质量，这方面是CMM的强项。
人才也是中国在推进CMM方面必须面对的一个关键问题。中国并不缺少软件编程人才，但是软件设计和技术管理的人才却严重缺乏。换句话说，中国有很多“技术工人”，但 “工程设计专家”却严重不足。这只能造成一个结果：大家都处于一片我行我素的混乱中，其结果可想而知。
因此，我们要通过各种途径让中国软件企业更多的认识到CMM的重要性，并提高紧迫性，以提高中国软件企业的国际竞争性。
CMM是什么？
CMM是能力成熟度模型（Capability Maturity Model）的缩写，是一种用于评价软件承包能力并帮助其改善软件质量的方法，也就是评估软件能力与成熟度的一套标准，它侧重于软件开发过程的管理及工程能力的提高与评估。
CMM标准共分五个等级，从第一级到第五级分别为：初始级、可重复级、定义级、管理级和优化级，从低到高，软件开发生产的计划精度越来越高，每单位工程的生产周期越来越短，每单位工程的成本也越来越低。
CMM是一种管理方法
CMM的意义不仅仅是对软件开发的过程管理，最关键的它还是一种高效的管理方法，有助于企业最大程度的降低成本，提高质量和用户满意度，而这正是中国软件业与美国、印度软件业最大的差距之处。
据<<软件战略>>杂志发表的报告看，美国软件业发达很重要的一个原因就是：无论规模大小，绝大多数企业都按照规范化的工作方法管理软件循环过程，始终把最终用户放在软件产品供应优化和质量控制的中心，把达到认证标准放在很重要的位置上。
印度在近几年一跃成为除美国以外最大软件出口国的原因也是他们从一开始就非常重视软件业的国际化管理。目前已获得全球最高级即第四或第五级认证的只有7%的软件企业，其中印度就占了其中的大多数。
中国的情况怎样呢？据调查，现在有相当一部分软件企业的经营者还根本不知道CMM是什么。如果不把摩托罗拉算在内，中国到去年才有第一家通过CMM认证的软件企业，而且是二级，这不能不引起人们的思考。
CMM，门槛有多高？
为什么中国软件企业在实施CMM方面落后美国、印度如此之多？是不是CMM的门槛很高？
其实，CMM本身只是一项标准，并不是企业最终的目标，每个企业不管大小都可以向这个标准靠近。追究中国在CMM认证方面的落后，其中有两点最为重要：一是观念和意义问题，一是人才问题。
中国的软件企业大多数仍然处于一种手工作坊式运营阶段，质量和效率观念都不强，在技术和产品本身与国际市场接轨方面更是一片空白。这些对软件企业而言，是一个致命的弱点。软件产业的游戏规则就是技术及其标准，全球软件产业其实处于一个非常开放的价值链中，因此如果你落后了这些技术和标准，就可能被抛出游戏中。另外，软件企业是一个技术密集型企业，获取竞争力的关键就在于提高开发应用效率，降低成本，同时提高产品的质量，这方面是CMM的强项。
人才也是中国在推进CMM方面必须面对的一个关键问题。中国并不缺少软件编程人才，但是软件设计和技术管理的人才却严重缺乏。换句话说，中国有很多“技术工人”，但 “工程设计专家”却严重不足。这只能造成一个结果：大家都处于一片我行我素的混乱中，其结果可想而知。
因此，我们要通过各种途径让中国软件企业更多的认识到CMM的重要性，并提高紧迫性，以提高中国软件企业的国际竞争性。
浙公网安备 33010602011771号