软件项目计划的计划制定
展开全部项目计划详细说明了所需软件工作及如何实现。
它定义了每一个主要任务,并估算其所需时间和资源,同时为管理层的评估和控制提供了一个框架。
项目计划也提供了一种很有效的学习途径。
如果能合理建档,它便是一个与实际运行效能比较的基准。
这种比较可以使计划者看到他们的估算误差,从而提高其估算精确度。
我们着重强调对项目规模和资源的估算,是因为低质量的项目资源估算将不可避免地造成资源短缺,进度延迟和预算超支。
又由于项目资源估算是从软件规模估算中直接衍生出来的,所以低质量的规模估算是造成许多软件项目问题的根本原因。
项目计划应在项目开始初期制定出,并随着工程的进展不断地加以精化。
起初,由于软件需求通常是模糊而又不完整的,我们的工作重点应在于明确该项目需要哪些领域的知识,并且如何获取这些知识。
如果不遵循这一指导原则,程序员们通常会积极地投入到那部分已知的工作中去,而把未知部分留滞到以后。
这种工作方式通常会产生很多问题,因为未知部分具有最高的风险系数。
软件项目计划的逻辑如下所述 :由于软件需求在初始阶段是模糊而又不完整的,质量计划只能建立在对客户需求的大致而不确切的理解之上。
因此,项目计划应该从找出含糊不确切与准确恰当的软件需求间的映射关系入手。
接着建立一种概念设计。
项目初始架构的建立要十分谨慎,因为它通常标定了产品模块的分割线,同时描述了这些模块所实现的功能及所有模块间的关系。
这就为项目计划和项目实施提供了组织框架,因此一个低质量的概念设计是不能满足要求的。
在每一次后续的需求精化时,也应同时精化资源映射,项目规模估算和工程进度。
软件项目计划-制订软件项目计划的方法与策略制订软件项目计划的目的在于建立并维护软件项目各项活动的计划,软件项目计划其实就是一个用来协调软件项目中其它所有计划,指导项目组对项目进行执行和监控的文件。
一个好的软件项目计划可为项目的成功实施打下坚实的基础。
软件项目有其特殊性,不确定因素多,工作量估计困难,项目初期难于制定一个科学、合理的项目计划。
我曾主持和参与过大大小小的软件项目十余项,下面我将把我制订软件项目计划的经验分享给大家。
1.注重项目计划的层次性软件项目计划的层次及其关系如下图所示。
高级计划,是项目的早期计划。
高级计划应当是粗粒度的,主要是进行项目的阶段划分,确定重大的里程碑,所需相关的资源,包括人力资源、设备资源、资金资源,即所谓的人、财、物三个要素。
大的阶段交替之前,应做好下一阶段的详细计划,我们称之为二级计划。
详细计划要确定各项任务的负责人,开始时间,结束时间,任务之间的依赖关系,设备资源,小的事件点(即里程碑)。
如果项目规模相对较大,可以有多级的计划,比如说,一个项目组可能分为几个开发组,二级计划是各开发组制订的适合的自己小组的计划。
如果开发组还分了小组,可以有小组的三级计划。
开发人员的个人计划是低级计划,由开发人员根据自己的任务自行制定,要把任务细化到人·日。
一般的,软件项目计划至多有四级就够了,过多的等级将会引发效率的瓶颈。
大的项目不见得要有庞大的组织和人员数量来支撑,合理的划分小组,减少组织的层次,有利于项目计划的制订和实施。
较小的软件项目由于工期不长,人员较少,有二级计划(高级计划与低级计划)也是可行的。
2.重视与客户的沟通与客户的沟通是很重要的。
不必害怕客户知道我们的开发计划,特别是项目进度情况,应当和客户共享这些信息。
首先,客户会提出一些对项目时间、进度、效果上的要求,这个指标往往经不起推敲,有的还带有较强的政策性。
如:在我主持的一个某单位人nnerlink>MIS系统的开发中就发现,客户方对时间上的约束是有成形的文件的,是他们单位领导们开会的决定。
客户给出的从项目启动到验收的时间只有三个月,但是,经过我们认真的需求调研,做出项目进度的粗计划和部分的二级计划后,发现三个月的时间是难于实现的。
我们把做出的调研文档和项目计划摆出来和和客户讨论,最终使项目的开发时间延长为六个月。
站在为了科学地分析和解决问题的立场上来看,项目组和客户的目的是一致的,所以对于合理的项目进度客户是会理解与支持的。
其次,我们有义务要让客户知道项目的计划。
这样才能让客户和用户主动、积极参与项目,达到项目的最终目标。
项目计划取得双方签字认可是一种好的习惯。
客户可能不愿意签正式的文件,那么在文档的封面上签上双方负责人的姓名、联系方式也行,虽然是非正式的,但留下了项目工作的痕迹。
有必要想办法让客户清楚签字意味着什么。
这就意味说双方有了一个约定,既让用户感觉心里踏实,也让自己的项目组有了责任感,有一种督促和促进的作用。
3.该详细的详细,该简略的就简略软件项目计划就如同软件项目本身一样有它特殊性,一个三五个人花两三个月就可以完工的小项目,可能项目计划就四五页纸,包括一个WBS(工作分解结构)和一个Gantee图(甘特图)。
一个需要五六十个人甚至上百人,要花上半年或更...
制定计划的时候需要注意什么呢?
这是是一款著名的图像处理软件,人们通常把它简称为PS。
除了出色的图像处理之外,它也是一款图文并茂的优秀编辑软件。
它的功能非常强大,从图文编辑的综合功能的角度而言,对于使用者的能力要求来说,起码要涉及摄影、图像、文字、美工、编辑、排版等等。
不夸张地说,全部玩转PS的所有功能,就相当于具有四、五个专业本科生的知识含量,何况这款软件也还在不断升级。
说完这些,似乎就已经回答了“能从事哪些工作”的问题。
很少有人敢说完全“熟练掌握”PS软件,仅图片制作加工就很不得了呢,放大、缩小、剪裁、翻转、拉伸、变形如果是小儿科的话,那么图片的像素和调整、滤镜、抽出、图层、通道、路径、样式、蒙版等等,会让不少人望而却步!也许有人认为在PS里面的文字排版和Word差不多,其实还是有较大的差别,我们姑且不争,但是文字的美工处理也是很不得了的,字体、字号、加粗、斜体都算是小儿科的话,那么字的虑色、混色、字变形、行变形、字形态、行形态、样式里面的发光字、闪光字、掠光字、彩虹字、内发光、外发光、投影、阴影、叠加、渐变、等高线、浮雕、纹理等等也让不少人望而却步。
还不说编辑、排版、美工等等。
但可以说逐步熟练掌握PS软件的某些功能,先掌握哪些功能一般是根据需要和兴趣而定的,对这些功能的熟练程度,与实际操作的时间成正比。
如果您想学用PS软件的话,我把我的入门和提高经过的简单经验告诉您:1.先到网上搜索PS有关工具的作用和用法。
2.想想自己现在很想学做什么比如照片加工。
3、马上打开PS界面,从“新建”、“打开”(双击工作区看看)、“导入导出”开始动手。
4、PS桌面上(工作区)一旦有一张图片,或新建了一张“画布”,就可以把所有的按钮点一下看看。
然后一步一步深入学习,一定会有收获。
一面学,一面用,学用PS可以说“艺无涯”。
建议:马上动手,定有收获。
共勉吧!
测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪...
软件测试计划是指导测试过程的纲领性文件,包含了产品概述, 测试策略,测试方法,测试区域,测试配置,测试周期,测试资源, 风险分析等内容;借助软件测试计划,参与测试的项目成员, 可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通, 跟踪和控制测试进度,应对测试过程中的各种变更。
在制定测试计划时需要考虑哪些因素
制定测试计划的考虑因素软件测试,是有计划、有组织和有系统的软件质量保证活动,为了规范软件测试内容、方法和过程,在对软件进行测试之前,必须创建测试计划。
软件测试,是一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。
它确认了测试项、被测特征、测试任务、人员安排,以及任何偶发事件的风险。
” 软件测试计划,是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
制定软件测试计划的重要目的,是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。
制定测试计划:目的是为了领导能够根据测试计划做宏观调空,进行相应资源配置等;测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等;便于其他人员了解测试人员的工作内容,进行有关配合工作。
做好软件的测试计划需要综合考虑各种影响测试的因素。
为了做好软件测试计划,需要注意以下几个方面: 1. 明确测试的目标,增强测试计划的实用性 当今任何商业软件都包含了丰富的功能,因此,软件测试的内容千头万绪,如何在纷乱的测试内容之间提炼测试的目标,是制定软件测试计划时首先需要明确的问题。
测试目标必须是明确的,可以量化和度量的,而不是模棱两可的宏观描述。
另外,测试目标应该相对集中,避免罗列出一系列目标,从而轻重不分或平均用力。
根据对用户需求文档和设计规格文档的分析,确定被测软件的质量要求和测试需要达到的目标。
制定软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。
因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确。
2. 坚持"5W、1H"规则,明确内容与过程 "5W、1H"规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。
利用"5W、1H"规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试活动的开始和结束日期(When),指出测试工具以及测试方法、测试策略进行测试(How),给出测试文档和软件的存放位置测试环境(Where)。
为了使"5W、1H"规则更具体化,需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术,在需要测试的内容里面突出关键部分,可以列出关键及风险内容、属性、场景或者测试技术。
对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法。
3. 采用评审和更新机制,保证测试计划满足实际需求 测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
测试计划包含多方面的内容,编写人员可能受自身测试经验和对软件需求的理解所限,而且软件开发是一个渐进的过程,所以最初创建的测试计划可能是不完善的、需要更新的。
需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估。
例如,在创建完测试计划后,提交到由项目经理、开发经理、测试经理、市场经理等组成的评审委员会审阅,根据审阅意见和建议进行修正和更新。
4. 分别创建测试计划与测试详细规格、测试用例 编写软件测试计划要避免“大而全”的测试计划:无所不包,篇幅冗长,长篇大论,重点不突出,既浪费写作时间,也浪费测试人员的阅读时间。
“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。
最好的方法是把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。
测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
http://www.uml.org.cn/ 注:测试计划模板参考要素:测试目的、测试项目简介、测试参考文档、测试提交文档、术语和定义、测试策略、确定测试内容、资源、测试进度、测试人员的任务分配、风险和问题。
零基础编程人员,学好软件开发需要多久的时间
川软教育软件测试培训基地网站上面有详细的介绍,转抄过来看下,或者可以到他们网站上面详细看下,测试方面的技术知识内容挺全的。
一、 新产品或工程管理流程1、 需求调研在软件需求分析阶段,测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研,以测试角度分析需求的可测性,可构思将来对其测试的方法、原则等;同时全面了解系统需求,从客户角度考虑软件测试需要达到的验证状态,即何些功能点需重点测试、何些无需,以便将来制定测试计划。
2、 制定测试计划进行每一种测试之前,测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”,制定总体的测试计划,详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容,“测试计划”经过审查通过,才能实施。
3、 需求Review开发在完成软件需求分析之后,会提交需求分析文档,测试人员根据需求调研所了解的需求以及产品需求说明文档等资料,对需求分析文档进行Review,检查文档是否满足了需求,是否与需求一致等等。
4、 设计Review在软件分析设计阶段,测试人员参与设计讨论,了解系统的实现方式和原理,并对概要设计和详细设计提出自己的见解。
设计结束之后,开发提交概要设计文档和详细设计文档,测试人员对设计进行Review,检查设计规划和实现方案是否合理,如果不合理,存在的问题是什么、如何改进等等。
5、 测试设计在设计测试方案时,首先分解测试内容,对于一个复杂系统,通常可以分解成几个互相独立的子系统,正确地划分这些子系统及其逻辑组成部分和相互间的关系,可以降低测试的复杂性,减少重复和遗漏,也便于设计和开发测试用例,有效的组织测试,将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档,重要的是描述对系统分解后每个功能点逐一的校验描述,包括何种方法测试、何种数据测试、期望测试结果等。
然后以功能点分析文档作为依据进行测试用例的设计,设计测试用例是关系到测试效果以至软件质量的关键性一步,也是一项非常细致的工作,根据对具体的北侧系统的分析和测试要求,逐步细化测试的范围和内容,设计具体的测试过程和数据,同时将结果写成可以按步执行的测试文档。
每个测试用例必须包括以下几个部分:(1) 标题和编号(2) 测试的目标和目的(3) 输入和使用的数据和操作过程(4) 期望的输出结果(5) 其他特殊的环境要求、次序要求、时间要求等6、开发测试工具和准备测试数据在软件测试中,为了提高测试工作的效益和质量,只要条件许可,应尽可能采用计算机自动或半自动测试的方法,利用软件工具本身的优势来提高工作效率。
7、测试执行当所有必需的测试准备工作都已完成,并且产品已经开发完毕并提交测试,则可以按照预定的测试计划和测试方案逐项进行测试。
在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来,填写测试记录。
为了能准确的找出问题产生的原因,及时的解决问题,保证测试工作的顺利进行,一般来说所发现的问题必须是能够重视的。
8、回归测试在测试中发现的任何问题和错误都必须有一个明确的解决方法。
一般来说,经过修改的软件可能仍然包含着错误,甚至引入了新的错误,因此,对于修改以后的程序和文档,按照修改的方法和影响的范围,必须重新进行有关的测试。
另一方面,对于版本更新后的软件也必须进行同样的测试过程。
9、测试分析报告测试结束后要及时地进行总结,对测试结果进行分析,由测试负责人提交“测试分析报告”。
为什么要在做测试计划前对软件需求进行评审和测试?
需求是不断更新的,当客户加上某点或是删去某点功能,需求变更随时都可能发生。
需求的开发是贯穿整个开发过程的,不是做测试计划前就完成。
这是一个不断循环迭代的过程。
需求验证活动可以确保需求符合优秀需求称述的特征,并且符合好的需求规格说明的特征。
因此,在部分需求确定下来时,就对这些已经发现的需求进行评审和测试,尽快开发测试用例,就能够及早发现需求方面的缺陷和问题,这样就可以只用较低的费用解决这些问题。
若是在测试结束后,才发现遗漏了某个重要需求;对于某个不是很重要的需求,开发过程中却将其作为重点等等这些问题,那么这个损失就巨大了,需要开发人员重新开发,甚至于重新回到原点,这样将耗费巨大的人力物力。
测试计划工作的目的是什么
展开全部 软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方单元测试完成之后,接下来的工作就是集成测试.软件集成测试主要依据软件结构设计(概要设计)文档,测试主要内容有功能性、可靠性、易用性、效率、维护性和可移植性中相关的部分,根据软件需求和设计的要求而选定。
验证各软件单元集成后形成的模块能否达到概要设计规格说明中各模块的设计目标;这里,模块可能是指某个软件部件,也可能是指某个或某几个子系统。
通常在做集成测试时先是从子系统内部的集成测试开始做起,做完以后再测试各子系统是否能集成为最终要实现的整体系统。
也有其他做法(如自顶向下集成测试方法、核心系统先做集成测试或每日集成测试等等)。
总之,万变不离其宗,集成测试要保证模块的内部正确性以及保证模块能最终集成为完整的系统。
集成测试有时也被称为组装测试或灰盒测试(有观点认为集成测试介于白盒与黑盒之间)。
软件集成测试具体内容包括:1.功能性测试(1)程序的功能测试。
检查各个子功能组合起来能否满足设计所要求的功能。
(2)一个程序单元或模块的功能是否会对另一个程序单元或模块的功能产生不利影响。
(3)根据计算精度的要求,单个程序模块的误差积累起来,是否仍能够达到要求的技术指标。
(4)程序单元或模块之间的接口测试。
把各个程序单元或模块连接起来时,数据在通过其接口时是否会出现不一致情况,是否会出现数据丢失。
(5)全局数据结构的测试。
检查各个程序单元或模块所用到的全局变量是否一致、合理。
(6)对程序中可能有的特殊安全性要求进行测试。
2.可靠性测试 根据软件需求和设计中提出的要求,对软件的容错性、易恢复性、错误处理能力进行测试。
3.易用性测试 根据软件设计中提出的要求,对软件的易理解性、易学性和易操作性进行检查和测试。
4.性能测试 根据软件需求和设计中提出的要求,进行软件的时间特性、资源特性测试。
5.维护性测试 根据软件需求和设计中提出的要求,对软件的易修改性进行测试。
6.可移植性测试 根据软件需求和设计中提出的要求,对软件在不同操作系统环境下被使用的正确性进行测试。