软件说明文档范本

第一篇：软件说明文档范本

软件名称及版本号 1 前言

本系统是一种XXXXX监控管理系统，应用射频识别技术、视频监控系统、智能控制系统、大型数据库技术、数据加密技术、防爆技术和嵌入式操作系统，可以通过计算机通讯网络，将信息实时反馈到设置在监管部门的数据中心，进行数据处理和保存，由监管部门进行动态监管，及时掌握所有使用情况，杜绝管理漏洞和安全隐患，实行历史追溯。现对系统各模块功能做一全面说明：

一．系统登录界面

图片

二．系统首页

登录成功，即进入系统主页面。

图片

三．信息查看

进入主页面后点击信息查看，即可查看相关情况。

图片

四．查看日志

进入主页面后点击查看日志下的远程操控子菜单，即可以动态监控情况。

图片

五．实时信息

1．动态视图

进入主页面后点击实时信息下的动态视图子菜单，即可查看实时状态信息，如果有信息，则动态显示信息。软件名称及版本号 2

图片

点击右上方下拉菜单，选择实时监控情况，并显示所对应检验情况(若检验不合格直接不予以)、充装时间、流量以及金额。

还可以显示相关情况、包括姓名、上班时间、许可证号及身份证号。（如上图）2．视频监控

进入主页面后点击实时信息下的视频监控子菜单，即可查看各地的实时视频信息。并可进行实时音频指导。

图片

点击右上方下拉菜单，选择后即可实时视频监控过程，右侧四个图标，绿色代表当前可用状态度，红色代表当前禁用状态，可通过点击图标进行状态控制。下侧为当前工作人员。可同时通过四个视频通道监控各地情况。（如上图）

图片

双击视频通道可详细查看操作过程，如发现有违规操作可通过点击右上方“打开对话按钮”，进行实时音频提示或警告。若情况严重可点击右侧图标上编号，控制停止非法行为。（如上图）

六．主站设置

进入主页面后点击设置下基本信息子菜单，即可对基本信息进行录入、维护。

图片

七．XX管理

1． XX信息 软件名称及版本号 3

进入主页面后点击XX管理下XX信息子菜单，即可以浏览各区县XX详细信息，包括XXX、所地区、使用登记证号、数量、发证单位、发证时间、应用类型、厂牌型号、所属单位、负责人、姓名、联系电话等相关信息。并且还可对相关信息进行新增、修改、删除、查看等操作。

图片

2． 数据查询

进入主页面后点击XX管理下XX数据查询子菜单，即可对XX相关信息进行查询，可以根据XXX、XX、使用登记证号、发动机号、车架号、发证开始时间、发证结束时间等字段进行单独或者联合查询。

图片

3． 数据统计

进入主页面后点击XX管理下XX数据统计子菜单，即可直观查看各区XX柱状图。

图片

八．XX管理

1． XX信息

进入主页面后点击XX管理下XX信息子菜单，即可浏览各区县相关信息，包括生产厂家、出厂编号、类型、生产年月、型号、使用状态、投用日期、安装日期、使用年限、可充装次数、检验状态、车牌号等相关信息。并且还可以对XX信息进进新增、修改、删除、查看等操作。

软件名称及版本号 4

图片

2．信息查询

进入主页面后点击XX管理下XX信息查询子菜单，即可对XX相关信息进行查询，可以根据生产厂家、出厂编号、使用状态、类型、车牌号等字段进行单独或者联合查询。

图片

2． XX统计

进入主页面后点击XX管理下XX统计子菜单，即可对市各种类型XX使用情况动态生成饼状图。

图片

3．电子标签

进入主页面后点击XX管理下电子标签子菜单即可查询、浏览XX相关信息，并可根据车牌号、出厂编号、使用状态、类型、生产厂家等字段进行单独或联合查询，还可以选择XX进行了发卡操作。

图片

4．标签查询

进入主页面后点击XX管理下标签查询子菜单，即可根据XX检验开始日期、结束日期、检验状态、车牌号等字段进行单独或者联合查询。软件名称及版本号 5

图片

九．充装数据

1．充装数据查询

进入主页面后点击充装数据下充装数据查询子菜单，即可查询车辆XX详细记录，可以根据开始时间、结束时间、充装状态、编号、车牌号等字段进行单独或者联合查询。

图片

2．充装数据统计

进入主页面后点击充装数据下充装数据统计子菜单，即可根据各站的XX次数生成三维柱状图，直观地展示各站的情况。

图片

3．本站充装数据统计

进入主页面后点击充装数据下本站充装数据统计子菜单，即可查看用户所在站的XX次数生成三维柱状图，直观地展示各月份情况。

图片

3． 本站数据查询

进入主页面后点击充装数据下本站数据查询子菜单，即可对用户所在站的车辆详细记录进行浏览，并可以根据开始时间、结束时间、充装状态、编号、车牌号等字段进行单独或者联合查询。

图片

软件名称及版本号 6

本系统有一个重要的创新，即可以借助视频和通讯系统，对XX站实现远程语音提醒，并可控制停止非法行为。系统对建立城市公共安全监管的长效机制，保证人民的生命财产和社会的和谐稳定具有重要意义。

第二篇：打卡机软件操作说明

软件安装使用的基本流程

一，打开软件系统光盘，找到setup.exe文件

二，双击运行打开，点击下一步，弹出如图所示，选择安装考勤系统路径，不推荐安装到系统C盘，假如安装到D盘，那么把C改为D，安装的时候自动会在D盘创建好目录

点击下一步，直到选择类别，根据实际机器类别选择安装：如图

选择好类别后点下一步（指纹机推荐安装ACCESS版本），完成安装！

三．如果安装指纹机，打开图标时可以直接登陆软件，如果是拍照机，都是SQL版本的，在点击图标后，会提示第一次运行本程序需要建库；如图所示：

