点此进入淘宝搜索页搜索　　參考價格: 点此进入淘宝搜索页搜索
　　分類: 图书,教材教辅与参考书,大学,计算机专业,
　　品牌: 朱少民

基本信息·出版社：清华大学出版社

·页码：264 页

·出版日期：2009年

·ISBN：7302186235/9787302186236

·条形码：9787302186236

·包装版本：1版

·装帧：平装

·开本：16

·正文语种：中文

·丛书名：高等学校教材·软件工程

产品信息有问题吗？请帮我们更新产品信息。

内容简介《软件工程导论》围绕软件工程最基本的核心——“质量和生产率”展开，力求通过一些具体的实例来说明软件工程的思想和方法。《软件工程导论》在回答为什么要研究软件工程问题之后，首先系统地给出软件工程的知识体系框架，帮助读者建立起软件工程的完整且清晰的概念。然后深入软件过程、软件工程目标和要求的讨论，全面阐述了软件工程的思想、方法、技术和工具，结合软件工程环境、软件项目管理等内容，使读者坚实地掌握和运用软件工程的知识内涵。

《软件工程导论》内容丰富，构思新颖，突破软件工程图书的传统框架，使整个软件工程体系更清晰，从思想和管理出发，自然延伸到流程、方法、工具和环境，重新阐释了软件工程体系。《软件工程导论》吸收了软件工程的最新进展，适应软件即服务（SaaS）的开发模式，增加了相应的内容，符合当今软件工程的实际需求。

《软件工程导论》系统性强、通俗易懂，内容丰富且实用，理论和实践有效地结合，可作为高等学校的软件工程专业、计算机软件专业和相关专业的教材，也适合各类软件工程管理人员和技术人员学习。

编辑推荐《软件工程导论》将揭示软件工程的实质和内涵，围绕软件工程最基本的核心一一“质量和生产率”展开，充分阐述软件工程的系统思想、方法体系和过程运行轨迹，从而帮助读者建立其软件工程的完整而清晰的概念，帮助读者理解学习软件工程的意义和内容，在思想高度上指导软件工程专业的其他课程学习。

目录

引子

第1章 为什么要研究软件工程

1.1 软件危机

1.1.1 软件不再只是程序

1.1.2 危机四伏

1.1.3 软件危机之证

1.2 软件的问题在哪里

1.2.1 软件特性

1.2.2 软件业所面临的问题

1.2.3 软件问题的幽默画

1.3 软件工程的诞生

1.4 软件工程的命题

1.5 软件工程知识体系

1.5.1 软件工程知识体系的构成

1.5.2 软件工程要素

1.5.3 SWEBOK

1.6 现代软件工程

1.6.1 开源软件运动

1.6.2 SaaS

1.6.3 现代软件工程的基本思想

1.7 小结

思考题

第2章 软件过程

2.1 完整的软件生命周期

2.1.1 软件的工程过程

2.1.2 综合的软件过程

2.2 需求工程

2.2.1 软件需求

2.2.2 需求开发

2.2.3 需求管理

2.3 设计

2.3.1 软件设计的目标

2.3.2 体系结构设计

2.3.3 详细设计

2.3.4 部署设计

2.3.5 设计评审

2.4 实施

2.4.1 单元测试

2.4.2 集成测试

2.4.3 功能测试

2.4.4 系统测试

2.4.5 验收测试

2.5 部署、运行和维护

2.5.1 系统部署

2.5.2 软件运行和技术支持

2.5.3 维护过程

2.6 软件非工程过程

2.6.1 计划

2.6.2 质量保证和管理的过程

2.6.3 项目管理过程

2.6.4 基础设施和过程改进

2.7 小结

思考题

第3章 软件工程目标和要求

3.1 软件工程的基本目标

3.2 软件工程的影响要素

3.3 软件工程的业务需求

3.4 软件工程的质量要求

3.4.1 质量的含义

3.4.2 客户是质量的焦点

3.4.3 软件质量的特性

3.4.4 影响软件产品质量的因素

3.4.5 软件过程的质量因素

3.4.6 软件质量的指标

3.5 软件工程的成本要求

3.5.1 软件工程的固有成本

3.5.2 软件的可变成本

3.5.3 软件工程的劣质成本

3.6 软件工程的资源限制

3.7 软件产品集成要求

3.7.1 传统产业的启示

3.7.2 软件产品工程

3.8 小结

思考题

第4章 软件工程思想

4.1 永远不可低估思想的作用

4.2 以人为本

4.3 软件开发不是一门艺术

4.4 向传统工业学习

4.4.1 客户为导向

4.4.2 需求分析是基础

4.4.3 过程决定结果

4.4.4 持续改进过程

4.4.5 缺陷预防

4.4.6 围绕项目开展工作

4.4.7 验证和确认缺一不可

4.4.8 以架构设计为中心

