项目管理的质量保证计划.docx

《项目管理的质量保证计划.docx》由会员分享，可在线阅读，更多相关《项目管理的质量保证计划.docx（28页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、项目管理的质量保证计划项目管理的质量保证计划的完成项目。项目管理包括了项目组开发各阶段的人员构造的配置，质量控制的施行方略，内部文档和产品文档的组织编写等各项工作。范化软件的生产方式进行生产，在生产流程上采用ISO9000的标准进行。项目开发介入的角色有项目经理，项目负责人，领域专家，系统分析员，程序员，测试组，技术支持部，质量监督组，文档组。下面就各个角色逐一讲明其主要职责。接洽和开发配合方面的事物，包括：项目合同的签定；提交开发计划给客户；组织客户与分析人员进行需求确定；组织客户阶段性验收；协调客户提供测试环境；监督项目进度与质量；提供开发人员所需的各种人力物力资源；负责项目开发经过中客户

2、、开发项目组、质量监督部，文档组等相关部门的联络与沟通。项目的开发采用项目负责人责任制。项目的开发由项目负责人全权负责，负责的范围包括：项目开发计划的制定；开发方法确实定；技术规范的编制；项目各阶段的人员配给与人员之间的配合；各阶段文档的生成和版本编号。家以由客户抽调技术骨干担任，可以以由开发商聘请担任。领域专家在开发经过中主要介入的阶段是系统需求分析，在明确了系统将来要完成的主要任务之后，领域专家的职责转向系统用户界面确实定上。开发出的系统能被客户接受的两个重要指标一个是系统正确性，即系统能否正确的完成了用户希望它完成的任务；第二就是系统操作的便捷性。便捷主要遭到使用系统的客户的操作习惯的制

3、约。领域专家往往是多年从事该项工作的人员，他们的使用习惯会对系统的易用性非常有帮助。领域专家介入的开发阶段遭到开发方式的影响。系统分析员是系统开发方法的贯彻者和系统实现的指导者。分析人员主要介入开发阶段的需求分析和系统设计两个阶段这两个阶段并不是截然分开的，由开发方式的不同，可能会贯穿整个开发工期。对领域进行分析，确定领域边界和领域内容。在完成这项任务后，系统分析员应当提交（系统需求报告）。（系统需求报告）由领域专家确认之后交给质量监督组进行复审，复审完毕由文档组进行文档规范化，进行存档和版本编号，与此同时，规范化的（系统需求报告）由项目经理转交给客户进行复审项目经理对（系统需求报告）的内容格

4、式等有审查的义务。人转交给系统分析员进行更新修正，并对版本进行升级。之后再经质量监督组和文档组等环节进行流转，直到该报告无须进行再流转为止。接下来系统分析员的一项主要任务是对领域进行分析和映射，构造系统构架，即进行体系构造的设计。当体系构造基本确定之后，定义分组和分组之间的接口，十分对将来需要密切接口的部分要进行具体定义，包括相互间的通讯协议，时间及方式等等。完成该项工作后必须产生（体系构造设计讲明）。（体系构造设计讲明）生成后由项目负责人提交给质量监督组进行复审，复审通过之后，由文档组进行格式化和版本编号并存档。（体系构造设计讲明）的完好流转经过在开发商内部，客户并不参与。以由系统分析员的指

5、导之下，由程序员进行界面原形的开发。界面原形由领域专家进行评审。评审通过后由客户进行复审。界面原形跳过质量监督由文档组进行格式化和存档。质量监督有了解和监督界面原形变化的责任。程序员介入系统详细设计，主要负责系统的实现工作，并对测试组提供相应的测试资源。由于具体设计的具体程度不易把握，有程序员介入的情况下，系统分析人员与程序员的沟通会有助于系统开发进度。在项目代码生产的后期，程序员要进行相应的白盒测试。之后，可执行体提交到测试组进行测试。（系统具体设计讲明）由分析员和程序员共同完成。通过项目负责人转交质量监督组进行复审，复审通过后，由文作。上面提到程序员在交给测试人员之前是进行过一定的白盒测试

6、的。测试人员根据具体设计的文档对软件要实现的功能进行逐一测试，保证软件的执行体正确的实现设计要求，在此也只证实了软件正确的反映了设计思想，但能否真正反映了用户的需求仍需要进一步的测试。在正确性测试完成之后，需要测试的是软件的性能，软件的性能在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。测试在不同的阶段需要不同的输入与输出。在正确性测试阶段，不需要太具体的测试计划和测试策略的设计。而在性能测试时，需要分析人员提出测试策略和测试用例，质量监督组同样会提出他们以为必要的测试策略和测试用例，后者提出的测试策略和测试用例被以为是对前者的抽样