选择是，就会弹出服务器数据库联接参数，如下图

首次安装，可直接点建库即可，成功后会提示“数据库建立完毕”（需在服务管理器运行的状态下才能完成，一般在程序启动项里面可以找到服务管理器图标，一般双击后，会自动出现在电脑右下角，如，正常运行时显示绿色，停止状态时显示红色，需要双击点开始运行）

三，打开软件图标，选择相应的考勤机类别，选择默认帐号为SYSETM，密码是123

498811037 四，建立当月帐套，每个月需要新建一次帐套，在弹出帐套管理窗口中，点击新建A，系统自动获取当前时间，点保存即可生成当月帐套，如下图，再点进入就已经登陆到软件里面了

五，在考勤机硬件操作窗口中增加机器设备信息，如下图 拍照机登记界面：

指纹机登记界面：

六，设置好机器信息后，在此框下侧选择连接状态（或选择机器号，点测试机器状态），点击读取状态，可以检测到当前的机器是否跟PC考勤系统软件实时通讯！如果显示当前机器号已联机，就可以说明机器已经成功跟软件实时通讯了！如下图 拍照机测试状态图：

指纹机测试状态图：

七，接着就可以在人事资料录入人员信息，保存完毕后，进入到考勤机硬件操作里面中的考勤机设置，点右键选择从人事资料导入，可将人事录入的姓名卡号导入到考勤机硬件设置里面，此时点卡片注册可将信息上传到机器里面！录入人员信息：

把人事导入到考勤机设置信息栏中：

硬件操作上传人员姓名卡号到考勤机窗口：

八，接着设置好基本班次，按照所需要的规律给相应的部门人员排好班 基本班次设置栏：

人员班次分布栏：

九，采集数据，选择机器号下载所有记录或者新记录，开始使用的时候需要点下载所有记录，下载记录完毕后，软件会自动提示“下载完毕”！以后每次下载可以点下载新记录，如果数据比较多，超过几万条，下载出来后请及时清除机器里面的考勤数据！拍照机数据采集框图：

指纹机数据采集框：

十，下载完记录后，在日报把相应的数据处理出来，再汇总月报表就可以导出打印了！日报表：

月报表：

可将统计好的报表导出打印

十一。数据库备份还原：

方法1：在软件界面顶部有一个数据备份按钮，选择好备份路径，点备份，系统会自动在选择的路径下备份一个R开头的MC文件，些文件还原时需打开电脑桌面左下角的开始菜单程序，里面有个安装好的考勤系统，打开后有个新建恢复数据，点还原数据，找到备份好的RXXX.MC文件，点还原即可！备份处：

还原处：

方法2。在软件图标点右键属性里面查找目标，弹出窗口就是本考勤系统的安装目录，找到DATABASE文件夹，此文件夹就是数据库文件，可将它复制保存好，待新软件安装好后，将此文件直接替换到新软件的安装目录下面即可！

如有其它疑问，可以查看软件的帮助说明或随机附带的说明书，如仍然有疑问，请及时与当地的经销商联系！

注意：软件需要重新安装的时候，必须先备份好考勤软件的数据库！

第三篇：软件需求说明[范文]

软件需求说明

某公司总部设在北京，在上海、广州、成都和西安有分支机构，公司员工接近700名。由于公司业务和员工团队的迅速发展，为了提升整体工作效率，公司准备开发一套员工报账系统，取代原来的人工处理方式。

报账系统将支持员工记录（或预见）日常业务活动的开销，并自动结算每个月应该返还员工的补偿金额，补偿额会直接存入员工的工资帐户中。

报账系统应具有基于先进技术的图形化界面，员工可以输入业务活动的种类和简短描述，活动开销的类别，选择不同的支付方式，并可以生成灵活的报表。

报账系统应该有能力根据员工提供的信息和要求返还补偿额，同时保存全部员工的报账信息。员工可以通过他们自己的电脑来使用报账系统。由于牵涉到财务信息，报账系统必须提供可信的安全机制。

公司现有一套基于MicroSoft SQL Server的人事管理数据库系统，记录员工共的基本信息和团队的组织结构。报账系统将和现有人事管理数据库系统协同工作，需要引用人事管理数据库系统中的部分信息，但不会更新其内容。

通过报账系统，员工能够在出差前（提前2天）按照规定的额度向公司申请借款，相关的经理人员能够通过报账系统批复或拒绝。报账系统应在相关负责人批复之后通知该员工提取现金或确认相应款项已经划入指定信用卡（根据员工的要求）；员工可以通过保账系统报销合理的业务活动经费。

财务部门将指定一位报账系统管理员监督拟建系统中的信息，负责初始设置和维护特定的分类额度准则，并能够定期或随机地向部门负责人提交报账系统情况的统计报告。

报账系统在每月的25日对通过审批的报账申请自动作一次结算，并以电子邮件的方式通知应该得到补偿的员工，同时生成一份统计报告传送给财务部门的系统监管人员。

具体的局部功能需求-----“提交报销申请”的Use Case

简介：

员工通过报账系统填写报销申请，输入相关活动产生的费用，在一次或者多次填写后提交，经验证之后，以电子邮件的方式通知相应经理批复。

事件流（Flow of Events）

基本事件序列(Basic Flow)1.打开报销单

[员工]：员工选择进入“报销申请”功能。

[系统]：该员工当月报销单存在，系统将取出相应信息并展示给员工；如果该员工的当月报销单不存在，则转至A1备选事件序列。2.添加报销记录

[员工]：员工要求添加一条报销记录。[系统]：系统显示一条空白的报销记录。3.填写报销记录单

