博主2023年11月通过了信息系统项目管理的考试，考试过程中发现考试的内容全部是教材中的内容，非常符合我学习的思路，因此博主想通过该平台把自己学习过程中的经验和教材博主认为重要的知识点分享给大家，希望更多的人能够通过考试，知识点完全是根据纸质教材手敲上去的，如果有文字的错误请大家谅解哈，每天都会更新，每天进步一点点
软件架构设计的一个核心问题是能否达到架构级的软件复用；
软件架构分类：
数据流风格：数据流风格包括批处理序列和管道/过滤器两种风格
调用/返回风格：包括主程序/子程序、数据抽象和面向对象，以及层次结构
独立构件风格。独立构件风格包括进程通信和事件驱动的系统
虚拟机风格。虚拟机风格包括解释器和基于规则的系统
仓库风格。包括数据库系统、黑板系统和超文本系统
2、软件架构评估
在架构评估过程中，评估人员所关注的是系统的质量属性。架构评估可归纳为三类：
基于调查问卷的方式
基于场景的方式（最常用）
基于度量的方式
软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反应这些条件或能力的文档说明。
业务需求
用户需求：质量功能部署是一种将用户要求转化成软件需求的技术，七亩地是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标QFD将软件需求分为三类：常规需求、期望需求和意外需求
常规需求
期望需求
意外需求
系统需求
需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认。
需求获取：需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。常见的需求获取方式：用户访谈、问卷调查、采样、情节串联版、联合需求计划
需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确、必要性。
需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不租的地方
结构化分析方法，期间里的模型的核心是数据字段。围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型。一般使用实体关系图（E-R图）表示数据模型，用数据流图表示功能模型，用状态转换图表示行为模型。E-R图主要描述实体、属性，以及实体之间的关系；DFD从数据传递和加工的角度利用图形符号通过逐层细分描述系统内各个部件的功能和数据在他们之间传递的情况，来说明系统所完成的功能；STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，支出作为特定时间的结果将执行哪些动作。
面相对象分析
需求规格说明书编制：是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础
需求验证与确认：一般通过需求评审和需求测试工作来对需求进行验证
UML中的实物
UML中的关系：
依赖：依赖是两个事务之间的语义关系，其中一个事物发生变化会影响另一个事物的语义
关联：关联描述一组对象之间链接的结构关系
泛化：泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象
实现：实现是类之间的语义关系，其中的一个类制定了由另一个类保证执行的契约
UML2.0中的图：
类图
对象图
构件图
组合结构图
用例图
顺序图
通信图
定时图
状态图
活动图
部署图
制品图
包图
交互概览图
UML视图：
逻辑视图：也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分
进程视图：进程视图是可执行线程和进程作为活动类的建模，他是逻辑视图的一次执行实例
实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模
部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构
用例视图：用例视图是最基本的需求分析模型
OOA方法中构件用例模型一般需求经理四个阶段：
识别参与者（必须的）
合并需求获得用例（必须的）
细化用例描述（必须的）
调整用例模型
是一种面向数据流的方法，他一SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段，其中概要设计又称为总体结构设计。在SD中，需要遵循一个基本的原则：高内聚，低耦合。
面相对象设计时OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。
OOD原则：单职原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、组合重用原则、迪米特原则
根据目的和用途不同，设计模式可分为创建型模式、结构型模式、行为型模式
创建型：工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式
结构型：处理类和对象的组合，适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式
行为型：主要用于描述类或对象交互以及职责的分配，职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、魔板方法模式、访问者模式
包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件分布管理与交付
目的是验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。
软件测试方法可分为静态测试和动态测试：
静态测试：采用人工检测和计算机辅助静态分析的手段对程序进行检测。包括对文档或代码的静态测试，对文档主要以检查单的方式，对代码是以桌签检查、代码走查和代码审查
动态测试：在金算计上世纪运行程序进行软件测试包括黑盒测试和白盒测试。
白盒测试：白盒测试也称为结构测试，主要用于单元测试，主要有控制流测试、数据流测试和程序编译测试。静态测试方法也可以实现白盒测试。最常用使用的技术是逻辑覆盖。
黑盒测试：也称为功能测试，主要用于集成测试、确认测试和系统测试，只检查程序工嗯呢是否能按照SRS的要求正常使用。黑盒测试根据SRS所规定的功能来设计测试用例，一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验发
软件部署与交付是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。
持续交付是一些列开发实践方法，用来确保让代码能够快速、安全地部署到生产环境中。持续交付是一个完全自动化的过程，当业务开发完成的时候，可以做到一键部署。持续交付提供了一套更为完善的解决传统软件开发流程的方案
在需求阶段，抛弃了传统的需求文档的方式，使用便于开发人员理解的用户故事；
在开发测试阶段，做到持续集成，让测试人员今早进入项目喀什测试
在运维阶段，打通开发和运维之间的通路，保持开发环境和运维环境的统一
持续交付具备的优势主要包括：
能够有效缩短提交代码到正式部署上线的时间，降低部署风险
能够自动、快速地提供反馈，及时发现和修复缺陷
让软件在整个生命周期内都处于可部署的状态
能够简化部署步骤，使软件版本更加清晰
能够让交付过程称为一种可靠的、可预期的、可视化的过程
持续部署方案：容器技术目前是部署中最流行的技术
部署原则
部署层次：三个环节：build-ship-run
不可变服务器：是一种部署模式，是指出了更新和安装补丁程序以外，不对服务器进行任何更改
蓝绿部署和金丝雀部署
蓝绿部署：部署的时候准备新旧两个部署版本，通过域名解析切花的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整。
金丝雀部署：指当有新版本发布的时候，先让少量的用户使用新版本，并且观察新版本是否存在问题，如果出现问题就几十处理并重新发布；如果一切正常就稳步地将新版本适配给所有的用户
CSMM模型由4个能力域、2-哥能力子域、161个能力要求组成：
治理：战略与治理、目标管理能力子域，用于确定组织的战略、产品的方向、组织的业务目标，并确保目标的实现
开发与交付：包括需求、设计、开发、测试、部署、服务、开源应用能力子域，这些能力子域确保通过软件功能过程交付满足需求的软件，为顾客与利益干系人增加价值
管理与支持：项目策划、项目监控、项目结项、质量保证、风险管理、配置管理、供应商管理能力子域，这些能力子域覆盖了软件开发项目的全过程，以确保软件项目能够按照既定的成本、进度和质量交付，能够满足顾客与利益干系人的要求
组织管理：包括过程管理、人员能力管理、组织资源管理、过程能力管理能力子域，对软件组织能力进行综合管理