一、软件工程概述
-
基于构件的软件开发，主要强调在构建软件系统时复用已有的软件“构件”，在检索到可以使用的构件后，需要针对新系统的需求对构件进行合格性检验、适应性修改，然后集成到新系统中。
-
需求分析确定软件要完成的功能及非功能性要求；
概要设计将需求转化为软件的模块划分，确定模块之间的调用关系；
详细设计将模块进行细化，得到详细的数据结构和算法；
编码根据详细设计进行代码的编写，得到可以运行的软件，并进行单元测试。 -
软件工程是一种层次化的技术，从底向上分别为质量、过程、方法和工具。任何工程方法必须以有组织的质量承诺为基础。
软件工程的基础是过程，过程是将技术结合在一起的凝聚力，使得计算机软件能够被合理地和及时地开发，过程定义了一组关键过程区域，构成了软件项目管理控制的基础；
方法提供了建造软件在技术上需要“如何做”，它覆盖了一系列的任务。方法也依赖于一些基本原则，这些原则控制了每一个技术区域 而且包含建模活动和其他描述技术；
工具对过程和方法提供了自动或半自动的支持，如：计算机辅助软件工程（CASE）。
软件工程的基本要素包括方法、工具和过程。 -
软件需求是软件系统必须完成的事以及必须具备的品质。软件需求包括功能需求、非功能需求和设计约束三个方面的内容。
功能需求是所开发的软件必须具备什么样的功能：
非功能需求是指产品必须具备的属性或品质，如可靠性、性能、响应时间和扩展性等等;
设计约束通常对解决方案的一些约束说明。“软件产品必须能够在3秒内对用户请求作出响应”主要表述软件的响应时间，属于非功能需求。 -
I/O软件隐藏了I/O操作实现的细节。I/O软件向用户提供的是逻辑接口。I/O软件将硬件与较高层次的软件隔离开来，而最高层软件向应用提供一个友好的、清晰且统一的接口，方便用户使用。
-
软件开发的增量模型：
增量模型是一种非整体开发的模型，该模型具有较大的灵活性，适合于软件需求不明确的一种模型。使用该模型开发产品，一般是尽快构造出可运行的产品，然后在该产品的基础上再增加需要的新的构建，使产品更趋于完善。 -
增量式开发的主要优点包括：
1.由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。
2.由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。
3.对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只变更部分部件，而不必影响整个系统。
主要缺点包括：
1.由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2.在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
3.如果增量包之间存在相交的情况且未很好处理，则必须 -
软件复杂性度量是软件度量的一个重要分支。
软件复杂性度量的参数有很多，主要包括：
1.规模，即指令数或者源程序行数；
2.难度，通常由程序中出现的操作数所决定的量来表示；
3.结构，通常用与程序结构有关的度量来表示；
4.智能度，即算法的难易程度。 -
三层C/S体系结构由逻辑上相互分离的表示层、业务层和数据层构成。其中表示层向客户提供数据，业务层实施业务相数据规则，数据层定义数据访问标准。该体系结构具有许多优点，如逻辑上相对独立，不同层可以用不同的平台、软件和开发语言，而系统的安装、修改和维护在各层都可能进行。
-
一般来讲，概要设计的内容可以包含系统构架、模块划分、系统接口、数据设计4个主要方面的内容，不包括模块内算法设计。
-
逆向工程从源代码得到软件系统的规格说明和设计信息，属于软件维护阶段行为，因此逆向工程工具属于软件维护工具。
二、软件过程管理
-
敏捷方法中，重构是一种重新组织技术，重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求，可以简化构件的设计而无需改变其功能或行为。
-
敏捷开发方法scrum的步骤：
Product Backlog 产品待办事项清单；
Refactoring 重构，不属于scrum的步骤；
Sprint Backlog，Sprint待办事项清单；
Sprint，冲刺迭代。 -
在敏捷开发的过程中：
极限编程XP是激发开发人员创造性、使得管理负担最小的一组技术；
水晶法Crystal认为每一个不同的项目都需要一套不同的策略、约定和方法论；
并列争球法（Scrum）使用迭代的方法，其中把每30天一次的迭代成为一个冲刺，并按需求的优先级来实现产品。多个自组织和自治小组并行地递增实现产品，并通过简短的日常情况会议进行协调。 -
敏捷开发方法XP是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法，其特性包含在12个最佳实践中。
1.计划游戏：快速制定计划、随着细节的不断变化而完善；
2.小型发布：系统的设计要能够尽可能早地交付；
3.隐喻：找到合适的比喻传达信息；
4.简单设计：只处理当前的需求使设计保持简单；
5.测试先行：先写测试代码再编写程序；
6.重构：重新审视需求和设计，重新明确地描述它们，以符合新的和现有的需求;
7.结队编程；
8.集体代码所有制；
9.持续集成：可以按日甚至按小时为客户提供可运行的版本；
10.每周工作40个小时；
11.现场客户；
12.编码标准。 -
统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，定义了不同阶段及其制品，
起始阶段专注于项目的初创活动。
精化阶段理解了最初的领域范围之后，进行需求分析和架构演进。
构建阶段关注系统的构建，产生实现模型。
移交阶段关注于软件提交方面的工作，产生软件增量。
产生阶段运行软件并监控软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更请求。 -
RUP应用了角色、活动、制品和工作流4种重要的模型元素，其中
角色表述“谁做”，
制品表述“做什么”，
活动表述“怎么做”，
工作流表述“什么时候做”。 -
CMM（Capability Maturity Model）是能力成熟度模型的缩写，。CMM共分五级。在每一级中，定义了达到该级过程管理水平所应解决的关键问题和关键过程。每一较低级别是达到较高级别的基础。其中
五级是最高级，即优化级，达到该级的软件公司过程可自发地不断改进，防止同类问题二次出现；
四级称为已管理级，达到该级的软件公司已实现过程的定量化；
三级为已定义级，即过程实现标准化；
二级为可重复级，达到该级的软件公司过程已制度化，有纪律，可重复；
一级为初始级，过程无序，进度、预算、功能和质量等方面不可预测。
三、软件开发项目管理
-
常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。
瀑布模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型，适合于软件需求很明确的软件项目。
V模型是瀑布模型的一种演变模型，将测试和分析与设计关联进行，加强分析与设计的验证。
原型模型是一种演化模型，通过快速构建可运行的原型系统，然后根据运行过程中获取的用户反馈进行改进,适用于需求不清晰且经常发生变化，但系统规模不太大且不太复杂。
演化模型特别适用于对软件需求缺乏准确认识的情况。
螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析。
结构化与方法：对于数据处理领域的问题，若系统规模不大且不太复杂，需求也不大。 -
根据上图计算出关键路径为A-B-D-G-I-K-L，其长度为22，关键路径上的活动均为关键活动。活动BD在关键路径上，因此松弛时间为0。 -
图中任务流A→G→I的持续时间为15；任务流A→D→F→H→I的持续时间为18；任务流B→E→G→I的持续时间为20；任务流C→F→H→I的持续时间为13。因此关键路径为B→E→G→I，其持续时间是20。
任务A处于任务流A→G→I和任务流A→D→F→H→I中，分别持续时间为15和18，A所在任务流持续时间最长为18，关键路径B→E→G→I，其持续时间是20，因此任务A的可延迟开始时间为2。 -
根据关键路径法，计算出关键路径为A—C—G—J—K，关键路径长度为65。
因此里程碑C在关键路径上，而里程碑B、D和I不在关键路径上。 若完成活动DG需要15天，则相当于A–D--G–J--K也是一个关键路径，而且活动AD推迟了三天才能完成，
此时，完成项目的最短时间应该是68天，比原来的最短时间65天多了3天。 -
活动图是描述一个项目中各个工作任务相互依赖关系的一种模型，项目的很多重要特性可以通过分析活动图得到，如估算项目完成时间，计算关键路径和关键活动等。根据上表给出的数据，构建活动图，如下图所示。
从上图很容易看出，关键路径为A-D-E-F-H，其长度为19，关键路径上的活动均为关键活动。 不能通过缩短非关键活动的工期，来缩短整个项目的完成时间。 -
在对软件开发资源进行规划时，为了确定构建软件系统所需的人数，
需要考虑软件系统的规模、
系统的技术复杂性、
项目计划和开发人员的技术背景等方面，
而与系统是否有市场前景无关。 -
风险是一种具有负面后果的、人们不希望发生的事件。通常认为
风险具有以下特点：
风险是可能发生的事件，其发生的可能性用风险概率来描述；
风险是会给项目带来损失的事件；
可能对风险进行干预，以期减少损失。
针对每一种风险，应弄清可能减少造成损失或避免损失的程度。对风险加以控制，采取一些有效的措施来降低风险或是消除风险。 -
风险分析实际上是4个不同的活动：风险识别、风险预测、风险评估和风险控制。
风险识别是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。
风险预测又称为风险估算，它从两个方面评估一个风险：风险发生的可能性或概率；以及如果风险发生时所产生的后果。
风险评估根据风险及其发生的概率和产生的影响预测是否影响 参考水平值, 定义风险参照水准是风险评估的一类技术，对于大多数软件项目来说成本、速度和性能是三种典型的风险参照水准。 。
风险控制的目的是辅助项目组建立处理风险的策略，有效的策略应考虑风 险避免、风险监控、风险管理及意外事件计划。 -
风险避免即放弃或不进行可能带来损失的活动或工作。例如，为了避免洪水风险，可以把工厂建在地势较高、排水方便的地方，这是一种主动的风险控制方法。
风险监控是指在决策主体的运行过程中，对风险的发展与变化情况进行全程监督，并根据需要进行应对策略的调整。
风险管理是指在一个肯定有风险的环境里把风险减至最低的管理过程。对于风险我们可以转移，可以规避，但不能消除,根据风险的优先级来确定风险控制策略，而优先级是根据风险暴露来确定的。
风险暴露是一种量化风险影响的指标，等于风险影响乘以风险概率，
风险影响是当风险发生时造成的损失。
风险概率是风险发生的可能性。 -
COCOMO用3个不同层次的模型来反映不同程度的复杂性，它们分别为：
基本模型（Basic Model）：是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的函数来计算软件开发工作量。
中级模型（Intermediate Model）：则在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
详细模型（Detailed Model）：包括中级COCOMO型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。 -
存在多种软件项目管理的成本估算方法。其中
专家估算方法主要依赖于专家的背景和经验，具有较大的主观性。
Wolverton模型基于一个成本矩阵，定义不同的软件类型（如控制、输入/输出等）和难易（容易和困难）的成本，基于此计算软件开发的成本。
COCOMO模型将规模视为成本的主要因素，考虑多个成本驱动因子。
在后来的版本COCOMO II中，还考虑了软件开发的不同阶段，包含三个阶段性模型，即应用组装模型、早期设计阶段模型和体系结构阶段模型。 -
COCOMOII模型也需要使用规模估算信息，在模型层次结构中有3种不同规模估算选择，即：对象点、功能点和代码行。
-
大规模项目最不适于采用无主程序员组的开发人员组织形式，因为大项目需要主程序员来整合各模块程序。
-
结构化分析模型包括数据流图、实体联系图、状态迁移图和数据字典，因此这些模型是需求分析阶段的输出。而确定软件体系结构是在软件设计阶段进行的。
-
无主程序员组的开发小组，每两十开发人员之间都有沟通路径，因此，8人组成的开发小组沟通路径为完全连通无向图的边数，即 m = n（n-1）/2，其中n和m分另表示图的顶点数和边数。当n=8时，m==28。
主程序员组中，除了主程序员外的每个开发人员只能和主程序员沟通，因此8人组成的开发小组的沟通路径8-1=7。 -
软件变更控制是变更管理的重要内容，要有效进行变更控制，需要借助配置数据库和基线的概念。配置数据库一般包括开发库、受控库和产品库。
-
配置管理是软件开发过程的重要内容，贯穿软件开发的整个过程。其内容包括：软件配置标识、变更管理、版本控制、系统建立、配置审核和配置状态报告。
-
系统开发人员与项目管理人员在项目期内进行沟通的文档主要有系统开发计划、系统开发月报以及系统开发总结报告等项目管理文件。
-
髙质量的文档应该体现在几个方面：
针对性，文档编制应考虑读者。按不同的类型、不同层次的读者，决定怎样适应他们的需要；
精确性，文档的行文应该十分确切，不能出现多义性的描述。同一项目几个文档的内容应该是协调一致，没有矛盾的；
清晰性， 文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性；
完整性，任何文 档都应当是完整的、独立的，应该自成体系；灵活性，各个不同软件项目，其规模和复 杂程度有着许多实际差别，不能一律看待；
可追溯性，由于各开发阶段编制的文档与各个阶段完成的工作有密切的关系，前后两个阶段生成的文档，随着开发工作的逐步延伸， 具有一定的继承关系，在一个项目各开发阶段之间提供的文档必定存在着可追溯的关系。 -
文档是系统建设过程的“痕迹”，是系统维护人员的指南，是开发人员与用户交流的工具。文档不仅仅描述和规定软件的适用范围及相关的操作命令。软件包括程序和文档，因此没有文档的软件不能称之为软件产品。软件文档的编制在软件开发中是相当重要的，高质量的文档对于发挥软件产品的效益有着重要的意义。
四、软件质量管理
-
-
模块结构评审时，主要包括以下方面的评审：
1.控制流结构：规定了处理模块与处理模块之间的流程关系。检查处理模块之间的控制转移关系与控制转移形式（调用方式）。
2.数据流结构：规定了数据模块是如何被处理模块进行加工的流程关系。检查处理模块与数据模块之间的对应关系；处理模块与数据模块之间的存取关系，如建立、删除、查询、修改等。
3.模块结构与功能结构之间的对应关系：包括功能结构与控制流结构的对应关系；功能结构与数据流结构的对应关系；每个模块的定义（包括功能、输入与输出数据）。 -
容错技术是对某些无法避开的差错，使其影响减至最小的技术。通常冗余技术分为四类，结构冗余、信息冗余、时间冗余和冗余附加技术。其中冗余附加技术是指为实现其他类型冗余技术所需要的资源和技术，包括程序指令、数据、存放和调动它们的空间和通道等。
在屏蔽硬件错误的容错技术中，冗余附加技术包括：关键程序和数据的冗余存储及调用：检测、表决、切换、重构、纠错和复算的实现。
在屏蔽软件错误的容错技术中，冗余附加技术包括：冗余备份程序的存储及调用；实现错误检测和错误恢复的程序；实现容错软件所需的固化程序。 -
软件配置管理SCM用于整个软件工程过程，其主要目标是标识变更、控制变更、确保变更正确的实现，报告变更。其主要内容包括版本管理、配置支持、变更支持、过程支持、团队支持、变化报告和审计支持等。
-
为了使用户满意，软件应该满足两个必要条件：设计的规格说明书符合用户的要求，这称为设计质量；程序按照设计规格说明所规定的情况正确执行，这称为程序质量。
设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明、在软件概要设计阶段产生的软件概要设计说明书等。
主要从以下方面进行评审：软件的规格说明是否合乎用户的要求；可靠性；保密措施实现情况等；操作特性实施情况等；性能实现情况；可修改性、可扩充性、可互换性和可移植性；可测试性；可复用性。 -
软件评审的内容包括设计质量评审、程序质量评审和与运行环境接口的评审。评审的主要目标是为了发现软件中的错误。
1991
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