[员工]：员工开始填写报销记录，每条报销记录包括的信息有：业务活动发生的时间、为了让员工方便而准确地输入相关信息，除了客户名称、业务活动原因和金额之外，其他信息域提供相应的下拉式选择列表。并记录员工输入的信息。

（重复以上针对每一条报销记录的活动），直至所有记录填写完毕。）4.验证报销单

[员工]：员工填写完毕所有报销记录之后，要求系统验证这些记录的合理性。[系统]：报销记录的初始状态为“未验证”，每当一条报销记录被验证为合理，系统将该报销记录的状态设置为“已验证”，系统在验证所有报销记录（为“已验证”）之后提示用户可以提交本月的报销单。验证为合理的记录必须满足集中条件：第一，不同种类的费用不超过相应得限额；第二，报销费用的类型要和员工的职能匹配。对于未通过的验证的报销记录，转至A5备选事件序列 5.提交报销单

[员工]：所有报销记录经过验证之后，员工提交当月的报销单。

[系统]：系统保存这张报销单，将报销单的状态设置为“已提交”并记录提交日期，同时这张报销单被设为“只读”。系统要从人事管理数据库中获知该员工及其经理（负担该员工当月开销者）的电子邮件地址。如果此时人事管理数据库不可用，转至A6备选事件序列。

为了及时通知相关人员，系统将自动生成一份以当前报销单为内容的电子邮件发送到该员工及其经理的信箱中。当邮件成功发送后，员工得到一个确认信息。如果此时邮件系统未能将邮件及时发送，转至备选事件序列A7。

备选事件序列组（Alternative Flows）

A1 创建当月报销单

[起始位置]：基本事件序列中，员工进入报销申请程序并准备打开当月报销单。

[触发条件]：系统没有发现和该员工对应的当月报销单。

[具体内容]：系统为员工创建一张当月报销单。

[返回位置]：基本事件序列中的“打开报销单” 步骤。

A2 删除报销记录

[起始位置]：在提交报销单之前任意时间点。

[触发条件]：员工希望删除某一条报销记录。

[具体内容]：系统删除有员工指定的某一条报销记录。[返回位置]：同“起始位置”。

A3 更新报销记录

[起始位置]：在提交报销单之前任意时间点。

[触发条件]：员工希望更新某一条报销单。

[具体内容]：系统根据员工输入的内容更新相应的一条报销记录。[返回位置]：同“起始位置”。

A4 保存当月报销单

[起始位置]：该Use Case 允许员工在事件流中的任意时间点保存当月的报销单。

[触发条件]：员工希望将已经录入的报销记录保存在报账系统中。

[具体内容]：系统保存该员工当月报销单，并给出确认信息。员工可以在保存当月报销单之后直接退出系统。

[返回位置]：同“起始位置”。

A5 报销记录不合理

[起始位置]：基本事件序列中，“验证报销单”步骤中对每一条报销记录验证结束之后。

[触发条件]：包销记录不满足某一条适用的准则。有两种情形：第一，某报销记录的金额超出了其对应类型费用的上限，已知有三种：请客户用餐人均超过300元，出差时每天住宿费超过800元，移动电话费再无特殊说明情况下超过800元；第二，报销费用的类型和员工所处部门及职能不匹配，已知的情形是业务部门的员工申请加班补助。

[具体内容]：系统告知员工不合理的报销记录编号，以及未通过验证的原因。[返回位置]：即本事件序列中的“填写报销单”步骤，目的是更正有问题的报销记录。

A6 人事管理数据库不可用

[起始位置]：即本事件序列中，提交报销单步骤结尾

[触发条件]：当报账系统向人事管理数据库索取信息而该数据库没有正常的响应。

[具体内容]：以对话框形式告知员工“人事管理数据库不可用，报账但没有提交成功”。

[返回位置]：Use Case 执行结束。

A7 邮件未即时发出

[起始位置]：基本事件序列中，“提交报销单”步骤的结尾，成功地从人事管理数据库获得相关信息后。

[触发条件]：报账系统要求发送相关邮件时，邮件系统没有及时的响应。

[具体内容]：系统将以提示信息的方式告知员工“邮件没有及时发出，但是报销单在系统内已经提交成功，待邮件系统恢复后，相关邮件会自动发出”。[返回位置]：Use Case 执行结束。

特殊需求列表（专属于该Use Case）

暂无

启动条件

员工成功登录系统，通过身份验证。被系统提示进入“报销申请”或“借款申请”功能。

结束状态(组)如果该Use Case 顺利执行，员工得报销申请记录将被建立，更新、保存或者保存并提交；否则，系统地状态应该保持和该Use Case 执行之前相同。

辅助图示(活动图)

“补充规约”要点 1.RDBMS数据库访问 2.分布式处理

词汇表 要点

 员工。公司的正式雇员

 经理。负责审批某员工当月开销的管理者，是较高级别的员工。

 报销纪录。与业务有关的某一项具体的花费，包括业务活动发生的时间、地点、客户名称（可选）、原因以及费用金额和种类（交通、餐饮、会议、通信和杂项）。 报销单。员工在一个（自然）月内的所有报销纪录的集合。

 工资户头。公司将员工用于日常业务活动开销的补偿金额返还至员工的银行账户，该帐户的基本功能是供员工接受工资。

 人事管理数据库。该数据库纪录了有关人事管理的相关信息，与报帐系统有关的是公司的组织机构(“员工”和“经理”的关系)。

 内部邮件系统。该邮件系统负责收发与公司业务有关的电子邮件信息。

“提交报销申请”[控制，SubmitClaim]的Use Case

简介：

员工通过报账系统填写报销申请，输入相关活动产生的费用，在一次或者多次填写后提交，经验证之后，以电子邮件的方式通知相应经理批复。

事件流（Flow of Events）

基本事件序列(Basic Flow)打开报销单