7、调查。无论是前者还是后者提出的测试策略和测试用例，都由测试组组织施行。件透明开发的主要环节。在项目开发的经过中几乎所有的部门都与质量监督组有关。质量监督组对项目经理提供项目进度与项目真正开发时的差异报告，提出差异原因和改良方法。在项目进度被延滞或质量监督组以为某阶段开发质量有问题时，提请项目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量监督是建立在文档的复审基础之上，因此文档版本的控制，十分是软件配置管理，直接影响软件质量监督的影响力和力度。文档组则是保证软件质量监督的得以施行的重要保证。分析人员能否正确的反映了用户的需求；软件执行体能否正确的实现了分析人员的设

8、计思想；测试人员能否进行了较为彻底的和全面的测试；文档组能否对文档的规范化进行的比拟彻底，版本控制能否有效；发完毕的同时，内部文档和外部文档都同时完成。内部文档的及时产生和规范，是保证项目开发各小组能够更好的接口和沟通的重要前提，从另一个方面讲，也是保证工程不被某个关键途径所阻塞而延滞的前提。如上所述，文档组还是保证质量监督组得以发挥作用的基础。发送需要存档和进行版本控制的文档；对文档进行单向出入的控制；对所有存档的文档进行版本控制；书写文档规范，并传到达开发组中；书写部分外部文档。用户提供最及时的技术服务，也为项目开发人员抽身进行新版本软件开发保证。技术支持部的人员能够作到对软件的使用人员进

9、行软件的安装、配置、正确使用进行培训。能够解决由于软件的不当使用产生的各种问题。技术支持部的人员也有对软件系统分析监督的作用。技术支持人员是软件开发经过中的虚拟用户，也就是讲在软件未正式提交用户之前，技术支持人员充当用户的角色。伙伴提供的保证Windows平台和VisualStudio为主要开发工具。我公司是微软Microsoft在中国最大的技术方案提供商，在软件开发方面能够直接从微软公司获得最快最全面的技术支持。另一方面，公司能最快速的获得微软最新的企业解决方案的培训和咨询。同时我公司还是微软出版社中国唯一总代理，公司拥有微软最全面的书面资讯。项目进度的保证开场之前，项目开发计划是必须的。假

10、如项目开发计划的制定的是完全合理的，那项目进度也就真正表达了项目与最终的交付使用之间的距离，然而要制定完全合理的项目开发计划几乎不太可能。可见要保证项目进度，首先要保证项目开发似业务的项目的经历有直接关系，通过经历往往能够预见潜在的阻碍，进而制定较为合理的项目开发计划。本公司已经开发过铁道部的结算系统，开发中的子项目多达六个，历时十五个月，目前多数项目已经开发完毕，有些系统已经投入运营五个月，项目金额数千万元。在这样的项目中，从管理者到开发人员到测试人员都积累了较为丰富的经历，十分是项目开发计划的制定，和项目进度的控制。完成情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，这种方式非常

11、有利于整个项目计划的动态调整。也利于项目质量的监督。是对项目在开发经过中完成的较大成果的定义，比方需求分析完毕、代码生产完毕、正确性测试完毕，都被定义为一个里程碑，每一个里程碑都需要对完成的界定方式进行定义。比方需求分析完毕为一里程碑，这一里程碑完成的定义是：（系统需求讲明）必须经过客户确实认，并在文档组进行了相应的归档工作。当然把完成需求分析作为里程碑不一定恰当，由于系统开发往往伴随着需求的不断变化和新需求的不断产生。如此又引出新的问题，即怎样定义恰当的里程碑，怎样界定里程碑的完成。里程碑将项目分成若干个较小的段，通过保证每一个段的顺利完成，来保证整个项目顺利完成，同时通过每个段的完成质量，

12、能够测度整个项目质量。同时里程碑保证各个阶段的产品的依靠关系尽可能的小，并以完备的文档作为里程碑完成的重要标志之一。在里程碑和完备文档的控制之下，项目已完成的阶段是遭到保护的，在任何时间，人员变动，甚至是开发商的变动，都不至于造成十分重大的损失，通过完备的文档，原有的成果能够被延续进行开发。成也有较大的影响。也有利于将问题空间向解空间映射进而得到愈加理想和完好的系统模型。同时面向对象的开发方法和实现方法也有利于系统错误被局限在较小的范围内，不会出现骨牌效应。面向对象的开发方法也有不利的方面。开发人员对它的熟悉程度不如传统的构造化的开发方法。对面向对象中新出现的名词需要重新在开发队伍中进行定义，

