推荐一本个人认为比较经典的软件工程书籍:
个体软件过程 - Introduction to the Personal Software Process
-[美]Watts S.Humphrey 著
-吴超英 车向东 译
-人民邮电出版社
-ISBN:7-115-09650
-页数:224
-尺寸:1/16
-印张:
-字数:365千字
为什么要推荐这本书?先来看看这边书的大致结构吧。
目录
第1章 软件工程师的任务 1
1.1 什么是软件工程 1
1.2 为什么工程质量很重要 1
1.3 个体软件过程 2
1.4 高质量工作的规范 2
1.5 高质量工作的重要性 3
1.6 如何提高工作质量 3
1.7 过程改进的步骤 4
1.8 本书的策略 5
1.9 总结 5
1.10 练习1 5
第2章 时间管理 7
2.1 时间管理的逻辑原理 7
2.2 了解时间的使用情况 8
2.3 工程记事本 9
2.4 工程记事本的设计 9
2.5 工程记事本示例 10
2.6 总结 12
2.7 练习2 13
第3章 时间跟踪 15
3.1 为什么要跟踪时间 15
3.2 记录时间数据 15
3.3 跟踪时间 16
3.4 使用标准的时间记录日志 17
3.5 处理中断 19
3.6 跟踪已完成的任务 19
3.7 在工程记事本中登记时间日志 21
3.8 时间记录的提示 21
3.9 总结 22
3.10 练习3 22
第4章 阶段计划与产品计划 23
4.1 阶段计划和产品计划 23
4.2 周活动总结表 24
4.3 总结每周的时间分配 26
4.4 计算阶段时间和工作效率 28
4.5 使用周活动总结表 32
4.6 总结 32
4.7 练习4 33
第5章 产品计划 35
5.1 产品计划的必要性 35
5.2 产品计划的用途 35
5.3 什么是产品计划 36
5.4 产品计划 36
5.5 制订小型任务的计划 37
5.6 术语定义 37
5.7 作业编号日志 37
5.8 关于使用作业编号日志的几点建议 42
5.9 使用产品的时间和效率数据 42
5.10 总结 43
5.11 练习5 43
第6章 产品规模 45
6.1 产品计划过程 45
6.2 规模测量 45
6.3 使用规模测量的注意事项 46
6.4 程序规模 47
6.5 其它的规模测量方法 49
6.6 程序规模估计 49
6.7 较大规模的估计 50
6.8 在作业编号日志中使用规模测量的方法 55
6.9 总结 56
6.10 练习6 56
第7章 管理好时间 57
7.1 时间管理的要素 57
7.2 活动分类 57
7.3 收集活动的时间数据 58
7.4 时间分配的评价 58
7.5 作出时间安排 58
7.6 找出更多的时间 60
7.7 制订基本规则 61
7.8 设定时间分配的优先级 64
7.9 管理好时间安排 66
7.10 关于管理可变动的时间的几点建议 67
7.11 时间管理的目标 67
7.12 总结 68
7.13 练习7 68
第8章 契约的管理 69
8.1 什么是契约 69
8.2 认真制订契约 70
8.3 契约的一个示例 71
8.4 工业中的示例 72
8.5 处理没有完成的契约 73
8.6 管理契约的重要性 73
8.7 不对契约进行管理的后果 74
8.8 管理契约的方法 75
8.9 总结 75
8.10 练习8 76
第9章 进度管理 77
9.1 进度管理的必要性 77
9.2 gantt图 78
9.3 制订项目进度表 79
9.4 检查点 79
9.5 跟踪项目计划 81
9.6 跟踪积分 83
9.7 总结 86
9.8 练习9 86
第10章 项目计划 89
10.1 项目计划的必要性 89
10.2 项目计划总结表 89
10.3 项目总结 92
10.4 程序规模 93
10.5 开发阶段的时间 95
10.6 估计的准确性 97
10.7 总结 97
10.8 练习10 97
第11章 软件开发过程 99
11.1 为什么使用过程 99
11.2 一些定义 99
11.3 过程脚本 100
11.4 检查点和阶段 102
11.5 更新的项目计划总结表 102
11.6 一个计划的示例 105
11.7 累计时间值计算的示例 109
11.8 总结 111
11.9 练习11 112
第12章 缺陷 113
12.1 什么是软件质量 113
12.2 缺陷和质量 113
12.3 什么是缺陷 114
12.4 缺陷与bug 115
12.5 缺陷类型 116
12.6 了解缺陷 117
12.7 缺陷记录日志 117
12.8 统计缺陷个数 120
12.9 使用缺陷记录日志 121
12.10 更新的psp过程 122
12.11 总结 127
12.12 练习12 128
第13章 缺陷查找技术 129
13.1 个人对产品质量的承诺 129
13.2 发现缺陷的步骤 129
13.3 发现和修复缺陷的方法 130
13.4 代码复查 131
13.5 为什么要尽早发现缺陷 131
13.6 发现和修复缺陷的费用 132
13.7 利用代码复查发现缺陷 133
13.8 编译前的复查 135
13.9 编译与测试缺陷的数据 135
13.10 更新后的psp项目计划总结表 136
13.11 其它种类的代码复查 141
13.12 总结 142
13.13 练习13 142
第14章 代码复查检查表 145
14.1 检查表的用途 145
14.2 代码复查检查表的示例 146
14.3 使用代码复查检查表 149
14.4 建立个人检查表 149
14.5 改进检查表 153
14.6 编码标准 156
14.7 总结 158
14.8 练习14 159
第15章 缺陷预测 161
15.1 缺陷率 161
15.2 缺陷数据的使用 162
15.3 缺陷密度 163
15.4 缺陷率的预测 163
15.5 缺陷估计 164
15.6 更新的项目计划总结表和示例 165
15.7 登入实际的数据 172
15.8 总结 173
15.9 练习15 173
第16章 缺陷排除的经济效益 175
16.1 高质量工作的必要性 175
16.2 缺陷排除问题 176
16.3 缺陷排除时间 176
16.4 缺陷引入和排除的经验 176
16.5 节省缺陷排除时间 178
16.6 在psp项目计划总结表中每小时缺陷数的计算 179
16.7 缺陷排除效益的计算 183
16.8 提高缺陷排除率 184
16.9 减少缺陷引入率 185
16.10 总结 186
16.11 练习16 186
第17章 设计缺陷 187
17.1 设计缺陷的本质 187
17.2 识别设计缺陷 188
17.3 什么是设计 189
17.4 设计过程 189
17.5 设计缺陷的起因 190
17.6 设计缺陷的影响 191
17.7 设计表达 191
17.8 总结 195
17.9 练习17 195
第18章 产品质量 197
18.1 质量第一 197
18.2 测试 197
18.3 过滤器概念 198
18.4 仔细工作的好处 199
18.5 缺陷排除效益的计算 201
18.6 最终的缺陷排除效益的估计 202
18.7 100%过程效益的好处 203
18.8 缺陷排除效益的经验 203
18.9 原型方法 205
18.10 总结 205
18.11 练习18 206
第19章 过程质量 207
19.1 过程测量 207
19.2 缺陷排除中的矛盾 207
19.3 缺陷排除策略 208
19.4 质量的成本 209
19.5 质量成本的计算 209
19.6 质检/过失比 213
19.7 改进复查的效率 216
19.8 质量成本的精确计算 217
19.9 总结 218
19.10 练习19 218
第20章 个人对质量的承诺 221
20.1 质量的重要性 221
20.2 低质软件的危险正在增长 221
20.3 制订个人质量承诺 222
20.4 个人的目标 223
20.5 成就的回报 223
我的看法:
现在来谈谈我为什么要推荐这本书。应该说一直以来我都是比较关注软件工程的,诸如工程的分析、设计方法,进度管理,代码规范等等。因为我知道,在现在高度发展的社会需求,个人英雄软件的时代早已一去不复返,取而代之是团队和协作。现在越来越多的软件公司也开始重视软件工程的培训和实施,然而我们依然可以看到大量的软件公司的项目都不能按时按量的完成。
为什么?我们知道,软件项目中最重要的指标应该是进度控制和质量管理,我们暂且不谈软件项目的质量如何,就是否能按时完成项目的这个问题也让许多的项目管理人员十分头疼,为什么?因为一个项目的按时完成与项目开发人员的素质有直接的关系。在一个项目投入运行初期,项目负责人及系统分析人员需要对系统做需求分析,设计并估算项目开发周期,制定项目开发计划。而这个开发周期的估算往往并不准确,原因也就是因为开发人员的个人素质是不相同的,这样所组成的团队的开发能力也是不一样的,因此如何科学的衡量一个团队的开发能力显得尤为重要。
个体软件过程这本书就是从个体程序员的角度去分析、探讨和建议个体程序员如何实施软件过程,分别从时间管理、阶段计划、进度管理、项目计划、缺陷管理、产品质量等方面入手,全面的分析和解决了目前个体程序员所面对的软件工程问题。
最近我也正是因为需要自己来制定半年的开发计划,所以我才想起重新温习这本我两年前所买的书,希望用它来指导我后续的工作。好了,暂时说到这里,欢迎大家关于与我一同讨论和体验软件工程给我们工作和生活所带来的乐趣。:)
兄弟归纳的不错,我也正在学习PSP,很多思想不错,但是使用得时候却不能完全照搬,很多东西对于目前中国的开发形式下都太理想化了,比如对project的size estimate就感觉不太适用
回复:不错,的确有些东西太过与理想化了,而且有些思想运用起来也比较繁琐。但不管怎样,如果真能在实际开发中采用或者改进一些方法,那对于我们的工作可能是受益终身的,我也是一直在体验中学习。^_^
你是熊吗??哈哈
^_^,我不知道该如何回答兄弟了,这只是个人喜好而已,不用研究吧。