《软件工程初级教程》汇总了作者多本教材的精华，融入了多年的教学经验，吸收了软件工程学科较新内容编写而成。在内容和体系结构上都有了新的调整和补充，不失为一本实用教材。软件工程内容分为软件工程管理和软件工程技术两大部分。传统的教材把理论部分放在前面，工程技术部分放在中间，最后介绍软件工程管理内容，这样往往在教学中会忽略软件工程管理部分的内容，使教学过程不好安排。本教材在体系上做了一些调整，将软件工程理论和软件工程管理部分的内容放在前面，逐步由理论深入到实践，连贯性较强； 避免了进入软件工程技术甚至实践部分以后，再回头讲软件工程管理内容时，教学过程不易组织。本教材在介绍了软件工程基本概念和原理的基础上，着重对从结构化方法到面向对象方法的过渡进行了合理安排，强调从方法论和软件工程思想的角度理解这种过渡，指出了结构化方法的优点、缺陷和面向对象方法的优势，并从内容上加大了面向对象方法的比重。书中安排了贯穿全程的实例，通过面向对象的建模过程实践，使得针对面向对象的方法的教学过程更具有可操作性。课程进行到后半学期，对于面向对象的部分可以安排适当的上机实践，本教材对这一部分提供了较详细的建模操作实例。《软件工程初级教程》实例丰富，注重对学生实践能力的培养，对初次开设软件工程课程的计算机及相关专业本科层次、大专层次都适用。

如果说“四人帮”的《设计模式》是设计模式领域的“圣经”，那么之后出版的各种关于设计模式的书都可称之为“圣经”的“注释版”或“圣经的故事”。《设计模式之禅》是得道者对“圣经”的“禅悟”，它既不像“圣经”那样因为惜字如金、字字珠玑而深奥、晦涩和难懂，又比“圣经”的“注释版”更深刻和全面、更通俗和生动、更接近开发者遇到的实践场景，更具指导性。《设计模式之禅》兼收并蓄、博采众长，也许是设计模式领域里的下一个里程碑之作。全书共分为四部分，第一部分从原理的角度阐述了面向对象程序设计的6大原则；第二部生动地讲解和剖析了23种常见的设计模式，并进行了扩展，通俗易懂，趣味性极强而又紧扣模式的核心；第三部分对各种相关联的设计模式进行了深入分析和比较，旨在阐明各种设计模式比较理想的应用场景和它们之间的区别；第四部分探讨了设计模式的混编，讲解了如何在实际开发中将各种设计模式混合起来使用，以发挥设计模式的最大效用。最后，《设计模式之禅》还附有一份设计模式彩图，可以裁剪，便于参考。禅宗曰：“教外别传，不立文字”，禅的境界本不该用文字来描述，言语也道不明白，但为了传道，悟道者仍要藉言语来说明。何为禅？一种境界，一种体验，一种精神领域的最高修为。何为设计模式？对面向对象思想的深刻理解，对软件设计方法和编码经验的完美总结。《设计模式之禅》是创造者的心路历程，是实践者的智慧结晶，是得道者的禅悟。它通过幽默风趣的故事和通俗易懂的讲述方式，引导你悟透设计模式的真谛。如果你在思考下面这些问题，也许《设计模式之禅》就是你想要的！1.业务分析如此细致，架构设计如此健壮、可靠和稳定，但为何仍然无法适应业务发展的需要，而且生命周期只有短短几年？2.为何你的团队协作了多年却始终无法沉淀出可复用的组件或构件？依赖和解耦的标准是什么？如何才能做到既不相互“刺伤”，又能相互“温暖”？3.架构设计时，如何才能实现高可扩展性和易维护性？如何避免维护成本大于开发成本的悲哀现状？4.交易型的系统如何大规模地借用设计模式的思想，以实现高性能、高可靠性的建设目标？5.架构设计时，如果遇到这样的情况：“有一个请求者和多个处理者，同时要求二者之间解耦，以便处理者可以动态地扩展”，这该如何处理？6.如果遇到过这样场景：“多个对象依赖一个对象，该对象状态改变时所有的依赖者都要相应地获得通知，并且要求对象间松散耦合”，这该如何处理？7.万物皆对象，不可能把每一个对象都分解到原子级别，如何适度地细化对象的颗粒度？怎样界定对象的粒度大小？8.同为创建类模式，工厂方法模式和建造者模式都可以创建对象，它们之间有何区别？适用的场景又有何不同？9.状态模式和策略模式的通用类图如此相似，在实际的应用场景中如何区分它们？10.如何使命令模式和责任链模式完美搭配并建立一个高可扩展性的系统架构，以解决客户端和处理者都参数化的场景？11.观察者模式和责任链模式真的没有可比性吗？它们的主要区别何在？实际应用中如何使用？12.组合模式只能用来表示部分和整体的关系吗？其扩展出的规格模式是如何实现的？透明的组合模式和安全的组合模式有何区别？

