目录
5.1软件工程
5.1.1架构设计
1.软件架构风格
软件架构设计的一个核心问题是能否达到架构级的软件复用，也就是说，能否在不同的系统中使用同一个软件架构。
软件架构分为：
①数据流风格。数据流风格包括批处理序列和管道/过滤器两种风格。
②调用/返回风格。调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
③独立构件风格。独立构件风格包括进程通信和事件驱动的系统。
④虚拟机风格。虚拟机风格包括解释器和基于规则的系统。
⑤仓库风格。仓库风格包括数据库系统、黑板系统和超文本系统。
2.软件架构评估
软件架构评估可以只针对一个架构，也可以针对一组架构。在架构评估过程中，评估人员所关注的是系统的质量属性。
敏感点(SensitivityPoint)和权衡点(Trade-offPoint)。敏感点是一个或多个构件(或之间的关系)的特性，权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
三类主要的评估方式，分别是基于调查问卷(或检查表)的方式、基于场景的方式和基于度量的方式。
这三种评估方式中，基于场景的评估方式最为常用。
基于场景的方式主要包括：架构权衡分析法(ArchitectureTrade-offAnalysisMethod,ATAM)、软件架构分析法(SoftwareArchitectureAnalysisMethod,SAAM)和成本效益分析法(CostBenefitAnalysisMethod,CBAM)
在架构评估中，一般采用刺激(Stimulus)、环境(Environment)和响应(Response)三方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激做出反应的。
5.1.2需求分析
1.需求的层次
简单地说，软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求。
质量功能部署(QualityFunctionDeployment,QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
2.需求过程
需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。
1)需求获取
常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
2)需求分析
需求分析的关键在于对问题域的研究与理解。
使用结构化分析(StructuredAnalysis,SA)方法进行需求分析，其建立的模型的核心是数据字典。
三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。
实体关系图(E-R图)表示数据模型，用数据流图(DataFlowDiagram,DFD)表示功能模型，用状态转换图(StateTransformDiagram,STD)表示行为模型。
面向对象的分析(Object-OrientedAnalysis,OOA)OOA模型包括用例模型和分析模型，用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模；分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型),以及它们如何保持通信，实现系统行为(动态模型)。
3)需求规格说明书编制
软件需求规格说明书(SoftwareRequirementSpecification,SRS)是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。
4)需求验证与确认
一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审，SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。
3.UML
统一建模语言(UnifiedModelingLanguage,UML)。
UML的结构包括构造块、规则和公共机制三个部分。
1)UML中的事物
UML中的事物也称为建模元素，包括结构事物(StructuralThings)、行为事物(BehavioralThings,也称动作事物)、分组事物(GroupingThings)和注释事物(AnnotationalThings,也称注解事物)。
2)UML中的关系
UML用关系把事物结合在一起，主要有四种关系，分别为：
●依赖(Dependency):依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
●关联(Association):关联描述一组对象之间连接的结构关系。
●泛化(Generalization):泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
●实现(Realization):实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
3)UML2.0中的图
UML2.0包括14种图
顺序图、通信图、定时图是一种交互图。
4)UML视图
包括5个系统视图：
●逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
●进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
●实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。
●部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
●用例视图：用例视图是最基本的需求分析模型。
4.面向对象分析
OOA的任务是“做什么”,OOD的任务是“怎么做”。
面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。
1)用例模型
在OOA方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必须的。
2)分析模型
建立分析模型的过程大致包括定义概念类，确定类之间的关系，为类添加职责，建立交互图等，其中有学者将前三个步骤统称为类-责任-协作者(Class-Responsibility-Collaborator,CRC)建模。
类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等。
5.1.3软件设计
1.结构化设计
结构化设计(StructuredDesign,SD)是一种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。
SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段，其中概要设计又称为总体结构设计，它是开发过程中很关键的一步，其主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
在SD中，需要遵循一个基本的原则：高内聚，低耦合。
2.面向对象设计
面向对象设计(OOD)是OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。
OOD的主要任务是对类和对象进行设计，包括类的属性、方法以及类与类之间的关系。OOD的结果就是设计模型。
常用的O0D原则包括：
●单职原则：设计功能单一的类。本原则与结构化方法的高内聚原则是一致的。
●开闭原则：对扩展开放，对修改封闭。
●李氏替换原则：子类可以替换父类。
●依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程。
●接口隔离原则：使用多个专门的接口比使用单一的总接口要好。
●组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。
●迪米特原则(最少知识法则):一个对象应当对其他对象有尽可能少的了解。本原则与结构化方法的低耦合原则是一致的。
3.设计模式
根据处理范围不同，设计模式可分为类模式和对象模式。类模式处理类和子类之间的关系，通过继承建立，在编译时刻就被确定下来，属于静态关系；对象模式处理对象之间的关系，这些关系在运行时刻变化，更具动态性。
根据目的和用途不同，设计模式可分为创建型(Creational)模式、结构型(Structural)模式和行为型(Behavioral)模式三种。
①创建型模式主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等；
②结构型模式主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等；
③行为型模式主要用于描述类或对象的交互以及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。
5.1.4软件实现
1.软件配置管理
软件配置管理通过标识产品的组成元素、管理和控制变更、验证、记录和报告配置信息，来控制产品的演进和完整性。
软件配置管理活动包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付等活动。
2.软件编码
程序设计风格包括4个方面：源程序文档化、数据说明、语句结构和输入/输出方法。
程序的定量的复杂程度可以作为模块规模的精确限度。
3.软件测试
软件测试方法可分为静态测试和动态测试。
①静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试一般采用桌前检查(DeskChecking)、代码走查和代码审查。
②动态测试是指在计算机上实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。
使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试的范畴。
黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试中。
5.1.5部署交付
软件的部署和交付不再是一个一劳永逸的过程，而是一个持续不断的过程，伴随在整个软件的开发过程中。
1.软件部署与交付
软件部署与交付是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。
2.持续交付
持续交付是一系列开发实践方法，用来确保让代码能够快速、安全地部署到生产环境中。持续交付是一个完全自动化的过程，当业务开发完成的时候，可以做到一键部署。
持续交付具备的优势主要包括：
●持续交付能够有效缩短提交代码到正式部署上线的时间，降低部署风险；
●持续交付能够自动、快速地提供反馈，及时发现和修复缺陷；
●持续交付让软件在整个生命周期内都处于可部署的状态；
●持续交付能够简化部署步骤，使软件版本更加清晰；
●持续交付能够让交付过程成为一种可靠的、可预期的、可视化的过程
3.持续部署
1)持续部署方案
容器技术目前是部署中最流行的技术，常用的持续部署方案有Kubernetes+Docker和Matrix系统两种。
2)部署原则
在持续部署管理的时候，需要遵循一定的原则，主要包括：
●部署包全部来自统一的存储库；
●所有的环境使用相同的部署方式；
●所有的环境使用相同的部署脚本；
●部署流程编排阶梯式晋级，即在部署过程中需要设置多个检查点，一旦发生问题可以有序地进行回滚操作；
●整体部署由运维人员执行；
●仅通过流水线改变生产环境，防止配置漂移；
●不可变服务器；
●部署方式采用蓝绿部署或金丝雀部署。
3)部署层次
部署层次的设置对于部署管理来说也是非常重要的。首先要明确部署的目的并不是部署一个可工作的软件，而是部署一套可正常运行的环境。
完整的镜像部署包括三个环节：Build—Ship—Run。
●Build:跟传统的编译类似，将软件编译形成RPM包或者Jar包；
●Ship:则是将所需的第三方依赖和第三方插件安装到环境中；
●Run:就是在不同的地方启动整套环境。
制作完成部署包之后，每次需要变更软件或者第三方依赖以及插件升级的时候，不需要重新打包，直接更新部署包即可。
4)不可变服务器
不可变服务器是一种部署模式，是指除了更新和安装补丁程序以外，不对服务器进行任何更改。
5)蓝绿部署和金丝雀部署
蓝绿部署是指在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整。
金丝雀部署是指当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问题，就及时处理并重新发布；如果一切正常，就稳步地将新版本适配给所有的用户。
4.部署与交付的新趋势
持续集成、持续交付和持续部署的出现及流行反映了新的软件开发模式与发展趋势，主要表现为：工作职责和人员分工的转变、大数据和云计算基础设施的普及进一步给部署带来新的飞跃、研发运维的融合。
5.1.6过程管理
软件过程能力是组织基于软件过程、技术、资源和人员能力达成业务目标的综合能力。包括治理能力、开发与交付能力、管理与支持能力、组织管理能力等方面。
1.成熟度模型
CSMM模型由4个能力域、20个能力子域、161个能力要求组成。
治理、开发与交付、管理与支持、组织管理。
2.成熟度等级
1级：初始级、2级：项目规范级、3级：组 织改进级、4级：量化提升级、5级：创新引领级
416
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
