软件工程文档规范(11个doc)
软件项目验收标准文档
文档修订记录*正式发布时文档版本号从1.0开始。
对文档进行小改动时，版本号以0.1进阶；大改动时版本号以1.0进阶。
文档审批记录目录1.前言31.1.目的31-2-范围31.3.术语定义31.4.预期读者与阅读建议31.5.参考42.工程概述43.验收原贝U 44.总体验收标准44.1.标准定义44.2.验收标准的详细说明54.2.1.软件错误的严重性等级54.2.2.错误与严重性等级对应64.2.2.1.一级错误的描述64.2.2.2.二级错误的描述64.2.2.3.三级错误的描述64.2.2.4.四级错误的描述64.2.2.5.五级错误的描述65.工程验收标准7■5.1.功能测试75.1.1.功能项测试75.1.1.1.功能一75.1.1.2.功能二75.1.2.业务流程测试75.1.2.1.业务流程一75.1.2.2.业务流程二852非功能测试85.2.1.容错测试85.2.2.安全性测试85.2.3.测试8524压力测试9 5.2.5.易用性测试95.2.6.适应性测试953.安装测试95.3.1.数据恢复测试95.3.2.数据接入95.3.3.服务954文档测试9！5.5.用户有特别要求的测试106.验收资料10un^H7.附录：GB/T 16260软件质量评价特性107.1.功能性10.7.1.1.适合性10712准确性117.1.3.互操作性、互用性117.1.4.依从性117.1.5.安全性1172.可靠性1172.1.1.熟性1172.1.2.错性1172.1.3.恢复性1273.易用性1273.1.1.理解性1273.1.2.学性1273.1.3.操作性1274效率121.1.1.时间特性121.1.2.资源特性127.5.维护性127.5.1.易分析性137.5.2.易改变性137.5.3.稳定性137.5.4.易测试性137.6.可移植性137.6.1.适应性137.6.2.易安装性137.6.3.遵循性137.6.4.易替换性141.前言1.1.目的〔如下描述:〕在参考了大量的实践案例和文献的基础上，结合工程特征、客户需求及当前业务实际制定本验收标准，确立工程质量目标，规范本软件的验收。
【参考文档】软件测试范例-范文word版 (11页)
本文部分内容来自网络整理，本司不为其真实性负责，如有异议或侵权请及时联系，本司将立即删除！== 本文为word格式，下载后可方便编辑和修改！ ==软件测试范例篇一：软件测试用例实例(非常详细)1、兼容性测试在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。
客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。
测试目的配置说明服务器操作系统系统软件外设应用软件结果Window201X(S) WindowXp Window201X(P) Window201X用例编号项目名称模块名称项目承担部门用例作者完成日期本文档使用部门评审负责人审核日期批准日期TestCase_LinkWorks_WorkEvaluate LinkWorks WorkEvaluate模块研发中心-质量管理部201X-5-27 质量管理部注：本文档由测试组提交，审核由测试组负责人签字，由项目负责人批准。
历史版本：版本/状态 V1.1作者参与者起止日期备注1.1. 疲劳强度测试用例强度测试也是性能测试是的一种，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。
如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。
而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。
强度测试还可用于确定测试对象能够处理的最大工作量。
测试目的测试说明前提条件测试需求功能1输入/动作 2小时 4小时 6小时 8小时功能12小时 4小时 6小时 8小时连续运行8小时,设置添加10用户并发输出/响应是否正常运行一、功能测试用例此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。
主要测试技术方法为用户通过GUI （图形用户界面）与应用程序交互，对交互的输出或接受进行分析，以此来核实需求功能与实现功能是否一致。
软件开发规范
软件开发行为规范第一版版权所有不得复制软件开发行为规范(第一版）为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。
与软件开发相关的所有人员都必须遵守本软件开发行为规范。
本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。
本软件开发行为规范，采用以下的术语描述：★规则：在软件开发过程中强制必须遵守的行为规范。
★建议：软件开发过程中必须加以考虑的行为规范。
★说明：对此规则或建议进行必要的解释。
★示例：对此规则或建议从正或反两个方面给出例子。
本软件开发过程行为规范由信息技术管理部负责解释和维护。
信息技术管理部目录1 软件需求分析 52 软件项目计划93 概要设计114 详细设计145 编码186 需求管理197 软件配置管理218 软件质量保证231 软件需求分析1-1：软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。
1-2：当产品的需求规格发生变更时，必须修订软件需求规格文档。
软件需求规格的变更必须经过评审，并保存评审记录。
1-3：必须对软件需求规格文档进行正规检视。
1-4：软件需求分析过程活动结束前，必须经过评审，并保存评审记录。
1-5：在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。
说明：参考建议1-1到1-16。
1-1：采用以下检查表检查软件需求规格文档中需求的清晰性。
1-2：采用以下检查表检查软件需求规格文档中需求的完备性。
1-3：采用以下检查表检查软件需求规格文档中需求的兼容性。
1-4：采用以下检查表检查软件需求规格文档中需求的一致性。
《软件工程》教学课件 第11章 软件项目管理
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 ， 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4（KLOG）1.05 MM=3.0（KLOG）1.12 MM=3.6（KLOG）1.20
进度 TDEV=10.5（MM）0.38 TDEV=10.5（MM）0.35 TDEV=10.5（MM）0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数，乘以根据经验推算的每行源代 码所需成本，即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部（FSD）负责的６０个项目的数据，利用最小二 乘法拟合，得到如下估算公式：
PERT（Program evaluation & review technique)计 划评审技术或CPM（Critical path method）关键路径法， 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间，数字结点为任务的起点和终点。
70
任务
月份 １ 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图（Gantt Chart）
软件配置管理指南
软件配置管理指南编号：PRO-SCMP版本 1.0变更记录1引言软件配置管理的目的是在项目整个软件生存周期过程中建立和维护软件项目产品的完整性和一致性。
软件配置管理包括确认在给定时间点上软件的配置（即选定的软件工作产品及其描述），系统地控制对配置的更改，并维护在整个软件生存周期中配置的完整性和可跟踪性。
置于软件配置管理之下的工作产品包括：软件过程资产（例如软件过程改进中的所有文档），交付给顾客的软件产品（例如软件需求文档和代码），内部使用的相关软件产品，以及为完成这些软件产品而生成的中间产品。
这些产品通常置于产品基线库中并由专门人员进行管理和控制。
软件配置管理过程需要达到的目标包括：1.保证软件项目的配置管理活动是有计划的。
2.所选择的软件工作产品是确定的、受控的、可访问和可用的。
3.对已经确定的软件工作产品的变更是受控的。
4.相关部门和人员能及时获知软件基线库的状态、变更和变更内容。
1.1目的本计划定义了项目的配置管理流程，目的是为了在整个软件生命周期中，控制构成软件产品的各配置项的标识、变更等活动，从而建立并维护软件产品的完整性、正确性、一致性和可追溯性。
1.2范围本软件配置管理计划适用于整个软件生存周期过程中已纳入配置管理库的配置项的活动。
置于配置管理系统下的工作产品通常包括：1.各种标准（代码书写标准、设计标准等）2.项目计划（开发计划、质量保证计划和配置管理计划等）3.软件需求说明书及相关的文档和静态原型4.设计文档5.软件源代码6.测试计划、测试程序和数据7.软件操作手册8.各种跟踪记录、测试记录、评审报告等9.过程改进文档10.其它相关的资料库（电子的和非电子的文档）11.其他和软件开发及管理相关的和必要的文档1.3术语定义1.软件配置项（SCI）软件配置项（Software Configuration Item）为了配置管理的目的而作为一个基本的独立单位来看待的软件成分或它们的集合体，如外部提交的软件产品、项目成果(代码、文档和数据)以及项目内部使用的支持工具(如文档测试用例软件工具)等。
《软件工程》课后习题答案
1、可行性研究的目的是用最小的代价，在尽可能短的时间内，确定该项目是否能够开发。
2、程序设计时代的生产方式是个体手工，程序系统时代的生产方式是作坊式小团体，软件工程时代的生产方式是工程化。
3、喷泉模型是一种以需求分析为动力，以对象为驱动的模型。
4、需求分析阶段，分析人员要确定对问题的综合需求，其中最主要的是功能需求。
5、可行性研究需要从以下三个方面分析研究每种解决方法的可行性：技术可行性、经济可行性、社会可行性。
6、可行性研究的目的不是去开发一个软件项目，而是研究这个软件项目是否值得开发，其中的问题能否解决。
7、判定树较判定表直观易读，判定表进行逻辑验证较严格，能把所有的可能性全部都考虑到。
可将两种工具结合起来，先用判定表做底稿，在此基础上产生判定树。
8、软件工具的发展特点是软件工具有单一工具向多个工具集成化方向发展。
重视用户界面的设计，不断的采用新理论和新技术。
软件工具的商品化推动了软件产业的发展，而软件产业的发展，又增加了对软件工具的需求，促进了软件工具的商品化进程。
9、环境集成主要有数据集成、界面集成、控制集成、平台集成、过程集成。
10、可行性研究实质上是进行一项简化、压缩了的需求分析、设计过程。
11、结构化方法有结构化分析、结构化设计、结构化程序设计构成，它是一种面向数据流的开发方法。
12、投资回收期就是累计的经济效益等于最初的项目投资所需的时间。
13、详细描述处理过程常用三种描述工具：图形、表格和语言。
14、数据流图中，每个加工至少有一个输入流和一个输出流。
15、结构化设计以数据流为基础映射成软件结构。
16、当数据流图中某个加工的一组动作存在着多个条件复杂组合的判断时，使用判定表或判定树较好。
17、由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。
18、有两类维护技术：在开发阶段是用来减少错误、提高软件可维护性面向维护的技术，在维护阶段用来提高维护的效率和质量的维护支援技术。
软件工程复习提纲(20160615)
软件工程复习提纲Chapter11.开发文档都有哪些?用图来表示它们之间的关系。
2.说明软件工程研究的内容.3.软件工程的7条基本原理有何现实意义。
4.怎样理解ISO9000的文档体系?质量手册、程序文件、质量记录三者有何联系和区别?5.怎样理解CMMI，如何用CMMI去管理软件企业？6.是否存在这一种现象：搞系统软件的公司不需要采用CMMI和ISO9000模式？CMMI和ISO9000模式只适用于搞应用软件的企业？如果是，为什么，如果不是，又为什么？7.软件工程与信息系统工程有何异同？8.怎样理解元数据？Chapter21.为什么要选择软件开发模型?软件开发模型与软件生存周期有什么关系？2.简述瀑布模型、增量模型、迭代模型、原型模型的优缺点。
3.软件公司的ISO9000或CMM管理体系与软件开发模型有关吗，为什么？4.你对“生存周期模型裁剪指南"有什么看法？5.“图书馆信息系统”的开发选用什么开发模型合适？Chapter31.立项的具体表现形式是什么？2.立项建议书的编制者为什么主要是软件公司的市场销售人员,而不是开发人员？3.什么叫风险分析，技能风险与技术风险有何区别？3.合同、任务书、立项建议书三者有何异同?有何关系？4.对软件项目和产品的“功能、性能、接口"三项指标如何理解？Chapter41.需求分析的目的是什么,需求分析的难点在哪里?2.需求分析的理论基础有哪几条？3.为什么说需求分析是面向流程的？4.解释术语：元数据、实体、中间数据.5.用户需求报告与需求规格书有何差异？6.需求描述有哪几种工具？你喜欢哪一种，为什么?1.简述软件策划的步骤.2.简述软件策划的方法。
3.简述对软件工作产品规模进行量化估计的方法。
4.软件工作产品和软件产品有何异同？5.名称解释：直接人工、直接费用、间接成本、制造费用、管理费用、不可预见费用。
6.怎样理解软件中的度量，它有何作用？Chapter61.概要设计说明书和详细设计说明书有何区别?2.怎么理解“软件概要设计是系统总体结构设计或系统架构设计”？3.模块实现设计包括哪些内容？4.为什么软件设计要遵守“抽象、分解与模块化、低耦合高内聚、封装、接口和实现分离”的设计原理？Chapter71.简述UML的优缺点。
软件工程答案整理
填空1．软件测试的目的是尽可能多地发现软件中存在的错误,将测试结果作为纠错的依据。
2．测试阶段的基本任务是根据软件开发各阶段的和程序的，精心设计一组，利用这些实例执行，找出软件中潜在的各种和。
3．测试用例由和预期的两部分组成.4．软件测试方法一般分为两大类：方法和方法。
5．动态测试通过发现错误。
根据的设计方法不同，动态测试又分为与两类。
6．静态测试采用和的手段对程序进行检测。
7．人工审查程序偏重于的检验，而软件审查除了审查还要对各阶段进行检验。
8．计算机辅助静态分析利用工具对测试程序进行分析。
9．黑盒法只在软件的处进行测试，依据说明书，检查程序是否满足要求。
10．白盒法必须考虑程序的和，以检查的细节为基础，对程序中尽可能多的逻辑路径进行.11．白盒测试是测试，被测对象是,以程序的为基础设计测试用例.12．逻辑覆盖是对程序内部有存在的逻辑结构设计测试用例，根据程序内部的逻辑覆盖程度又可分为、、、、和6种覆盖技术。
13．实际的逻辑覆盖测试中，一般以覆盖为主设计测试用例,然后再补充部分用例，以达到覆盖测试标准. 14．循环覆盖是对程序内部有存在的逻辑结构设计测试用例,它通过限制来测试。
15．基本路径测试是在程序基础上，通过分析控制构造的复杂性,导出集合，从而设计测试用例。
16．黑盒测试是测试，用黑盒技术设计测试用例有4种方法：、、和。
17．等价类划分从程序的说明，找出一个输入条件（通常是或），然后将每个输入条件划分成两个或多个。
18．边界值分析是将测试情况作为重点目标，选取正好等于、刚刚大于或刚刚小于的测试数据。
如果输入或输出域是一个有序集合，则应选取集合的元素和元素作为测试用例。
19．在测试程序时，根据经验或直觉推测程序中可能存在的各种错误，称为。
20．因果图的基本原理是通过画图，把用自然语言描述的转换为，最后为每一列设计一个测试用例。
21．测试的综合策略是在测试中，联合使用各种方法。
通常先用法设计基本的测试用例，再用法补充一些必要的测试用例。
软件工程(第4版·修订版)
1.7 开发团队的成 员
1.8 软件工程发生 了多大的变化
1.9 信息系统的例 子
1.10 实时系统的 例子
1.11 本章对单个 开发人员的意义
1.12 本章对开发 团队的意义
1 软件工程概述
1.15主要参考文献
1.14 学期项目
1.13 本章对研究 人员的意义
C
B
A
1.16 练习
D
01
1.1.1 问题 求解
4.19 练习
4.5 建模表示法
4.6 需求和规格说 明语言
4 获取需求
4.7 原型化需求
4.3.1 解决 冲突
1
4 获取需求
4.3 需求的类型
4.3.2 两种 需求文档
2
4 获取需求
4.8.1 需求定义
A
4.8.2 需求规格说明
B
4.8.3 过程管理和需 02
1.1.2 软件 工程师的角
色是什么
1 软件工程概述
1.1 什么是软件工程
1 软件工程概述
1.3.1 产品的 质量
1.3.2 过程的 质量
1.3.3 商业环境 背景下的质量
1.3 什么是好的软件
1 软件工程概述
1.5.1 系统 的要素
1
1.5.2 相互 联系的系统
2
1.5 系统的方法
1 软件工程概述
4.8 需求 文档
4.3 需求 的类型
4.9 确认 和验证
4.10 测量需求
4.12 信息系统的例子
4.14 本章对单个开发人 员的意义
4 获取需求
4.11 选择规格说明技术
4.13 实时系统的例子
4.15 本章对开发团队的 意义
软件工程 第4版 第11章 软件工程管理
本章内容
11.1 软件工程管理概述 11.2 软件开发成本估算 11.3 软件工程人员组织 11.4 软件配置管理 11.5 软件质量保证 11.6 软件开发风险管理 11.7 软件工程标准与软件工程文档
这种估算方法的优点是，由于各个任务单元的成本 可交给该任务的开发人员去估计，因此估计结果比较准 确。缺点在于，由于具体工作人员往往只注意到自己职 责范围内的工作，而对涉及全局的成本。
11.2.3 COCOMO2 模型
COCOMO2 模型分为如下3 个模型，在估算软件开发工作量时，对软件细节问题考虑的详 尽程度逐渐增加。
OPTION
软件开发人员一般分为项目负责人、系统分析员、高级程序员、程序员、初级程序员、资 料员和其他辅助人员。
项目负责人需要对项目的需求和团队人员有全面的了解
系统分析员需要有概括能力、分析能力和社交活动能力
程序员需要有熟练的编程能力等 资料员和其他辅助人员负责及时登记软件工程每个阶段的文档等资料
11.3 软件工程人员组织
11.1 软件工程管理概述
02 软件工程管理的重要性
OPTION
基于软件本身的复杂性，软件工 程将软件开发划分为若干个阶段，每 个阶段完成不同的任务、采取不同的 方法。
如果软件开发管理不善，造成的 后果会很严重。因此软件工程管理非 常重要。
11.1 软件工程管理概述
03 软件工程管理的内容
OPTION
02 组织机构
OPTION
软件开发团队不能只是一个简单的集合，要求具有良好的组织机构，要具有合理的人员分 工和有效的通信，共同高效率地完成任务。
按项目划分的模式
按职能划分的模式
矩阵型模式
11.3 软件工程人员组织
软件工程第11章面向对象设计
2. 重用已有的类
重用已有类（代码重用）实现分析模型；若没有可以重用类而需要创建新 类时，则在设计这些新类时需要考虑其可重用性。
对于已有的可重用类，典型重用方法和过程如下： 1）选择可能被重用的已有类，标出类中对本问题无用的属性和服务，选 择那些能使无用的属性和服务最少的类； 2）从被重用的已有类派生出问题域类（继承重用类而产生问题域类）； 3）标出从已有类继承来的属性和服务，而无须在分析类内定义；
6. 可重用
软件重用是提高软件开发生产率和目标系统质量的重要途径。 重用有两方面的含义： 一是尽量使用已有的类（类库或已建立的类）， 二是如果确实需要创建新类，则在设计这些新类的协议时，应该考虑将 来的可重复使用性。
11.2
启发规则
与结构设计规则类似，通过OOD实践也总结了一些设计规则： 1. 设计结果应该清晰易懂 设计结果清晰、易读、易懂，是提高软件可维护性和可重用性的重要 措施。保证设计结果清晰易懂的主要因素为：用词一致；使用已有的 协议；避免模糊的定义等。
1）层次组织：这种组织方案把软件系统组织成一个层次系统，每层是一 个子系统。上层和下层自系统形成C/S结构 层次结构的两种模式：封闭式和开放式：封闭式，每层子系统仅仅使用其 直接下层提供的服务；开放式，任一层次可以向下跨层次调用。 2）块状组织：把软件系统垂直地分解成若干个相对独立的、松耦合的子 系统，一个子系统相当于一块，每块提供一种类型的服务。
第11章
11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 11.10 11.11
面向对象设计
面向对象设计的准则 启发规则 软件重用 系统分解 设计问题域子系统 设计人机交互子系统 设计任务管理子系统 设计数据管理子系统 设计类中的服务 设计关联 设计优化
项目经理必读法律法规一览表
项目经理必读法律法规一览表Document number：PBGCG-0857-BTDO-0089-PTT1998项目经理必读法律法规一览表1、法律：（1）中华人民共和国招标投标法（2）中华人民共和国合同法节选总则1-8章，分则9、18章）（3）中华人民共和国劳动法（4）中华人民共和国专利法（5）中华人民共和国着作权法（6）中华人民共和国产品质量法（7）中华人民共和国计算机信息系统安全保护条例（8）计算机软件保护条例（9）中华人民共和国公司法（10）国发[2000]18号"国务院关于印发鼓励软件企业和集成电路产业发展若干政策的通知"（11）信部规［1999］1047号"关于发布《计算机信息系统集成资质管理办法（试行）》的通知"（12）信部规［2000］821号"关于发布计算机信息系统集成资质等级评定条件的通知"（13）信部规［2002］382号"关于发布《计算机信息系统集成项目经理资质管理办法（试行）》的通知"（14）信计资［2002］064号"关于发布《计算机信息系统集成项目经理资质管理办法（试行）》过渡时期暂行规定的通知"2、软件工程的国家标准基础标准：（1）信息处理-程序构造及其表示法的约定 GB/T 13502-92开发标准：（2）计算机软件单元测试 GB/T 15532-95（3）软件维护指南 GB/T 14079-93文档标准：（4）软件文档管理指南（5）计算机软件需求说明编制指南 GB/T 9385-88（6）计算机软件测试文件编制指南 GB/T 9386-88管理标准：（7）计算机软件质量保证计划规范 GB/T 12504-90（8）计算机软件可靠性和可维护性管理 GB/T 14394-93（9）信息技术软件产品评价质量特性及其使用指南GB/T 16260-96 3、软件工程文档模板（1）操作手册（GB8567-88）.doc（2）测试分析报告（GB8567-88）.doc（3）测试计划（GB8567-88）.doc（4）概要设计说明书（GB8567-88）.doc（5）开发进度月报（GB8567-88）.doc（6）可行性研究报告（GB8567-88）.doc（7）模块开发卷宗（GB8567-88）.doc（8）软件需求说明书（GB856T-88）.doc（9）数据库设计说明书（GB8567-88）.doc（10）数据要求说明书（GB856T-88）.doc（11）文件给制实施规定的实例（GB8567-88）.doc（12）详细设计说明书（GB8567-88）.doc（13）项目开发计划（GB856T-88）.doc（14）项目开发总结报告（GB8567-88）.doc （15）用户手册（GB8567-88）.doc。
《软件工程》教学大纲
《软件工程》教学大纲一、课程概述本课程向学生介绍与大型软件相关的规划. 分析. 设计. 实现. 测试. 维护等概念. 原理. 技术与工具，同时向学生讲述传统的结构化开发方法与当前流行的面向对象开发方法。
要求学生牢固掌握软件生命周期. 软件质量. 软件成本等基本概念以及传统的结构化分析. 设计与实现方法；掌握面向对象软件工程的基本概念与表示技术，基本掌握软件开发中的管理技术。
通过本课程的学习，让学生对软件工程学有一个全貌的了解，对其所涉及的基本概念. 原理. 方法和有关技术逐步领会并进行运用。
要求学生能够在已有的程序设计. 数据结构. 数据库等理论基础上，为今后进行实际的软件开发奠定一个良好的基础。
本课程应强调实际运用，最好在教学中安排学生参予系统开发的策划. 分析. 设计. 编码. 测试等阶段工作的环节，积极引导学生从个人的单纯编程活动转移到进行系统分析与设计方面上来。
如果受条件所限，可让学生在毕业设计中将这一环节补上。
本课程的先修课程为“面向对象程序设计”. “数据结构与算法”与“数据库”。
本课程的后续课程可以为“程序设计方法学”与“算法分析与设计”。
二、课程目标1．知道《软件工程》这门学科的性质. 地位. 独立价值. 研究范围. 基本框架. 研究方法. 学科进展和未来方向等。
2．理解该门学科的主要概念. 基本原理和策略等。
3．学会运用一些具体的策略或技术等，如软件测试过程中所用到的黑盒测试法和白盒测试法。
4．能够把所学的原理应用到具体的实践中去，如对于具体系统开发过程中所遇到的问题能够自行进行处理，培养学生发现. 分析和解决问题的能力等。
三、课程内容和教学要求这门学科的知识与技能要求分为知道、理解、掌握、学会四个层次。
这四个层次的一般涵义表述如下：知道———是指对这门学科和教学现象的认知。
理解———是指对这门学科涉及到的概念、原理、策略与技术的说明和解释，能提示所涉及到的教学现象演变过程的特征、形成原因以及教学要素之间的相互关系。
《软件工程》各章课后习题答案
第一章课后参考答案1.什么是软件危机？它们有哪些典型表现？为什么会出现软件危机？“软件危机”是指计算机软件的“开发”和“维护”过程中所遇到的一系列“严重问题”。
这些问题决不仅仅是不能正常运行的软件才具有的，实际上，几乎“所有软件”都不同程度地存在这些问题。
它们有以下表现：（1）对软件开发成本和进度的估计常常很不准确；（2）用户对“已完成的”软件系统不满意的现象经常发生；（3）软件产品的质量往往靠不住；（4）软件常常是不可维护的；（5）软件通常没有适当的文档资料；（6）软件成本在计算机系统总成本中所占的比例逐年上升；（7）软件开发生产率提高的速度，远远跟不上计算机应用普及深入的趋势。
出现软件危机的主要原因（1）与软件本身的特点有关（2）与软件开发和维护过程中使用的方法不正确有关2.假设自己是一家软件公司的总工程师，当把图1.1给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”时在引入变动，当然付出的代价更高。
一个故障是代码错误造成的，有时这种错误是不可避免的，但要修改的成本是很小的，因为这不是整体构架的错误。
3.什么是软件工程？它有哪些本质特征？怎么用软件工程消除软件危机？软件工程是指导知道计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
4.4 影响
[说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改。
]
4.4.1.对设备的影响
[说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改]
4.4.2.对软件的影响
[说明为了使现存的应用软件和支持软件能够同所建议系统相适应，而需要对这些软件所进行的修改和补充。
]
4.4.3.对用户单位机构的影响
[说明为了建立和运行所建议系统，对用户单位机构、人员的数量和技术水平等方面的全部要求。
]
4.4.4.对系统运行过程的影响
[说明所建议系统对运行过程的影响。
]
4.4.
5.对开发的影响
[说明对开发的影响。
]
4.4.6.对地点和设施的影响
[说明对建筑物改造的要求及对环境设施的要求。
]
4.4.7.对经费开支的影响
[扼要说明为了所建议系统的开发，统计和维持运行而需要的各项经费开支。
]
4.5 技术条件方面的可能性
[本节应说明技术条件方面的可能性]
5. 可选择的其他系统方案
[扼要说明曾考虑过的每一种可选择的系统方案，包括需开发的和可从国内国外直接购买的，如果没有供选择的系统方案可考虑，则说明这一点。
]
5.1 可选择的系统方案1
[说明可选择的系统方案1，并说明它末被选中的理由。
]
5.2 可选择的系统方案2
[按类似5。
1条的方式说明第2个乃至第n 个可选择的系统方案。
]
[……]
6. 投资及效益分析
6.1 支出
[对于所选择的方案，说明所需的费用，如果已有一个现存系统，则包括该系统继续运行期间所需的费用。
]
6.1.1 基本建设投资
[包括采购、开发和安装所需的费用。
]
6.1.2 其他一次性支出
6.1.3 非一次性支出
[列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用。
]
6.2 收益
[对于所选择的方案，说明能够带来的收益，这里所说的收益，表现为开支费用的减少或避
免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进等，包括：
6.2.1 一次性收益]
[说明能够用人民币数目表示的一次性收益，可按数据处理、用户、管理和支持等项分类叙述。
]
6.2.2 非一次性收益
[说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民币数目表示的收益，包括开支的减少和避免。
]
6.2.3 不可定量的收益
[逐项列出无法直用人民币表示的收益。
]
6.3 收益/投资比
[求出整个系统生命期的收益/投资比值。
]
6.4 投资回收周期
[求出收益的累计数开始超过支出的累计数的时间。
]
6.5 敏感性分析
[是指一些关键性因素与这些不同类型之间的合理搭配、处理速度要求、设备和软件的配置等变化时，对开支和收益的影响最灵敏的范围的估计。
]
7. 社会因素方面的可能性
7.1.[法律方面的可行性]
7.2.[使用方面的可行性]
8. 结论
[在进行可行性研究报告的编制时，必须有一个研究的结论]。