文章目录
-
- 一、软件工程概述
- 二、软件过程管理
- 三、软件开发项目管理
- 四、软件质量管理
一、软件工程概述
-
基于构件的软件开发，主要强调在构建软件系统时复用已有的软件“构件”，在检索到可以使用的构件后，需要针对新系统的需求对构件进行合格性检验、适应性修改，然后集成到新系统中。
-
需求分析确定软件要完成的功能及非功能性要求；
概要设计将需求转化为软件的模块划分，确定模块之间的调用关系；
详细设计将模块进行细化，得到详细的数据结构和算法；
编码根据详细设计进行代码的编写，得到可以运行的软件，并进行单元测试。 -
软件工程是一种层次化的技术，从底向上分别为质量、过程、方法和工具。任何工程方法必须以有组织的质量承诺为基础。
软件工程的基础是过程，过程是将技术结合在一起的凝聚力，使得计算机软件能够被合理地和及时地开发，过程定义了一组关键过程区域，构成了软件项目管理控制的基础；
方法提供了建造软件在技术上需要“如何做”，它覆盖了一系列的任务。方法也依赖于一些基本原则，这些原则控制了每一个技术区域 而且包含建模活动和其他描述技术；
工具对过程和方法提供了自动或半自动的支持，如：计算机辅助软件工程（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模型是瀑布模型的一种演变模型，将测试和分析与设计关联进行，加强分析与设计的验证。
原型模型是一种演化模型，通过快速构建可运行的原型系统，然后根据运行过程中获取的用户反馈进行改进,适用于需求不清晰且经常发生变化，但系统规模不太大且不太复杂。
演化模型特别适用于对软件需求缺乏准确认识的情况。
螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析。
结构化与方法：对于数据处理领域的问题，若系统规模不大且不太复杂，需求也不大。 -
-
-
模块结构评审时，主要包括以下方面的评审：
1.控制流结构：规定了处理模块与处理模块之间的流程关系。检查处理模块之间的控制转移关系与控制转移形式（调用方式）。
2.数据流结构：规定了数据模块是如何被处理模块进行加工的流程关系。检查处理模块与数据模块之间的对应关系；处理模块与数据模块之间的存取关系，如建立、删除、查询、修改等。
3.模块结构与功能结构之间的对应关系：包括功能结构与控制流结构的对应关系；功能结构与数据流结构的对应关系；每个模块的定义（包括功能、输入与输出数据）。 -
容错技术是对某些无法避开的差错，使其影响减至最小的技术。通常冗余技术分为四类，结构冗余、信息冗余、时间冗余和冗余附加技术。其中冗余附加技术是指为实现其他类型冗余技术所需要的资源和技术，包括程序指令、数据、存放和调动它们的空间和通道等。
在屏蔽硬件错误的容错技术中，冗余附加技术包括：关键程序和数据的冗余存储及调用：检测、表决、切换、重构、纠错和复算的实现。
在屏蔽软件错误的容错技术中，冗余附加技术包括：冗余备份程序的存储及调用；实现错误检测和错误恢复的程序；实现容错软件所需的固化程序。 -
软件配置管理SCM用于整个软件工程过程，其主要目标是标识变更、控制变更、确保变更正确的实现， 告变更。其主要内容包括版本管理、配置支持、变更支持、过程支持、团队支持、变化 告和审计支持等。
-
为了使用户满意，软件应该满足两个必要条件：设计的规格说明书符合用户的要求，这称为设计质量；程序按照设计规格说明所规定的情况正确执行，这称为程序质量。
设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明、在软件概要设计阶段产生的软件概要设计说明书等。
主要从以下方面进行评审：软件的规格说明是否合乎用户的要求；可靠性；保密措施实现情况等；操作特性实施情况等；性能实现情况；可修改性、可扩充性、可互换性和可移植性；可测试性；可复用性。 -
软件评审的内容包括设计质量评审、程序质量评审和与运行环境接口的评审。评审的主要目标是为了发现软件中的错误。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！