CMMI 3级精简并行过程综述

bankit

9.4.2 建模分析法
        人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓“一图低千言”就是这个道理。
        在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。
一、结构化分析法
        软件的建模分析兴起于20世纪60年代末期和70年代初期。结构化分析方法并不是由里程碑式的明确地涉及这个主题的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的单一方法。相反地，它是几乎发展了20多年的一个混合物。结构化分析方法在70年代和80年代非常流行，相关论著很多。对结构化分析方法有较大贡献的学者有DeMarco, Gane, Sarsen, Yourdon, Constantine, Ward, Mellor, Hatly, Pirbhai等人。文献[Pressmen99, p206-p214]对结构化分析方法作了高度概括（如图9-2所示），我们不妨称之为“一个中心三种图”：
        “数据字典”是中心，它包含了软件中所有数据对象的描述。
        “实体－关系图”是用图形符号来标识数据对象以及它们之间的关系。
        “数据流图”指明了数据在系统中移动时如何被变换。
        “状态－变迁图”表示了系统存在的各种状态以及它们之间的变迁方式。

图9-2 结构化分析方法示意图

bankit

二、面向对象分析法
        面向对象分析设计（OOAD）方法兴起于20世纪80年代，从90年代起至今它已经在分析设计领域占据了无可争议的主流地位。
        作者在读本科（90年至94年）时就充分地感受到了人们对“面向对象”的狂热。关于“面向对象”的课堂、学术报告常常人满为患。搞软件研发的人都“言必谈对象”，并引以为荣。
        面向对象分析设计领域有一些比较著名的学派，如：
        Coad和Yourdon学派，其代表作为[Coad91]。
        Booch学派，其代表作为[Booch94]。
        Jocobson学派，其代表作为[Jacobson92]。
        Rumbaugh学派，其代表作为[Rumbaugh91]。
有趣的是，这些学派的掌门人就像上帝、真主、如来佛，他们用各自的方式定义了这个世界，并留下一堆经书来解释这个世界。这种混乱的局面被学术界称为百家争鸣，每年诞生了许多论著和教授。叫苦的是软件企业和开发人员：没有统一的方法，不好干活啊！
        终于等到了那一天，Rational公司招纳了Booch, Jocobson, Rumbaugh，这三位“面向对象”业界的权威强强联手，制定了“统一建模语言”（UML）。1997年11月，UML被国际对象管理组织（OMG）采纳，此后UML成为OOAD建模语言的国际标准。
        UML吸取了各种OOAD方法的精髓，对于OOAD中的语义、图形表示法和使用规则作了完整而详细的定义。UML的建模能力超过了以往任何一种OOAD方法，当然其复杂性也随之膨胀。大多数软件开发人员没有兴趣阅读枯燥乏味的UML文档（如[Rumbaugh99]）。真正使UML流行的是Rational公司基于UML的建模工具Rose。Rose易学易用，它能交互式地构建类图、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等等，深得开发人员的喜爱。
        介绍UML和Rose的书籍非常多，读者自己选择、学习，这里不再论述。

bankit

三、恰当地使用图形符号
        现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。
        世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在需求规格说明书中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求规格说明书的附录中，便于正文引用。
9.5 实施建议
        先对需求分析员进行培训，让他们掌握必要的需求开发技能。
        对需求开发过程域产生的所有有价值的文档进行配置管理。
        对于非合同项目，本规范中有关客户的活动可以简化。
        需求的建模分析有较高的技术难度，需求分析员应当根据自身水平进行取舍。建议企业购买Rational Rose作为需求建模分析的工具。
        需求分析员根据产品的特征，适当地修改《用户需求说明书》和《产品需求规格说明书》的模板。

bankit

用户需求说明书

bankit

产品需求说明书

bankit

第10章 技术预研

        技术预研（Technical Pre-Research, TPR）是指在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，以便尽可能早地发现并解决开发过程中将会遇到的技术障碍。
技术预研过程域是SPP模型的重要组成部分。本规范阐述了技术预研的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。

bankit

10.1 介绍
        在产品开发过程中，技术问题可能会层出不穷。如果一点技术障碍都没有遇到，要么是开发人员的技术水平实在太高了，要么是项目的技术含量实在太低了，这类情况比较少见。
一般说来，在设计或实现阶段遇到了技术障碍，才去攻克问题，其代价通常比较高。因为其他人的工作可能会被阻塞，已经投入的不少资源将被闲置。最糟糕的是，如果此技术障碍无法攻克，不得已要改变技术方案、重新设计系统，那么不仅浪费了人力、财力、时间，处理不好还会使开发队伍陷入混乱状态。
        所以开展技术预研工作至少有两大好处：
        帮助开发人员更好地进行需求开发、系统设计和程序设计。
        防止开发进程被技术障碍打断，导致大量的相关工作被阻塞。
技术预研的流程如图10-1所示。

图10-1 技术预研流程
技术预研过程中产生的主要文档有：
        《技术预研计划》，模板见 [SPP-TEMP-TPR-PLAN]。
        《技术预研报告》，模板见 [SPP-TEMP-TPR-REPORT]。
10.2 技术预研规程
10.2.1 目的
        提前发现并解决开发过程中将会遇到的技术障碍。
10.2.2 角色与职责
        项目经理或技术负责人识别项目中的技术难题，指定技术预研人员攻克该问题。
10.2.3 启动准则
        项目中的技术难题已经识别。
        技术预研人员已经指定。
10.2.4 输入
        一些用户需求文档和技术方案文档

bankit

10.2.5 主要步骤
[Step1] 制定计划
        技术预研人员制定《技术预研计划》，主要内容包括：
        确定技术预研的内容和目标。
        确定应递交的工作成果。
        分配任务，制定进度表。
        项目经理或技术负责人审批该计划，如果该计划被批准，则转向 [Step2]。
[Step2] 开展技术预研
        技术预研人员按照计划开展技术预研工作。
[Step3] 撰写技术预研报告
        在预研任务结束时，技术预研人员撰写《技术预研报告》。
[后续活动]
        技术预研人员向相关人员介绍工作成果。
        项目经理或技术负责人视具体情况决定是否对该预研成果进行技术评审。

bankit

10.2.6 输出
        《技术预研报告》
10.2.7 结束准则
        指定的预研任务已经完成，《技术预研报告》已经产生。
10.2.8 度量
        技术预研人员统计工作量和工作成果的规模，汇报给项目经理。
10.3 实施建议
        技术预研不同于真正地开发产品，投入人员与时间相对比较少。一个项目可以有多次技术预研，由项目经理或技术负责人视具体情况而定。
        对技术预研过程中产生的所有有价值的文档进行配置管理。

bankit

预研计划