2软件开发计划(SDP)
软件测试术语中英文对照
data definition C-use pair：数据定义C-use使用对
data definition P-use coverage：数据定义P-use覆盖
data definition P-use pair：数据定义P-use使用对
data definition：数据定义
data definition-use coverage：数据定义使用覆盖
data definition-use pair ：数据定义使用对
data definition-use testing：数据定义使用测试
Check In :检入
Check Out :检出
Closeout : 收尾
code audit ：代码审计
Code coverage : 代码覆盖
Code Inspection：代码检视
Core team : 核心小组
corrective maintenance：故障检修
correctness ：正确性
coverage ：覆盖率
coverage item：覆盖项
crash：崩溃
Beta testing : β测试
Black Box Testing：黑盒测试
Blocking bug : 阻碍性错误
Bottom-up testing : 自底向上测试
boundary value coverage：边界值覆盖
boundary value testing：边界值测试
Bug bash : 错误大扫除
bug fix : 错误修正
Bug report : 错误报告
软件设计模式sdp-第4章
public Result service(Parameter p){ //服务实现 //return语句
} }
使用单例时，需要注意以下问题
• 编程语言中反射和序列化/反序列化可能会 破坏单例特性
• 多客户端并发访问单例时，也可能会破坏 单例特性
• 在软件系统中使用过多的单例对象，会导 致使程序性能下降
使用原型模式时需要注意的问题
• 对象拷贝在不同的编程语言中有深度拷贝 （Deep Copy，也翻译成深度复制、深拷贝 等）和浅拷贝（Shallow Copy，也翻译成影 子拷贝、影子复制、浅度复制、浅复制等） 的区别
• 如果原型类之间有循环引用的作用域，则 无法实现深度拷贝
使用原型模式的行业案例1
notification.setContent(content);//设置通知内容 notification.setTitle(title);//设置通知标题 notification.setReceiver(receiver);//设置通知接收者 send(notification); //发送通知 } /** * 发送通知 */ private void send(Notification noti) { sendQueue.add(noti); //其他操作 } }
public class NotificationProtoManager {
private static HashMap<String, Notification> manager =
new
HashMap<String,
Notification>();//原型管理器
static {
02 - 软件开发计划(SDP)
软件开发计划(SDP)说明：1.《软件开发计划》(SDP)描述开发者实施软件开发工作的计划，本文档中“软件开发”一词涵盖了新开发、修改、重用、再工程、维护和由软件产品引起的其他所有的活动。
2.SDP是向需求方提供了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。
3.本计划的某些部分可视实际需要单独编制成册，例如，软件配置管理计划、软件质量保证计划和文档编制计划等。
目录软件开发计划(SDP) (1)1引言 (6)1.1标识 (6)1.2系统概述 (6)1.3文档概述 (6)1.4与其他计划之间的关系 (6)1.5基线 (6)2引用文件 (6)3交付产品 (7)3.1程序 (7)3.2文档 (7)3.3服务 (7)3.4非移交产品 (7)3.5验收标准 (7)3.6最后交付期限 (7)4所需工作概述 (7)5实施整个软件开发活动的计划 (7)5.1软件开发过程 (8)5.2软件开发总体计划 (8)5.2.1软件开发方法 (8)5.2.2软件产品标准 (8)5.2.3可重用的软件产品 (8)5.2.4处理关键性需求 (9)5.2.5计算机硬件资源利用 (9)5.2.6记录原理 (9)5.2.7需方评审途径 (9)6实施详细软件开发活动的计划 (10)6.1项目计划和监督 (10)6.1.1软件开发计划(包括对该计划的更新) (10)6.1.2CSCI测试计划 (10)6.1.3系统测试计划 (10)6.1.4软件安装计划 (10)6.1.5软件移交计划 (10)6.1.6跟踪和更新计划，包括评审管理的时间间隔 (10)6.2建立软件开发环境 (10)6.2.1软件工程环境 (11)6.2.2软件测试环境 (11)6.2.3软件开发库 (11)6.2.4软件开发文档 (11)6.2.5非交付软件 (11)6.3系统需求分析 (11)6.3.1用户输入分析 (11)6.3.2运行概念 (11)6.3.3系统需求 (11)6.4系统设计 (11)6.4.1系统级设计决策 (11)6.4.2系统体系结构设计 (11)6.5软件需求分析 (11)6.6软件设计 (11)6.6.1CSCI级设计决策 (12)6.6.2CSCI体系结构设计 (12)6.6.3CSCI详细设计 (12)6.7软件实现和配置项测试 (12)6.7.1软件实现 (12)6.7.2配置项测试准备 (12)6.7.3配置项测试执行 (12)6.7.4修改和再测试 (12)6.7.5配置项测试结果分析与记录 (12)6.8配置项集成和测试 (12)6.8.1配置项集成和测试准备 (13)6.8.2配置项集成和测试执行 (13)6.8.3修改和再测试 (13)6.8.4配置项集成和测试结果分析与记录 (13)6.9CSCI合格性测试 (13)6.9.1CSCI合格性测试的独立性 (13)6.9.2在目标计算机系统(或模拟的环境)上测试 (13)6.9.3CSCI合格性测试准备 (13)6.9.4CSCI合格性测试演练 (13)6.9.5CSCI合格性测试执行 (13)6.9.6修改和再测试 (13)6.9.7CSCI合格性测试结果分析与记录 (13)6.10CSCI/HWCI集成和测试 (13)6.10.1CSCI/HWCI集成和测试准备 (14)6.10.2CSCI/HWCI集成和测试执行 (14)6.10.3修改和再测试 (14)6.10.4CSCI/HWCI集成和测试结果分析与记录 (14)6.11系统合格性测试 (14)6.11.1系统合格性测试的独立性 (14)6.11.2在目标计算机系统(或模拟的环境)上测试 (14)6.11.3系统合格性测试准备 (14)6.11.4系统合格性测试演练 (14)6.11.5系统合格性测试执行 (14)6.11.6修改和再测试 (14)6.11.7系统合格性测试结果分析与记录 (14)6.12软件使用准备 (14)6.12.1可执行软件的准备 (15)6.12.2用户现场的版本说明的准备 (15)6.12.3用户手册的准备 (15)6.12.4在用户现场安装 (15)6.13软件移交准备 (15)6.13.1可执行软件的准备 (15)6.13.2源文件准备 (15)6.13.3支持现场的版本说明的准备 (15)6.13.4“已完成”的CSCI设计和其他的软件支持信息的准备 (15)6.13.5系统设计说明的更新 (15)6.13.6支持手册准备 (15)6.13.7到指定支持现场的移交 (15)6.14软件配置管理 (15)6.14.1配置标识 (16)6.14.2配置控制 (16)6.14.3配置状态统计 (16)6.14.4配置审核 (16)6.14.5发行管理和交付 (16)6.15软件产品评估 (16)6.15.1中间阶段的和最终的软件产品评估 (16)6.15.2软件产品评估记录(包括所记录的具体条目) (16)6.15.3软件产品评估的独立性 (16)6.16软件质量保证 (16)6.16.1软件质量保证评估 (17)6.16.2软件质量保证记录、包括所记录的具体条目 (17)6.16.3软件质量保证的独立性 (17)6.17问题解决过程(更正活动) (17)6.17.1问题/变更报告 (17)6.17.2更正活动系统 (17)6.18联合评审(联合技术评审和联合管理评审) (17)6.18.1联合技术评审包括----组建议的评审 (17)6.18.2联合管理评审包括----组建议的评审 (17)6.19文档编制 (17)6.20其他软件开发活动 (18)6.20.1风险管理，包括已知的风险和相应的对策 (18)6.20.2软件管理指标，包括要使用的指标 (18)6.20.3保密性和私密性 (18)6.20.4分承包方管理 (18)6.20.5与软件独立验证与确认(IV&V)机构的接口 (18)6.20.6和有关开发方的协调 (18)6.20.7项目过程的改进 (18)6.20.8计划中未提及的其他活动 (18)7进度表和活动网络图 (18)8项目组织和资源 (18)8.1项目组织 (19)8.2项目资源 (19)9培训 (19)9.1项目的技术要求 (19)9.2培训计划 (19)10项目估算 (19)10.1规模估算 (20)10.2工作量估算 (20)10.3成本估算 (20)10.4关键计算机资源估算 (20)10.5管理预留 (20)11风险管理 (20)12支持条件 (20)12.1计算机系统支持。
物业管理系统
物业管理系统软件开发计划书1、概述（1）项目介绍项目中文名称：物业管理系统。
项目英文名称：Property Management System。
项目代号：NS/TEL-PMS-CRM。
项目目的：面向社会广大的物业管理开发商，适用与一切的物业管理功能，将帮助广大的用户更好的管理，服务与业主。
项目背景：CMM过程改进。
客户信息：物业管理开发商。
与其他系统的关系：基于BOSS的业务数据进行分析，同时又是DSS的扩展，与他们既有交叉，又有延伸。
（2）范围资料维护：包括开发商的资料，物业基本资料。
住房管理：包括住户入住登记，住户资料的修改和住户的变更。
财产管理：包括小区物业管辖内的资产、设施等管理。
财务管理：包括物业管理费、小区停车费、物业维修基金、“水费、电费、煤气费”三费的收取。
信息管理：小区出租、出售房屋信息发布，投诉管理。
小区工作人员和保安人员的岗位人员的管理。
（3）子计划软件配置管理计划；软件质量保证计划；软件测试计划；（4）项目计划的维护项目计划在下列情况下将被更新；1）项目关键问题的解决；2）需求更改导致项目进度的调整在两周或两周以上；3）项目资源需求的改变；4）新技术的引入；5）开发过程的改变；6）软件工作产品的改变；7）项目特性的改变；在项目阶段性审核时，如果更改项目计划，那么项目进度表也应作相应的更新。
如果项目进度或项目特性有重大改变时，项目计划的更新更改应得到SCCB认可。
（5）项目特性研发初期的阶段性产品。
需求部分可以确定，大部分不能马上确定。
宣传推广新的CRM理念是一种概念化的产品。
2、软件工作产品软件工作产品进度表A=审核，R=评审，采用审查还是评审由项目组决定。
3、假设、依赖和约束假设：项目估计所用到的条件是真实的，从而得到基本准确的计划。
依赖的外部条件：1）开发环境条件配备；2）开发人员如期到位；3）项目组及相关组成员受过必要的培训；4）和客户联系顺利；5）指派SCCB、PM、SQA、SCM、测试组人员。
GJB438B军用软件开发文档通用要求
软件使用准备 分承制方管理
软件移交准备 与IV&V机构联系
软件验收支持 与相关开发方协调
组织活动类（2个）
软件开发环境建立
项目过程的改进
文档表示方式
表示形式：为使各文档章条的信息更加清晰 可读，可采用图、表、矩阵或其它形式的表 示方式进行说明。 页码编制
文档正文的目录使用小写罗马数字编号； 文档正文和附录均使用阿拉伯数字顺序编号； 若一个文档分为若干卷，则每一卷应重新开始按顺序编 号。
软件移交计划（STrP）
描述开发方向保障机构移交应交付项的计 划。 如果在合同或软件研制任务书中规定了向 独立保障方移交的责任，应制定STrP。
STrP的主要内容
软件保障资源：描述支持可交付软件所需的设施、硬件、软 件及其相关的文档，描述支持可交付软件所需的人员及其它 资源，并标识各部分软件保障资源之间的关系。 推荐的过程：描述为支持可交付的软件和相关的保障环境， 开发方希望向保障机构推荐的规程，包括建议和经验教训。 培训：描述开发方关于软件交付支持人员的培训计划。
STP的主要内容
测试依据：列出软件测试必须遵循的依据。
软件测试环境：描述在各测试现场的测试活动所需的软件项、硬件和固件 项等，描述网络拓扑图及所需的其它材料，描述与软件测试环境中每个元 素有关的专有性质、需方权利与许可证等问题，描述开发方安装、测试和 控制软件测试环境中的每一项的计划，描述拟建立的测试环境与需求环境 之间的差异，描述参与现场测试的组织及职责、人员及分工，描述测试前 和测试期间要进行的人员培训，标识测试现场要执行的测试等。 测试标识：描述要执行的测试的级别、类别、一般测试条件、测试进展、 数据记录整理和分析等一般信息，描述计划执行的测试等。 测试进度：描述实施本计划中所标识测试的进度表。 测试终止条件：描述被测软件的评价准则和方法以及结束测试的条件。 需求的可追踪性。
pdca循环运用例子
pdca循环运用例子在ASPICE标准的理解过程中，初学者常常面对纷繁复杂的过程实践不知何从下手（Practice）——其中的265个基本实践（Base Practice）和42个通用实践（Generic Practice）分布在32个过程域、5个级别的框架中，各司其职又彼此关联。
如果不能用清晰的脉络厘清这些实践中的序列关系，很容易陷入“只见树木、不见森林”的处境。
在之前一篇ASPICE的解析文章《红绿蓝——ASPICE过程域的组织形式》中（以下为地址），用红绿蓝三色滤镜对ASPICE各个过程域组织形式的全貌做了整体的概览。
而在这一篇里将用PDCA四色分光镜对具体的实践进行解析。
从ASPICE3.1的《表E.1 —参考标准》来看（如下图），其来源无一例外地来自ISO族的标准（如ISO33020 / ISO12207等），而与ISO最广为人知的质量体系标准ISO9000系标准类似，它同样遵循着过程方法的原则(Process Approach)。
在众多方法论中，被广泛应用的“戴明环”PDCA同样在ASPICE的实践序列的定义中得到体现。
ASPICE3.1的《表E.1 —参考标准》在具体解析之前，我们先看看PDCA的定义——PDCA（Plan-Do-Check-Act的简称）循环式品质管理，针对品质工作按计划、执行、检查与行动来进行活动，以确保可靠度目标之达成，并进而促使品质持续改善。
由美国学者爱德华兹·戴明提出，因此也称戴明环。
这个四步的循环一般用来提高产品品质和改善产品生产过程。
（参考维基百科）了解了基本定义，我们随着这四个步骤，解读在ASPICE中，具体的过程域中是如何把这个过程方法的原则落地的，因为篇幅有限，本文讨论的是VDA范围的主要的工程过程域，即系统部分（SYS.2-SYS.5）和软件部分（SWE.1-SWE.6），以及相关的的项目管理部分（MAN.3）。
计划篇（Plan）建立明确的目标，并制定相关的计划和确定必要的程序。
软件测试英语专业词汇
1.软件测试英语专业词汇2.NLV：Nation Language Version 本地化版本3.FVT：Functional Verification Testing 功能验证测试T：Translation Verification Testing 翻译验证测试5.SVT：System Verification Testing 系统验证测试6.fault－－故障在软件中一个错误的表现。
7.feasible path－－可达路径可以通过一组输入值和条件执行到的一条路径。
8.feature testing－－特性测试参考功能测试（Functional Testing）9.FMEA－－失效模型效果分析（Failure Modes and Effects Analysis）可靠性分析中的一种方法，用于在基本组件级别上确认对系统性能有重大影响的失效10.FMECA－－失效模型效果关键性分析(Failure Modes and EffectsCriticality Analysis)FMEA的一个扩展，它分析了失效结果的严重性。
11.FTA－－故障树分析(Fault Tree Analysis)引起一个不需要事件产生的条件和因素的确认和分析，通常是严重影响系统性能、经济性、安全性或其它需要特性。
12.functional decomposition－－功能分解参考模块分解（modular decomposition）13.Functional Specification －－功能规格说明书一个详细描述产品特性的文档。
14.Functional Testing－－功能测试测试一个产品的特性和可操作行为以确定它们满足规格。
15.glass box testing－－玻璃盒测试参考白盒测试（White Box Testing）16.IEEE－－美国电子与电器工程师学会（Institute of Electrical andElectronic Engineers）17.incremental testing－－渐增测试集成测试的一种，组件逐渐被增加到系统中直到整个系统被集成。
专业英语软件测试吐血整理
NLV：Nation Language Version 本地化版本FVT：Functional Verification Testing 功能验证测试TVT：Translation Verification Testing 翻译验证测试SVT：System Verification Testing 系统验证测试fault－－故障在软件中一个错误的表现。
feasible path－－可达路径可以通过一组输入值和条件执行到的一条路径。
feature testing－－特性测试参考功能测试（Functional Testing）FMEA－－失效模型效果分析（Failure Modes and Effects Analysis）可靠性分析中的一种方法，用于在基本组件级别上确认对系统性能有重大影响的失效FMECA－－失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)FMEA 的一个扩展，它分析了失效结果的严重性。
FTA－－故障树分析(Fault Tree Analysis)引起一个不需要事件产生的条件和因素的确认和分析，通常是严重影响系统性能、经济性、安全性或其它需要特性。
functional decomposition－－功能分解参考模块分解（modular decomposition）Functional Specification －－功能规格说明书一个详细描述产品特性的文档。
Functional Testing－－功能测试测试一个产品的特性和可操作行为以确定它们满足规格。
glass box testing－－玻璃盒测试参考白盒测试（White Box Testing）IEEE－－美国电子与电器工程师学会（Institute of Electrical and Electronic Engineers）incremental testing－－渐增测试集成测试的一种，组件逐渐被增加到系统中直到整个系统被集成。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
身高体重分析软件开发计划(SDP)组员：说明：1.《软件开发计划》(SDP)描述开发者实施软件开发工作的计划，本文档中“软件开发”一词涵盖了新开发、修改、重用、再工程、维护和由软件产品引起的其他所有的活动。
2.SDP是向需求方提供了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。
3.本计划的某些部分可视实际需要单独编制成册，例如，软件配置管理计划、软件质量保证计划和文档编制计划等。
目录软件开发计划(SDP) (1)1引言 (6)1.1标识 (6)1.2系统概述 (6)1.3文档概述 (6)1.4与其他计划之间的关系 (6)1.5基线 (6)2引用文件 (6)3交付产品 (7)3.1程序 (7)3.2文档 (7)3.3服务 (7)3.4非移交产品 (7)3.5验收标准 (7)3.6最后交付期限 (7)4所需工作概述 (8)5实施整个软件开发活动的计划 (8)5.1软件开发过程 (8)5.2软件开发总体计划 (8)5.2.1软件开发方法 (8)5.2.2软件产品标准 (8)5.2.3可重用的软件产品 (8)5.2.4处理关键性需求 (8)5.2.5计算机硬件资源利用 (8)5.2.6记录原理 (8)5.2.7需方评审途径 (8)6实施详细软件开发活动的计划 (9)6.1项目计划和监督 (9)6.1.1软件开发计划(包括对该计划的更新) (9)6.1.2CSCI测试计划 (9)6.1.3系统测试计划 (9)6.1.4软件安装计划 (9)6.1.5软件移交计划 (10)6.1.6跟踪和更新计划，包括评审管理的时间间隔 (10)6.2建立软件开发环境 (10)6.2.1软件工程环境 (10)6.2.2软件测试环境 (10)6.2.3软件开发库 (10)6.2.4软件开发文档...........................................................................错误!未定义书签。
6.2.5非交付软件...............................................................................错误!未定义书签。
6.3系统需求分析 (10)6.3.1用户输入分析 (10)6.3.2运行概念 (11)6.3.3系统需求 (11)6.4系统设计 (11)6.4.1系统级设计决策 (11)6.4.2系统体系结构设计 (11)6.5软件需求分析 (11)6.6软件设计 (11)6.6.1CSCI级设计决策 (11)6.6.2CSCI体系结构设计 (11)6.6.3CSCI详细设计 (11)6.7软件实现和配置项测试 (11)6.7.1软件实现 (11)6.7.2配置项测试准备 (12)6.7.3配置项测试执行 (12)6.7.4修改和再测试 (12)6.7.5配置项测试结果分析与记录 (13)6.8配置项集成和测试 (13)6.8.1配置项集成和测试准备 (13)6.8.2配置项集成和测试执行 (13)6.8.3修改和再测试 (13)6.8.4配置项集成和测试结果分析与记录 (13)6.9CSCI合格性测试 (13)6.9.1CSCI合格性测试的独立性 (13)6.9.2在目标计算机系统(或模拟的环境)上测试 (13)6.9.3CSCI合格性测试准备 (13)6.9.4CSCI合格性测试演练 (13)6.9.5CSCI合格性测试执行 (13)6.9.6修改和再测试 (13)6.9.7CSCI合格性测试结果分析与记录 (13)6.10CSCI/HWCI集成和测试 (13)6.10.1CSCI/HWCI集成和测试准备 (13)6.10.2CSCI/HWCI集成和测试执行 (14)6.10.3修改和再测试 (14)6.10.4CSCI/HWCI集成和测试结果分析与记录 (14)6.11系统合格性测试 (14)6.11.1系统合格性测试的独立性 (14)6.11.2在目标计算机系统(或模拟的环境)上测试 (14)6.11.3系统合格性测试准备 (14)6.11.4系统合格性测试演练 (14)6.11.5系统合格性测试执行 (14)6.11.6修改和再测试 (14)6.11.7系统合格性测试结果分析与记录 (14)6.12软件使用准备 (14)6.12.1可执行软件的准备.................................................................错误!未定义书签。
6.12.2用户现场的版本说明的准备.................................................错误!未定义书签。
6.12.3用户手册的准备.....................................................................错误!未定义书签。
6.12.4在用户现场安装.....................................................................错误!未定义书签。
6.13软件移交准备 (14)6.13.1可执行软件的准备 (14)6.13.2源文件准备 (15)6.13.3支持现场的版本说明的准备 (15)6.13.4“已完成”的CSCI设计和其他的软件支持信息的准备 (15)6.13.5系统设计说明的更新 (15)6.13.6支持手册准备 (15)6.13.7到指定支持现场的移交 (15)6.14软件配置管理 (15)6.14.1配置标识 (15)6.14.2配置控制 (15)6.14.3配置状态统计 (15)6.14.4配置审核 (15)6.14.5发行管理和交付 (16)6.15软件产品评估 (16)6.15.1中间阶段的和最终的软件产品评估 (16)6.15.2软件产品评估记录(包括所记录的具体条目) (16)6.15.3软件产品评估的独立性 (16)6.16软件质量保证 (16)6.16.1软件质量保证评估 (16)6.16.2软件质量保证记录、包括所记录的具体条目 (16)6.16.3软件质量保证的独立性 (16)6.17问题解决过程(更正活动) (16)6.17.1问题/变更报告 (16)6.17.2更正活动系统 (16)6.18联合评审(联合技术评审和联合管理评审) (16)6.18.1联合技术评审包括----组建议的评审 (16)6.18.2联合管理评审包括----组建议的评审 (16)6.19文档编制 (16)6.20其他软件开发活动 (17)6.20.1风险管理，包括已知的风险和相应的对策 (17)6.20.2软件管理指标，包括要使用的指标 (17)6.20.3保密性和私密性 (17)6.20.4分承包方管理 (17)6.20.5与软件独立验证与确认(IV&V)机构的接口 (17)6.20.6和有关开发方的协调 (17)6.20.7项目过程的改进 (17)6.20.8计划中未提及的其他活动 (17)7进度表和活动网络图 (17)8项目组织和资源 (18)8.1项目组织 (18)8.2项目资源 (18)9培训 (18)9.1项目的技术要求 (18)9.2培训计划 (19)10项目估算 (19)10.1规模估算 (19)10.2工作量估算 (19)10.3成本估算 (19)10.4关键计算机资源估算 (19)10.5管理预留 (19)11风险管理 (19)12支持条件 (20)12.1计算机系统支持。
(20)12.2需要需方承担的工作和提供的条件。
(20)12.3需要分包商承担的工作和提供的条件。
(20)13注解 (20)附录 (20)1引言1.1标识标题：身高体重分析软件版本号：1.01.2系统概述一套针对身高体重测试的分析软件，所有人都能使用，它包括了检测体型是否正常，个人身高所对应的标准体重，预测未来身高以及最合适的伴侣体型。
需求方：健身中心，减肥中心等开发者：计算机团队小组用户：所有人均可使用原有系统只能依靠输入身高体重来测试自己体型是否正常。
现有系统可以通过测试身高体型比例来提出合理的饮食建议，此外还实现了许多额外功能来使软件功能更加丰富，更受使用者青睐。
1.3文档概述本文档为此项目开发的计划文档，用于规划整个开发过程。
本文档的阅读对象如下：1、开发人员2、测试阶段人员3、对本文档进行评审的人员或机构4、项目组及其他有权需要调用本文档的人员1.4与其他计划之间的关系无1.5基线版本：“1.0”2引用文件《软件工程》第二版——高等教育出版社《软件工程导论》第五版——清华大学出版社《计算机软件文档编制规范》GB-T8567-20063交付产品3.1程序完整的安装程序。
3.2文档规格说明书，操作指南。
3.3服务版本升级服务。
3.4非移交产品测试版本：1.0beta(拥有配套的测试软件）3.5验收标准可运行的完整测试程序。
3.6最后交付期限2013年5月20日。
4所需工作概述本项目需开发出一个可以在windows操作系统上运行的身高体重分析软件。
所需文档包括可行性分析（研究）报告（FAR）和软件需求规格说明书（SRS）。
在系统生命周期中处于软件开发时期。
选用五人小组开发计划，由五人配合一起完成软件的开发。
5实施整个软件开发活动的计划5.1软件开发过程因为本项目开发的目的已经很明确，而且不用在短时间内先设定软件的原型，因此本软件开发采用瀑布式模型，按线性结构并依靠文档驱动进行规范的开发。
依据软件功能需求进行设计，并且最终编码实现（主要），和测试升级维护。
5.2软件开发总体计划5.2.1软件开发方法*本系统采用面向过程开发方法。
5.2.2软件产品标准GB/T 8567-2006标准5.2.3可重用的软件产品不适用5.2.4处理关键性需求不适用5.2.5计算机硬件资源利用在计算机上进行全程开发，测试以及维护工作。
5.2.6记录原理不适用5.2.7需方评审途径开发小组介绍软件的方法与构造，然后交付软件由任课老师评审。
6实施详细软件开发活动的计划6.1项目计划和监督小组五人分配项目中的任务，软件分析定义（包括需求分析，可行性分析）由王葵、殷春蕾负责；软件开发（包括详细设计，编码实现）由李武晨、贠向前负责；综合测试（包括测试，维护，升级）由张奕男负责。
五人互相监督完成各自任务，不用独立完成各自负责任务，尽量团队合作一起完成。
6.1.1软件开发计划(包括对该计划的更新)根据需求分析，该软件应该基本实现：体型是否标准测算：选择性别，输入身高和体重，根据相应公式算出结果，并给出建议。