13、以便在开发的经过中相互沟通时表达的愈加准确，进而减少开发队伍之间的通讯量。通讯量的降低意味着效率的提高，减少了占用开发时间讨论一个相互立场根本一致的问题的时间。软件构架定义了该领域中特定对象必然发生关系的发生方式，这种发生方式以构架中抽象类之间定义的关系被固化在构件中，开发人员在开发应用系统时不必再为定义这种互相作用方式而书写代码，这为将来系统的维护奠定了坚实的基础，也为将来新版本软件的透明升级并保持兼容性和正确性提供了有利保证。通过面向对象的继承特性，能够在不伤害原有系统的情况下，任意替换功能模块，进而以效率更高的模块代替原有模块，从另一角度讲，也实现了软件模块的配置功能。要实现真正的软件模

14、块的即插即用，还需要利用面向对象的另一优势-组件。以与语言无关的二进制方式被存储和调用。这就是COM技术。显然软件构架实现的基础是COM组件。由于COM是二进制的方式被存储，因此它能够被任何语言编写的软件所调用。组件与系统分离，只是在发生系统调用时才被调入内存执行，这就保证了系统更高层次的即插即用。的技术进行该项目的开发是值得的。采用如下方法进行克制：第一，在系统开发之前，首先定义技术术语，然后定义领域术语，这样保证了开发经过中开发人员用同种语言进行沟通，避免了文不对题的讨论或争论。第二，指定技术规范。在殊途同归的情况下，我们只允许那些在技术规范之内的技术来实现。技术规范定义了若干种对象技术，

15、这些技术规范在整个开发小组中进行统一认识方面的学习。技术和问题领域而作出的策略性的考虑。显然开发策略与所用的开发方法、实现技术以及问题领域的特征密切相关。一般来讲，鉴于面向对象的无缝特性，采用原形法比拟恰当，而开发经过则采用螺旋式开发方法。螺旋式开发方法提高了人员的利用率，使得软件开发的局部阶段互相重叠，在整体上构成多道流水线重叠并行。显然这又缩短了开发的总周期。需求分析系统分析的经历来看，这个经过往往是个循序渐进的经过，一次性对系统构成完好的认识是困难的。只要不断地和客户领域专家进行沟通确认，方能逐步明了用户的需求。从系统开发的经过得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越

16、是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。同时，想在某个时间点上公布需求分析已经完毕，不再需要进行进一步的需求分析，这也是不现实的。经历告诉我们，往往在测试经过中会发现，用户真正想要的并非您脑海中的设想，另一方面用户往往知道本人肯定不需要什么，而无法明确告知他们需要的是什么。面对这些事实，我们无法期望改变用户；比方提高用户同分析人员的沟通能力，让他们讲出的话更能被分析人员理解。唯一的做法是采用一定的方式方法，诱导用户尽可能早地将需求表达出来，表达得完好。面：一是请领域专家介入到系统开发的早期阶段；二是开发系统原形，原形包括功能性的原形和用户界面

17、性的原形，可以以是二者混合的原形，用这些原形确认用户的需求。让领域专家介入开发的早期阶段，是保证分析人员有充足的时间和领域专家进行充分的沟通和确认。在这个阶段，原形可能在提交到用户之前，首先被领域专家确认，这样保证了原形被认可的程度和认可经过消耗的时间尽可能的短，进而在提高效率的同时保证了质量。施：系统分析委员会保证系统分析群策群力；质量监督组对分析工作的监督；技分析部分的分析讲明书前，必须通过委员会的共同审议，委员会的成员根据各自的分析经历和本身所分析的部分对别人的分析报告提出质疑。如此审议过后保证了各部分间互相关联的部分被明确定义，避免了由于疏忽造成系统在后期进行整合时出现较严重的系统鸿沟

18、或系统重叠。都要提出监督计划。根据监督计划分配相应的资源来保证某阶段的开发质量。分析阶段的监督计划会在分析任务之前被项目经理，项目负责人、系统分析员以及技术支持所了解。为保证分析工作高质量进行，同时分析工作又不被过分打搅，质量监督组则主要针对（系统分析报告）进行复审，只在以为确实有必要的情况下才召开质量复审会议。质量复审会议的主要介入者是项目经理、项目负责人、分析人员和质量监督组组长。会议的主要议题是提出质量质疑，给出改良建议即可。详细能否存在质量问题，能否需要改良，不在会议中进行讨论。以此保证了会议介入的人数较少，会议的时间尽可能的短。发现，技术支持介入分析调研有利于对分析工作的监督，在获得