[员工]：员工[实体，关键抽象，Employee]选择进入“报销申请”[边界，SubmitClaimForm]功能。

[系统]：如果该员工当月报销单[实体，关键抽象，ClaimReport]存在，系统将取出相应信息并展示给员工；如果该员工的当月报销单不存在，则转至A1备选事件序列。添加报销记录

[员工]：员工要求添加一条报销记录。[系统]：系统显示一条空白的报销记录。填写报销记录单

[员工]：员工开始填写报销记录[实体，关键抽象，ClaimRecord]，每条报销记录包括的信息有：业务活动发生的时间、地点、客户名称（可选）、原因以及费用金额和种类（交通、餐饮、会议、通信和杂项）。

[系统]：系统显示并记录员工输入的信息。为了让员工方便而准确地输入相关信息，除了客户名称、业务活动原因和金额之外，其他信息域提供相应的下拉式选择列表。

（重复以上针对每一条报销记录的活动），直至所有记录填写完毕。）验证报销单

[员工]：员工填写完毕所有报销记录之后，要求系统验证这些记录的合理性[实体，ValidRule]。

[系统]：包销记录的初始状态为“未验证”，每当一条报销记录被验证为合理，系统监该报销记录的状态设置为“已验证”，系统在验证所有报销记录（为“已验证”）之后提示用户可以提交本月的报销单。验证为合理的记录必须满足集中条件：第一，不同种类的费用不超过相应得限额；第二，报销费用的类型要和员工的职能匹配。对于未通过的验证的报销记录，转至A5备选事件序列 提交报销单

[员工]：所有报销记录经过验证之后，员工提交当月的报销单。

[系统]：系统保存这张报销单，将报销单的状态设置为“以提交”并记录提交日期，同时这张报销单被设为“只读”。系统要从人事管理数据库[边界，HRDatabase]中获知该员工及其经理（负担该员工当月开销者）的电子邮件地址。如果此时人事管理数据库不可用，转至A6备选事件序列。

为了及时通知相关人员，系统将自动生成一份以当前报销单为内容的电子邮件发送到该员工及其经理的信箱中。当邮件成功发送后，员工得到一个确认信息。如果此时邮件系统[边界，MailSystem]未能将邮件及时发送，转至备选事件序列A7。

第四篇：公司软件工程质量管理体系说明

目录

一：职责分工...................................2

1、研发总监职责

...........................2

2、研发部职责

.............................2

二、开发要求.................................3

1、确立设计开发项目

.......................3

2、设计开发的策划

.........................3

3、设计开发输入

...........................4

4、设计开发输出

...........................4

5、设计和开发的评审

.......................4

6、设计开发的验收

.........................5

7、设计开发的确认

.........................5

8、设计更改

...............................5

公司软件工程质量管理体系说明

我公司已软件工程要求建立了质量管理体系，严格控制产品的设计和开发的策划和过程，确保新产品满足市场要求。

一：职责分工

1、研发总监职责

主管公司技术、产品发展方向的调查研究,确定新产品的开发项目和新技术的研究方向；

主管新产品的确定、设计、开发、评审、验证、确认等过程；

主管新产品市场推广的技术支持和新产品的试运行。

2、研发部职责

组织实施新产品开发之前的可行性调研；

参与对立项报告的评审；实施新产品的形态设计，编制新产品研发计划；

负责根据公司技术发展战略开展技术研究和新产品开发及老产品的改造、升级工作；

负责针对每个开发的软件产品进行全方位的测试，保障产品质量；

参与对产品开发过程的阶段性评审和开发结束时的验收。负责软件技术的积累和成长，产品的软件开发、测试，产品软件的技术支持等，对软件的质量和稳定性负责，部门成员参加具体的产品的软件开发过程。

二、开发要求

1、确立设计开发项目

根据市场调查、技术发展或市场需要提出新产品立项或重大改进需求的由指定专人进行可行性调研，编写《立项报告》，申请立项；

根据立项申请，由研发总监组织相关人员（必要时聘请专家）进行评审并对结果进行记录。

2、设计开发的策划

由研发部成立专门的项目小组对已立项的新产品编制《设计开发需求》，然后开始系统设计，以此作为项目组成员进行设计开发活动的依据。应阐明设计项目的输入和输出要求、设计的进度要求、人工预计、任务描述、设计验收的时机等活动的安排，并规定实施这些活动的职责；

研发部在系统设计完成时形成设计文档，由项目小组进行内部评审，形成记录。然后开始进行程序代码开发；

项目负责人的选定要求其具有相当的能力和经验，项目组成员的选定也要求遵循资源优化的原则，有利于提高效率，避开矛盾，使资源得到合理的配置；

项目开发计划可随设计的进展作必要的修改； 项目组长对开发组织各技术接口所交流的信息进行管理，以确保设计开发过程有效。

3、设计开发输入

设计开发输入包括：《立项报告》、《设计开发需求》相关客户需求资料及竞争对手资料还有国内国际法律法规以及行业标准，包括公司内部的设计规范

设计开发输入是设计开发验收的重要依据；

在设计完成之时和进行之中，应对设计输入进行适当的评审，尤其对设计输入中不完善、含糊、矛盾的要求，应提出并会同提出者一同解决，并对其进行记录。

4、设计开发输出

项目正式开始进行，设计人员开始系统设计，输出系统功能模块的形态设计文档；

设计输出文件必须经设计验证评审通过后，由技术总监或总工签署后才能提交到技术管理中心备案，开发部则按照设计文档进行下一步的代码开发；

研发人员在每个开发、测试阶段完成之后将产生功能模块的源代码、软件各功能模块的说明书、测试报告，评审小组评审后写出评审报告，通过的话表示这个阶段的完成。

5、设计和开发的评审

