软件开发领域模型
定义
软件开发模型是指软件开发全部过程、活动和任务结构的框架。
SDLC（软件生命周期）
定义
软件生命周期 - 指的是软件从产生直到报废的生命周期，包含六个阶段。
1、问题定义
主要进行软件研发的背景研究及其研发目的
2、需求分析
对提出的需求进行分析。 分析来源（原型图/软件需求说明书） 参与人员（产品经理、前端、后端、测试） 投入 产出 风险 从而得出可行性分析
3、软件设计阶段
概要设计：数据库、框架等抽象设计 详细设计：伪代码级别
4、编码阶段
分配开发任务、程序员进行编码
5、软件测试阶段
-
单元测试
单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。 方法：属于白盒测试 范围：单元内部的数据结构、逻辑控制、异常处理 评估基准：逻辑覆盖率 好处：确保一个程序模块的行为符合我们设计的测试用例
-
单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。
-
方法：属于白盒测试 范围：单元内部的数据结构、逻辑控制、异常处理 评估基准：逻辑覆盖率 好处：确保一个程序模块的行为符合我们设计的测试用例
-
集成测试
集成测试：是在假定各个软件单元已经通过了单元测试的前提下，检查各个软件单元之间的接口是否正确。 方法：灰盒测试 范围：模块之间接口与接口数据的传递，以及模块组合后的整体功能 评估基准：接口覆盖率 过程： 计划阶段 设计阶段 实现阶段 执行阶段 评估阶段
-
集成测试：是在假定各个软件单元已经通过了单元测试的前提下，检查各个软件单元之间的接口是否正确。
-
方法：灰盒测试 范围：模块之间接口与接口数据的传递，以及模块组合后的整体功能 评估基准：接口覆盖率 过程： 计划阶段 设计阶段 实现阶段 执行阶段 评估阶段
-
系统测试
系统测试：是对整个系统的测试，将硬件、软件、操作人员看作是一个整体，检验系统是否有不符合操作文档的地方。 方法：黑盒测试 范围：整个系统相对于需求的符合度 评估基准：测试用例对于需求规格的覆盖率 内容： 安全测试 压力测试 流畅度测试 兼容性测试
-
系统测试：是对整个系统的测试，将硬件、软件、操作人员看作是一个整体，检验系统是否有不符合操作文档的地方。
-
方法：黑盒测试 范围：整个系统相对于需求的符合度 评估基准：测试用例对于需求规格的覆盖率 内容： 安全测试 压力测试 流畅度测试 兼容性测试
6、软件的运行与维护
-
版本、产品上线（版本的升级改进）、bug的修复等
瀑布模型
软件开发的各项活动严格各个阶段进行，每一个阶段的产出都是下一个阶段的输入，如果下一阶段不通过，则需要返回修改。 优点：适用于大型底层无需改动的系统设计，例如微软windows等底层系统。 缺点：一旦某个环节出了问题就要推到重来，代价大，难以应对灵活度高的需求。
计划
需求分析
软件设计
编码
测试
运行维护
敏捷模型
介绍
-
背景
-
如今是世界已经进入VUCA时代，我们正面对着一个易变（volatility）、不确定（uncertainty）、复杂性（complexity）、和模糊（ambiguity）的世界，而敏捷把需求按优先级排序形成需求池，迭代地进行研发，快速响应变化、快速试错、小步快跑，无疑是符合时代潮流的。
-
-
定义
-
敏捷：是一种价值观 + 原则 + 一系列符合价值观和原则的方法。
-
以用户的需求进化为核心，采用迭代、循序渐进的方法进行开发。
-
推进敏捷
-
1、评估诊断
-
1、选定代表项目
-
2、访谈评估
-
3、制定转型计划和评估
-
-
2、团队试点
-
3、规模化推广
优缺点
-
优点
-
1、适应性更高，响应更快、容错率高
-
2、灵活多变、能发挥每个人的优势，并行开发
-
-
缺点
-
项目周期过长，若无标准开发文档，很难在项目上很好的交接
-
Scrum 敏捷项目管理方法
-
定义
-
Scrum 是一个引申词，原义是橄榄球场上的并列争球，就像橄榄球运动极度强调团队协作一样，它是用于开发和交付软件产品的一个框架，且过程是增量和迭代的
-
-
迭代
-
根据需求优先级，开发工作被拆分为一系列固定周期（一般平均两周）的小项目被称为迭代。每一个迭代都包含了定义、需求分析、设计、实现与测试。
-
-
角色
-
产品负责人PO（Product Owner）
-
代言人
-
从经济层面来考量，他要考虑每一期迭代的资金投入是否合算，或者说投资回报率 ROI（Return on Investment）。最重要的是，与各内部干系人形成一个统一愿景，这些干系人一般会包括业务方、市场人员等等
-
-
产品定性
-
负责敲定要开发什么，以什么优先级顺序开发
-
-
职责
-
1、确定产品的功能；
-
2、决定发布的日期和发布内容；
-
3、为产品的ROI负责；
-
4、根据市场价值确定功能优先级；
-
5、每个sprint中，根据需要调整功能和优先级（每个sprint开始前调整）；
-
6、接受或拒绝开发团队的工作成果；
-
7、参与Scrum Planning Meetings（Sprint计划会议），Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）
-
-
-
敏捷教练（ScrumMaster）
-
负责指导团队在通用的 Scrum 框架上遵循正确的敏捷过程，他也会帮助大家解决跨团队的沟通问题，让每个人理解、并乐于接受 Scrum 的价值观、原则和实践
-
职责
-
1、保证团队资源合理利用；
-
2、保证各个角色及职责良好协作；
-
3、解决团队开发中的障碍；
-
4、作为团队和团队外部的接口，协调解决沟通中的问题；
-
5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）
-
-
-
开发团队（TO）
-
擅长跨团队的沟通
-
组织整个开发团队开展 CodeReview 代码评审会、新知识培训，以及与运维方一起完善 CI/CD
-
-
-
故事点
-
背景
-
由于个人技能水平，团队联调等待，数据准备，团队公共人力等因素会影响让估算不能准确的反映客观的工作量，存在浪费等现象，因此引入了故事点的估算
-
-
定义
-
故事点估算实际上是一个综合的对于用户故事的复杂度，工作量，风险或不确定性等，针对不同的用户故事类型设计不同的基准故事点
-
-
故事点的估算——Story Point＝f(E,R,U,C)
-
工作量（Effort）：开发一款个人信息的web页面 VS 多款web页面
-
复杂度（Complexity）：页面包含不同的组件，比如包含日期，信用卡号，省份等复杂度不同
-
风险（Risk）：改动底层敏感模块，破坏现有功能。
-
不确定性（Uncertain）：需求开发初期不清晰的情况。
-
-
相对大小
-
相对大小是团队估算的基础，有了相对估算，团队估算才可以有效实施
-
-
团队估算
-
1、会给与更多团队成员分析需求的机会，激发了团队分析思考的热情，促进了团队分析能力的快速培养
-
2、在估算的过程中，团队一起碰撞讨论需求，使得对需求的理解更加清晰，更贴近用户的需求，开发风险暴露的越充分
-
-
估算如何在团队间对齐
-
1、将组长设置为一个量化标杆
-
2、根据每个人不同的情况，对应标杆预估故事点
-
-
步骤
-
1、迭代需求分析
-
根据优先级，按照平均2周一个迭代的时间表，划分每次迭代的范围，并梳理本次迭代需求的功能点、业务流程
-
-
2、迭代澄清会议
-
SE向每个开发人员讲解每个需求，并确认每个需求的开发点
-
-
3、故事墙
-
issue一般分为待处理、进行中、已关闭三大类，研发人员根据各自的进度，将issue带入工作流中
-
-
4、开发
-
每个开发以issue为单位进行开发，可建立子任务来辅助开发流程
-
-
5、shouCase
-
每一个故事完成时，需要向SE，展示功能
-
-
6、调试
-
测试人员测试功能，并决定需不需要reopen
-
-
7、复盘
-
梳理团队好的、不好的一些建议。针对不同的方法抽取2~3个，分析解决方法，并在下一个迭代跟进
-
代码质量
-
编码要求
-
编码规范
-
程序架构
-
编码规范
-
-
编码环境
-
代码静态检测
-
自动化测试
-
持续集成环境
-
质量管控
VUCA时代
大纲
-
1、质量元素分析
-
2、软件产品和过程的质量目标
-
3、实施质量活动的人员与职责
-
4、过程检查计划
-
5、技术评审计划
-
6、软件测试计划
-
7、缺陷跟踪工具
-
8、审批意见
基本衡量指标
-
1、覆盖率
-
覆盖率(Coverage Ratio) – 度量完整性的一个指标和手段。
-
覆盖率 ＝ （至少被执行一次的item数） / item的总数。
-
-
2、缺陷修复率
-
衡量解决问题、修复缺陷(BUG)的能力和效率。
-
缺陷修复率 = ∑修复（关闭）的缺陷数量（个） / ∑有效缺陷数量（个）。
-
-
3、测试指标
-
测试绩效指标：如果想衡量我们的测试能力和绩效，可以使用一下的测试绩效指标来分析。
-
缺陷探测率
-
计算内部发现的缺陷数除以内部发现的缺陷数与用户发现的缺陷数之和，主要查看内部发现缺陷的能
-
缺陷探测率 = 内部发现的缺陷数（个） / （内部发现的缺陷数（个）+用户发现的缺陷数（个））*100%。
-
-
有效缺陷率
-
计算被开发人员确认的BUG数总和除于本人上报BUG的总和，可用于查看测试人员的个人测试质量，也可用于查看整个测试组的测试质量。
-
有效缺陷率 = 测试人员发现的有效缺陷数（个） /测试人员发现的总缺陷数（个）*100%。
-
-
用例执行率
-
计算测试人员执行的用例数除以执行测试的时间，主要查看测试人员执行测试的效率。
-
用例执行率 = ∑测试人员执行的用例数（个） / ∑执行用例的时间（h）。
-
-
缺陷发现率
-
计算测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。
-
缺陷发现率 = ∑提交缺陷数（个） / ∑执行测试的有效时间（小时）。
-
-
-
-
4、软件上线交付指标
-
软件发布以后，可能会有故障或者功能回滚（Rollback），可以这么评价。
-
发布回滚率
-
计算计划上线需求个数减去加载回滚的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量。
-
发布回滚率 = （上线需求数（个）-发布当时回滚需求数（个））/上线需求数（个）*100%
-
-
故障回滚率
-
计算计划上线需求个数减去故障回滚的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量
-
故障回滚率 = （上线需求数（个）-故障回滚需求数（个））/上线需求数（个）*100%
-
-
-
质量管理的三套体系
-
1、建立预防体系
-
1）专家培训，不断提高大家的技术水平、管理水平
-
2）流程化，不断提高规范化水平，把经验和教训固化在流程中
-
3）复用化。处理相同的事最好尽量复用现有代码，或者把公共功能做成模块，便于大家复用
-
-
2、建立有效检查体系
-
1）技术评审。请专家对技术方案、思路进行评审，在编码之前找出可能的问题。
-
2）测试。测试是查漏补缺的重要手段
-
软件测试阶段
-
单元测试
单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。 方法：属于白盒测试 范围：单元内部的数据结构、逻辑控制、异常处理 评估基准：逻辑覆盖率 好处：确保一个程序模块的行为符合我们设计的测试用例
-
单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。
-
-
-
-
方法：属于白盒测试 范围：单元内部的数据结构、逻辑控制、异常处理 评估基准：逻辑覆盖率 好处：确保一个程序模块的行为符合我们设计的测试用例
- 集成测试
集成测试：是在假定各个软件单元已经通过了单元测试的前提下，检查各个软件单元之间的接口是否正确。
方法：灰盒测试
范围：模块之间接口与接口数据的传递，以及模块组合后的整体功能
评估基准：接口覆盖率
过程：
计划阶段
设计阶段
实现阶段
执行阶段
评估阶段
- 集成测试：是在假定各个软件单元已经通过了单元测试的前提下，检查各个软件单元之间的接口是否正确。方法：灰盒测试 范围：模块之间接口与接口数据的传递，以及模块组合后的整体功能 评估基准：接口覆盖率 过程： 计划阶段 设计阶段 实现阶段 执行阶段 评估阶段
- 系统测试
系统测试：是对整个系统的测试，将硬件、软件、操作人员看作是一个整体，检验系统是否有不符合操作文档的地方。
方法：黑盒测试
范围：整个系统相对于需求的符合度
评估基准：测试用例对于需求规格的覆盖率
内容：
安全测试
压力测试
流畅度测试
兼容性测试
- 系统测试：是对整个系统的测试，将硬件、软件、操作人员看作是一个整体，检验系统是否有不符合操作文档的地方。方法：黑盒测试 范围：整个系统相对于需求的符合度 评估基准：测试用例对于需求规格的覆盖率 内容： 安全测试 压力测试 流畅度测试 兼容性测试
- 自动化测试
- 静态测试、动态测试、白盒测试、黑盒测试、单元测试、模块测试、系统测试、回归测试、功能测试、性能测试、易用性测试手工测试、自动测试
- 3）过程检查
- 软件开发过程中有一些大家公认的过程或规范能够避免产生一些问题，那这些过程和规范就应该被检查，保证软件开发过程与规范被大家遵守。这主要是QA的工作
- 4）代码评审
- 评审工作主要看代码是否与当初的设计方案一致。这样我们就能最大限制减少问题的产生。-
3、建立快速抢救体系
-
在软件产品发布之后，客户可能会发现问题。因此一定要尽早回应、解决，尽量减少对客户的影响
-
CRM系统等
-
214
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