4.5 软件工程的例外

4.5.1 迭代

4.5.2 敏捷开发思想

4.5.3 持续构建和集成

4.5.4 永远的Beta

4.5.5 面向对象是一种思想

4.5.6 软件工程应归为知识管理

4.6 软件工厂思想

4.6.1 模块化思想

4.6.2 面向构件思想

4.6.3 软件复用

4.6.4 中间件

4.6.5 自动化无处不在

4.7 小结

思考题

第5章 软件工程方法

5.1 软件方法论

5.1.1 系统工程方法论

5.1.2 软系统方法论

5.1.3 软件工程方法体系

5.2 用户需求的获取方法

5.3 软件工程的分析方法

5.3.1 系统分析方法

5.3.2 问题分析方法

5.3.3 根本原因分析

5.3.4 决策分析

5.4 软件工程的设计方法

5.4.1 原型设计方法

5.4.2 结构化方法

5.4.3 面向对象方法

5.4.4 面向构件设计方法

5.4.5 面向服务方法

5.4.6 可视化方法

5.5 软件测试方法

5.5.1 白盒和黑盒的测试方法

5.5.2 静态和动态的测试方法

5.5.3 ALAC测试和随机测试

5.5.4 自动化测试方法

5.6 小结

思考题

第6章 软件建模

6.1 一个简单建模的例子

6.2 软件建模

6.2.1 为什么要建模

6.2.2 软件建模概述

6.2.3 如何建模

6.3 元建模

6.4 建模语言和UML

6.4.1 建模语言的起源

6.4.2 实体关系建模

6.4.3 UML

6.4.4 UML视图

6.4.5 建模机制

6.4.6 系统建模语言SysML

6.4.7 虚拟现实建模语言

6.5 软件过程模型

6.5.1 瀑布模型的不足

6.5.2 V模型诠释软件过程

6.5.3 没有统一天下的RUP

6.5.4 MSF的过程模型

6.6 小结

思考题

第7章 软件工程环境

7.1 环境造就软件

7.2 软件工程组织

7.2.1 软件组织环境

7.2.2 软件组织的作用

7.2.3 PSP改进个人能力

7.2.4 TSP提高团队水平

7.2.5 完整的组织框架

7.3 软件工程文化

7.3.1 过程文化

7.3.2 质量文化

7.4 软件工程基础设施

7.5 过程定义

7.5.1 软件过程定义的基础

7.5.2 剪裁标准软件过程的指南和准则

7.6 过程评估和改进

7.6.1 软件过程评估的目标和期望

7.6.2 软件过程评估的内容和范围

7.6.3 软件过程评估的方式和类型

7.6.4 软件过程评估的方法

7.6.5 过程改进的IDEAL模型

7.6.6 过程改进的Raytheon方法

7.6.7 过程改进实施的原则

7.6.8 过程改进实施

7.7 小结

思考题

第8章 软件项目管理

8.1 软件项目管理概述

8.1.1 软件项目管理的3P

8.1.2 软件项目管理的实质

8.1.3 软件项目管理的目标和范围

8.2 软件项目的分类

8.3 制定计划

8.3.1 软件规模度量

8.3.2 软件开发的估算模型

8.3.3 项目工作量估算

8.3.4 日程和人力资源安排

8.3.5 项目成本估算

8.4 资源管理

8.5 进度和成本管理

8.5.1 里程碑控制和关键路径

8.5.2 项目成本控制

8.5.3 项目进度的特性及外在关系

8.6 质量管理

8.6.1 软件质量计划

8.6.2 软件评审

8.6.3 缺陷预防

8.6.4 质量度量

8.7 风险管理

8.7.1 风险识别

8.7.2 风险分析和评估

8.8 软件配置管理

8.8.1 配置管理的基本概念

8.8.2 版本控制

8.8.3 变更控制

8.9 项目跟踪和控制

8.1 0小结

思考题

第9章 软件工具

9.1 ICASE

9.2 IDE

9.3 商业工具解决方案

9.3.1 典型的完整解决方案

9.3.2 商业IDE

9.3.3 需求分析和管理工具

9.3.4 建模和设计工具

9.3.5 测试工具

9.3.6 配置管理工具

9.4 开源工具集成的解决方案

9.4.1 开源代码许可协议

9.4.2 开源的Web开发框架

9.4.3 开源的IDE

9.4.4 PHP及其他语言的IDE

9.4.5 开源测试工具

9.4.6 覆盖软件过程的其他开源工具

9.5 小结

思考题

附录A 软件工程术语中英文对照

附录B 项目视图和范围的文档模板

参考文献

……[看更多目录]

