1. PSP/TSP导入式培训
孙少羚
2010年9月16、17日
Site:
http://sempsalon.wikispaces.com/
Email: semp.salon@gmail.com

2. 课程目标
课程结束时，参加人员能够:
说出PSP/TSP的目的和作用
掌握PSP/TSP的基本过程和方法
在项目中尝试使用PSP/TSP
对PSP/TSP产生兴趣
产生兴趣

3. 课程大纲
• 第一天
– PSP/TSP简介
– 计划
– 跟踪
• 第二天
– 质量控制
– 设计
– 案例分析

4. PSP/TSP简介

5. 内容
• 什么是PSP/TSP？
• PSP/TSP目的
• PSP/TSP核心内容

6. 什么是 PSP/TSP
PSP – Personal Software Process
TSP – Team Software Process
养成良好的职业习惯，使
养成良好的职业习惯
PSP是一套旨在帮助软件工程师养成良好的职业习惯
之成为企业需要的职业工程师的方法和工具集
TSP为一组具备PSP能力的工程师进行协同工作，提供指
导和帮助

7. PSP/TSP 和 CMMI
CMMI - Builds
organizational
capability
TSP - Builds
quality products
on cost and
schedule
PSP - Builds
individual skill
and discipline

8. 我们的行业特征
•大规模知识劳动 (Large Scale Knowledge
Labor Work)
• “在以大规模知识劳动为主的企业中，人员管
理的难度极高 ，并且很难靠他人管理，更多
地依赖于自身管理” --- Watts Humphrey

9. 我们的应对
以流程为中心的风险规避机制
•以流程为中心的风险规避机制
• Models & Standards – CMMI, ISO…
• Organizational Processes – PLCM…
• Method & Tools – PSP/TSP, Agile…

10. 我们的问题
•我们的开发效率真的高吗？
•我们对承诺真的有信心吗？
•我们真的了解项目完成时的质量吗？
•我们真的能及时发现并纠正问题吗？
•。。。
流程规避了一半风险，
流程规避了一半风险，还有另一半是由千差万别的个人带来的

11. 人与人之间的差别
• 性格不同
• 能力不同
• 经验不同
• 习惯不同

12. 案例分析 – 印度的崛起

13. 印度站上世界舞台

14. Forbes 2000 (软件与服务) – 2009.4
Rank Sales ($BIL) Profit ($BIL)
• TATA 834 5.70 1.25
• Infosys 891 4.16 1.16
• Wipro 989 4.98 0.82
• Tencent 1535 0.52 0.21
• Baidu 1962 0.47 0.15
http://www.forbes.com

15. Forbes 2000 (软件与服务) – 2010.4
Rank Sales ($BIL) Profit ($BIL)
• TATA 741 5.41 1.02
• Infosys 807 4.22 1.17
• Wipro 826 5.00 0.76
• Tencent 1073 1.05 0.41
• Baidu 1375 0.65 0.22
http://www.forbes.com

16. 我们的启示
不同的智商/情商?
不同的经验/能力?
不同的环境?
不同的职业习惯 – PSP/TSP Focus
印度软件教育不全靠大学，软件蓝领大多出自职业培训机构
印度软件教育不全靠大学，软件蓝领大多出自职业培训机构
蓝领

17. PSP的目的
帮助软件工程师养成良好的职业习惯
•帮助软件工程师养成良好的职业习惯
•让每一个工程师都能
• 了解自己
• 控制自己
• 改善自己
产品和项目的绩效是每个工程师绩效的叠加

18. SEI提供的PSP/TSP收益数据
Average Effort Deviation - Range Average Schedule Deviation - Range
120% 160%
100% 140%
120%
80%
100%
60% 80%
40% 60%
40%
20%
20%
0% 0%
-20% -20%
Pre TSP/PSP With TSP/PSP Pre TSP/PSP With TSP/PSP
Defects/KLOC in Acceptance Test - Range Post-Release Defects/KLOC - Range
0.9 1.4
0.8 1.2
0.7
1
0.6
0.5 0.8
0.4 0.6
0.3
0.4
0.2
0.1 0.2
0 0
Pre TSP/PSP With TSP/PSP Pre TSP/PSP With TSP/PSP