19、用户需求的口头表达之后，能帮助技术支持更好地扮演开发阶段用户的角色。技术支持具有相当的计算机技术背景，在接下来的开发经过中就能较好的起到监督的作用，也为将来维护和为用户提供更好的服务奠定基础。构应当具备可扩展性和可配置性，这两方面因素的实现是通过WindowsDNA的应用完成的，正如建议书中所述，在此不再赘述。的生产经过。从设计的构造图中能够看出，生产的类别有类的生产，组件的生产，构件的生产，应用系统的整合，以及各种测试用例的生产。为了能够提高生产的质量，我们将生产的程序人员按职能分成两组，测试用例的生产和测试用例生产，也就是讲假如某个程序员生产了某个组件，则其测试用例不能再由该程序员来生产，

20、但他能够生产其他组件的测试用例。这样穿插生产更容易发现组件的存在的问题。测试人员根据测试用例来测试组件的各项指标提出测试报告。产的不断深化，组件的生产日趋减少，构件的生产的量开场逐步增加，生产构件的经过又是对组件的考验经过。因而描绘组件实现的文档是非常重要的，它将有可能成为阻碍进一步生产的瓶颈。文档组在生产经过中的重要工作是对各类部件的文档进行丰富和规范，同时进行版本的控制。文档的完备与否，在开发的后期，对项目进度有至关重要的影响。文档是分享前期开发成果的唯一手段。根据上一节描绘的应用系统体系构造来看，整个开发环节丝丝相扣，每一步都遭到上一步的制约。泛滥。文档组和质量监督组协同完成软件开发的配

21、置管理。配置管理的目的在于控制软件开发经过中的变化，这种变化可能是外部引起的，如需求的变化。可以能是来自于内部的变化，如早期设计的某个部件不够完备，需要修需求讲明报告的某个点。在本项目中需要控制的内部配置项包括需求报告，设计报告，组件代码，组件接口文档，构件及构件相关文档；外部配置项包括项目计发组以前，文档能够在开发组内部任意地被修改，但一旦文档被提交，则相关的部门就会被调动，来维护文档的质量。因而为了保证工作效率，开发组提交文档之前必须慎重，以免引起不必要的工作量的增加。从另一角度来看，开发部遭到严密的监督，进而保证了开发的各个环节对于开发的全经过保持透明，避免了由于个人的原因造成整个开发的

22、瘫痪或受阻。项目经理通过质监报告能够了项目开发的进度和质量情况，为调整开发计划提供有利的根据。内部流程在配置管理的经过中遭到的监管是非常有限的。配置管理所能起的作用完全是建立在文档之上。当项目进度非常紧张时，开发部可能书写文档的时间会非常少，在此情况之下质量监督组和文档组就肩负将开发部提供的文档进行丰富和完善的工作，进而减少开发部书写文档的时间，当然这是增加质量监督组与开发部的口头沟通为代价的。括：软件的正确性：正确性测试主要是测试软件的功能能否被正确的实现。测试的方式主要是根据功能的要求根据给定的输入，看能否有给定的输出。在非标称输入时，输出能否异常等。一方面测试软件的功能能否实现，同时能否

23、实现的完好。包含了压力测试、攻击性测试等测试，软件所能承受的极限是多少，一般来将软件的极限应当高出用户要求的性能，各种指标也应当为用户所了解。性：软件的使用界面在设计实现的时候应当设法使之与功能的实现相脱离。脱离的原因在于易用性是通过友好的界面实现的。然而让开发人员以使用者的角度来确定软件能否易用是件非常困难的事情，在确定使用界面时往往需要屡次的反复修改，甚至只能在软件的最后交付之前或用户使用一段时间之后才被提出来。鉴于这种特点，软件在开发的不同阶段都作了相应的保证措施，比方在软件需求界定的时候请领域专家介入，在软件设计阶段，让功能的实现尽可能地包含在软件的组件之中，也就是没有界面要求的底层实

24、现。界面的实现仅仅依靠于一个数据接口，界面仅仅负责将用户输入的数据送到指定的数据块中，用于显示的数据也在指定的数据块中提取，只要保证数据块被互斥的访问就能够了。有了这样的设计构造，软件的易用性也就相当容易保证了。当测试中发现易用性的问题时，软件不会伤到筋骨，皮毛的修改总是非常容易的。的由开发向用户方向转移。的结果真正是反映了软件的质量。一般来讲，假如测试测出的错误数是收敛的情况，基本以为测试本身应当是比拟全面的和足够深化的。二是测试结果的反应。测试报告是测试结果的正式书面反应形式。测试报需要经过质量监督组的复审，并进行统计，再构成质量监督报告的一部分，提交到项目经理和项目开发组组长处。同时，测试组产生的测试报告和测试统计报告也要进行归档，以便跟踪软件的质量进展。这也是软件进行版本编号的一个重要根据。档维护主要是文档组的工作。文档从用处上分主要分为内部文档和外部文档。构件索引；构件成分讲明；构件接口及调用讲明；组件索引；组件接口及调用讲