国内IT企业长期面临着软件产品质量低下、进度延误、费用超支等难题,究其根源,是由于企业在软件工程与项目管理领域的能力不足所致。\r\n\r\n本书深入阐述软件工程与项目管理的原理,把追求企业利益最大化这个根本目标分解到软件工程与项目管理的诸多实践之中。旨在帮助软件人员理解“是什么、为什么和怎么办”这些基本问题,使他们能够自然而然地将软件工程与项目管理方法应用于产品开发过程之中,从而达到“提高质量、提高效率和降低开发成本”的目的。\r\n\r\n本书的主要读者对象是IT企业的研发主管、项目经理和软件开发人员,以及即将到IT企业工作的高校毕业生。本书可以作为软件学院的教学参考书。\r\n
\r\n
第1章 新视野:企业—产品—人 1 \r\n\r\n 1.1 软件危机新理解 2 \r\n\r\n 1.2 企业—产品—人 3 \r\n\r\n 1.3 企业的根本目标 5 \r\n\r\n 1.3.1 观点和论断 5 \r\n\r\n 1.3.2 案例与评论 7 \r\n\r\n 1.3.3 推论 9 \r\n\r\n 1.4 产品开发之道 10 \r\n\r\n 1.4.1 开发正确的产品 10 \r\n\r\n 1.4.2 正确地开发产品 11 \r\n\r\n 1.5 用人之道 15 \r\n\r\n 1.5.1 如何组建软件开发团队 15 \r\n\r\n 1.5.2 如何管理软件开发团队 20 \r\n\r\n 1.6 漫谈软件白领 23 \r\n\r\n 1.6.1 软件白领的概念 23 \r\n\r\n 1.6.2 软件白领的生活现状 24 \r\n\r\n 1.6.3 软件白领的前途 25 \r\n\r\n 1.7 如何成为优秀的软件人才 27 \r\n\r\n 1.7.1 学习强势知识 28 \r\n\r\n 1.7.2 提高表达能力 34 \r\n\r\n 1.7.3 提高管理能力 39 \r\n\r\n 1.7.4 提升人格魅力 40 \r\n\r\n 1.8 小结 42 \r\n\r\n 思考与练习 43 \r\n\r\n 第2章 立项管理和结项管理 45 \r\n\r\n 2.1 什么是立项管理 46 \r\n\r\n 2.2 立项建议 47 \r\n\r\n 2.2.1 规程介绍 47 \r\n\r\n 2.2.2 产品构思 48 \r\n\r\n 2.2.3 立项调查 48 \r\n\r\n 2.2.4 如何撰写立项建议书 49 \r\n\r\n 2.3 可行性分析 52 \r\n\r\n 2.3.1 为什么要进行可行性分析 52 \r\n\r\n 2.3.2 市场可行性分析 53 \r\n\r\n 2.3.3 政策可行性分析 53 \r\n\r\n 2.3.4 技术可行性分析 54 \r\n\r\n 2.3.5 成本收益分析 55 \r\n\r\n 2.3.6 SWOT分析 56 \r\n\r\n 2.4 立项评审 57 \r\n\r\n 2.4.1 角色职责 57 \r\n\r\n 2.4.2 如何评审 58 \r\n\r\n 2.5 项目筹备 61 \r\n\r\n 2.6 结项管理 62 \r\n\r\n 2.6.1 什么是结项管理 62 \r\n\r\n 2.6.2 结项管理的流程 62 \r\n\r\n 2.7 小结 65 \r\n\r\n 思考与练习 66 \r\n\r\n 第3章 项目规划与项目监控 67 \r\n\r\n 3.1 项目规划的概念 68 \r\n\r\n 3.2 如何进行项目估计 69 \r\n\r\n 3.2.1 数学模型真的好用吗 69 \r\n\r\n 3.2.2 简单直观的估计方法 70 \r\n\r\n 3.3 制定项目计划 73 \r\n\r\n 3.4 项目计划审批 75 \r\n\r\n 3.5 项目计划变更控制 76 \r\n\r\n 3.6 Future项目规划工具介绍 77 \r\n\r\n 3.7 如何有效地监控项目 83 \r\n\r\n 3.7.1 为什么要进行项目监控 83 \r\n\r\n 3.7.2 任务进度监控 84 \r\n\r\n 3.7.3 项目开支监控 84 \r\n\r\n 3.7.4 人员业绩记录 85 \r\n\r\n 3.7.5 软硬件资源监控 85 \r\n\r\n 3.7.6 风险管理 86 \r\n\r\n 3.7.7 项目进展报告 87 \r\n\r\n 3.8 Future项目监控工具介绍 87 \r\n\r\n 3.9 小结 94 \r\n\r\n 思考与练习 94 \r\n\r\n 第4章 需求开发与需求管理 95 \r\n\r\n 4.1 什么是需求 96 \r\n\r\n 4.1.1 基本概念 96 \r\n\r\n 4.1.2 需求案例 96 \r\n\r\n 4.2 了解用户 98 \r\n\r\n 4.3 需求工程 99 \r\n\r\n 4.3.1 基本概念 99 \r\n\r\n 4.3.2 一些感悟 103 \r\n\r\n 4.4 需求开发的主要困难与对策 104 \r\n\r\n 4.4.1 知识技能问题 104 \r\n\r\n 4.4.2 态度问题 104 \r\n\r\n 4.4.3 合作关系 105 \r\n\r\n 4.4.4 用户说不清楚需求 107 \r\n\r\n 4.4.5 双方误解需求 107 \r\n\r\n 4.4.6 开发人员写不好需求文档 108 \r\n\r\n 4.4.7 用户经常变更需求 108 \r\n\r\n 4.5 如何开展需求调查 109 \r\n\r\n 4.5.1 需求调查规程 109 \r\n\r\n 4.5.2 准备调查 109 \r\n\r\n 4.5.3 调查与记录 110 \r\n\r\n 4.5.4 撰写用户需求说明书 111 \r\n\r\n 4.6 如何进行需求分析 114 \r\n\r\n 4.6.1 问答分析法 114 \r\n\r\n 4.6.2 建模分析法 115 \r\n\r\n 4.6.3 做出决策 117 \r\n\r\n 4.7 什么是好的产品需求规格说明书 118 \r\n\r\n 4.7.1 正确 118 \r\n\r\n 4.7.2 清楚 118 \r\n\r\n 4.7.3 无二义性 118 \r\n\r\n 4.7.4 一致 119 \r\n\r\n 4.7.5 必要 119 \r\n\r\n 4.7.6 完备 120 \r\n\r\n 4.7.7 可实现 120 \r\n\r\n 4.7.8 可验证 120 \r\n\r\n 4.7.9 确定优先级 121 \r\n\r\n 4.7.10 阐述“做什么”而不是“怎么做” 121 \r\n\r\n 4.8 如何定义产品需求 121 \r\n\r\n 4.8.1 规程 121 \r\n\r\n 4.8.2 软件需求规格说明书的模板 123 \r\n\r\n 4.9 需求确认 125 \r\n\r\n 4.9.1 规程 125 \r\n\r\n 4.9.2 需求评审 126 \r\n\r\n 4.9.3 需求承诺 129 \r\n\r\n 4.10 需求跟踪 130 \r\n\r\n 4.11 需求变更控制 132 \r\n\r\n 4.12 Future需求管理工具介绍 134 \r\n\r\n 4.13 小结 137 \r\n\r\n 思考与练习 138 \r\n\r\n 第5章 软件系统设计 139 \r\n\r\n 5.1 软件系统设计的核心内容 140 \r\n\r\n 5.2 漫谈设计模式 142 \r\n\r\n 5.3 体系结构设计 145 \r\n\r\n 5.3.1 体系结构设计原则 145 \r\n\r\n 5.3.2 体系结构设计的规程与模板 149 \r\n\r\n 5.3.3 谈谈层次结构 152 \r\n\r\n 5.4 用户界面设计 155 \r\n\r\n 5.4.1 什么是好的用户界面 155 \r\n\r\n 5.4.2 用户界面设计原则 157 \r\n\r\n 5.4.3 用户界面设计的规程与模板 162 \r\n\r\n 5.4.4 示例及详细的设计规则 165 \r\n\r\n 5.5 数据库设计 172 \r\n\r\n 5.5.1 数据库设计的主要困难与对策 172 \r\n\r\n 5.5.2 数据库设计的规程与模板 175 \r\n\r\n 5.6 模块设计 180 \r\n\r\n 5.6.1 何为“模块”与“模块化” 180 \r\n\r\n 5.6.2 模块设计原则 181 \r\n\r\n 5.6.3 模块设计的规程与模板 184 \r\n\r\n 5.7 数据结构与算法设计理念 187 \r\n\r\n 5.8 小结 189 \r\n\r\n 思考与练习 189 \r\n\r\n 第6章 软件实现 191 \r\n\r\n 6.1 软件实现的流程 192 \r\n\r\n 6.2 准备工作 193 \r\n\r\n 6.2.1 要准备什么 193 \r\n\r\n 6.2.2 制定计划 193 \r\n\r\n 6.2.3 制定编程规范 196 \r\n\r\n 6.2.4 技术攻关 197 \r\n\r\n 6.3 对编程的建议 198 \r\n\r\n 6.3.1 尽可能采用成熟可靠的技术 198 \r\n\r\n 6.3.2 对代码进行单步跟踪调试 199 \r\n\r\n 6.3.3 写工作日记 199 \r\n\r\n 6.3.4 源代码的版本管理 201 \r\n\r\n 6.3.5 正常作息 202 \r\n\r\n 6.4 代码审查 202 \r\n\r\n 6.5 开发小组内部测试 204 \r\n\r\n 6.6 调试改错的方法 205 \r\n\r\n 6.7 完善性工作 207 \r\n\r\n 6.8 小结 208 \r\n\r\n 思考与练习 208 \r\n\r\n 第7章 软件测试 209 \r\n\r\n 7.1 测试的常识与道理 210 \r\n\r\n 7.1.1 你真的懂测试吗 210 \r\n\r\n 7.1.2 为什么需要测试 211 \r\n\r\n 7.1.3 测试的目的是什么 212 \r\n\r\n 7.1.4 一些常识和经验之谈 213 \r\n\r\n 7.2 测试的分类与比较 213 \r\n\r\n 7.2.1 测试的分类及关系图 213 \r\n\r\n 7.2.2 黑盒测试与白盒测试的比较 216 \r\n\r\n 7.2.3 有了黑盒测试为什么还要白盒测试 216 \r\n\r\n 7.2.4 单元测试 217 \r\n\r\n 7.2.5 集成测试 218 \r\n\r\n 7.2.6 系统测试 219 \r\n\r\n 7.2.7 验收测试 219 \r\n\r\n 7.2.8 回归测试 220 \r\n\r\n 7.3 测试人员的组织 221 \r\n\r\n 7.3.1 Microsoft公司的经验教训 221 \r\n\r\n 7.3.2 测试心理学 222 \r\n\r\n 7.3.3 如何组织测试人员 222 \r\n\r\n 7.3.4 避免开发人员与测试人员产生矛盾 223 \r\n\r\n 7.4 企业的测试策略 224 \r\n\r\n 7.4.1 一些指导方针 224 \r\n\r\n 7.4.2 如何合理地减少测试工作量 224 \r\n\r\n 7.4.3 测试何时结束 226 \r\n\r\n 7.4.4 需求经常变更怎么办 227 \r\n\r\n 7.4.5 奖励机制 227 \r\n\r\n 7.5 测试规范 228 \r\n\r\n 7.5.1 流程图 228 \r\n\r\n 7.5.2 测试的“启动准则”和“完成准则” 228 \r\n\r\n 7.5.3 测试计划 229 \r\n\r\n 7.5.4 测试用例 232 \r\n\r\n 7.5.5 测试报告 233 \r\n\r\n 7.6 软件系统的主要测试内容及技术 235 \r\n\r\n 7.6.1 接口与路径测试 235 \r\n\r\n 7.6.2 功能测试 239 \r\n\r\n 7.6.3 健壮性测试 242 \r\n\r\n 7.6.4 性能测试 244 \r\n\r\n 7.6.5 用户界面测试和评估 246 \r\n\r\n 7.6.6 信息安全性测试 251 \r\n\r\n 7.6.7 压力测试 252 \r\n\r\n 7.6.8 可靠性测试 254 \r\n\r\n 7.6.9 安装/反安装测试 255 \r\n\r\n 7.7 小结 257 \r\n\r\n 思考与练习 257 \r\n\r\n 第8章 软件维护 259 \r\n\r\n 8.1 什么是软件维护 260 \r\n\r\n 8.2 影响软件维护代价的主要因素 260 \r\n\r\n 8.3 怎样进行软件维护 262 \r\n\r\n 8.4 再生工程 264 \r\n\r\n 8.4.1 什么是再生工程 264 \r\n\r\n 8.4.2 重构 265 \r\n\r\n 8.4.3 逆向工程 265 \r\n\r\n 8.4.4 前向工程 266 \r\n\r\n 8.5 小结 266 \r\n\r\n 思考与练习 266 \r\n\r\n 第9章 软件质量管理 267 \r\n\r\n 9.1 软件的质量属性和质量要素 268 \r\n\r\n 9.2 商业目标决定质量目标 270 \r\n\r\n 9.3 质量保证能够保证质量吗 271 \r\n\r\n 9.4 质量人员的状况 272 \r\n\r\n 9.4.1 郁闷的质量人员 272 \r\n\r\n 9.4.2 路在何方 274 \r\n\r\n 9.4.3 赞美诗 275 \r\n\r\n 9.5 全面软件质量管理 277 \r\n\r\n 9.5.1 模型 277 \r\n\r\n 9.5.2 质量人员的职责 278 \r\n\r\n 9.5.3 质量管理计划 279 \r\n\r\n 9.5.4 技术评审 281 \r\n\r\n 9.5.5 软件测试 284 \r\n\r\n 9.5.6 过程检查 285 \r\n\r\n 9.5.7 缺陷跟踪工具 286 \r\n\r\n 9.6 Future质量管理工具介绍 287 \r\n\r\n 9.7 小结 292 \r\n\r\n 思考与练习 293 \r\n\r\n 第10章 软件配置管理 295 \r\n\r\n 10.1 什么是软件配置管理 296 \r\n\r\n 10.2 为什么需要软件配置管理 297 \r\n\r\n 10.3 人的问题 298 \r\n\r\n 10.4 软件配置管理规范 299 \r\n\r\n 10.4.1 概念与流程 299 \r\n\r\n 10.4.2 配置管理计划 300 \r\n\r\n 10.4.3 版本控制规则 302 \r\n\r\n 10.4.4 变更控制规则 303 \r\n\r\n 10.4.5 配置库操作 304 \r\n\r\n 10.4.6 配置审计 305 \r\n\r\n 10.5 常用配置管理工具 305 \r\n\r\n 10.5.1 SourceSafe 305 \r\n\r\n 10.5.2 CVS 307 \r\n\r\n 10.5.3 ClearCase 308 \r\n\r\n 10.5.4 Future配置管理工具介绍 309 \r\n\r\n 10.6 小结 310 \r\n\r\n 思考与练习 310 \r\n\r\n 第11章 软件外包管理 311 \r\n\r\n 11.1 软件外包管理流程 312 \r\n\r\n 11.2 选择承包商 312 \r\n\r\n 11.3 签订外包合同 315 \r\n\r\n 11.4 监控外包开发过程 316 \r\n\r\n 11.5 成果验收 317 \r\n\r\n 11.6 Future合同管理工具介绍 319 \r\n\r\n 11.7 小结 320 \r\n\r\n 思考与练习 321 \r\n\r\n 参考文献 323 \r\n
\r\n
写作背景
我国大多数IT企业长期面临着软件产品质量低下. 进度延误. 费用超支等难题, 人们把解决这个难题的方法和实践称为软件过程改进(Software Process Improvement, SPI).
软件过程改进的根本目标是提高产品质量. 提高开发效率. 降低开发成本. 从20世纪90年代至今, 软件过程改进成为软件工程学科的一个主流研究方向, 其中CMM/CMMI是该领域举世瞩目的重大成果.
近几年来, 国内CMM/CMMI的培训. 推广. 认证持续升温. 我经常参加相关的研讨会, 听到的官方报道总是正面的. 鼓舞人心的. 而我从广大第一线软件开发人员. 项目经理. 质量人员那里得到的信息却是令人沮丧的:
自从公司搞了CMM后, 产品质量没见明显提高, 进度倒是更加延误了, 成本增加了, 人员也更累了. 人们除了学会一堆概念外, 并没有得到实质性的好处.
错误不在于CMM, 是人们以错误的方式使用CMM, 得到了失败的结果.
CMM的知识框架是原创性的(例如成熟度等级. 过程域概念等), 但是它所建议的大部分实践则取材于经典的软件工程与项目管理, 却没有把软件工程与项目管理阐述透彻. 例如CMM第三等级有个关键过程域叫软件产品工程, 让你看了一头雾水, 简直不知如何下手.
尽管CMM是评估软件过程能力的参考标准, 但它本身却是糟糕的工程与管理参考书. 可以把CMM比喻为英语考试大纲, 考试大纲虽然可以评估英语能力, 但是并不能帮助学生真正有限地提高英语能力. 很多软件工程师和项目经理实在难以理解CMM, 只好生吞活剥, 对照CMM的过程域和关键实践一个一个地遍历. 我也曾经干过这样的蠢事, 这哪是产品开发之道啊, 焉有不败之理.
企业的根本目标是合法地赚取尽可能多的利润, 使企业利益最大化. 企业所有的特定目标和行动都是围绕上述根本目标开展的, 任何背离根本目标的行动都将对企业造成伤害, 应当杜绝.
令人遗憾的是, 不论是CMM还是ISO 9000系列都闷头讲“过程与质量”, 根本不讲怎样做才能使企业利益最大化, 怎样权衡“质量. 效率和成本”, 注定要遭遇重重困难. 同样的问题也存在于软件工程与项目管理教科书中.
软件工程师和项目经理们读了很多书, 掌握了许多技能, 却不知道“什么是赚钱的产品, 怎样使产品做得好. 做得快, 并且少花钱”.
IT职业似乎在国内很吃香, 但举目望去, 大部分IT白领其实都是穷人, 光是住房问题就压得无数人一辈子喘不过气来. 许多才华出众. 勤劳工作的IT白领没有真正脱贫致富, 揭示了一个广泛存在的问题:
中国高科技产业最大的悲哀莫过于大批掌握科学技术的人才缺乏商业头脑, 不懂得把知识转化为财富, 长期沦落为卖苦力的打工仔.
因此, 为了脱贫致富, 我们应该时不时地洗洗脑子, 提高自己的商业才能.
软件工程和项目管理是成熟的学科, 我并不想添加一本无聊的纸上谈兵的著作, 因此要标新立异. 本书最大的特色是:把追求企业利益最大化这个根本目标分解到软件工程与项目管理的诸多实践之中, 大谈赚钱和省钱的思想方法. 我还写了一句广告词“将商业智慧引入软件工程与项目管理, 为企业创造更多的经济效益. ”
我曾在网上公布了部分章节, 不少读者写信告诉我:“看了文章后很震惊, 因为发现自己一直以错误的方式工作和生活”.
本书大多数内容都是作者亲身验证过后总结出来的, 将给多数读者带来有益的震撼. 敬请读者首先敞开心扉阅读, 然后进行大脑风暴, 吸取精华, 摒弃糟粕.
研究历程
2000年7月我从浙江大学博士毕业, 加入上海贝尔有限公司(现改名为上海贝尔阿尔卡特股份有限公司), 至今一直从事软件工程. CMM/CMMI. 企业研发管理流程的研究与推广工作.
在读硕士时, 我愤慨于大学科研机构弄虚作假, 而立誓“做一名诚实. 正直. 优秀的科技人员”, 这誓言写入我的档案之中. 可惜我在读博士期间荒废了几年青春, 博士毕业的时候虽然拿了不少奖状, 颇有虚名, 但无多少真才实学, 充其量只是硕士水平而已.
我刚到公司时, 很多年轻的员工们恭敬地叫我“林博士”, 甚至还有一些年轻人特意来看看我这个“好榜样”, 我感到非常羞耻. 因此我给自己树立了短期目标:踏踏实实地工作, 在实践中提升自己的学问, 三年内成为国内最好的软件工程专家.
2001年初, 我在网络应用事业部成立了6人的SEPG, 全职研究与推广CMM. 我和很多同行交流时发现, 上海贝尔面临的软件工程与项目管理问题在很大程度上代表了国内IT业界的共性问题. 2001年10月, 我构思了一套切合国情的软件过程改进解决方案(Software Process Improvement Solution, SPIS).
SPIS的目标是帮助国内IT企业以比较低的代价将软件能力提升到CMMI 3级水平, 其核心内容分两块:一是软件过程改进方法论, 二是配套的软件工具. 国内有成千上万家IT企业, 我相信SPIS有很大的市场需求, 于是向公司申请立项. 但是该立项建议被否决, 因为SPIS并不符合上海贝尔的产品发展战略.
2002年初, 网络应用事业部解体, 我调到CTO部门工作, 此后再也没有人员可供我调用了. 我就在这种状况下独立创作SPIS, 白天上班, 晚上回家组织一些志同道合的朋友干活. 这样的工作生活有一年半多了, 比较劳累而且愁心, 可以说没有舒坦过一天. 令我欣慰的是具有实用价值的成果不断产生:
(1)在2002年内, 我创作完成通用的“CMMI 3级软件过程改进方法与规范”, 命名为“精简并行过程”(Simplified Parallel Process, SPP). SPP模型见彩图1, 它包含19个过程域. 40余个规程. 60多个文档模板, 我大约写了500多页文档. 电子工业出版社在2003年1月出版了该书, 已经有不少企业采用了SPP, 给我发来感谢信. 我或多或少有了一些成就感.
(2)集成化项目管理系统Future 1.0将在2003年10月推出. Future是与SPP配套的管理系统, 它将项目规划. 项目监控. 需求管理. 质量管理. 配置管理. 合同管理. 日常工作管理等功能集成在Web环境之中(参见彩图2), 帮助企业降低管理难度. 提高管理效率. 开发Future不是我一个人做得了的事情, 由于缺人缺钱, 开发进程曾经被中断几次, 所幸最近有生力军加入, 得以顺利实现.
(3)《软件工程与项目管理解析》将在2003年10月出版, 它不仅对SPP作了补充解释, 进一步完善了SPIS方法论. 最大的贡献是围绕企业利益最大化这个目标阐述软件工程与项目管理的原理, 将指导许多软件人员学会以正确的方式开发产品.
我建立了软件过程改进解决方案网站http://www.chinaspis.com, 研究成果将及时在网站上发布, 目前已经有数万次访问量, 正逐渐被用户了解和接受.
三年来上海贝尔发生了几次重大变革, 我是“两耳不闻窗外事. 一门心思做学问”, 这种做法对于我在公司的职业发展很不利. 我的学问在不断增长, 同时职位与薪资却在下降, 压力和感受很难用语言表达. 为了实现自己的目标, 我真的在和时间赛跑, 我暂时赢了.
2003年7月, 公司首批9名专家当选为Alcatel集团技术委员会会员(Member of Alcatel Technical Academy, ALTA), 我是其中之一. ALTA会员是Alcatel集团授予为保持全球技术领先地位做出突出贡献的技术专家的荣誉和资格. 说来巧合, 时间刚好是3年, 这个ALTA证书就当做是我实现了自己短期目标的见证吧. 我也该重新规划职业发展计划了.
5年前我常把“振兴民族软件产业”挂在嘴上, 第一次创业失败后, 我基本上不再喊动听的口号了, 但是理想从未泯灭. 自从前几年网络泡沫破裂后, 风险投资机构变得非常谨慎, 创业人士可谓四处碰壁. 我越发体会到“只有真正给用户带来利益的软件商品才有市场价值, 才可能存活并持续发展”. 为了使自己具备卓越的核心竞争力, 我有足够的耐心让自己继续沉淀, 在忧患之中奋进, 直至第二次创业成功.
无封面