按照《立项报告》、《设计开发需求》由技术管理中心在适宜时机对产品在设计开发进行时组织人员进行阶段性的评审，评审方式以会议讨论方式进行，评审主要由技术副总和开发部人员和公司技术骨干参加，主要评价开发满足设计的要求和开发满足《质量保证计划》的能力，识别开发过程中出现的问题，评审中应提出解决办法，并作好记录保存；

6、设计开发的验收

在设计完成时，需由评审小组对设计进行验收，主要评审功能形态设计及其设计过程产生的文档，通过后将提交到技术管理中心；

产品开发完成后，提交所有的开发文档，由项目验收小组进行产品验收评审，以保证输出满足输入要求的软件产品。

7、设计开发的确认

质检部应根据所策划的安排对已完成的样品进行验证。以验证样品的要求符合设计输入的要求。并将验证的结果给以记录。

当客户有要求或需要时就按照相应的产品标准对样品进行测试，作为验证方式的一种。记录并保存好有关的测试结果。

验证的结果及任何必要措施的记录将给以保存。

8、设计更改

在设计开发过程的各个阶段，如需要较大的更改设计，相关的提出部门或设计人员应确定修改的内容，提出设计更改建议。

针对不同类型的设计开发项目，设计更改建议需在经过不同的相关负责人和/或技术委员会以及其他相关人员的确认，保持相关记录，转交回设计人员手中，同时作为项目文档保存。

在更改实施前必须对其进行验证、确认，以保证不会因更改而造成新的问题；对设计更改的内容应予以记录，并及时传递到有关部门和场所。

第五篇：软件项目计划书编写说明

软件项目计划书编写说明

一、项目计划书格式

根据《GB8567－88计算机软件产品开发文件编制指南》中项目开发计划的要求，结合实际情况调整后的《项目计划书》内容索引如下： 1 引言

1.1 编写目的 1.2 背景 1.3 定义

1.4 参考资料

1.5 标准、条约和约定 2 项目概述 2.1项目目标

2.2产品目标与范围 2.3假设与约束 2.4 项目工作范围 2.5 应交付成果 2.5.1 需完成的软件

2.5.2 需提交用户的文档 2.5.3 须提交内部的文档 2.5.4 应当提供的服务 2.6 项目开发环境

2.7 项目验收方式与依据 3 项目团队组织 3.1 组织结构 3.2 人员分工 3.3 协作与沟通 3.3.1 内部协作 3.3.2 外部沟通 4 实施计划

4.1 风险评估及对策 4.2 工作流程

4.3 总体进度计划 4.4 项目监控

4.4.1 质量控制计划 4.4.2 进度监控计划 4.4.3 预算监控计划 4.4.4 配置管理计划 5 支持条件

5.1 内部支持（可选）

5.2 客户支持（对项目而言）5.3 外包（可选）6 预算（可选）6.1 人员成本 6.2 设备成本

6.3 其它经费预算

6.4 项目合计经费预算 7 关键问题 8专题计划要点

二、项目计划书的编写说明 引言

1.1 编写目的

说明编写这份项目计划的目的，并指出预期的读者。

作用：本节是为了说明编制“项目计划书”亦即本文档的意图和希望达到的效果。注意这里的“目的”不是“项目目标”，而是为了说明本文档的目的与作用。“项目目标”在2.1中说明。

意义：使项目成员和项目干系人了解项目开发计划书的作用、希望达到的效果。开发计划书的作用一般都是“项目成员以及项目干系人之间的共识与约定，项目生命周期所有活动的行动基础，以便项目团队根据本计划书开展和检查项目工作。”

例如可以这么写：为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。

常见的问题：把项目本身的“项目目标”误作编制项目开发计划的目的。

1.2 背景

主要说明项目的来历，一些需要项目团队成员知道的相关情况。主要有以下内容：

项目的名称：经过与客户商定或经过立项手续统一确定的项目名称，一般与所待开发的软件系统名称有较大的关系，如针对“XX系统”开发的项目名称是“XX系统开发”。

项目的委托单位：如果是根据合同进行的软件开发项目，项目的委托单位就是合同中的甲方；如果是自行研发的软件产品，项目的委托单位就是本企业。项目的用户（单位）：软件或网络的使用单位，可以泛指某个用户群。注意项目的用户或单位有时与项目的委托单位是同一个，有时是不一样的。如海关的报关软件、税务的报税软件，委托单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。

项目的任务提出者：本企业内部提出需要完成此项目的人员，一般是领导或商务人员；注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。如果是内部开发项目，则两者的区别在于前者指人，后者指单位。项目的主要承担部门：有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门（也有的分为不同事业部）。项目的特点就是其矩阵式组织，一般一个项目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。需要根据项目所涉及的范围确定本项目的主要承担部门。

项目建设背景：从政治环境上、业务环境上说明项目建设背景，说明项目的大环境、来龙去脉。这有利于项目成员更好地理解项目目标和各项任务。例句：根据《某部关于某建设工作的实施意见》精神，为了保障某建设工作的正常实施，必须加强监督考核，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容，及时掌握进度，相关部门建立市某建设工作简报制度，及时反映全市某建设工作动态。

目前对于某建设工作的工作主要采用计划部门手工编制计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划，某建设工作单位手工上报建设工作进度情况的方式，而全市的建设工作有数百个，加上前期建设工作的数量和今后某市建设发展的趋势，建设工作的数量将越来越多，原来的工作模式已经越来越无法适应市委市政府的要求。因此，充分利用现代信息化、因特网的优势，建立“某市某建设工作信息报送反馈系统”，提高某建设工作信息报送反馈工作效率，提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要和紧迫的任务。

软件系统与其他系统的关系：说明与本系统有关的其他系统，说明它们之间的相互依赖关系。这些系统可以是这个系统的基础性系统（一些数据、环境等必须依靠这个系统才能运行），也可以是以这个系统为基础的系统，或者是两者兼而有之的关系、互相依赖的系统。例句：本系统中对外部办公部分如需要各个建设单位报送材料的子系统应当挂在市政府网站。