19. 内容
• 什么是PSP/TSP？
• PSP/TSP的目的
核心内容
• PSP/TSP核心内容

20. PSP/TSP提供
PSP Training – 体验式培训，帮助职业习惯的养成
7 Assignments; Results Analysis…
Individual/Team Scripts/Standards – 个人/团队过程和标准
Design; Code Review…
Statistical experience – 量化经验数据
CR Rate: 200 Loc/hour; CR Time: 0.5*Coding Time…
PSP/TSP Tools – PSP/TSP工具
Way for personal/Team operation
TSP Coach – 过程顾问
Process Implementation Insurance

21. 体验式培训
• 1 Instructor
！
• <=12 Trainees
Discipline！
• 5D Fundamental
+5D Advanced
• 4+3 Programs
• Mission: 0 Bug in
Compile & UT

22. Scripts脚本

23. Standards标准

24. PSP/TSP工具
• PSP Estimation Tool (Customized Access Tool)
• Authorized by CMU/SEI if applying for the PSP training
• Being used during PSP Training
• Get the first personal performance baseline from the 1st 7
programs after the training
• PSP/TSP Project Management Tool (Customized Excel Tool)
• Authorized by CMU/SEI if applying for a SEI Certified TSP
Coach
• Being used during project lifecycle
• Process Dashboard (Web Based Tool)
• License free

25. 核心度量

26. 计划

27. 问题
Why are plans needed?
为什么需要计划？
为什么需要计划？

28. 计划的作用
Plans are needed to
需要计划来:
– Make commitments
给出承诺
– Guide the work
指导工作
– Track the work
跟踪工作

29. 问题
What are the steps in planning?
计划有哪些步骤？
计划有哪些步骤？

30. 计划的基本步骤
Basic steps of planning are 计划的基本步骤是:
1. Understand the requirements 理解需求
2. Conceptual Design 概念设计
3. Estimate size and effort of job 估算规模和工作量
4. Make a task list 制定任务列表
5. Make a schedule 制定进度计划
6. Review and Commitment 评审并达成共识

31. 估算的问题
Detailed size measures such as lines of code (LOC), screen controls, or data base
objects are needed to make good effort estimates
需要有详细的规模度量标准（比如代码行、页数或数据库对象）来做工作量估算。
At the initial planning stage, directly estimating LOC, screen controls, or data base
objects is usually difficult
在计划的初始阶段，直接估算代码行、页数或者数据库对象是非常困难的。
These are not the items you visualize directly from the requirements or
specification
这些元素并不能直接从需求或者规格说明书中获得。
How can this be handled?
那怎么处理呢？
Requirements Lines of
Code?

32. 估算案例：建房子 1
Suppose you want to build a new house
假定你希望建一座房子
You go to a builder to get a cost estimate
你向一个建筑商询价
The builder tells you that the cost is directly related to the size, in
square feet, of the house
建筑商告诉你：价格与房子的规模
规模，即面积
规模 面积直接相关
面积
How can you come up with the needed size estimate?
你如何获得所需的规模估算呢？

