软件重点总结文档格式.docx
《软件重点总结文档格式.docx》由会员分享，可在线阅读，更多相关《软件重点总结文档格式.docx（35页珍藏版）》请在冰点文库上搜索。
对人力资源的估计：
20%的人，解决了软件中80%的问题；
对投入资金的估计：
企业信息系统中80%的问题，可以用20%的资金来解决。
软件生命周期模型是指在整个软件生命周期中，软件开发过程应遵循的开发路线图。
或者说，软件生命周期模型是软件开发全部过程、活动和任务的结构框架。
软件开发方法是指在软件开发路线图中，开发人员对软件需求、设计、实现、维护所采用的开发思想、开发技术、描述方法、支持工具等。
曾经出现过的面向过程方法有：
（1）.面向结构化数据系统的开发方法DSSD（DataStructuredSystemsDevelopment）；
（2）.面向可维护性和可靠性设计的Parnas方法；
（3）.面向数据结构设计的Jackson方法；
（4）.面向问题设计的PAM方法；
（5）.面向数据流方法。
4种开发方法的比较
方法名称
优点
缺点
适合的场合
面向过程的方法
简单好学
不适应窗口界面，维护困难
大型工程计算，实时数据跟踪处理，各种自动化控制系统，以及系统软件实现等领域
面向对象的方法
功能强大
不易掌握
互联网络时代，完全由用户交互控制程序执行过程的应用软件和系统软件的开发
面向元数据的方法
通俗易懂
不适宜窗口界面
以关系数据库管理系统为支撑环境的信息系统的建设
形式化的方法
准确、严谨
难于上手和应用
对安全性要求极高，不容许出错的软件系统，如军事、医药、交通等领域
利用计算机网络技术、数字通信技术与数据库技术实现信息采集和处理的系统，称为当代信息系统。
“五个面向”实践论是指“面向流程分析、面向元数据设计、面向对象实现、面向功能测试、面向过程管理”。
面向流程分析，就是面向流程进行需求分析。
面向元数据设计，就是面向元数据进行概要设计。
面向对象实现，就是面向对象进行详细设计和编程实现。
面向功能测试，就是面向功能进行模块测试、集成测试、Alpha测试和Beta测试。
面向功能测试的方法就是黑盒子测试方法。
黑盒子测试方法的测试思路是：
针对需求分析时建立的系统功能模型，将每一个需求功能点，都分解为多个测试功能点。
再将每一个测试功能点，都分解并设计为多个测试用例。
然后，对每一个测试用例，都执行测试过程，产生测试记录数据。
最后，汇总并分类整理所有的测试记录数据，就可以形成测试报告。
面向过程管理，就是面向软件生命周期过程，对软件生命周期各个阶段进行过程管理与过程改进。
软件工程中的三类过程管理
序号
名称
来源
特点
1
ISO9001质量管理和质量保证体系
国际标准化组织ISO
按20个过程域（或质量要素）管理
2
CMMI能力成熟度模型集成
美国卡内基-梅隆大学软件工程研究所（CMU/SEI）
按22个过程域PA，分阶段模型和连续模型两种方式管理，属于重载过程管理
3
软件企业文化
Microsoft文化、IBM文化、敏捷文化
属于轻载过程管理
课后习题
1.2简述软件工程研究的内容。
软件工程研究的内容包括软件开发方法、软件开发模型、软件支持过程和软件管理过程。
其中软件开发方法的内容又涵盖市场调研、正式立项、需求分析、项目策划、概要设计、详细设计、编程、测试、试运行、产品发布、用户培训、产品复制、销售、实施、系统维护、版本升级。
常用的软件开发模型有瀑布模型、迭代模型、增量模型和原型模型。
软件支持过程由所支持的CASE工具组成，常用的CASE工具有PowerDesigner和RationalRose。
软件管理过程主要有CMMI、ISO9000、微软企业文化和敏捷文化现象。
1.3详细解释软件的定义、程序的定义及软件工程的定义。
软件的定义：
软件＝程序＋数据＋文档。
这里的程序是指程序系统。
这里的数据不仅包括初始化数据、测试数据，而且包括研发数据、运行数据、维护数据，也包括软件企业积累的项目工程数据和项目管理数据中的大量决策原始记录数据。
这里的文档指的是软件开发过程中的分析、设计、实现、测试、维护文档、管理文档。
现在有一种新提法正在引起关注，这种提法是：
软件＝知识＋程序＋数据＋文档。
程序是计算机为完成特定任务而执行的指令的有序集合。
从应用的角度可理解为：
面向过程的程序＝算法＋数据结构
面向对象的程序＝对象＋信息
面向构件的程序＝构件＋构架
1.11什么叫软件危机？
通过本章的学习，你认为应该怎样克服软件危机？
“软件危机”这个专业术语的首次出现，是1968年NATO（NorthAtlanticTreatyOrganization，北约）的计算机科学家，在联邦德国召开的国际学术会议上提出的。
为了克服软件危机，同样是在1968年，北约科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。
就在那次会议上，第一次提出了软件工程（SoftwareEngineering）这个专业术语。
当时人们的想法是：
若借用建筑工程或机器制造工程的思想、标准、规范、规程去开发软件与维护软件，也许能克服软件危机。
以后的实践证明：
用工程的方法开发软件与维护软件是个好主意，但是要完全克服软件危机，还有许多其他工作要做。
例如，将软件公司纳入CMMI的过程改进轨道，就能真正克服软件危机。
第二章
瀑布模型（WaterfallModel）又称流水式过程模型，它可以形象地用阶梯瀑布描述，水由上向下一个阶梯接着一个阶梯地倾泻下来，最后进入一个风平浪静的大湖，这个大湖就是软件企业的产品库。
瀑布模型适合于结构化方法，即面向过程的软件开发方法。
原型模型与迭代模型相同点是：
反复循环几次，直到客户确认为止。
不同点是：
原型模型事先有一个展示性的产品原型（样品），而迭代模型可能没有。
迭代模型的四个阶段
（1）初始阶段。
本阶段主要工作是确定系统的业务用况和定义项目的范围。
（2）精化阶段。
本阶段主要工作是分析问题域、细化产品定义，定义系统的构架并建立基线，为构建阶段的设计和实施工作提供一个稳定的基础。
（3）构建阶段。
本阶段主要工作是反复地开发，以完善产品，达到用户的要求。
（4）产品化（移交）阶段。
本阶段主要工作是将产品交付给用户，包括安装、培训、交付、维护等工作。
软件开发模型比较表
序号
模型名称
优点
缺点
适用范围
1
瀑布模型
逆转性差
面向过程开发
2
增量模型
可以分阶段提交
有时用户不同意
系统可拆卸和组装
3
迭代模型
需求可变
风险大
有高素质软件团队
4
原型模型
开发速度快
不利于创新
已有产品的原型
5
螺旋模型
建设周期长
庞大、复杂、高风险项目
6
喷泉模型
提高开发效率
不利于项目的管理
面向对象开发
7
XP模型
不适合大团队、大项目
小团队，小项目
2.1软件生命周期是什么含义？
它与软件生命周期模型有何关系？
软件生命周期划分为市场调研、立项、需求分析、策划、概要设计、详细设计、编程、单体测试、集成测试、运行、维护、退役几个过程，前一过程的终止点就是后一过程的起始点。
软件生命周期与软件生命周期模型有关：
不同的生命周期模型，可能对应着不同的生存周期。
生存周期不同，该软件的开发阶段划分、评审次数、基线标准都有所不同，甚至维护方法都有所区别。
2.4简述瀑布模型、增量模型、迭代模型、原型模型、XP等模型的优缺点。
第三章:
开发“非订单软件”需要“立项”，开发“订单软件”需要签订“合同”。
所以，“立项”与“合同”是IT企业软件项目（或产品）的两个源头。
3.3《立项建议书》的编制者为什么主要是软件公司的市场销售人员，而不是开发人员？
软件开发出来终归要推向市场的，软件能不能被市场接受是软件开发成功的标准。
市场销售人员长期和市场客户打交道，他们最了解客户和市场的需求，最知道什么样的产品具有巨大商机。
3.7《合同》、《任务书》、《立项建议书》三者有何异同？
有何关系？
合同是与固定客户签订的协议书，签订合同后软件公司启动该项目的开发，该软件被称为“订单软件”。
立项建议书是相对“非订单软件”而言的，是相关人员对立项过程的书面描述。
任务书是企业决定开发某个软件时，对此任务的具体部署情况，以书面的形式表达出来，包括正文和附件。
只有立项建议书或合同签订以后才能下达任务书，三者都是软件开发的源头。
3.8下达任务的时间和方法是什么？
满足以下三个条件中的任意一个，即可下达任务书：
（1）企业已签订了项目《合同》。
（2）《立项建议书》已通过了评审。
（3）作为特殊情况，软件组织的上级下达了某个项目的指令性软件开发计划。
例如，有跨组织、跨部门的某个大系统项目，软件的需求由它的系统总体设计组分配。
下达任务书的方法是：
（1）下达一份《任务书》的正文。
包括任务的下达对象、内容、要求完成的日期、决定投入的资源、必要时包括任命项目经理（技术经理和产品经理）、其他保证措施、奖惩措施等。
《任务书》的正文可长可短，若合同或立项建议书很详细，则正文可短。
若合同或立项建议书很粗略很短，则正文应该详细，当然也应该很长。
（2）下达一份《任务书》的附件。
一般情况下它就是软件《合同》或《立项建议书》，如果是指令性计划，它的格式和内容，也应与《合同》或《立项建议书》基本相同，即附件的内容应覆盖系统的功能点列表、性能点列表、接口列表、资源需求列表、开发进度列表、阶段评审列表等。
第四章
1．需求分析定义
1997年,IEEE软件工程标准词汇表中定义需求为：
（1）.用户解决问题或达到目标所需的条件或能力（Capability）。
（2）.系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）.一种反映上面
（1）或
（2）所描述的条件或能力的文档说明。
需求分析分为两个阶段，需求获取阶段和需求规约阶段。
需求关心的是系统目标而不是系统实现。
需求可以分为两大类，功能性需求和非功能性需求，前者定义了系统做什么，后者定了系统工作时的特性。
2．需求分析为什么重要
需求分析特别重要。
这是因为：
（1）.许多大型应用系统的失败，最后均归结到需求分析：
要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；
要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
（2）.用户需求报告既是软件生命周期中的第一个里程碑，又是客户、软件开发人员、软件测试人员和项目管理人员四者共同工作的基线，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据。
（3）.需求分析要占用整个软件开发时间或工作量的30%左右。
（4）.需求获取中的错误，属于软件开发中的早期错误，将给项目成功带来极大风险，因为这些错误会在后续的设计和实现中进行发散式的传播。
根据以上四项原因，IT企业的高层经理，对需求分析特别重视，常常派经验最丰富的人员去作项目需求。
软件需求的三个层次软件需求包括三个不同层次：
高层领导的战略决策需求、中层管理的查询统计需求、基层人员的实时操作需求。
这个上中下三层需求，构成一个需求金字塔。
需求分析名词解释
名词
名词解释
8
9
10
11
12
提取对象、属性和方法的技术
在面向对象的需求分析中，如何提取对象（准确说是对象集或类）呢？
或者说，对象在哪里？
属性在哪里？
方法在哪里？
回答是：
因为“对象”是“名词或名词短语”，所以要到需求分析的重要名词或名词短语集合中去发现有用的“对象”；
因为“属性”是“形容词或服务性名词”，所以要到需求分析的主要形容词集合或服务性名词集合中去发现对象的“属性”；
因为“方法”是“动词”，所以要到需求分析的主要动词中去发现“方法”。
需求评审检查的项目包括：
（1）.需求是否描述清楚，不存在歧义。
（2）.需求是否是可量化的，可验证的。
（3）.需求间是否存在冲突，以及它们之间的依赖关系。
（4）..非功能性需求是否明确、合理。
（4）.需求是否注明来源。
（5）.每个需求是否分配了唯一的标识。
4.1为什么需求分析特别重要？
需求分析特别重要，是因为：
（1）许多大型应用系统的失败，最后均归结到需求分析：
（2）需求分析的输出文档是《用户需求报告》，它既是软件生存周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，是三者共同工作的基础，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据。
（3）需求分析要占用整个软件开发时间或工作量的30%左右。
（4）需求获取中的错误，属于软件开发中的早期错误，它会在后续的设计和实现中进行发散式的传播。
根据以上4个原因，IT企业的高层经理，对需求分析特别重视，常常派经验最丰富的人员去作项目需求。
正因为如此，“系统分析员”才是软件行业中的最高技术职称。
4.2需求分析的目的是什么？
需求分析的难点在哪里？
软件需求分析，其目的是用于说明软件产品或软件项目需要满足的条件和限制。
在软件工程项目中首先要获取用户的需求，通过对软件需要的提取、分析、文档化及验证，为进一步的设计和实现提供依据。
需求分析的难点是：
在系统的功能、性能和接口方面，开发者与客户达成完全一致的需求，让客户最终签字确认，并保证在项目验收前，需求相对稳定不变。
万一需求有一点变化，双方必须履行“需求变更管理程序”，而变更管理程序在签订合同时已经做了规定。
要知道，合同是具有法律效力的。
4.5为什么说需求分析是面向流程的？
系统的功能、性能、接口、界面都是在流程中动态实时的反映出来。
在所有的流程（物流、人流、资金流、信息流、单据流、报表流、数据流）中，数据流最重要，也最具有代表性。
因为在计算机网络系统内，一切流程都表现为数据流，或者说是数据流在不同方向的投影。
而流程是动态的、实时的。
所以说，需求分析是面向流程的。
第五章：
软件策划，既是为软件开发者和管理者制定合理的计划，又是为软件项目跟踪和监控提供考核依据。
软件策划是项目经理和高级经理的职责范围，是IT企业的重大事件之一。
软件估计既是软件策划的核心，又是软件策划的重点与难点。
软件策划的目的，是为软件开发和软件管理制定合理的计划。
软件策划的四个目的
步骤
步骤名称
步骤内容
估计软件工作产品的规模、工作量、费用及所需的资源
软件工作产品，包括需求规格说明书、概要设计说明书、详细设计说明书、源代码、测试计划和测试报告、质量保证计划、软件配置管理计划、里程碑及评审计划。
每个工作产品所需的工作量（人年）、费用及其所需的其他资源，都要量化
制定时间表
包括开发进度时间表和日历进度时间表：
软件开发计划、质量保证计划、软件配置管理计划、测试计划、评审计划
鉴别和评估风险
政策风险、资源风险、市场突变风险、技术风险和技能风险等
与相关的组或人协商策划中的有关约定
策划的结果要实事求是，要得到各有关方面的同意和认可
项目策划和跟踪用的三个软件估计已建立文档。
这三个估计是：
──工作产品规模估计
──工作量及成本估计
──计算机资源估计
所谓定义软件过程，就是根据选定的生命周期模型，规定软件的开发阶段，及每一阶段的工作步骤和文档标准等内容。
Delphi法又称希腊古都法。
在没有历史数据的情况下，Delphi法是最流行的专家评估技术。
执行Delphi法的基本步骤是：
（1）协调人向各专家提供项目规格和估计表格；
（2）协调人召集小组会，各专家讨论与规模相关的因素；
（3）各专家匿名填写迭代表格；
（4）协调人整理出一个估计总结，以迭代的形式返回专家；
（5）协调人召集小组会，讨论较大的估计差异；
（6）专家复查估计，总结并在迭代基础上提交另一个匿名估计；
（7）重复4-6，直到达到一个最低和最高估计的一致为止，以完成此次估计。
软件策划文档就是《软件开发计划书》，它还包括《质量保证计划》、《软件配置管理计划》、《测试计划》、《里程碑及评审点计划》。
5.2简述软件策划的步骤。
软件策划的4个步骤是：
5.4为什么在策划过程中要考虑到受影响的组和个人？
受影响的组主要有：
软件工程组（项目组）、软件估计组、系统测试组、质量保证组、配置管理组、合同管理组、文档支持组等，这些小组的活动始终贯穿于整个软件工程的全过程，对软件项目的成败有着至关重要的作用，是保证软件产品质量的关键所在，任何一个组的疏忽，都有可能影响到整个软件产品的开发进度。
5.8定义软件过程是什么含义？
5.9软件估计是什么含义？
所谓软件估计，指对软件项目进行量化估计，并记录估计结果的过程。
软件估计是软件度量的一部分，它既是软件策划的核心，又是软件策划的重点与难点。
第六章
功能模型的表示方法为：
系统功能需求列表、性能需求列表、接口需求列表、界面需求列表。
UML规定主要采用“用例图”来描述功能模型。
功能模型的设计和实现方法为：
将相同的功能归并，设计为一个个的构件或组件（部件），将不同的功能设计成模块，然后用面向对象的语言将这些离散的部件或模块组装起来，形成一个完整的系统。
业务模型的描述方法为：
组织结构图、岗位（或角色）职能表、业务流程图加上业务规则说明
在UML中，完整的业务模型由用例图、时序图、交互图、状态图、活动图来表述。
并且，时序图在表述中起到核心作用。
6.1业务模型、功能模型、数据模型各是什么含义？
三者之间有什么关系?
功能模型是描述系统能做什么，即对系统的功能、性能、接口和界面进行定义。
业务模型是描述系统在何时、何地、由何角色、按什么业务规则去做，以及做的步骤或流程，即对系统的操作流程进行定义。
数据模型是描述系统工作前的数据来自何处，工作中的数据存到什么地方，工作后的数据放到何处，以及这些数据之间的关联，即对系统的数据结构进行定义。
功能模型和业务模型是在需求分析时建模，是两个基本点。
数据模型是一个中心，在设计时建模。
功能模型和业务模型给数据模型提供数据与维护数据，数据模型支持功能模型和业务模型的正常运行。
通常，数据模型建模用PowerDesigner，ERWin或OracleDesigner工具实现；
功能模型用功能点列表（或用况图）表示；
业务模型用自然语言加上流程图（或顺序图）表示。
信息系统的业务模型就是系统的操作流程和业务规则，功能模型就是系统的功能菜单和用户界面，数据模型就是系统的数据结构和数据字典。
第七章：
三层结构优点
（1）.三层之间的低耦合，所以互不干扰，哪一层出了问题就去找哪一层去解决；
（2）.三层结构减少了客户机的工作量，提高了网络系统的运行效率；
（3）.三层结构有利于系统的维护和升级，各个层的维护，互不影响。
例如，修改表示层，不会影响用修改业务层；
修改业务层，也不会影响用修改数据层。
而且，所有层的维护与修改，都是在服务器上进行，不需要到用户现场出差。
软件设计原理，就是各种软件设计方法都应该遵守的共同基本原理。
这些设计原理包括：
抽象、模块化、信息隐藏、模块独立性、封装
升级会员 