软件系统与机构的关系：说明软件系统除了委托单位和使用单位，还与哪些机构组织有关系。例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。

1.3 定义

列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。注意尽量不要对一些业界使用的通用术语进行另外的定义，使它的含义和通用术语的惯用含义不一致。

1.4 参考资料

列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位，必要时说明得到这些文件资料和标准的途径。本节与下一节的“标准、条约和约定”互为补充，注意“参考资料”未必作为“标准、条约和约定”，因为“参考”的不一定是“必须遵守”的。常用资料如：

本项目的合同、标书、上级机关有关通知、经过审批的项目任务书； 属于本项目的其他已经发表的文件；

本文档中各处引用的文件、资料，包括所要用到的软件开发标准。

1.5 标准、条约和约定

列出在本项目开发过程中必须遵守的标准、条约和约定。例如：相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。“参考资料”一般具有“物质”特性，一般要说明参照了什么，要说明在哪里可以获得；“标准、条约和约定”一般具有“精神”特性，一般是必须遵守的，不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。项目概述

2.1 项目目标

设定项目目标就是把项目要完成的工作用清晰的语言描述出来，让项目团队每一个成员都有明确的概念。注意，不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。注意“要完成一个系统”只是一个模糊的目标，它还不够具体和明确。明确的项目目标应该指出了服务对象，所开发软件系统最主要的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。项目目标应当符合SMART原则： l S Specific 明确的陈述 l M Measurable 可以衡量的结果 l A Attainable 可以达成的目标

l R Realistic 合理的，现实的或者说是能和实际工作相结合 l T Trackable 可以跟踪的

项目目标可以进行横向的分解也可以进行纵向的分解。横向分解一般按照系统的功能或按照建设单位的不同业务要求，如分解为第一目标、第二目标等等；纵向的分解一般是指按照阶段，如分解为第一阶段目标、第二阶段目标等等，或近期目标、中期目标、远期目标等等。阶段目标一般应当说明目标实现的较为明确的时间。一般要在说明了总目标的基础上再说明分解目标，可加上“为实现项目的总目标，必须实现以下三个阶段目标······”

2.2 产品目标与范围

根据项目输入（如合同、立项建议书、项目技术方案、标书等）说明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。对项目成果（软件系统）范围进行准确清晰的界定与说明是软件开发项目活动开展的基础和依据。软件系统产品目标应当从用户的角度说明开发这一软件系统是为了解决用户的那些问题。产品目标如“提高工作信息报送反馈工作效率，更好地进行工作信息报送的检查监督，提高信息的及时性、汇总统计信息的准确性，减轻各级相关工作人员的劳动强度。”

2.3 假设与约束

对于项目必须遵守的各种约束（时间、人员、预算、设备等）进行说明。这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成。如：“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”

约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如人力资源的约束限制，就必须牺牲进度或质量等等。

假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性（概率）、造成的影响、应当采取的相应措施。

2.4 项目工作范围

说明为实现项目的目标需要进行那些工作。在必要时，可描述与合作单位和用户的工作分工。注意产品范围与项目工作范围的不同含义。

产品范围界定：软件系统产品本身范围的特征和功能范围。

工作范围界定：为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。

产品范围的完成情况是参照客户的需求来衡量的，而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。

2.5 应交付成果 2.5.1 需完成的软件

列出需要完成的程序的名称、所用的编程语言及存储程序的媒体形式。其中软件对象可能包括：源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。2.5.2 需提交用户的文档

列出需要移交给用户的每种文档的名称、内容要点及存储形式，如需求规格说明书、帮助手册等。此处需要移交用户的文档可参考合同中的规定。2.5.3 须提交内部的文档 可根据《GB8567-88计算机软件产品开发文件编制指南》附录O：“文件编制实施规定的实例（参考件）”结合各企业实际情况调整制定《软件开发文档编制裁减衡量因素表》。根据《因素表》确定项目对应的项目衡量因素取值，以确定本项目应完成的阶段成果。将不适用于本项目的内容裁减，以减少不必要的项目任务和资源。

根据因素取值列出本项目应完成的阶段成果，说明本项目取值所在的区间，将其他因素值区间删除。

2.5.4 应当提供的服务

根据合同或某重点建设工作需要，列出将向用户或委托单位提供的各种服务，例如培训、安装、维护和运行支持等。具体的工作计划如需要编制现场安装作业指导书、培训计划等，应当在本计划“4.3总体进度计划”中条列出。

2.6 项目开发环境

说明开发本软件项目所需要的软硬件环境和版本、如操作系统、开发工具、数据库系统、配置管理工具、网络环境。环境可能不止一种，如开发工具可能需要针对Java的，也需要针对C++的。有些环境可能无法确定，需要在需求分析完成或设计完成后才能确定所需要的环境。

2.7 项目验收方式与依据

说明项目内部验收和用户验收的方式，如验收包括交付前验收、交付后验收、试运行（初步）验收、最终验收、第三方验收、专家参与验收等等。项目验收依据主要有标书、合同、相关标准、项目文档（最主要是需求规格说明书）。项目团队组织

3.1 组织结构

说明项目团队的组织结构。项目的组织结构可以从所需角色和项目成员两个方面描述。所需角色主要说明为了完成本项目任务，项目团队需要哪些角色构成，如项目经理、计划经理、系统分析员（或小组）、构架设计师、设计组、程序组、测试组等等。组织结构可以用图形来表示，可以采用树形图，也可以采用矩阵式图形，同时说明团队成员来自于哪个部门。除了图形外，可以用文字简要说明各个角色应有的技术水平。注意虽然有一些通用的结构可以套用，但各种不同规模、不同形式的项目组织结构是不一样的。如产品研发项目可能就不需要实施人员（小组），但需要知识转移方面的人员（小组）。而软件编码外包的项目则不需要程序员，测试人员也可以适当地减少。3.2 人员分工