33. 估算案例：建房子 2
The builder has detailed size data on actual room sizes for many houses
建筑商拥有许多房间实际面积的详细数据
The data are organized by room type such as bedroom, bath, and kitchen
with the typical small, medium, and large size
这些数据按照房间类型（卧室、浴室、厨房等）以及规模(小、中、大）来组织

34. 估算案例：建房子 3
You visualize a conceptual design of your desired house by listing the
rooms you want and their relative sizes; small, medium, or large
通过列出你想要的房间类型和它们的相关面积，将概念设计形象化:
– To estimate the house size
估算房屋面积
– To estimate the square footage of each room, look up the room type and relative size in
the builder’s size table
为了估算每个房间的平方米，从建筑商的规模表中查找房间类型和相关面积
– Total the estimated room sizes by adding the individual estimates together.
把各个房间估算累加得到总的估算规模
To estimate the cost, multiply the final size estimate by his cost per square
foot
为了估算成本，将每平方米的成本乘以最终的估算面积

35. 类推到软件
– From the requirements, visualize the “parts” needed to build the program (such as the
rooms of the house), the “types” of these parts, and their relative sizes
来自需求，对构造程序所需的“部件
部件”(譬如建造房屋的房间)进行形象化：这些“部件”的
部件
类型以及相关规模。
– Use historical data on the software parts already developed, organized into a relative size
table by part “types,” to estimate “part” size.
历史数据，按组件类型组织一份相关规模表来估算组件
使用曾经开发的软件组件的历史数据
历史数据
模
– Estimate the program size by summing the “part” estimates and adjusting the sum by the
relationship of past estimates to actual sizes
通过累加组件估算得到总的程序规模，以及根据历史估算值与实际规模的关系对累计
校准。
值加以校准
校准
– Estimate effort by multiplying the size estimate by historic productivity.
通过将估算的规模乘以历史生产率 历史生产率(size/hour)，得到估算的时间。
历史生产率

36. PROBE估算过程

37. Conceptual Design
A conceptual design 概念设计
– relates the requirements to the product
将需求与产品关联起来
– defines the product parts that will needed to build the product
定义用以构建产品的组件
– is used as the basis for estimating the size of the product you plan to build
用作规模估算的基础
Conceptual design are not the same as detailed designs
概念设计与详细设计不同
For most projects, the conceptual design can be produced relatively
quickly
对大多数项目而言，概念设计可以相对快速地生成。
If you do not understand the product well enough to make a conceptual
design, you do not know enough to make a plan.
如果你对产品的了解不足以做概念设计，那么也不足于做计划。
如果你对产品的了解不足以做概念设计，那么也不足于做计划。

38. Identify and Size the Proxies
Based on the conceptual design, categorize those parts by comparing each to types
of parts historically produced
基于概念设计，通过把每个组件与历史组件类型比较来对它进行分类。
Next, estimate the relative size of each part by comparing to the size of parts
historically produced
接下来，通过与历史组件的规模比较来估算每个组件的相关规模。
Finally, combine the part estimates to estimate total size of new parts
最后，综合各组件估算值从而估算出新组件的总规模。

39. Estimate Other Element Sizes
If you will be modifying or including existing code, you will need to
estimate those other parts
如果你要修改或者包含已存在的代码，则你将必须估算这些组件。
Base parts are existing parts that will be changed by adding, deleting,
or modifying
“Base parts”，是已经存在并即将被改变的组件(增加、删除或修改)。
Reused parts (R) are parts that will be used unmodified
“Reused parts (R)”，是不会被改变的组件。

40. Calculate Projected Total Program
Size and Effort
To calculate total program size, you add up the individual pieces
为了计算程序的总规模，你需要将各个部分相加。
The total size may be adjusted based on your historical data to
calculate a projected total program size
总规模可以基于你的历史数据进行调整，以计算出计划的程序总规模。
The estimation of development effort is based on the projected
program size
开发工作量的估算基于开发程序的规模。
The projected program development effort can also be adjusted based
on your historical data
程序开发工作量也可以基于历史数据进行调整。

41. 选择合适的规模度量
In class, we encourage you to use LOC as the size measure; you will
likely need additional size measures in practice, however.
在课堂上，我们鼓励使用代码行来度量规模；在实际工作中，你可能
需要其它的规模度量。
Criteria for selecting size measures
选择规模度量方法的标准：
– relates to effort
与工作量相关
– Precise
精确
– machine countable
能够自动计算

42. 规模度量的精确性
A size measure is precise if
精确的规模度量是指：
– Every time you measure the same item you get the same
result
每次度量的结果相同
– Every person who measures the same item gets the same
result
不同人的度量结果相同
Is LOC a precise measure?
代码行是一种精确的度量吗？

43. 代码行统计标准
LOC is not a precise measure unless LOC has been defined precisely
代码行只有被精确地定义才是一种精确的度量
Defining LOC precisely in the work environment can be a significant task
在工作中精确定义代码行是非常重要的任务
In this class, we use the following simple rules for defining a line of code
在我们的课程中，使用下面简单规则来定义代码行
– Count each physical line as one LOC
每个物理行做一个代码行
– Do not count blank lines
不计算空白行
– Do not count line that are only comments
不计算只包含注释的行
– Do not count machine generated lines
不计算自动生成的代码

44. 代码行的类型
The types of LOC include
代码行包括:
– base [B] – LOC that you start with and make changes to
base [B]：你开始时的基础代码，并要对它进行改变。
• deleted [D] – LOC removed from the base “deleted [D]” ：从基代码中删除的
• modified [M] – LOC in the base that is modified “modified[]”: 基代码中修改的
– added [A] – LOC that is new
added [A]：新的代码行
– reused [R] – LOC from a library that is used without changes
reused [R]：从程序库中拿来直接使用且没有任何改变的代码行
– added and modified [A&M] – sum of added and modified LOC
added and modified [A&M]：增加和修改代码的总和
：
– new reusable – new LOC that is put into a reuse library
new reusable：用以放进重用库的新代码行
– total [T] - the LOC in the entire program
total [T]：整个程序的代码行

45. 程序代码行类型

46. PROBE估算原则
Estimating is a continuously precise process
估算是一个逐渐精确
逐渐精确的过程
逐渐精确
– No one knows how big the product will be at beginning
没有人在一开始知道产品规模会有多大；
– The earlier the estimate, the less is known
越早做估算，知道得就越少；
– Estimates can be biased by business and other pressures
估算可能因业务需要或其它压力而有所偏差。
Estimating is an intuitive learning process
估算是一个逐渐学习
逐渐学习过程
逐渐学习
– Ability improves with experience and data
能力会随经验和数据而提高
– Some people will be better at estimating than others
部分人估算得比其它人要好
The objective is to become consistent
目标变得一致
– You will then understand the variability of your estimates
然后你就能理解你的估算的变化性
– You seek an even balance between under- and overestimates
你要平衡乐观与悲观估算
平衡乐观与悲观估算

47. PROBE估算样例

48. 任务工作量分配
•Planning
•Detail Design (DLD) – 20%
•Detail Design Review (DLDR) – 10%
•DLDINSP (Detail Design Inspection) – 10%
•Code (Coding) – 20%
•CR (Personal Review / Buddy Code Review) – 10%
•Compile – 3%
•CODEINSP (Code Inspection) – 10%
•UT (Unit Testing) – 7%
•Post Mortem – 10%

49. 进度和任务计划样例

50. 跟踪

51. 项目跟踪的问题
• Project tracking would be simple if
如果下面说法存在，则项目跟踪会变得容易:
– we always completed tasks in the planned order
我们总是按照计划的次序完成任务
– no tasks were added or deleted
没有任务增加或删除
• But this never happens 但这绝不可能发生
– Requirements always change 需求总是在变更
– Tasks get cancelled or deferred 任务总被取消或者延迟
– Some tasks are dropped, and others are added 我们经常取消一些任
务或增加一些新任务
– Estimating errors are common 任务的估算也总有些误差

52. EV挣值跟踪
• To track project status in a dynamic environment, you need a way to assign a
value that measures the contribution of each task towards the whole project.
为了在动态环境中跟踪项目状态，我们需要一个值，用于度量每个任务
对项目的贡献。
• Then you can
有了这个值，我们就可以
– add up the value of the completed tasks
知道全部已完成任务的总值
– compare this value to the value of the total job
将已完成任务的总值和项目所有任务的总值相比较
– calculate the percentage of job completion
计算工作完成的比例
• The PSP/TSP does this with a method called earned value (EV)
PSP/TSP通过挣值 挣值做到这一点
挣值

53. 挣值 Earned Value
• The planned value (PV) for a task is the percentage of the total project hours
that is planned for that task
一个任务的 计划挣值 计划挣值PV是这个任务的计划时间与总的项目计划时间的百
分比
• When a task is completed, it is assigned an earned value (EV) that is equal to
the planned value for that task (regardless of how many hours it actually took)
当一个任务完成时，它被赋以一个挣值(EV)，这个值等于其计划值，而不
管实际花多长时间完成
• Partially completed tasks receive no earned value.
没有完全完成的任务是没有挣值的

54. 样例 – 计划挣值 PV

55. 样例 – 挣值EV

56. 挣值计算
• To estimate the project completion date with EV 为
了利用挣值预计项目结束日期，必须:
1. Determine the EV needed to finish 确定需要完成的挣值
2. Determine the rate at which the individual is earning EV
确定获得挣值的速率
3. Determine how long it will take the individual to earn the
remaining EV 确定需要多久来获得剩余的挣值

57. 预计项目结束日期 - 1
• After three weeks, the work has taken longer than expected, and the developer is not
getting 15 task hours per week
3周之后，实际工作需要花费的时间比期望的要长，并且开发者没有做到每周工作
15小时
• As tasks are completed, their EV is entered for the week earned. Partially completed
work earns no value
随着任务的完成，所对应的周获得了它们的挣值。部分完成的工作没有挣值。

58. 预计项目结束日期 - 2
• The team member has earned 42.8
EV in 3 weeks, or 14.3 EV per week
小组成员在3周内获得42.8的挣值，
或者说每周14.3.
• There are 100 - 42.8 = 57.2 EV to
go. At 14.3 EV per week, that is 4.0
more weeks to go.
还需要得到100 - 42.8 = 57.2 EV . 按
照14.3/周的速度，还需要4周.
• Added to the 3 weeks spent so far,
that is 7.0 weeks.
加上已经花费的3周，总共是7周
• At the current rate of progress, the
team member will be 2.0 weeks late.
按照目前进展速度，小组成员有2
周的延迟

59. 练习： EV挣值跟踪
• 根据数据，回答下列问题

60. 问题 1
• Is this team ahead of or behind schedule, and by
how much?
小组领先或者落后进度吗？程度如何？

61. 问题 2
• Why is the team behind schedule?
• 落后进度的原因是什么?

62. 问题 3
• At this rate, can the team members finish on the original
plan of 25 weeks? If not, how late will they be?
以这样的速度，小组能够按计划的25周完成任务吗？如
果不行，会延期多久？

63. 问题 4
• Can this five-person team meet the original schedule? If
not, what help would they need from management to do?
这个5人组成的团队能够实现进度要求吗？如果不能，
他们需要管理层提供什么样的帮助？

64. 质量控制

65. 软件质量
To be useful, software must 有用的软件必须是:
– install quickly and easily 快速方便地安装
– run consistently 稳定运行
– handle normal and abnormal cases 恰当地处理正常与非正常状况
– not perform in a destructive or unexpected way 不会以破坏性或意想
不到的方式运行
– be essentially bug-free 基本没有缺陷
Defects are not important to users, as long as they do not
– affect operations 影响操作
– cause inconvenience 造成不方便
– cost time or money 消耗时间和金钱
– cause loss of confidence in the results 影响对程序结果的信心

66. 质量问题
With common quality practices, software groups typically
实践表明，软件团队通常：
– spend more than 50% of the schedule in test
时间进度的50%花费在测试上
时间
– devote more than half their resources to fixing defects
一半以上的资源
资源用于发现和解决缺陷
资源
– cannot predict when they will finish
无法预测测试工作什么时候可以结束
无法预测
– deliver poor-quality and over-cost products
发布低质量
低质量和超支的产品
低质量
To get quality, you must put quality into test
为了得到高质量的软件产品，它必须在进入测试之前就已经具备高质量

67. 质量与生产率
Managed quality = 60% increased team productivity
管理质量 = 60%的team生产率提高
的 生产率提高

68. 质量控制方法
发现和解决缺陷的主要方法包括：
– unit, integration and system test
单元、集成和系统测试
– reviews, inspections, walkthroughs
评审、正式评审、走读
– compiling, static code analysis
编译、静态代码分析

69. Review类型
A personal review is conducted by the developer who examines his or
her own product with the goal of finding and fixing as many defects as
possible.
“personal review”是开发者为了尽可能多地解决缺陷，检查自己的产
品。
An inspection is a structured team review of a software product
“inspection”是有组织地对软件产品进行小组评审。
A walkthrough is less formal than an inspection. The product is
presented to an audience that raises issues and asks questions.
“walkthrough”没有“inspection”正式，向听众演示，由听众提出问题。

70. Personal Review原则
The PSP review goal is to find every defect before the first test.
PSP review的目标是在第一次编译或测试之前发现每个缺陷。
To address this goal, you should
为了达到这个目标，你应当:
– Take a break between working and reviewing
在review和工作之间有所间隔
– Review before compiling or testing
在编译和测试之前进行review
– Follow a structured review process
遵循一个结构化的review过程
– Use a checklist derived from personal defect data
使用根据个人缺陷数据不断更新的checklist
– Measure your review process
度量你的review过程
– Use data to improve your reviews
使用数据来改进你的review活动.

71. Reviewing Before Inspecting
The principal focus of inspections should be to find problems that you cannot
find in personal review.
Inspection主要关注在找出个人review中无法发现的问题
When programs have many simple defects, inspectors are distracted and often
miss more important problems
当程序有太多简单缺陷，inspectors会被分散注意力以至于经常遗漏更加重要
的问题。
Reviewing the product first
Inspection之前需要review产品，可以：
– provides a quality product for the inspection
为inspection提供高品质的产品
– shows respect for the inspectors’ time
对inspector的时间表示尊重
– produces higher quality inspections
提高inspection的效率

72. 使用检查表 Checklist
Your reviews will be most effective when your personal checklist is
customized to your own defect experience
当你的checklist是根据自己的缺陷经验定制时，你的review是最有效的。
– Use your own data to create the checklist items
用你自己的缺陷数据建立checklist项
– Adjust the checklist with experience.
根据实际使用结果调整checklist.
在Review过程中，你应该
– Read every check in the checklist before review
在开始Review之前，熟读Checklist中的每一项.
– Link the defects with the checks in the checklist
将检查到的缺陷与Checklist中的Check项进行关联
– Check off each item as you complete it
完成review前核对每一个检查项

73. Review vs. Test
In testing, you must
– detect unusual behavior 发现不正常的行为
– determine what the test program was doing 确定测试程序的运行状况
– find where the problem is in the program 找到问题在程序中的位置
– figure out which defect could cause such behavior 找到产生这种行为的缺陷
This can take a lot of time 这需要很多的时间
With reviews and inspections, you
– follow your own logic 跟随你自己的逻辑
– know where you are when you find a defect 发现一个缺陷时，知道其对应的位置
– know what the program should do, but did not 知道程序应当怎样做却没有做到
– know why this is a defect 知道为什么这是一个缺陷
– are in a better position to devise a correct fix 处于较好的设计纠正措施的位置

74. Defect Removal效率

75. 比较不同的质量控制方法

76. Reviewing Before Compile
When your development environment has a compile step, it is more
efficient to do code reviews before compiling
如果开发中有编译的步骤，则在编译前进行code review更为有效
The reasons for this are as follows 原因如下
– Avoid compiler reliability mentally, improve coding quality
从心理上消除对编译器的依赖性，
从心理上消除对编译器的依赖性，从而提高编码的质量
– Review time is about the same before or after compiling
在编译前或者后进行review的时间长度基本相同
– If reviews are done before compiling, compile time is substantially reduced
如果在review后进行编译，编译和测试的时间显著减少
– Programs with many compile defects often have many test defects
有很多编译缺陷的程序往往也会有很多测试缺陷

77. 质量指示器
The PSP/TSP has many useful quality and process-control
measures:
PSP/TSP有很多有用的质量和过程控制度量标准
– Phase Yield
– Review Rate
– defects found per unit of size
缺陷发现密度(发现的缺陷数/规模单元）
– defects injected and removed per hour
每小时注入/移除缺陷数
– A/F Ratio
Appraisal (Review, Inspection)时间和Failure (Unit, Integration, System
Testing)时间之比

78. 质量管理原则
The quality of a software system is determined by the quality of its
worst components
软件系统的质量是由最差组件决定的。
The quality of a software component is governed by the individual who
developed it
软件组件的质量是由开发人员决定的。
The key to quality is the individual developer’s skill, commitment, and
personal process discipline
质量的关键在于开发人员的技能，承诺和纪律。

79. 设计

80. PSP对设计文档的要求
• Operation Specification
• Functional Specification
• Logic Specification
• State Specification

81. Operation Specification

82. Functional Specification

83. Logic Specification

84. State Specification

85. UML设计方法

86. 什么是UML？
• UML是一种Language（语言）
• UML是一种Modeling（建模）Language
• UML是Unified（统一）Modeling Language

87. 建模的目的？
• 把复杂的事务进行抽象
把复杂的事务进行抽象
• 以可视化的形式表现出来
可视化的形式表现出来
• 以帮助理解和沟通
以帮助理解和沟通
• 作为生产的基础
作为生产的基础

88. UML建模图形分类
• 业务需求建模
• 静态结构建模
• 交互行为建模
• 动态行为建模
• 物理实现建模
• 模型组织

89. UML建模图形 - 1
• 业务需求建模
– 活动图 （Activity Diagram）
）
• 类似于流程图，描述业务/程序流程和逻辑
– 用例图（Use Case Diagram）
用例图（ ）
• 描述用户需求，表达用户和系统的交互
• 静态结构建模
– 类图（Class Diagram）
类图（ ）
• 描述类的方法和属性、以及类与类之间的关系
– 对象图（Object Diagram）
• 类图在某一时刻的快照

90. UML建模图形 - 2
• 交互行为建模
– 顺序图（Sequence Diagram）
顺序图（ ）
• 重点在对象间消息传递的时间顺序
– 通信图（Communication Diagram）
• UML 2 新增，原协作图，重点在对象间的连接
– 交互概览图 （Interactive Overview Diagram）
• 顺序图和活动图的结合，将活动图中的某些活动以顺序图表
示
– 复合结构图 （Composite Structure Diagram）
• UML 2新增，描述模块间的静态和交互关系

91. UML建模图形 - 3
• 动态行为建模
– 状态机图 （State Chart Diagram）
）
• 描述对象的不同状态对不同消息的不同响应
– 定时图（Timing Diagram）
• 描述对象各状态之间迁移的定时约束

92. UML建模图形 - 4
• 物理实现建模
– 组件图（Component Diagram）
• 描述组件，以及各组件之间的关系
– 部署图（Deployment Diagram）
• 描述系统运行时资源的物理分布
• 模型组织
– 包图（Package Diagram）
• 描述模型的层次结构

93. UML建模过程
Modeling Steps Output
Business Modeling Activity Diagram, Business Use Case Diagram
System Modeling Use Case Diagram, Component Diagram,
Deployment Diagram , Package Diagram
Static Modeling (iterative 1) Class Diagram, Object Diagram, Composite
Structure Diagram
Interactive Modeling (iterative 2) Sequence Diagram, Communication Diagram,
Interactive Overview Diagram
Behavior Modeling (iterative 3) State Chart Diagram, Timing Diagram
Verify the Models Rules, logics and consistencies check results，
Animation

94. TSP介绍

95. TSP核心内容
• TSP Launch
• TSP Team
• TSP Coach
• TSP Data

96. TSP Launch
Day 1 Day 2 Day 3 Day 4
1. Establish 4. Build top-
7. Conduct 9. Hold
product and down and
risk management
business next-phase
assessment review
goals plans
8. Prepare
2. Assign roles 5. Develop
management Launch
and define the quality
briefing and postmortem
team goals plan
launch report
3. Produce 6. Build bottom-
development up and
strategy consolidated
and process plans

97. TSP Team
Built by PSP trained engineers

98. TSP Coach
•Lead the TSP Launch
•Weekly review the TSP project data
•Lead the project postmortem

99. TSP Data
•Automatically consolidated from PSP data
•Automatically generated by TSP tools
•Used to monitor the project
•Weekly reviewed by the TSP team

100. THA
NK Y
谢谢 OU!
！
Software Engineering Methodology Practices
Simple Efficient Measurable Practical
http://semp.wikispaces.com
Semp.salon@gmail.com
Version 1.00, page 100