序言40年前，人们就开始讨论“软件工程”这样一个话题，但至今软件工程依然不太成熟，例如今天的软件质量水平依旧不高，软件的开发模式还在探索之中，而这一切主要归结于软件技术的日新月异的变化和软件自身的复杂特性。互联网的普及将软件技术的变化推向新的高潮，人们借助互联网的力量可以随时随地沟通、协作，可以共享知识、技能和经验，甚至可以积聚全世界的力量共同探讨同一个技术主题，所有这些极大地推动软件技术的发展。而在这同时，软件产业也在悄悄地发生着巨大的变化，从传统的软件产品销售模式向软件服务模式转化，软件即服务（software as a service）或按需服务（ondemand service）的趋势越来越明显，其中最具代表性的服务就是Salesforce。Salesforce为中小型企业提供各种业务应用的在线服务，每年以80%的速度增长，客户满意度高达97%，从销售团队自动化到合作伙伴关系管理、市场营销和客户服务，Salesforce重新定义客户关系管理。企业不再需要部署自己的服务器、不需要购买软件等，只要按照自己的实际需求，访问Salesforce.com以获得自己所需要的业务处理功能，每个月或每年只要付出很低的服务费。软件开发模式，也自然随着SaaS模式诞生而正在发生巨大的变化，有必要在这关键时刻重新审视软件工程的思想、方法和实践，这也是本书写作的主要理由。

软件工程不仅面临着技术突飞猛进的挑战，还要面临需求变化频繁、质量难以控制的巨大挑战。下面两个例子，在某种程度上说明了这种挑战的严峻性。

例一： 交通红绿灯的需求变化。

大家都非常熟悉街道上的红绿灯，可以根据不同方向的车流量和人流量，进行调节，实施智能控制。但早期的红绿灯，可不是这样的，非常简单，一个方向红的时候则另一个方向绿，每隔60秒交替变化，这时用简单的定时模拟电路控制就可以了。

后来，人们觉得这样的设计不够人性化，中途经过十字路口的行人或驾驶员不知道要等多少时间，绿灯才会亮。所以，加上一个数字计时器，显示剩下的等待秒数。这时，模拟电路控制就必须改为数字电路，需要重新设计和实现。

再到后来，人们发现一个十字路口的两个方向，车与人的流量是不一样的，需要调整不同方向的红绿灯切换的间隔时间，例如一个方向是75秒而另外一个方向是25秒。而且，将来的车流量会发生变化，即红绿灯间隔时间用户可自行设置，这样要求对原来的数字电路或控制程序进行修改，这种改动可能很大，需要修改设计和修改实现。

文摘4.2 以人为本

软件丁程是由软件企业去实施的，而企业的企字就是“人”加上“止”字。止，下基也，指企业的住所、房子，而房子有了“人”才能成为企业。人是在建筑之上，所以人决定了企业，企业不前止于人，企业成功也在于人。事业之成，成于人才，管理的核心问题就是人的管理。

人们在讨论软件工程思想时，会说出一大串的观点，诸如“规范流程”、“持续改进”、“持续集成”、“目标驱动”、“分工协作”和“模块化、组件化”等。这些思想理念都没错，但有时掩盖了或忽视了一些最简单、最基本的观点，如“一切从客户出发”和“简单就是一种美”。在软件T程中，人们谈得最多的是软件工程三要素——方法、过程与工具，人们却往往忽视其决定的因素——软件工程人员。

1.管理学的佐证

在传统管理中，大生产以机器为中心，工人只是机器系统的配件，人被当作是物，管理的中心是物。但是，随着信息时代的到来，组织中最缺乏的不是资金和机器，而是高素质的人才。在组织中，人的作用越来越突出。这就促使管理部门日益重视人的因素，管理丁作的中心也从物转向人。传统管理和现代管理的一个重要区别，就是管理中心从物本管理到人本管理。

在管理理论的研究中，差不多所有的管理理论都建立在人性的假设理论基础上。许多学派管理理论的不同，主要是出于对人的本性认识不同。20世纪之初泰罗的科学管理是基于“经济人”这一假设的，20世纪30年代梅奥等人的行为管理是基于“社会人”这一假设的，至50年代又有了基于“自我实现的人”假设的马斯洛的人性管理，80年代以来出现的文化管理，强调实现自我的企业文化和企业现象。管理研究发展史表明，管理学理论明显地存在着以人为本的发展趋势。

2.由智力活动所决定

在制造业，可以直接通过计件来衡量个人的生产效率，质量的检验方法也非常成熟、及时和自动化，即传统制造业的管理完全可以做到量化的管理，“以人为本”的管理意识就不是十分突出。而在软件企业，不能简单用代码行去衡量工作量。水平差的初级程序员编写1000行代码的程序，由一个非常资深的软件工程师来修改，能够精炼成几百行代码，甚至是几十行代码的程序，而且程序性能高、运行稳定。

 

 

免责声明：本文为网络用户发布，其观点仅代表作者个人观点，与本站无关，本站仅提供信息存储服务。文中陈述内容未经本站证实，其真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。