Title: 软件开发流程
Notebook: Code
Tags: EVND
Tags:

出处

[TOC]

st=>start: 开始q
e=>end: 结束
op1=>operation: 操作步骤
cond=>condition: 是 或者 否?
op2=>operation: 还有一步呢
op3=>operation: end 在哪?

st->op1->cond
cond(no)->op1
cond(yes)->op2
op2->op3->e->

1
2
3
4
5
6
7
8
9
10

st=>start: Start:>https://www.zybuluo.com
io=>inputoutput: verification
op=>operation: Your Operation
cond=>condition: Yes or No?
sub=>subroutine: Your Subroutine
e=>end

st->io->op->cond
cond(yes)->e
cond(no)->sub->io

项目启动会

• 明确产品开发项目的目标

• 说明项目目标、阶段划分、组织结构、管理流程等关键事项，
  并将这些内容写入 PPT（最好是有固定格式和范文，让团队内部或者公司内部共同遵守规范）

• 对于角色的任命

用户需求

确定代价和所获得价值的对比

ROI（Return On investment）

并安排资源支撑软件生存

制定客户需求

• 客户需求由客户提出,不描述技术, 只描述产品目标

• 产品需求由客户需求转化而来的技术实现需求

  针对客户希求的产品目标进行细分,总结每一个具体功能点
  
  针对每一个功能细节 细分不同的操作流程
  
  每一个流程进行技术化定义
  

制定产品需求

• 为什么要做这个项目从而确定本质业务需求
  • 从业务需求里确定需求分析

• 产品需求包括 需求规格说明书和产品需求矩阵

  产品需求矩阵一般按照子系统、功能集、执行单元的结构列出所有的功能需求，

  每列则对应每项功能的工作步骤以及每个步骤的工作量。

评审产品需求

1. 产品,技术描述是否完整

2. 产品功能正常的场景是什么

3. 是否形成闭环

4. 异常场景是什么

5. 是否考虑周全

• 开发人员

  技术方案

  • 评审

  包括

  业务流程图为了树立开发对业务理解,是否和需求一致

  时序图梳理需求设计的系统交互

• 测试人员

  测试用例

总体设计

对待开发系统的架构进行分析和设计,并建立系统构架的基线，以提供一个稳定的基础。

设计:
`帮助人类梳理业务逻辑,抓住核心需求`
稳定可拓展的业务系统
评估业务开发周期和成本`有效规避风险`

整个系统框架型设计

##初始设计

在对给定的数据流图进行复审和精化的基础上，将其转化为初始的模块结构图。

##精化设计

依据模块“高内聚低耦合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口。

##设计复审

对前两个阶段得到的高层软件结构进行复审，必要时还可能需要对软件结构做一些精化工作。

概要设计

描述系统的每个模块的内部设计，对总体设计和详细设计承担承上启下的作用。

按照结构化设计方法进行设计

按照问题域，将软件逐级细化，分解为不必再分解的的模块，每个模块完成一定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。

软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块间调用关系和接口.

主要集中于划分模块、分配任务、定义调用关系。

模块间的接口与传参在这个阶段要制定得十分细致明确，需要编写严谨的数据字典

• 反复地进行结构调整合并功能重复的模块,分解可复用的模块

最大限度地提取可以重用的模块，建立合理的结构体系

分层数据流图

结构图

数据字典以及相应的文字说明等。

详细设计

依据概要设计阶段的分解，设计每个模块内的算法、流程，为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。
描述某一个模块内部的处理流程、开发方法和编码技巧。

设计者的工作对象是一个模块，根据概要设计赋予的局部任务和对外接口，设计并表达出模块的算法、流程、状态转换等内容。

如果发现有结构调整（如分解出子模块等）的必要，必须返回到概要设计阶段，将调整反应到概要设计文档中，而不 能就地解决，不打招呼。

详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。
一个模块对应一篇详细设计文档。

生成软件结构图

• 流程图
• N-S 图
• PAD 图

• 伪代码

  项目简介
  模块说明（具体说明每一个模块内部的流程、功能、逻辑、消耗以及未解决问题）
  接口设计（包括内部接口和外部接口）、数据结构设计（包括物理结构和逻辑结构）
  特殊处理等

编写代码

核心模块的压测

业务压力在哪里，业务请求的重心在哪里

确保过程可控

一定要保持中间的输出

多打日志

在代码不满意,效率不够,不够简洁,但不是重点时,留下注释
下一步优化思路,或可行方案

简单易懂的逻辑

可读性,有必要时切分函数

不要沉迷框架

避免繁冗嵌套

使用熟悉成熟的技术

使用新技术前，建议全面了解该技术的特征，适用范围，以及不适用的范围

代码审核

提升代码质量，分享项目知识、明确责任，最终达到构建更好的软件、更好的团队。

一周一次

利于跟踪项目进展情况

更早发现是否误入歧途

单元测试 白盒测试

一个功能块或者方法的测试

对单元的代码细节很清楚才能做的测试。

单元测试的编写和执行都是由软件工程师来做的。

测试逻辑所依赖的环境是否正常不是单元测试的目的.
在环境访问代码中引入逻辑，只会让逻辑更难测试，导致逻辑代码无法进行单元测试。
可测试代码可用 main 直接运行
可测试的代码还有另一个特征，就是该方法单元的参数，开发人员可以自由模拟，不需要依赖外部环境。

集成测试 黑盒测试

组装测试或联合测试

将所有模块按照设计要求组装成为子系统或系统，进行集成测试。

测试人员根据软件的功能手册来进行测试，需要有专门的测试环境配合。集成测试又分功能测试、回归测试等。

检查软件单位之间的接口是否正确

根据集成测试计划 ，一边将模块或其他模块组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。

在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元、功能模块接口、链接等）进行的联合测试，以决定他们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。

• 自顶向下

• 自底向上

系统测试 黑盒测试

系统测试方案及用例编写、功能性测试、性能测试、稳定性测试。

>验证需求分析确定的功能是否齐全并被正确实现
>对安装、部署、适应性、安全性、界面等非功能性需求进行测试

功能性测试

主要测试系统是否符合“需求规格说明书”,把系统完整地模拟客户环境来进行的测试.
将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。

性能测试

验证系统的稳定性和效率，检查系统是否满足规定的性能要求。

选择一些典型的功能，检验这些功能在大量用户同时使用系统时系统是否稳定。
性能测试由测试人员负责，可以在系统测试完成后进行，
也可以对重要模块先进行性能测试，可以贯穿整个测试周期，

尽早发现系统的性能瓶颈并提早解决

稳定性测试和性能测试

等到系统基本没问题、趋于稳定时再进行才有效果

稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为 7x24 小时），检测系统是否能够稳定运行。

产品发布 如不需要试制环节

系统测试员输出系统测试报告并批准产品发布（上线）就可以了。

产品发布前需要通过产品发布说明会形式，对整个产品开发过程从立项开始回溯过程，指出整个过程中的不足点，总结经验，为下一个项目提供经验案例。

尽最大可能说清楚这个产品发布之后的效果、效益，为上线后的价值评估做准备。

开发复盘

所有的总结，只有带着问题去思考才会有收获，这就是复盘。
总结项目经验教训的目的，在于总结问题、分析原因，避免以后犯同样的错误.