如何将手机/平板/其它电脑作为扩展屏?
普通屏幕
连根线就行, 跳过
如何将手机/平板/其它电脑作为扩展屏幕
一些可行的方案
如果只是为了演示屏幕,方案很多, 使用各种远程工具啥的都可以如anydesk, 向日葵等.
如果是扩展, 那必须要是要支持部分内容到扩展屏幕
可以配置活动窗口如deskreen
采用vnc的工具如 VirtScreen
前提
基于Intel集显中的Virtualheads功能, 目前笔记本也是集显,没试其他方案
这里也是采用vnc技术来搞, 如果是用现成的推荐virtscreen
扩展屏在 右
环境
archlinux(主) + i3wm桌面管理器
android(扩展) 小米平板
xrandr设置屏幕扩展
将笔记本屏幕扩展到android平板上, 并且采用分屏方式
查看现有配置
~: xrandr
1 | Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 |
该命令显示了电脑当前的显示状态,Screen 0
是当前正在显示的屏幕的分辨率参数,eDP1是笔记本内置显示屏当前的分辨率参数,下面的一堆数字是该显示屏所支持的分辨率及刷新率,最底下的三行分别是
HDMI 接口输出及虚拟输出,如果没有连接则会显示disconnect
增加虚拟屏幕
使用cvt命令获取所需分辨率的相应配置信息,
如我想让扩展屏幕分辨率为1920x1080~: cvt 1920 1080
1
2# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync其中第二行 Modeline 后面的内容 是接下来需要的
产生新的分辨率模式 xrandr –newmode
~: xrandr –newmode
上述Modelline后边部分,或者直接使用下面命令一步到位~: xrandr –newmode `cvt 1920 1080|tail -n1 |sed 's/Modeline
//' |sed 's/"//g'`此时通过查看xrandr, 多出了Virtual1部分,
1
2
3
4
5
6
7
8
9
10
11
12
13Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 310mm x 170mm
1920x1080 60.02*+ 59.93
1680x1050 59.88
1400x1050 59.98
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
1920x1080_60.00 (0x20a) 173.000MHz -HSync +VSync
h: width 1920 start 2048 end 2248 total 2576 skew 0 clock 67.16KHz
v: height 1080 start 1083 end 1088 total 1120 clock 59.96Hz启用新的显示器
~: xrandr –addmode VIRTUAL1 "1920x1080_60.00"
注意VIRTUAL1变成了connected1
2VIRTUAL1 connected (normal left inverted right x axis y axis)
1920x1080_60.00 59.96xrandr –output VIRTUAL1 –right-of eDP1 –auto eDP1为主屏幕,
扩展屏幕在右边,所以使用right-of,
该命令最好执行两次,否则可能不生效关闭扩展屏设置
~: xrandr –output VIRTUAL1 –off
X11vnc
启动x11vnc server服务并设置扩展屏
x11vnc -rfbport 5900 -clip 1920x1080+1920+0 -wait 1 –defer 1 -nowf -sb
0
x11vnc -rfbport 5900 -clip xinerama1 -wait 1 –defer 1 -nowf -sb 0
1 | -rfbport:指定了连接所用的端口,默认为5900也可以自行设置。 |
客户端连接工具
安卓下可以使用bvnc
默认配置地址如192.168.1.xx:5900即可
adb工具(usb连接才需要)
打开手机的开发者模式, 并且选择usb调试
电脑端安装adb工具
使用adb reverse tcp:5900 tcp:5900 创建代理
扩展端配置host地址为127.0.0.1:5900即可
参考
https://blog.csdn.net/u010750137/article/details/104277527
测试
将活动程序移动到扩展屏
Win+Shift+Right
光标定位扩展屏
Win+Right 注意观察鼠标光标
问题处理
安装virtscreen以来python-quamash提示编译不通过(弃用)
python版本过高,考虑降低版本
找不到xrandr: cannot find mode "1920x1080_60.00"
执行该命令时提示上述错误xrandr –delmode VIRTUAL1 "1920x1080_60.00"
1 | VIRTUAL1 disconnected (normal left inverted right x axis y axis) |
注意这里的mode不能有双引号, 必须是1920x1080_60.00
而不是"1920x1080_60.00"
bvnc客户端连接失败
确认服务端已经启动,客户端连接失败, 一般为防火墙导致
关闭防火墙systemctl stop iptables.service
增加防火墙规则(推荐)
扩展没效果?
该命令最好执行两次,否则可能不生效
xrandr –output VIRTUAL1 –right-of eDP1 –auto
迁移polardb问题一
环境
polardb版本
1 | <dependency> |
mybatis版本
直接使用springboot引入
1 | <dependency> |
问题描述
1 | javax.servlet.ServletException: org.springframework.dao.DataIntegrityViolationException: |
原因
mybatis查询act_tem_def表涉及到blob字段(content_bytes),
默认的BlobTypeHandler的getBlob方法不适用, 需要重写handler
解决方案
- 在业务下重写BlobTypeHandler, 获取getBinaryStream然后转换byte数组
- mapper.xml -> resultmap中, 加入下述转换
1 | <result column="CONTENT_BYTES" property="contentBytes" jdbcType="BLOB" |
转换逻辑
1 | public static byte[] toByteArray(InputStream input) throws IOException { |
代码
软件终验测试报告
::: {.center}
xx公司
2020-01-01
:::
文档管理
合理地管理主文档,
确保文档版本的及时更新,同时保持备份文档和源文档的一致性。
版本管理
本版本修订日期 2019-08-12 生效日期 2019-08-12
版本 生效日期 变更内容 编制人
V1.0 2020-01-01 初稿编写完成 xx
测试目的
终验测试是项目终验的组成部分,用于各方现场验证系统各功能可用,试运行中发现的问题是否已经解决。
测试对象
描述所测试的软件系统名、版本等信息
测试方式
由业主方、承建方、监理方、总集方代表在用户现场,依据本方案进行测试,并记录测试结果,时间以半天到一天为宜。测试结束后,现场编制终验测试报告并由各方签字确认。
测试通过准则
终验测试方案中所列所有测试项均已通过,则终验测试通过,否则为不通过。
测试时间
说明实施测试的时间
测试地点
说明实施测试的地点
测试参与人员
说明参与终验测试的各方人员,要说明所属单位
功能测试结果记录
根据终验测试方案,以表格的方式列出各项所测功能是否通过
问题解决情况记录
根据终验测试方案,以表格的方式列出各项所测问题是否全部解决
测试结论
给出终验测试是否通过的结论。
内容审核要点:
参考
软件终验测试方案
::: {.center}
xx公司
2020-01-01
:::
文档管理
合理地管理主文档,
确保文档版本的及时更新,同时保持备份文档和源文档的一致性。
版本管理
本版本修订日期 2019-08-12 生效日期 2019-08-12
版本 生效日期 变更内容 编制人
V1.0 2020-01-01 初稿编写完成 xx
测试目的
终验测试是项目终验的组成部分,用于各方现场验证系统各功能可用,试运行中发现的问题是否已经解决。
测试对象
描述所测试的软件系统名、版本等信息
测试方式
由业主方、承建方、监理方、总集方代表在用户现场,依据本方案进行测试,并记录测试结果,时间以半天到一天为宜。测试结束后,现场编制终验测试报告并由各方签字确认。
测试通过准则
本测试方案中所列所有测试项均已通过,则终验测试通过,否则为不通过。
功能测试
功能名1
以表格方式列出子功能、测试方法、是否通过、备注
功能名2
。。。
试运行期间问题解决情况测试
以表格方式列出问题、问题描述、测试方法、是否通过、备注
内容审核要点:
参考
软件详细设计说明
::: {.center}
xx公司
2020-01-01
:::
文档管理
合理地管理主文档,
确保文档版本的及时更新,同时保持备份文档和源文档的一致性。
版本管理
本版本修订日期 2019-08-12 生效日期 2019-08-12
版本 生效日期 变更内容 编制人
V1.0 2020-01-01 初稿编写完成 xx
引言
编写目的
说明编写这份详细设计说明书的目的,指出预期的读者范围。
背景
说明:
待开发的软件系统的名称;
列出本项目的任务提出者、开发者、用户以及将运行该项软件的单位。
术语和缩略语
列出本文件中用到的专门术语的定义和缩写词的原词组。
参考资料
列出要用到的参考资料,如:
本项目的经核准的计划任务书或合同、上级机关的批文;
属于本项目的其他已发表的文件,包括软件需求说明书、软件概要设计说明等;
本文件中各处引用的文件、资料,包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
系统结构
以表格方式列出本程序系统内的每个程序(包括每个模块和子程序)的名称、标识符和它们之间的层次结构关系。并用文字说明每个程序完成的功能,以及互相之间的调用关系。
程序1(标识符)设计说明
从本章开始,逐个地给出各个层次中的每个程序的详细设计。以下给出的提纲是针对一般情况的。对于一个具体的模块,可能根据需要在其说明条目上有适当增减。
程序描述
给出对该程序的简要描述,主要说明安排设计本程序的目的意义,并且说明本程序的特点。
功能
说明该程序应具有的功能,可采用IPO图(即输入-处理-输出图)的形式。
性能
说明对该程序的全部性能要求,包括对精度、灵活性和时间特性的要求。
输入项
给出对每一个输入项的特性,包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式、数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
输出项
给出对每一个输出项的特性,包括名称、标识、数据的类型和格式、数据值的有效范围、输出的形式、数量和频度、输出媒体、对输出图形及符号的说明、安全保密条件等等。
算法
详细说明本程序所选用的算法,具体的计算公式和计算步骤。
流程逻辑
用图表(例如流程图、判定表等)辅以必要的说明来表示本程序的逻辑流程。
接口
用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序,说明参数赋值和调用方式,说明与本程序相直接关联的数据结构。
限制条件
说明本程序运行中所受到的限制条件。
单元测试
说明对本程序进行单元测试的计划和方式,包括单元测试用例的设计等。
尚未解决的问题
说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。
程序2(标识符)设计说明
......
内容审核要点:
本文档内容与概要设计说明、软件需求规格说明等文档中的内容是否一致性;
所述内容是否完备;
各子程序模块描述是否清楚;
是否有必要的单元测试用例编制方面的考虑;
程序模块间关系是否清楚准确。
参考
软件测试报告
::: {.center}
xx公司
2020-01-01
:::
文档管理
合理地管理主文档,
确保文档版本的及时更新,同时保持备份文档和源文档的一致性。
版本管理
本版本修订日期 2019-08-12 生效日期 2019-08-12
版本 生效日期 变更内容 编制人
V1.0 2020-01-01 初稿编写完成 xx
引言
标识
本条应包含本文档及其所适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本号、发行号。
系统概述
本条简述本文档适用的系统和软件的用途。应描述系统与软件的一般性质;描述系统基本功能;概述本系统或软件的开发、测试、试运行和维护的历史;标识项目的承建方、业主方、总集方、监理方等;标识系统当前和计划的运行现场;
文档概述
本条应概括本文档的用途与内容,并描述与其使用有关的保密性方面的要求。
引用文件
本条应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。
术语与缩略语
提供此文档中用到的专门术语的定义和缩写词的原词组。
测试概述
测试目的
描述本次测试的目的。
测试内容
描述本次测试的主要内容,包括需要进行测试的功能和特性。可以引用测试计划和测试说明文档中的内容。对于出厂测试,要将用户文档的正确性测试作为测试的内容之一。
测试的质量目标
描述本次测试所要达到的质量目标,如A、B类bug低于多少个,系统响应时间、系统表现达到什么目标等等。
测试依据
描述本次测试的所依据的方案、文档和标准。
测试环境描述
描述本次测试的软硬件环境,包括使用的服务器的软硬件环境和配置,网络和客户端环境,部署情况说明等。与生产系统环境的差异。
测试时间
说明本次测试的执行时间。
测试人员及工作量
说明本次测试投入的人员、工作量,以及具体每个功能子模块的人员、计划工作量、实际工作量的分配。
测试问题记录
通过列表的方式列出测试发现的主要问题记录,包括问题编号、问题说明、对应测试用例、解决情况等。
测试结果分析及软件评价
对被测试软件的总体评价
根据本报告中所展示的测试结果,提供对该软件的总体评价,包括遗留bug的统计与分析、软件存在的主要问题、是否达到本次测试的质量目标等。
测试技术分析
分析测试技术对测试结果的影响。
测试环境的影响
对测试环境与操作环境的差异进行评估,并分析这种差异对测试结果的影响。
改进建议
针对对被测试软件还存在的问题,提出改进建议。
附录
附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理,附录可单独装订成册。附录应按字母顺序(A,B等)编排。
文档中,如果定义了缺陷等级分类代码,需要在附录中给出其定义。
内容审核要点:
是否全面、真实地反映了测试执行过程;测试记录是否完整、有效;
是否全面总结了测试执行过程中发现的软件问题和缺陷;
对问题及缺陷的判断和定位是否准确;
所测试内容与测试计划是否一致。
参考
软件测试计划
::: {.center}
xx公司
2020-01-01
:::
文档管理
合理地管理主文档,确保文档版本的及时更新,同时保持备份文档和源文档的一致性。
版本管理
本版本修订日期 2019-08-12 生效日期 2019-08-12
版本 生效日期 变更内容 编制人
V1.0 2020-01-01 初稿编写完成 xx
范围
标识
本条应包含本文档及本文档适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本号和发行号。
系统概述
本条应简述本文档适用的系统和软件的用途,它应描述系统和软件的一般特性;概述系统开发、运行和维护的历史;标识项目的开发方、业主方、总集方、监理方等;标识当前和计划的运行现场等。
文档概述
本条应概述本文档的用途和内容,并描述与其使用有关的保密性和私密性的要求。
引用文档
应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。
术语和定义
提供此文档中用到的专门术语的定义和缩写词的原词组。
测试目标和测试内容
测试目标
描述本测试计划的测试目标。如完成软件的出厂测试,达到可交付验证测试的目的。
测试的功能和特性
概要说明本次需要测试的功能和特性
不测的功能和特性
说明本次不测的功能、特性及原因
测试质量目标
简要说明测试的质量目标,如:
测试计划中所有测试方法和模块已经执行通过
所有的测试案例已经执行过
所有的重要等级Bug已经解决并由测试验证
应交付的测试成果文档
说明最终需要交付的测试成果文档,包括软件测试计划、软件测试说明(含测试用例、软件测试报告、测试问题报告等。文档名和数量因具体项目而异,应确定文档责任人。
测试策略
整体测试策略
说明基本的测试过程和策略。如测试人员在需求和设计阶段参与需求评审和设计评审、在开发完成前实施测试案例设计和测试开发,在系统开发完成之后正式执行测试等。
问题等级划分
划分软件缺陷的等级分类代码。推荐的等级划分如下:
A 严重缺陷
文档与软件不符、文档严重不足、关键性内容错误。软件需求明显未实现。软件不能正常运行,导致系统崩溃或资源严重不足。例如: 由程序引起的死机、非法退出;死循环;导致数据库发生死锁;错误操作导致的程序中断;与数据库连接错误;数据通讯错误等
B 较严重缺陷中现
软件能够运行,但当前缺陷严重影响软件基本功能的正确实现。例如:软件功能与需求不符;程序接口错误;数据流错误;数值计算错误等。
C 一般性缺陷
软件能够运行,但当前缺陷影响部分功能的正确实现。例如:界面错误;打印内容或格式错误;简单的输入限制未放在前台进行控制;删除操作未给出提示;数据输入没有边界值限定或不合理等。
D 较小缺陷
软件能够运行,软件功能基本实现,但当前缺陷使操作者不方便或遇到麻烦。例如:辅助说明描述不清楚;显示格式不规范;系统处理未优化;长时间操作未给用户进度提示;提示窗口文字未采用行业术语等。
开始/中断/完成标准
测试启动条件
说明启动测试的条件。如对于出厂测试,已经过评审、测试人力资源已经具备、软件需求规格说明/详细设计文档/测试说明文档已经过确认、内部模块测试和组装测试已经完成等。
其中业主方、总集方、监理方交付验证测试的准入条件:
软件源代码正确通过编译且为最终版本;
软硬件测试平台已搭建并已配置完成;
业主方具有测试所需的各种文档(纸质、电子版);
业主方获得的各种文档均与最终版本的软件相对应,且全部通过审核;
承建方、监理方已完成测试并提交测试报告。
测试中断条件
说明测试中断的条件。例如:
在测试中发现A类bug,并导致后续的测试无法继续时;
已执行完所有的测试用例,并已报告给承建方,等待承建方在限期内改正时。
测试终止条件
说明在什么条件下终止本计划所述产品交付验收证测试。如:
正常终止条件:
按照测试计划完成所有定义的测试用例;
客观、详细地记录了软件测试过程和软件测试中发现的问题;
有效完成了定位缺陷的回归测试循环;
测试中未发现A、B缺陷,以及少于n个C类缺陷;
提交测试报告。
异常终止条件
太多的A或B类缺陷以致测试无法进行或测试周期已结束。
或者针对软件规模,规定C类bug不超过n个
测试工具选择
说明需要用到的测试工具软件,应包括软件版本号。
测试流程
阐述或引用测试流程,应包括问题报告、审核、分配、跟踪、回归等各方面。测试流程与承建方内部质量管理制度和业主方的要求相关。
测试技术和方法
确定测试需要的技术或方法,如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术等;明确测试用例的设计和选择方法,针对不同类型的测试(功能测试、性能测试、容量测试、用户界面测试,
根据需要,应给出针对性的测试用例设计要求。
评价准则和方法
测试通过准则
定义系统测试通过准则,以下是一个测试通过准则的示例:
可执行软件与需求规格说明书、设计说明书是一致的;
测试覆盖率应达到100%
测试用例通过率要达到95%;
软件缺陷终结率达到100%
系统页面风格符合规范化要求,程序代码编写以及各种命名符合规范化要求。
各模块正确衔接。
对异常数据应有相应的提示信息,并能安全终止异常操作。
对测试结果处理方法
测试结果分为通过和未通过。测试达到通过准则的要求称为”通过”,测试结果没有达到测试通过准则的称为”未通过”。说明对不同测试结果的处理方法。
测试项目组织与资源
参与部门和组织
说明参与测试的组织/部门
角色和职责
说明参与测试的组织/部门中各角色划分及职责。
人员和培训要求
说明参与测试的组织/部门的员及角色对应关系。以及是否需要预先进行相关培训。
关键资源
说明需要用到的关键资源
测试活动和进度计划应根据测试资源和测试项目内容,分解测试活动,分配测试资源,编制测试进度计划。以下是一个进度计划的示例:
测试阶段 开始时间 完成时间 测试人员 阶段完成标志
制定测试计划
需求 Review
设计 Review
设计测试用例
测试开发
测试环境准备
测试实施
功能测试
集成测试
性能测试
系统测试
验收测试
文档编写
风险分析及应对措施
风险分析是评测项目管理的重要内容。常见的风险包括供测试的软件版本混乱、软件缺陷修改时间过长、回归不足引发新的问题、测试方和开发方对缺陷的认识存在差异等。建议以列表的方式给出识别的风险并提供针对性的缓解措施。
内容审核要点:
测试内容是否完整,是否涵盖了测试目的、内容、方法策略、资源、进度安排等各方面;
测试进度安排是否合理;
测试资源要求是否充分;
测试技术和方法的选择是否可行;
是否包含了对测试结果评价分析标准;
是否包含了对测试过程的跟踪和控制规程。
参考
软件测试说明
::: {.center}
xx公司
2020-01-01
:::
文档管理
合理地管理主文档,确保文档版本的及时更新,同时保持备份文档和源文档的一致性。
版本管理
本版本修订日期 2019-08-12 生效日期 2019-08-12
版本 生效日期 变更内容 编制人
V1.0 2020-01-01 初稿编写完成 xx
范围
标识
本条应包含本文档及本文档适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本号和发行号。
系统概述
本条应简述本文档适用的系统和软件的用途,它应描述系统和软件的一般特性;概述系统开发、运行和维护的历史;标识项目的开发方、业主方、总集方、监理方等;标识当前和计划的运行现场等。
文档概述
本条应概述本文档的用途和内容,并描述与其使用有关的保密性和私密性的要求。
引用文件
应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。
术语和缩略语
提供此文档中用到的专门术语的定义和缩写词的原词组。
测试准备
以下按照软件测试类型(如:功能测试、性能测试、可靠性测试等)分章节编写。
每一项测试类型均应有唯一的标识号,应描述如何准备并获取测试资源,如测试环境所必须的软件、硬件、数据资源等;必要时,应描述如何准备测试程序,如开发测试接口所需的数据仿真、业务仿真程序以及测试支持软件等。
(测试名称、唯一标识号)
设施环境要求
描述对测试场所、设施和环境的要求。(若有)分析上述差异对测试可能造成的影响。
硬件准备
描述对测试硬件的要求。分析硬件差异对测试可能造成的影响。
软件准备
描述对测试软件的要求。分析软件差异对测试可能造成的影响。
数据准备
描述对测试数据的要求。分析数据差异对测试可能造成的影响。
其它测试准备
描述对测试程序等分面的其他测试准备工作。
测试项分解
将需测试的内容进行层次化的分解形成测试项,并进行标识命名。对最终分解后的每个测试项,说明测试用例设计方法的具体应用、测试数据的选择依据等。测试项与具体的功能和性能要求对应,测试项还应包含对用户文档(用户手册、安装部署手册)的测试。
测试说明
逐层对测试项和测试用例进行标识和说明。其中,测试用例至少应包含:所属测试项、用例名称标识、用例说明、对应需求、前提和约束、执行步骤、预期结果等。
注:测试用例可采用表格方式,可作为本文档的附件另行成文,以下是对测试用例相关项的解释。
对应需求:说明测试所依据的内容来源,如软件需求规格说明书中的需求功能编号或具体条款
测试说明:简要描述测试的对象、目的和所采用的测试方法。
前提和约束:说明实施该测试用例的前提条件和约束条件,如环境条件、准备工作等。
执行步骤:编写按照执行顺序排列的一系列相对独立的步骤,每一个执行步骤应包括测试操作动作、测试程序输入或设备操作、期望的测试结果。
预期结果:期望测试结果应有具体内容(如确定的元数值、业务流程状态等),不应是不确切的概念或笼统的描述。
测试用例执行顺序
应确定软件测试用例的执行顺序,从而合理安排测试执行过程,避免重复执行测试用例,提高测试工作效率。同时,通过合理的测试用例执行顺序实现对完整的业务流程的确认和验证。
内容审核要点:
测试说明的范围与合同及其附件要求等是否一致;是否覆盖了全部软件需求;是否覆盖了全部测试需求;
软件测试准备是否充分;
软件测试分解是否合理;测试设计思路是否清晰;测试技术实现方法是否科学;
对接口的分析和说明是否完整、准确;对接口测试的正常和容错说明是否全面;
测试用例是否充分;除正常操作、正常流程、正常数据外,是否覆盖了可测试的异常情况;
测试用例的执行顺序是否合理;是否可覆盖必要的业务流程。
参考
软件开发计划
::: {.center}
xx公司
2020-01-01
:::
文档管理
合理地管理主文档,
确保文档版本的及时更新,同时保持备份文档和源文档的一致性。
版本管理
本版本修订日期 2019-08-12 生效日期 2019-08-12
版本 生效日期 变更内容 编制人
V1.0 2020-01-01 初稿编写完成 xx
引言
标识
本条应包含本文档的完整标识,以及本文档适用的系统和软件的完整标识,包括标识号、标题、缩略词语、版本号和发行号。
系统概述
本条应简述本文档适用的系统和软件的用途,应描述系统和软件的一般特性;概述系统开发、运行和维护的历史;标识项目的业主方、用户、承建方、监理方等;标识当前和计划的运行现场等。
文档概述
概述本文档的用途和内容,并描述与其使用有关的保密性和私密性的要求。
与其他计划之间的关系
描述本计划和其他项目管理计划的关系。
输入基线
给出编写本项目开发计划的输入基线,如业务需求说明书等。
引用文件
应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。
项目范围及约束条件
交付产品
列出本项目的交付产品成果,包括软件程序、交付文档等,以及各交付成果的交付期限。
业务需求和约束条件
分条阐述项目的业务需求和约束条件;
其它方面的需求和约束条件
分条阐述其它方面的约束,如项目进度要求、保密性等。
项目目标
综述项目进度目标、成本目标、质量目标。
项目总体计划
软件开发过程和里程碑
描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款,确定已计划的开发阶段(适用)、目标和各阶段要执行的软件开发活动。
里程碑设置分条阐述里程碑/阶段名称、期限、里程碑标志说明(进入条件和输出)、评审方式等。
提供一张工作产品矩阵表,描述各工作产品的编号、名称、产生阶段、评审方式等。工作产品包括各阶段产生的过程文档和技术文档等,是工作任务分解和配置管理计划制定的重要依据。
软件开发方法
描述或引用要使用的软件开发方法,包括为支持这些方法所使用的手工、自动工具和过程的描述。
软件产品标准
描述或引用在表达需求、设计、编码、测试用例、测试过程和测试结果方面要遵循的标准和要求。对要使用的各种编程语言应提供编码标准。
评审途径
阐述软件内部评审的方式,以及需方或授权代表(总集、监理)实施软件产品和活动评审的途径和方式。
软件配置管理
描述针对本项目所采用和遵循的软件配置管理方法.包括配置项的标识、控制、状态统计、审核、交付等。
具体的配置项识别和管理可在配置管理计划中另文给出。
软件质量保证
描述针对在本项目所采用和遵循的软件质量保证方法。包括软件质量保证评估、软件质量保证记录和处理、第三方独立性保证等。质量保证计划也可另文给出。承建方应在计划中落实下述内部审核和检查工作:
软件计划审核:在软件计划编制阶段结束后必须进行软件计划审核,以确保在软件开发计划、软件配置管理计划、软件质量保证计划中所规定的计划的合适性。
软件需求审核:在软件需求分析阶段结束后必须进行软件需求审核,以确保在软件需求规格说明中所规定的各项需求的合适性。
软件概要设计审核:在软件设计结束后必须进行软件设计的审核,以评价软件概要设计说明、数据结构设计说明中所描述的软件设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性;以及在数据结构、功能、算法和过程描述等方面的合适性。
软件详细设计、编码阶段的审核:在软件详细设计和编码实现完成之后要对软件详细设计说明、软件测试计划、软件测试说明(含软件测试用例)、目标程序生成说明进行审核,以确认业主方的业务需求是否得到满足,验证软件需求规格说明中的需求是否已由软件设计说明描述的设计实现,软件设计说明表达的设计是否已由编码实现。
出厂测试审核:在完成出厂测试之后要对源代码交付验证说明、软件测试报告(含源代码交付验证报告)以及按照合同要求应提交给业主方的所有文档(如:软件用户手册等)进行审核,以评价待交付的程序及文档的质量是否满足出厂交付要求、覆盖了业主方的业务需求、做好了交付准备。
部署审核:在配合监理方和业主方完成测试工作后承建方进入系统部署阶段,在完成软件部署并配合完成系统联调联试后,要对部署实施报告进行审核,以验证部署实施的真实性以及外部接口的正确性。
问题跟踪和处理(更正活动)
描述软件更正活动中要遵循的方法,包括不同阶段的问题发现、纪录、报告、处理、审核和更正流程,问题/bug跟踪系统的选用等。须论及出厂测试、需方验证测试、试运行三个阶段。
档案收集
阐述作为承建方在项目进行过程中进行自身档案收集管理的方法,包括纸质档案。
项目估算及进度计划
工作任务分解
分解项目工作任务,得出工作任务分解结构(WBS)。
规模估算
估算项目规模,如需新编的代码行数、文档页数等。
工作量估算
根据规模估算及项目经验,估算项目工作量。
进度计划
在工作任务分解结构(WBS)、工作量估算的基础上,进行活动排序、资源分配,进而编制进度计划甘特图,标识各活动的依赖关系、资源分配情况、起止时间等。
风险估计及应对方法
逐条给出识别的风险及其风险估计量化指标(可能性、严重性等级)、相应的对策和缓解方案。建议以列表的方式给出。
项目跟踪与变更管理
项目日常跟踪
阐述项目日常跟踪方法,包括由业主方和授权代表(监理方)参与的项目跟踪。
里程碑评审
阐述或引用项目各里程碑评审的方法。
变更管理
包括计划变更、需求变更等的处理流程、机制和方法。
项目组织和资源
项目组织
本条应描述本项目要采用的组织结构,包括涉及的组织机构、机构之间的关系、执行所需活动的每个机构的权限和职责。
项目资源
本条应描述适用于本项目的资源。 主要包括:
人力资源,分条说明投入此项目的人员、职责、投入阶段、地理位置和涉密程度等;
开发人员要使用的设施,包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的设施的其他特性;
为满足合同需要,需方应提供的设备、软件、服务、文档、资料及设施及需要提供的时间。
内部培训
根据项目的技术要求和项目成员的情况,确定是否需要进行项目培训,并制订培训计划。如不需要培训,应说明理由。
注解
本章应包含有助于理解本文档的一般信息(例如原理)。本章应包含为理解本文档需要的术语和定义,所有缩略语和它们在文档中的含义的字母序列表。
附录
附录可用来提供那些为便于文档维护而单独出版的信息(例如图表、分类数据)。为便于处理,附录可单独装订成册。附录应按字母顺序(A,
B等)编排。
内容审核要点:
项目范围阐述与合同及其附件要求等是否一致;
工作任务分解与项目范围/需求是否一致;
工作任务分解、工作量估计和活动进度安排是否合理;
计划内容是否包括软件项目管理的各个必要的方面;
作产品定义是否包含需方所要求的各相关必要文档;
织机构和人力资源安排和分配是否合理并符合合同相关要求;
目日常跟踪管理是否具有可操作性;
目开发过程中的问题/bug处理机制是否具有可操作性;
案收集管理是否具有可操作性。
是否制定了合适的配置管理策略和质量保证策略。