《软件工程概论》内容简介：软件工程学科具有知识面广、发展迅速、实践性强等特点。《软件工程概论》作者针对软件工程的学科特点，在系统讲解软件工程理论、方法和工具的同时，注重结合实例分析软件工程方法、技术和工具的综合应用；在兼顾传统的结构化方法的同时，注重介绍广为采用的面向对象方法。全书内容组织成四部分：第一部分是软件工程概述，第二部分介绍传统的软件开发方法，第三部分讲述面向对象的软件开发方法，第四部分介绍软件维护与软件管理。 《软件工程概论》结构合理、内容丰富，讲解由浅入深，既体现知识点的连贯性、完整性，又体现知识在实际中的应用，适合作为计算机科学与技术、软件工程等专业本科生用教材。

《开源软件之道》将开源运动的前世今生和游戏规则完整地呈现给读者。第一篇帮助大家认识开源，包括其定义、历史、现状、优势、使用成本、商业模型等。第二篇探讨使用开源软件时需要注意的各项具体事宜，特别是与知识产权相关的方面，例如软件著作权、许可证等，然后分享搜索所需开源软件的技巧，并罗列了一些流行的开源软件。第三篇全面介绍如何参与开源社区的工作，引导大家融入开源社区从而探析各个开源软件的技术精髓，深入认识开源文化，提升个人在技术、交流等各方面的能力，希望能帮助提高国内开发人员的整体水平——这对于中国软件行业的发展善莫大焉！《开源软件之道》适合对开源软件感兴趣的人员、IT从业人员、致力于开源健康发展的人员阅读和参考。

谈论软件质量的方法有很多，感兴趣的听众也有很多。本书是为软件测试人员而写的，写的是一种我认为比其他任何缺陷都重要的特殊缺陷：即逃过所有各种检测手段而最终存在于发布产品中的缺陷。　任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的？为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来？为什么自动化测试没有找出它们？那些缺陷有些什么特质使其能逃过手工测试？　什么是找出产品缺陷的最好方法？　本书针对的正是最后一个问题。在第2章“手工测试”中，我提出了一个观点：因为用户是在使用软件过程中找到这些缺陷的，所以我们的测试人员也应该通过使用软件来找到它们。无论使用自动化测试和单元测试，还是其他一些手段，都难以接触到这些缺陷。无论测试人员怎么实现自动化测试，即使全部都自动化，这些缺陷还是会处处作怪，并在产品中屡屡重现从而伤害最终用户。　问题在于很多现代化手工测试实践都缺乏目的性，随机性强且重复性强。有些人可能还会加上一条：手工测试无聊透顶。本书试图为手工测试流程提供一些指导、技术和规划。　在第3章“局部探索式测试法”中，针对测试人员在运行任何一个测试用例时都需要做出很多细微的战术层面决定，我给出了详尽的指导建议。测试人员必须决定对于某个特定的输入字段应该使用什么输入值，或者给应用程序使用的文件提供什么数据。在测试过程中，必须做出许多这样的小决定。在缺乏指导的情况下，这些决定常常是未经分析且不是最优化的。在向一个文本框内输入一个数时，选择整数4难道就胜过整数400么？应该用长度为32字节的字符串还是长度为256字节的字符串？选择一个而不选另一个是有一定道理的，这一切都取决于处理该输入的软件的具体情况。鉴于测试人员每天都要做出数百次这样的小决定，在这里提供有效的指导建议显得至关重要。　在第4章“全局探索式测试法”中，针对测试人员在编制测试计划和测试用例设计时需要考虑哪些广泛的战略性问题，我也给出了一些指导建议。这些技术都基于“漫游测试”（tour）概念，如同一个导游带领旅游团队参观大都市中一系列著名景点一样，这种漫游测试法指出的路线可以指导测试人员如何探索软件的方方面面。这里的探索并不一定是随机的或者漫无目的的。本书所记录的方法已经成为微软和谷歌的许多测试人员日常工作的一部分。诸如“地标测试法”（landmark tour）和“极限测试法”（intellectual’s tour）等词汇已经列入了手工测试人员的标准词汇表中。测试技术以前确实被称作“漫游”，但是用整个旅游业来隐喻软件测试，并在测试实际发布的应用程序时，大规模使用这些隐喻的名称，还属于本书的一个创举。　全局探索式测试法对于制定完整的测试策略给出了指导建议。例如，如何创建一组特性覆盖率（feature coverage）较高的测试用例？如何确定是否要在一个单独的测试用例中使用多个特性？如何创建一个完整的测试用例套件（test case suite），从而使软件尽可能地满负荷工作以便能找到更多重要的缺陷？这些都是设计测试用例和保证测试套件质量时必须解决的重大问题。　在第5章“混合探索测试技术”中，通过把探索式测试和传统的脚本或基于场景的测试技术相结合，进一步扩展了漫游的概念。我们将讨论如何修改各种端到端场景（end-to-end scenario）、测试脚本（test script）或用户故事（user story），来创造更多的变化情况，以激发传统静态测试技术查找缺陷的潜力。　在第6章“探索式测试的实际应用”中，来自微软不同产品组的五位客串作者提供了他们使用漫游技术后得到的经验报告。这些作者和他们的团队在真实的开发环境中，把漫游方法应用在真实的软件上。他们记录了各自是如何使用漫游、修改漫游甚至创建自己的漫游的。这些内容来自于使用漫游法测试重要的关键软件产品的测试人员，属于真正的第一手资料。　最后，我用两章内容总结前面各章所讨论的内容。在第7章“漫游测试的棘手问题”中，描述了我认为的测试中最困难的几个问题，以及如何将那些具有高度针对性的探索式测试方法融入一个更广泛的解决方案中。在第8章“软件测试的未来”中，我更进一步讨论在未来几年中，诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法，收集了我以前一些深受读者喜爱的文章（加入了一些新的注解），其中一些文章已经无法在其他地方看到了。　写这本书对我来说是一种享受，我希望你阅读本书也是一种享受。