确定项目团队的的每个成员属于组织结构中的什么角色，他们的技术水平、项目中的分工与配置，可以用列表方式说明，具体编制时按照项目实际组织结构编写。以下是一个示例。

3.3 协作与沟通

项目的沟通与协作首先应当确定协作与沟通的对象，就是与谁协作、沟通。沟通对象应该包括所有项目干系人，而项目干系人包括了所有项目团队成员、项目接口人员、项目团队外部相关人员等等。

其次应当确定协作模式与沟通方式。沟通方式如会议、使用电话、QQ、内部邮件、外部邮件、QuickPlace、聊天室等等。其中邮件沟通应当说明主送人、抄送人，聊天室沟通方式应当约定时间周期。而协作模式主要说明在出现什么状况的时候各个角色应当（主动）采取什么措施，包括沟通，如何互相配合来共同完成某项任务。定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等

3.3.1 项目团队内部协作

本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。

3.3.2 项目接口人员

应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括： a、负责本项目同用户的接口人员；

b、负责本项目同本企业各管理机构，如计划管理部门、合同管理部门、采购部门、质量管理部门、财务部门等的接口人员；

c、负责本项目同分包方的接口人员。3.3.3 项目团队外部沟通与协作模式

项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。本节说明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录办法等内容。明确最终用户、直接用户及其所在本企业／部门名称和联系电话。明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。实施计划

4.1 风险评估及对策

识别或预估项目进行过程中可能出现的风险。应该分析风险出现的可能性（概率）、造成的影响、根据影响应该采取的对策，采取的措施。风险识别包括识别内在风险及外在风险。内在风险是指项目工作组能加以控制和影响的风险，如人事任免和成本估计等。外在风险指超出项目工作组等控制力和影响力之外的风险，如市场转向或政府行为等

风险的对策包括：避免：排除特定危胁往往靠排除危险起源；减缓：减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数；吸纳：接受一切后果，可以是积

极的（如制定预防性计划来防备风险事件的发生），也可以是消极的（如某些费用超支则接受低于预期的利润）。

对于软件开发项目而言，在分析、识别和管理风险上投入足够的时间和人力可以使项目进展过程更加平稳，提高项目跟踪和控制的能力，由于在问题发生之前已经做了周密计划，因而对项目的成功产生更加充分的信心。软件开发项目常见预估的风险： 1)工程／规模／进度上的风险

规模大，规模估算不精确甚至误差很大；就规模而言，用户要求交付期、费用很紧；预料外的工作(测试未完时的现场对应等)； 2)技术上的风险

使用新的开发技术、新设备等，或是新的应用组合，没有经验；是新的行业或业务，没有经验；性能上的要求很严； 3)用户体制上的问题

用户管理不严，恐怕功能决定、验收不能顺利地完成（或者出现了延迟）；或者恐怕功能会多次变更；与用户分担开发，恐怕工程会拖延（或者出现了延迟）；用户或其他相关单位承担的工作有可能延误；

4)其它：应该包含此处没有、但据推测有风险的项目。

4.2 工作流程

说明项目采用什么样的工作流程进行。如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是自己创建的工作流程。不同的流程将影响后面的工作计划的制定。必要时画出本项目采用的工作流程图及适当的文字说明。4.3 总体进度计划

这里所说的总体进度计划为高层计划。作为补充，应当分阶段制定项目的阶段计划，这些阶段计划不在这份文档中，当要以这份总体计划为依据。

总体进度计划要依据确定的项目规模，列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果，在阶段时间安排中要考虑项目阶段成果完成、提交评审、修改的时间。

对于项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收等工作，给出每项工作任务的预定开始日期、完成日期及所需的资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件（里程碑）。例如

需求评审

设计评审

表格中检查点／里程碑等阶段划分为举例，实际作业阶段划分、阶段成果等请根据项目需要确

定。

制定软件项目进度计划可以使用一些专门的工具，最常用的是Microsoft的Project作为辅助工具，功能比较强大，比较适合于规模较大的项目，但无法完全代替项目计划书，特别是一些主要由文字来说明的部分。小规模的项目可简便地使用EXCEL作为辅助工具。关于如何使用这些工具不在此作详细说明。

制定软件项目进度计划应当考虑以下一些因素: 1）对于系统需求和项目目标的掌握程度。如开始时对于系统需求和项目目标只有比较数的了解，就只能制定出比较粗的进度计划，等到需求阶段或设计阶段结束，就应该进一步细化进度计划。2）软件系统规模和项目规模，这两个不是一个概念。软件系统规模往往是从功能点的估算或其他估算方式得来的，而项目规模还要考虑对文档数量与质量的要求，使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。例如，完成一个大型的系统，在一定的时间内一个人或几个人的智力和体力是承受不了的。由于软件是逻辑、智力产品，盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理方面的问题将更为严重。

3）软件系统复杂程度和项目复杂程度：和软件系统规模和项目规模一样，软件系统的复杂程度主要是考虑软件系统本身的功能、架构的复杂程度，而项目的复杂程度主要是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度，多项目情况下资源保障的情况，等等等等。软件系统的规模与软件系统的复杂程度未必是成比例的关系；同样项目的规模与项目的复杂程度未必是成比例的关系。

4）项目的工期要求，就是项目的紧急程度。有些项目规模大，却因为与顾客签订了合同，或者为了抢先占领市场，工期压缩得很紧，这时就要考虑如何更好地合理安排进度，多增加人选多采用加班的方式是一种万不得已的选择。增加人选除了增加人的成本外必定会增加沟通的成本（熟悉项目任务所需要的时间）；加班如果处理不好会造成情绪上的问题，也可能会因为过于忙碌而无法顾及质量，造成质量的下滑。

