软件文档写作

This commit is contained in:
yinkanglong_lab
2021-03-08 21:48:04 +08:00
parent 87a902041d
commit b3c226d7ce
46 changed files with 2803 additions and 0 deletions

View File

@@ -0,0 +1 @@
## 丢失

View File

@@ -0,0 +1,63 @@
### 软件文档的定义
软件 = 程序+文档+数据。
文档是某种数据媒体和其中所记录的数据。
### 软件文档的特点
文档具有永久性,可供人阅读。
文档是计算机软件的重要组成部分
### 软件的生存周期
* 从构思软件开始到该产品不再使用为止的时间段
* 分为计划、开发、运行三个时期。不同实践不同角色参与其中。
* 计划时期:
* 问题分析
* 可行性研究
* 制定计划
* 开发时期
* 需求分析
* 概要设计
* 详细设计
* 编码测试
* 软件发布
* 运行维护时期
* 运行维护
### 软件文档的作用
管理的依据
技术交流的语言
软件质量的保证
支持培训与参考
支持软件维护
记录软件的历史
### 软件文档的分类
* 使用范围:
* 管理类文档,记录项目管理的信息
* 开发类文档,描述软件开发过程本身
* 产品类文档,描述开发过程的产物
* 阅读对象:
* 管理人员
* 开发人员
* 维护人员
* 最终用户
* 软件开发方法
* 面向过成的文档
* 面向对象的文档
### 软件工程文档标准化的意义
* 提高软件的可靠性、可维护性和可移植性
* 提高软件的生产率和软件人员的技术水平
* 提高软件人员之间的通信效率,减少差错和误解
* 有利于软件管理
* 有利于降低软件产品的成本和运行维护成本
* 有利于缩短软件开发周期
### 软件工程文档标准的层次:
国际标准
国家标准
行业标准
企业规范
项目规范
### 常见的软件文档类型

Binary file not shown.

After

Width:  |  Height:  |  Size: 104 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 90 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 171 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 88 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 68 KiB

View File

@@ -0,0 +1,57 @@
### 软件文档编制的原则
应该适应文档的读者
应有必要的重复性
应具有一定的灵活性
应覆盖整个软件的生存周期
应是可管理的
应采用并标明文档标准
应规定支持的工具
### 软件文档编制的灵活性
文档的种类
文档的详细程度
文档的扩展
章节的扩展与缩并
程序设计的表现形式
文档的表现形式
文档的其他种类
### 软件文档标准的建立步骤
选择软件生存周期模型
规定文档类型和内容
确定文档的质量等级
最低限度文档(一级文档):个人开发自用
内部文档2级文档团队内部交流
工作文档3级文档项目开发
正式文档4级文档产品开发
### 软件文档编制的步骤
制定文档编制计划
编写文档
文档编号
文档评审
文档部署
文档的归档与保存
文档维护
### 软件文档的质量要求
针对性
精确性
清晰性
完整性
灵活性
可追溯性
### 软件文档的编制技巧
* 从技术角度进行文档的编制和评价
* 明确文档编制人员的责任
* 让编制人员对开发项目有准确的认识
* 让开发和设计人员参与文档审阅工作
### 项目开发文档化
* 记录项目中的各种数据
* 总结项目开发经验
* 规范团队开发过程
* 增强项目可见度
* 提高团队沟通效率

View File

@@ -0,0 +1,64 @@
## 传统的软件过程
| 生命周期模型 | 强    项 | 弱    项 |
|---|---|---|
| 构造与调试模型 | 适合小程序,不需要维护的程序 | 几乎没有软件工程的概念,不适合任何稍大的程序 |
| 瀑布模型 | 有纪律的方法,文档驱动 | 交付的产品可能无法满足用户的要求 |
| 快速原型模型 | 快速体现用户需求,确保交付的产品满足用户的要求,非常适合界面和人机交互的系统的快速开发 | 原型通常只是一个参考。很多软件的原型很难做 |
| 增量模型 | 早期投入得到最大化的回报,提升可维护性 | 要求体系结构必须开放,可能退化为建造和调试模型 |
| 螺旋模型 | 结合上述的所有优点 | 只能用于大规模的内部产品,开发者必须有风险分析和回避的能力 |
| 喷泉模型 | 支持每个阶段内部的迭代以及阶段间的并行工作 | 可能退化为CABTABcode a bit, test a bit |
## 构造与调试
![](2021-03-08-21-30-24.png)
## 瀑布模型
![](2021-03-08-21-30-38.png)
## 快速原型模型
![](2021-03-08-21-30-56.png)
## 增量模型
![](2021-03-08-21-31-42.png)
## 螺旋模型
![](2021-03-08-21-31-23.png)
## 喷泉模型
![](2021-03-08-21-32-15.png)
## 敏捷开发
—个体和交互  胜过  过程和工具
—可以工作的软件  胜过  面面俱到的文档
—客户合作  胜过  合同谈判
—响应变化  胜过  遵循计划
![](2021-03-08-21-32-30.png)
## Scrum敏捷开发过程
步骤:项目开发——迭代——冲刺——模块
一次完整的项目开发过程由若干次迭代开发过程组成,每次迭代完成后将发布一个功能有限的软件产品,经历若干次迭代后,最终发布功能完备的软件产品。
![](2021-03-08-21-32-53.png)
一次迭代开发过程需要在需求稳定的前提下开展,分别经历需求分析、架构设计、数据库设计(可选)、界面设计、若干次冲刺开发过程,以及集成测试,最终发布产品
![](2021-03-08-21-33-09.png)
一次冲刺开发过程由若干次模块开发过程组成,本次冲刺中包含的所有模块开发完成后,本次冲刺开发过程结束。
![](2021-03-08-21-33-26.png)
一次模块开发过程需经历物理设计、编码自测、代码评审、验收测试、模块测试等活动,最终以通过模块测试为结束依据。
![](2021-03-08-21-33-46.png)