《用户故事与敏捷方法》详细介绍了用户故事与敏捷开发方法的结合，诠释了用户故事的重要价值，用户故事的实践过程，良好用户故事编写准则，如何搜集和整理用户故事，如何排列用户故事的优先级，进而澄清真正适合用户需求的、有价值的功能需求。《用户故事与敏捷方法》对于软件开发人员、测试人员、需求分析师和管理者，具有实际的指导意义和重要的参考价值。

本书讲解什么是自动化测试，为什么要进行自动化测试，以及实施自动化测试过程中的各种方法和需要注意的问题。全书分为两部分。在第一部分，作者以自身的经验向我们阐释自动化测试的重要性以及好处。第二部分用6个要点来讲解需求收集、制定自动化测试的策略、开发自动化测试框架（主要是开发原则）、制定测试计划以及人员安排。附录A是一个测试阶段一览表，附录B快速地讲解了各种类型的测试以及在这些测试中如何应用自动化。附录C用了大量的篇幅介绍各种主流测试工具，以及评估这些工具的方法，附录D是一个真实的自动化框架的案例研究。本书适合软件测试人员、质量评估人员、项目管理人员和软件开发人员阅读。测试占新软件开发的时间和成本的百分比越来越大。使用自动化软件测试（AST），开发人员和软件测试人员可以优化软件测试生命周期，从而减少成本。随着技术和开发发展得越来越复杂，AST将变得不可或缺。本书是根据一些已经证明的实践和自动化测试生命周期方法学（ATLM）而写，提供了更新的实践，为成功实施AST提供了全面指导。在本书中，三位权威专家详细地阐释了AST，系统地回顾了AST的组成元素、能力以及限制。他们利用在防御系统和商业中部署AST的经验，带领你浏览整个实施过程——确定最佳实践、关键的成功因素、关键隐患，以及避免这些隐患的解决方案。本书内容·为AST构建实际可行的商业案例，使用AST获取主动权·澄清测试需求，并开发一个自动化策略反映这些需求·构建高效的测试环境，为该环境选择合适的自动化工具和技术·使用经过证明的指标持续地跟踪过程，并做出相应的调整不管你是测试专业人员、QA专家、项目经理还是开发人员，本书都会带给你前所未有的有效测试，然后使用AST改进整个开发生命周期。

《基于Quartus II的FPGA/CPLD设计与实践》从实验、实践、实用的角度出发，通过丰富的范例讲述基于Quartus II 9.0软件进行FPGA/CPLD应用产品的开发和应用。全书共6章，主要讲述了编程基础知识、简单逻辑门电路的设计、常用逻辑门电路的设计、时序电路的设计，以及实际系统的应用及开发过程。《基于Quartus II的FPGA/CPLD设计与实践》是结合作者丰富的教学与实践经验编写而成的，语言简洁、结构清晰，内容由浅入深。书中的范例具有很强的实用性，并且均通过了软、硬件调试与仿真验证。《基于Quartus II的FPGA/CPLD设计与实践》适合从事FPGA/CPLD研发的技术人员阅读，也可作为高等学校相关专业的教学用书。

《软件工程教程》全面系统地介绍了软件工程的有关概念、原则、方法和工具。全书共15章，内容包括：软件工程中面向过程、面向对象的开发方法，技术度量，质量保证，软件项目计划与管理，用统一建模语言UML开发软件的方法等。另外，还对设计模式、敏捷软件开发、Web工程等软件工程相关领域进行了介绍和讨论。《软件工程教程》既注重科学性和系统性，又注重实用性和新颖性。《软件工程教程》可作为大学计算机及相关专业本（专）科学生的教材或教学参考书，也可作为研究生的参考教材。

本书系统介绍了软件项目管理的理论、方法与案例，全书共分15章，内容包括软件项目管理、组织平台、软件项目立项、软件开发过程、软件估算、软件项目计划、软件配置管理、软件质量管理、软件度量、风险管理、软件外包管理、人力资源管理与团队建设、软件知识产权管理、项目经理面临的政治、项目管理技巧。本书适合软件工程及计算机相关专业的研究生使用，也町作为软件领域开发人员的参考书。