5）项目成员的能力。这些能力包括项目经理的管理能力，系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员的测试能力，以及企业或项目团队激发出这些能力的能力。从另外一个角度看还有总体上对客户行业业务的熟悉程度；对于建模工具、开发工具、测试工具等技术的掌握程度；企业内部对行业业务知识和主要技术的知识积累。

4.4 项目控制计划

4.4.1 质量保证计划

执行质量评审活动，对过程质量进行控制。规模较大的项目应当单独编写《软件开发项目质量计划》。根据GB/T 12504 计算机软件质量保证计划规范，内容包括： l 引言（本章节包括质量计划的目的、定义、参考资料）

l 管理（描述负责软件质量管理的机构、任务及其相关的职责）

l 文档（列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则）

l 标准、条例和约定（列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施）

l 评审和检查（规定所要进行的技术和管理两个方面的评审和检查工作，并编制或引用有关的评审和检查规程，以及通过与否的技术准则。至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查）l 软件配置管理（编制有关配置管理条款，或在“4.4.4 配置管理计划”中说明，或引用按照《GB/T 12505 计算机软件配置管理计划规范》单独制定的文档）

l 工具、技术和方法（指明用于支持特定软件项目质量管理工作的工具、技术和方法，指出它们的目的和用途）

l 媒体控制（说明保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化）

l 对供货单位的控制（供货单位包括项目承办单位、软件销售单位、软件开发单位。规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。）

l 记录的收集、维护和保存（指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限）4.4.2 进度控制计划

（可直接引用以下描述或根据项目情况制定本节内容）本项目的进度监控执行本企业《项目管理规范》，由本企业过程控制部门如质量管理部统一进行监控，并保留在监控过程中产生的日常检查记录。4.4.3 预算监控计划

说明如何检查项目预算的使用情况。根据项目情况需要制定。4.4.4 配置管理计划

编制有关软件配置管理的条款，或引用按照GB/T 12505单独制订《配置管理计划》文档。在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。

根据《GB/T 12505 计算机软件配置管理计划规范》，软件配置管理计划内容如下：

l 引言（本章节包括质量计划的目的、定义、参考资料）

l 管理（描述负责软件配置管理的机构、任务、职责及其有关的接口控制。）

l 软件配置管理活动（描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等到四方面的软件配置管理活动的需求。）

l 工具、技术和方法（指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法）

l 对供货单位的控制（供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求）

l 记录的收集、维护和保存（指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施，并指明要保存的期限）支持条件

说明为了支持本项目的完成所需要的各种条件和设施。5.1 内部支持

逐项列出项目每阶段的支持需求（含人员、设备、软件、培训等）及其时间要求和用途。例如，设备、软件支持包括客户机、服务器、网络环境、外设、通讯设备、开发工具、操作系统、数据库管理系统、测试环境，逐项列出有关到货日期、使用时间的要求。5.2 客户支持

列出对项目而言需由客户承担的工作、完成期限和验收标准，包括需由客户提供的条件及提供时间。

5.3 外包（可选）

列出需由外单位分合同承包者承担的工作、完成时间，包括需要由外单位提供的条件和提供的时间。6 预算

6.1 人员成本

列出产品/项目团队每一个人的预计工作月数。

列出完成本项目所需要的劳务（包括人员的数量和时间）

劳务费一般包括工资、奖金、补贴、住房基金、退休养老金、医疗保险金 6.2 设备成本

设备成本包括：原材料费，设备购置及使用费

列出拟购置的设备及其配置和所需的经费 列出拟购置的软件及其版本和所需的经费 使用的现有设备及其使用时间 6.3 其它经费预算

列出完成本项目所需要的各项经费，包括差旅费、资料费、通行费、会议费、交通费、办公费、培训费、外包费等，包括：

（1）差旅费（旅费、出租）（含补贴）

（2）资料费（图书费、资料费、复印费、出版费）

（3）通信费（市话长话费、移动通信费、上网费、邮资）

（4）会议费（鉴定费、评审会、研讨费、外事费等）

（5）办公费（购买办公用品）

（6）协作费（业务协作招待费、项目团队加班伙食费）

（7）培训费（培训资料编写费、资料印刷费、产地费、设备费）其他（检测、外加工费、维修费、消耗品、低易品、茶话会等）6.4 项目合计经费预算

列出完成本项目需要的所有经费预算（上述各项费用之和）。7 关键问题

逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目成败的影响。

8专题计划要点

专题计划也就是因为项目的需要在本文档之外独立建立的计划，本节说明本项目开发中需要制定的各个专题计划的要点。专题计划可能包括分合同计划、分项目计划、项目团队成员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装部署计划。参考文献

《项目管理—计划、进度和控制的系统方法》（第7版）Harold Kerzner（电子工业出版社，杨爱华等译）；

《计算机软件工程规范国家标准汇编2003》中国标准出版社； 《PMBOK-2000》PMI； 《PMBOK-2004》PMI；

《成功的项目管理》Trevol L Young（泰晤士报商业版，严鸿娟译）； 《成功的项目管理》Jack Gido ＆ James P.Clements（21世纪管理经典教材系列，张金城等译）； 《如何做好项目管理》Stanley E.Portny（IDG新经济工商实务傻瓜丛书，宁俊等译）； 《管理软件开发项目》（第二版）Neal Whitten（软件项目管理系列丛书，孙艳春等译）； 《IT项目管理》Kathy Schwalbe（项目管理译丛 王金玉等译）； 《高级项目管理基础》（信息产业部计算机信息系统集成高级项目经理培训讲义）