View File

@@ -0,0 +1,48 @@
## 为什么要评审
提高项目的生产率,减少开发时间,加快开发进度。
改善软件质量,改进开发过程。
在评审过程中,使开发团队的其他成员更熟悉产品和开发过程。
通过评审,标志着软件开发的一个阶段的完成。
生产出更以维护的软件。
## 参与评审的角色
评审组长
评审的组织者,确保评审入口准则得到满足确保遵循评审的流程,指明评审的关注点,确保所有评审软院已经充分检视。确保评审的进度,确保发现、整理、修正问题。
宣读员
在评审会议上通过讲解来引导评审团队浏览工作产品
记录员
记录会议上的信息
作者
确保工作产品已经准备好,在评审会议上详解工作产品。在评审会议结束后修改所有已经确认的缺陷。
评审员
寻找被评审工作产品中的缺陷,填写评审表单并上交。参加评审会议,就评审出的缺陷提出建设性建议。
## 评审的内容
管理评审——组织的最高管理者就管理体系就现状、适宜性、充分性和有效性以及方针和目标的贯彻落实及实现情况进行正式的评价。
技术评审——发现软件在功能、逻辑、实现上的错误,验证软件符合他的需求规格。确认软件符合预先定义的开发规范和标准。保证软件在同一模式下进行开发。
过程评审——评估主要的质量保证流程;卡利率如何处理和解决评审过程中发现的不符合问题;总结和共享好的经验;支出需要进一步完善和改进的部分。
文档评审——对象有:需求文档评审、设计文档评审、测试文档评审。
## 需求文档评审
分层次评审
正式评审与非正式评审结合
分阶段评审
充分准备评审
精心挑选评审员
对评审员进行培训
充分利用需求评审检查单
做好评审后的跟踪工作
## 设计文档评审
1. 概要设计说明书是否与软件需求说明书要求一致
2. 概要设计说明书是否正确完整、一致。
3. 系统的模块划分是否合理
4. 接口定义是否明确
5. 文档是否符合有关标准规定
## 测试文档评审
1. 软件测试计划评审
2. 软件测试说明评审
3. 软件测试报告评审
4. 软件测试记录评审

View File

@@ -0,0 +1,13 @@
## 软件文档管理组成
### 文档形成
严格按照规定,保证编制、评审、版本管理等环节的质量。
### 标识文档类型
便于保存、查找、使用、修改。文档所属项目标识、文档种类标识、同类文档中的版本号标识、文档的性质、保密界别和阅读范文标识。
### 文档控制
保证文档的一致性、各个版本之间的有序性、文档的安全性。
### 文档修改管理
提出修改建议说明修改的理由、修改的内容。
对文档修改建议进行评论。
审核修改建议
批准修改建议
实施修改

View File

@@ -0,0 +1,25 @@
## 管理类文档的作用
软件开发阶段工作成果的体现。
把软件开发过程可视化
记录开发过程中的技术信息
掌握开发过程,控制开发质量和维护工作提供原始信息
提供团队内外之间相互沟通、协调的窗口,有利于把我软件的正确性和可用性。
## 管理类文档的分类
![](2021-03-08-21-12-53.png)
## 各类文档说明
### 《可行性分析报告FAR》
项目初期策划的结果,分析了项目的要求、目标和环境;提出了集中可供选择的方案;并从技术、经济和法律各方面进行了可行性分析。
建议内容包括:可行性分析的前提、可选方案、所建议的系统、经济可行性、技术可行性、法律可行性、用户使用可行性。
### 《软件开发计划SDP》
了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。
建议内容包括:
* 《软件测试计划STP》
* 《软件安装计划SIP》
* 《软件移交计划STRP》
* 《软件配置管理计划SCMP》
* 《软件质量保证计划SQAP》
* 《开发进度月报DPMR》
* 《项目开发总结报告PDSR》