软件开发项目解决方案模板及软件开发项目规范

解决方案XXXX科技有限公司XXXX年XX月目录第1章 关于本方案 4第2章 概述 42.1 项目背景 42.2 建设目标 42.3 建设原则 4第3章 需求描述及分析 43.1 概述 43.1.1 需求分析目标和任务（可选） 43.1.2 需求分析组织方式 43.2 需求描述 53.2.1 业务需求 53.2.2 接口需求 53.2.3 性能需求 53.2.4 安全需求 53.2.5 其它需求 53.3 需求分析 53.3.1 系统涉众分析 53.3.2 功能需求分析 63.3.3 对技术架构的要求 6第4章 总体设计 64.1 总体设计目标 64.2 总体设计原则 64.3 总体逻辑架构设计 64.4 网络系统设计 64.5 硬件系统设计 64.5.1 服务器 74.5.2 网络设备 74.5.3 存储系统 74.6 平台选择 74.7 标准规范设计（可选） 7第5章 详细设计 75.1 技术架构设计 75.1.1 设计思路 75.1.2 设计原则 75.1.3 架构决策 85.1.4 技术架构 85.2 功能设计 85.3 安全设计 85.4 用户界面设计(可选) 85.4.1 界面设计原则 95.4.2 易用性设计 95.4.3 界面原型设计 9第6章 项目实施方案 96.1 项目实施策略与运行管理机制 96.1.1 项目实施策略 96.1.2 项目运行管理机制 96.2 项目实施和管理 96.2.1 项目组织结构 96.2.2 项目管理 96.2.3 项目计划 96.2.4 项目组人员配置 96.2.5 项目测试方案 106.2.6 软件开发过程（可选） 10第7章 技术支持和服务 10第8章 项目预算 10第9章 公司简介 10第10章 附录一XXX平台简介 11第11章 附录二XXX技术，标准及规范简介 11关于本方案[这里描述本方案和招标方技术文件规定的内容的对应性。这样，可以更有针对性的突出我们方案的要点,便于招标方快速理解。]概述项目背景[介绍本项目的背景，一般来自于招标方的技术文件，也可以在互联网上搜索相关背景做介绍，便于方案阅读者了解项目的背景知识，便于理解方案的后面章节。]建设目标[一般来自于客户招标文件，明确系统建设的目标。]建设原则[这里描述系统的建设原则，一般比较统一，以“XX性”等系统属性为中心进行描述。]需求描述及分析概述需求分析目标和任务（可选）[这里描述通过需求分析要达到的目标，从大的方面描述需求分析的任务。]需求分析组织方式[需求分析包含两部分，首先是需求描述，包括业务需求、接口需求、性能需求、安全需求以及其它补充需求。其次是需求分析，包括对系统涉众的分析，列举所有与系统有关的角色，清楚的说明他们是如何看待和使用本系统的。接着以系统用例图的形式描述系统的总体功能需求。最后，描述本系统对技术架构的需求，用于指导后面的架构设计。]需求描述[注：如果方案包含多个应用和子系统，可按应用或子系统分别描述需求。]业务需求[这里用文字和流程图描述业务需求，目录可自行组织。]接口需求[这里描述所有和系统有联系的接口方面的需求。]性能需求[这里描述系统的性能需求。]安全需求[这里描述系统的安全方面的需求。]其它需求[这里可以描述其它无法归类的客户需求。]需求分析系统涉众分析[这里描述和系统相关的用户，包括客户，最终用户细分，他们在系统中的职责，以及他们如何使用系统。简单的说，就是本系统的所有干系人及职责描述，相当于用例分析中的角色。]功能需求分析[这里描述系统的所有功能需求，可以使用用例图，如果功能需求比较多，可以采用用例包。最好在开始时，给出系统用例图。]对技术架构的要求[这里描述对架构设计有指导性的关键需求，会影响到后面的架构设计。]总体设计总体设计目标[这里描述系统的总体设计目标。]总体设计原则[这里描述系统的总体设计原则。]总体逻辑架构设计[这里以逻辑结构图（一般分层组织）的方式，描述我们提供的整个软件生态系统，一般不涉及具体的技术。]网络系统设计[这里用网络拓扑图的形式描述网络方面的设计。]硬件系统设计[这里描述硬件方面的设计，一般包括：数据库服务器、备份服务器、Web服务器、应用服务器、存储设备、防火墙等。]服务器[这里描述硬件服务器的选型，依据内容多少，目录可自行添加。]网络设备[这里描述网络设备的选型，依据内容多少，目录可自行添加。]存储系统[这里描述存储设备的选型，依据内容多少，目录可自行添加。]平台选择[这里列出所有数据库，应用服务器，web服务器，操作系统等软件平台的选型，可以包含介绍和选择理由。]标准规范设计（可选）[在有些大型系统中，需要做开创性的规范方面的设计，用来指导后面系统的开发。一般就是数据方面的规范。这里可以分两个方面进行描述，一个是规范采用的技术，一般是xml；另一个就是规范初步设计。]详细设计技术架构设计设计思路[描述整个技术架构的设计思路，一般是介绍架构设计的历史，引导出本系统实际的符合先进行的架构思路。]设计原则[简要描述设计原则，一般都是都是固定的，可参考指南。]架构决策[列出所有架构决策的要点，并逐点解释其与架构需求的对应。]技术架构平台技术架构（可选）[给出方案所选平台的技术架构，一般是采用厂商平台的技术架构，可以从厂商网站或ppt中拷贝。]总体技术架构图[在平台架构的基础上，给出具体针对本项目的技术架构。]技术架构说明[对上面的技术架构进行说明]功能设计[按子系统或模块进行组织，可以使用树形图表示。]安全设计[视客户具体要求，可独立章节，写方案时应考虑招标方的具体安全需求，并给出具体的建议措施。]用户界面设计(可选)[写方案时应考虑招标方的具体界面需求，并给出演示的界面效果图。]界面设计原则易用性设计界面原型设计项目实施方案项目实施策略与运行管理机制项目实施策略项目运行管理机制项目实施和管理项目组织结构项目管理项目管理计划项目管理模式技术分工项目规范建立项目评审制度用户项目经理职责项目计划项目工作内容项目实施计划项目组人员配置组织结构人员安排人员背景资历项目测试方案制定统一的测试标准明确的测试目标测试流程确定测试阶段分析测试需求确认测试策略制定测试人员安排软件开发过程（可选）[结合项目具体要求，列出我们采用的软件开发过程。]技术支持和服务[描述公司允诺的技术支持和服务]项目预算[分门别类给出项目费用预算，包括采购的平台软件，硬件，本方案的软件报价以及培训费用等。]公司简介[分门别类给出公司的成功经验和能力。]附录一XXX平台简介[详细介绍本技术方案使用的主要平台的技术特点。]附录二XXX技术，标准及规范简介[详细介绍本技术方案使用的主要技术，标准和规范等。]软件项目开发和管理规范本文阐述软件项目开发和管理的流程规范，作为软件项目开发的高级指引，本规范定义了软件开发的各个阶段以及每个阶段的工作活动和工件，但不对活动和工件的细节作过多规定。在项目开发过程中，每个项目根据自身的需要确定这些活动和工件的细节。项目阶段图2-1项目开发的五个阶段启动阶段这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结项目工作的范围、所需资源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。计划阶段这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。执行阶段这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。控制阶段这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题，如：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。结束阶段这个阶段的工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。阶段完成标志在项目开发过程中，当一个阶段完成后才会开展下一个阶段的工作；另外，“某个阶段完成”通常被定义为项目的一个里程碑，里程碑标识了项目的进度，它是项目开发和控制的重要参考，对整个项目有重要的意义。因此，“确证某个阶段是否已经完成”的工作非常有重要。每一个阶段的结束以它特定任务的完成为象征只有当某个阶段中被规定的所有工作任务都完成了，这个阶段才算真正结束，整个项目才可以进入到下一个阶段中去。反过来说，要是阶段中某个任务没有全部完成，按照项目的定义，整个阶段就不能算是完成，因此项目就不能进入到下一个阶段去。衡量阶段结束的工作结果必须是实在的交付品阶段中的任务是否完成是透过任务活动中产生的交付品来体现的，交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如：某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束，都应该有这样的实质性东西的完成作为象征。跨阶段的进程以阶段结尾的合格验证和审核来决定当一个阶段结束时，在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证，并检查这一阶段的工作质量和效率，由此判断是否可以进入到下一个阶段。这些检验象征了一个阶段的结尾终点，表示项目的进程离开了上一个阶段而进入了下一个阶段。启动阶段图3-1启动阶段的任务和工件产品领域研究研究产品所在领域的状况，为项目论证提供依据。研究内容包括：产品领域的现状和前景产品领域的商业模式和业务流程产品的价值和盈利空间产品的特性和复杂度技术可行性研究研究产品的实现技术，总结技术可行性。研究内容包括：类似产品的当前实现技术和技术趋势实现技术的候选方案各个方案的优点、成本和风险开发团队与实现技术的匹配情况项目论证基于商业和技术等方面对项目的可行性进行论证，确定项目是否开展。如果开展项目，则进一步论证项目的总体方案。论证的内容包括：商业可行性技术可行性当前产品与类似产品的比较项目收益和前景项目的成本和风险项目的总体方案确定项目目标和范围项目开始时，所有相关人员必须对项目的目标和范围达成共识，形成共同的项目愿景。并把愿景叙述为《项目开发大纲》向相关人员传达。《项目开发大纲》的内容包括：概述用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责高级功能用一个段落来综述产品，再用一个段落来描述每个重要的功能不实现的功能用一个段落来描述每个对产品有用的但本项目不实现的功能涉众用一个段落来明确每个重要的涉众群体和他们的风险股本项目需求用一个段落来讲述每个重要的项目需求项目风险按风险暴露量对每个重要的项目风险都用一个段落来讨论项目回报用一个段落综述产品的回报，其后再对每个重要的项目回报都用一个段落来讨论结论用一到三个段落将上述所有部分联系起来，明确项目的需求和风险，再用论点和论据来总结为什么这个项目会成功表3-1项目开发大纲计划阶段图4-1计划阶段的任务和工件规模、工作量评估围绕各项计划的制定工作对项目的规模、工作量等进行评估，评估的内容包括：模块数量与复杂度输入、输出和对外接口等数量与复杂度SLOC和功能点非生产性的支持工作量开发工作量（人月）进度与里程碑进度风险定制项目开发计划项目开发计划体现了项目组对整个开发周期的预期，指定了项目开发的总体方针。与其他计划一样，项目开发计划不是固定不变的，在执行过程中要对计划进行监控，可能会根据实际情况修改计划并重新发布。《项目开发计划》的内容包括：概述用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责。（《项目开发计划》的概述部分应该是《项目开发大纲》中概述部分的拷贝。当项目计划改变时，修订《项目开发计划》的概述部分而不是修订《项目开发大纲》。这样，以后在进行项目评价时，通过比较《项目开发大纲》和《项目开发计划》的概述，就能看出项目是如何改变的）高级功能用一到五页的篇幅来概述产品的功能，其中，要包括这些功能的附加信息（开发者需要这样的信息来了解实现需求）。项目成员确定软件工程职能角色，以及分配到这些角色的人员数量。软件过程概述这个项目中所应用的软件过程。（具体内容可在《质量保证计划》中定义）软件工程方法概述这个项目中所应用的软件工程方法和技术。（具体内容可在《质量保证计划》中定义）进度和工作量这一部分要表达出整个项目进度和工作量的估计。其中要包括：对固定不变的里程碑和同步点的解释在评估中的设想情况、评估中的不准确性的可能来源随着项目的进展如何更新评估（具体进度表内容可在《开发进度表》中定义）风险管理计划概述这个项目中风险管理计划。（具体内容可在《风险管理计划》中定义）测量概述这个项目中要收集的测量。软件工具列出要使用的每一项软件工具，以及该工具所支持的任务。项目支持硬件支持明确所需的硬件，包括那些需要移动、获取或升级的硬件。

软件支持明确所需的软件，包括需要获取、安装或升级的软件件。

人力支持由哪个人、部门或团队为开发组的哪项任务提供支持。表4-1项目开发计划定制风险管理计划风险管理任务包括：风险识别、风险分析、确定风险优先级、定制风险化解方案、风险化解和风险监控【如：图4-2】。图4-2风险管理任务《风险管理计划》定义这些任务的执行流程和人员分配。《风险管理计划》的内容包括：概述用文字和图表概述风险管理任务的总体执行流程。风险识别详细说明“风险识别”任务的实施细节和各项工作的负责人。风险分析详细说明“风险分析”任务的实施细节和各项工作的负责人。确定风险优先级详细说明“确定风险优先级”任务的实施细节和各项工作的负责人。定制风险化解方案详细说明“定制风险处理方案”任务的实施细节和各项工作的负责人。风险化解当风险发生时，需要采取相应的措施化解风险。这部分的内容是描述风险化解工作的操作规范和流程。风险监控详细说明风险监控任务的实施细节和各项工作的负责人。表4-2风险管理计划风险管理中通常会用到《TopN风险列表》，风险列表按照风险暴露量排序列出当前项目中主要的N个风险，《TopN风险列表》的内容包括：本周排名本周的排名（如果本周已被完全化解用“”表示）上周排名上周排名（如果是新识别的风险用“”表示）上表周数该风险已上表的周数风险风险的名称或简述类型风险类型（只针对进度相关的风险）：计划编制组织和管理设计和实现客户和需求承包商产品人员过程技术外部环境开发环境发生概率风险发生的百分比概率损失程度风险发生时损失的进度（工作日或工作周）暴露量发生概率X损失程度状态风险的当前状态：未发生、已发生、已化解化解方案简述风险的化解方案，如果有具体的化解方案文档则链接到相应文档化解进度对已发生的风险，简述化解进度（未发生的风险用“”表示）表4-3风险列表定制质量保证计划保证工作质量的一个重要步骤是制定一套合理的质量保证计划并贯彻执行。《质量保证计划》的内容包括：概述说明编写的目的、适用范围以及对相关人员的要求等软件过程详细说明这个项目中所应用的软件过程。软件工程方法详细说明这个项目中所应用的软件工程方法和技术。工作规范对工程方法中的各种工作任务进行规范，明确执行的时机、流程和准则等。这些工作任务包括：常规开发活动（需求分析、架构设计、详细设计、编码和测试、发布和实施等）会议（工作例会、进度会议、审查会议等）评审（方案评审、技术评审、质量评审等）测量（产品规模测量、进度测量、缺陷率测量、测试覆盖率测量等）其他活动（技能培训、资料收集、内部流、客户沟通等）表4-4工作规范定制开发进度计划基于当前对项目的规模和工作量评估，定制初步的开发进度表，作为项目开发计划的组成部分。《开发进度表》的内容包括：项目的开始和结束时间项目各个阶段的开始和结束时间每个阶段的工作任务及其开始和结束时间每个工作任务的子任务的及其开始和结束时间里程碑和同步点角色的定义和任务分配作为跟踪项目进度的重要依据，进度表在项目推进过程中需要不断细化。另外，当实际进度与计划进度出现偏差时，需要修改进度表并重新发布。执行阶段图5-1执行阶段的任务和工件需求分析分析产品的关键需求、对架构设计有影响的需求和风险较高的需求，直到分析的程度能开展足界面原型设计和架构设计工作。《需求规格说明书》的内容包括：商业或业务需求从商业或业务角度宏观上对产品或系统的要求。它主要在宏观的层面归纳总结为满足客户提出的要求或赢得市场竞争所必须实现的功能、性能、质量等要求。做什么做的范围对结果的要求使用者需求从客户对软件产品或系统使用方案的角度出发，描述和总结使用者利用该软件产品或系统能够做的事或能够完成的任务。功能需求根据上述使用者需求列出的使用方案，列出开发者必须为软件产品或系统实现的功能。性能需求运行速度、容量、并发性能对资源的利用率对外界输入的反馈速度和准确性对差错的负荷能力系统需求必须适应的运行环境的要求（包括运行平台、网络及其他硬件要求）与其他系统兼容的要求（包括与操作系统、数据库、浏览器及其他应用软件的兼容要求）与外部其他系统和组件的接口要求质量需求对用户重要的质量标志（可靠性、效率性、灵活性、安全性、互操作性、稳定性、健全性、可用性）对开发者重要的质量标志（可维护性、多用转换性、重复使用性、可测试性）其他需求不属于上述需求范围的，但受到其他环境和商业合同影响的要求。国家或地区的任何特别的标准软件使用界面的特别要求与知识产权有关的要求软件所面对的市场和行业的规范客户的特别要求开发的局限对开发的成功与否起很大影响的因素，是开发能力的局限：人员的局限技术的制约和局限客户的特别要求表5-1需求分析告《需求分析报告》的编制方式可以是多样的，例如把所有“非功能性需求”组织成“外部接口需求”、“质量属性需求”和“需求约束”。【如：图5-2】图5-2需求规格说明书界面原型设计明确了系统的关键需求后，就可以进行界面原型设计工作，获取用户的反馈，尽快确定产品的界面基调。同时要编写一份《界面设计概要》文档，作为后续的界面设计工作的指导。《界面设计概要》的内容包括：设计的理念理念的来源或参考设计的要点与类似产品界面的对比架构设计架构设计从关键需求开始，建立概念性的架构，并逐步细化和验证。最终生成架构设计说明书和架构基线代码。架构设计的方法：可以从几个不同的视角进行架构设计，然后汇总综合得出完整的设计。（架构设计的五个视图【如：图5-3】）图5-3架构设计的五视图《架构设计说明书》的内容包括：概述说明编写的目的、适用范围以及设计原则等。逻辑架构关注功能。其设计着重考虑功能需求。细化功能单元发现通用机制细化领域模型确定子系统接口和交互机制开发架构关注程序包。其设计着重考虑开发期质量属性，如可扩展性、可重用性、可移植性、易理解性和易测试性等。确定要开发或直接利用的程序包之间的依赖关系确定采用的技术、框架等数据架构关注持久化数据的存储方案。其设计着重考虑“数据需求”。持久化数据存储方案数据传递、数据复制、数据同步等策略运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。其设计着重考虑运行期质量属性，例如性能、可伸缩性、持续可用性和安全性等。确定引入哪些进程与线程确定主动对象、被动对象，以及控制关系处理进程线程的创建、销毁、通信机制、资源争用等协议设计物理架构关注软件系统最终如何安装或部署到物理机器。其设计着重考虑“安装和部署需求”。确定物理配置方案确定如何将目标程序映射到物理节点总结基于上述的设计进行总结，并描述架构基线。表5-2架构设计说明书架构设计的另一个重要任务是编写架构基线代码，基线代码表述和验证架构，同时也是指导后续开发的基础代码。架构基线代码的内容包括：所有工程项目工程目录结构软件包结构导入所有依赖包基础公共代码架构框架代码架构框架示例代码和测试代码数据库框架图5-4和图5-5展示了软件架构师的工作和成功的软件架构设计包含的内容：图5-4软件架构师的工作图5-5成功的软件架构设计1软件构建软件可以分阶段进行构建，每个阶段可以使用增量的方式开发，用通过若干个Build构建，最后发布阶段性产品成果。（注意：在这里，名词“阶段”的含义和本文其他地方的含义不一样）阶段计划构建阶段计划的内容包括：确定本阶段要实现的功能列出阶段任务计划Build构建数量细化《开发进度表》中本阶段的工作内容Build构建详见：下一节阶段产品发布构建阶段完成后发布阶段产品成果，向用户展示并接受用户反馈，同时做好阶段总结。《发布清单》的内容包括：产品版本号和日期改正的Bug修改的功能实现的新功能其他说明《阶段总结报告》的内容包括：阶段任务的完成情况进度计划的执行情况用户的反馈情况本阶段碰到的主要问题下一阶段的改进建议2Build构建Build构建以增量的方式执行阶段的开发任务，每个Build构建的周期一般不超过两星期，每一次Build构建都会发布为一个内部版本，并提交测试。测试发现的问题留待以后的Build构建解决。Build计划《Build计划》的内容包括：本次Build的版本号本次Build的历时本次Build的工作任务要解决的遗留Bug本应由以前的Build实现的，但推迟到本次Build实现的功能要实现的新功能其他工作任务工作任务分配需求细化根据《Build计划》，细化本次Build要实现的需求，细化到能进行详细设计为止。有了细化的需求后就编写本次Build的测试计划。《测试计划》的内容包括：功能测试要测试的功能测试时间测试方式验收标准其他测试（性能测试、边界测试、使用界面测试、可用性测试、安全性测试等）要测试的内容测试时间测试方式验收标准。。。。。。界面设计根据细化的需求设计用户界面，当界面确定后即可编写测试用例。《测试用例》的内容包括：测试用例对应的功能模块测试用例的性质（功能测试用例、性能测试用例、。。。。。。）输入（或操作步骤）期望输出实际输出（执行测试后再填写）是否通过（执行测试后再填写）详细设计详细实际每项需求的实现方法，对于重要的设计决策、算法、公共模块和外部接口等必须以模块设计文档的形式进行记录。《模块设计文档》的内容包括：模块名称设计思想设计图表（类图、流程图等）要点描述（包、接口、类、方法、算法、设计模式）测试方式编码、单元测试编码和单元测试是开发人员的工作，对于重要的代码都必须进行单元测试，编写代码必须遵守下列准则：遵守编码规范编码前必须充分理解相关的需求编码前先进行设计，把流程理顺注意设计方法和设计模式的灵活运用总体考虑问题，使代码遵从架构并容易测试设计时要充分考虑异常情况和临界条件严禁Copy-Paste，注意提取公共代码，在编码过程中实现重构异常处理必须记录日志，严禁草率地直接打印异常信息灵活运用ASSERT()/VERIFY()等断言来帮助调试程序单元测试是程序员的工作，所以编码完成后必须对代码严格测试功能代码完成后必须先做以下4件事情：编译代码，保证编译通过（不运行程序）对代码进行全面检查用调试模式启动程序，一行一行单步执行代码，并注意调试输出改变条件，让代码尽可能走遍所有程序分支CheckIn代码前必须保证能编译通过创建Build代码集成发布前需冻结代码，所有人把要提交的代码CheckIn，并保证编译后的程序能在测试服务器上正常启动，界面能正常打开。同时还要提交Build清单。《Build清单》的内容包括：Build版本号和日期改正的Bug修改的功能实现的新功能其他说明集成测试按照《测试计划》针对《Build清单》执行《测试用例》，测试完成后编写测试报告。《测试报告》的内容包括：测试用例汇总（用例数量、通过的用例数量、未通过的用例数量等）Bug汇总（Bug总数、新增Bug数量、关闭Bug数量、Bug趋势图表等）测试计划执行情况测试总结控制阶段图6-1控制阶段的任务和工件风险管理开发期间要对风险进行监控，定期检查、更新和发布《风险列表》。质量管理1）评审评审是质量保证的重要环节，原则上每个重要的工作任务或阶段结束前都必须经过评审，如：方案评审、计划评审、需求评审、设计评审和代码评审等，工作是否被通过、是否需要修改或重做均由评审结果决定，评审结果以《评审报告》的形式发布。《评审报告》的内容包括：基本信息评审主题、时间、提交者、评审者等评审内容评审内容的列表和简述问答记录评审过程中重要的问答记录评审结论整个评审的结果，如：完全通过，无需修改基本通过，需要作小量修改，但不必再评审大体通过，需要作一些修改，之后再评审不通过，需要作大幅修改，之后必须重新评审评审意见针对评审结论提出的意见和建议表7-1评审报告2）测试测试是对被构建产品最直接有效的质量保证措施，测试结束后需要提交《测试报告》。变更管理开发过程中经常会出现多种变更，如：需求变更、设计变更或人员变更等。这些变更通常会对开发进度造成影响，因此要对变更及其处理过程进行跟踪，最后报告变更的处理结果。《变更处理报告》的内容包括：基本信息变更主题、发生时间等详细信息变更的详细描述变更处理变更的处理方式和步骤处理结果变更的处理结果变更影响变更对项目造成的影响表7-2变更处理报告进度监控项目进度会议是了解项目实际进度的有效措施，在会议中评审工作报告，解决遇到的问题并计划下一步工作：《工作报告》的内容包括：基本信息：报告者、汇报时间、工作时间段等工作情况：已完成的工作、未完成的工作遇到的问题：工作中碰到的阻碍工作计划：下一步的工作计划项目进度会议的另一个重要议题是审查进度表，了解项目实际进度与计划进度的差异。为进度表调整和资源调配提供重要依据。测量在项目开发过程中，收集一些关键的测量，对了解项目状态和进行项目决策很有帮助，同时也为以后的项目提供历史数据参考。每个测量都要生成测量报告并存档。《测量报告》的内容包括：基本信息，包括测量主题、测量时间、测量者等测量内容和测量值测量分析结束阶段图7-1控制阶段的任务和工件产品测试因为产品即将验收和发布，所以必须对产品进行完整测试，产品测试比其他测试要求更严格，当产品的质量达到发布的要求后才能发布。产品的质量由《测试报告》体现。RC版本发布发布RC版本让用户体验并收集反馈意见，为产品验收作准备。RC版本发布后，产品不应该有大改动，一般只是界面的局部调整。编制用户文档针对不同的使用者角色，编制相应的用户文档，对管理者用户需要提供《安装、维护指南》，对普通用户需要编制《产品使用手册》。《安装、维护指南》的内容包括：产品各组件的说明产品部署架构安装、配置和卸载等步骤启动、停止和重启等操作其它操作：日志、备份、还原等《产品使用手册》的内容包括：产品介绍各个功能的介绍通过实际案例介绍各个功能的使用方式和操作步骤产品使用培训对于为特定客户开发的软件产品，在发布前需要对用户进行产品的使用培训。培训前需要部署好操作环境，编写培训资料，然后组织培训会议。产品验收对于为特定客户开发的软件产品，通常根据签订的开发合同和产品方案等条款逐项验收，验收时，用户通常会执行验收测试案例。最后修订在产品验收通过后，正式发布前对产品作最后的修订，可能包括：开发文档修订用户文档修订代码整理正式版发布正式版的发布标志着开发阶段的结束，产品从此时起进入维护阶段，正式发布前可能要做一些准备工作，如：数据迁移和环境配置等。项目总结项目结束后需要对整个项目开发阶段的工作进行总结，交流心得，吸取经验和教训，并归档为《项目总结报告》。《项目总结报告》的内容包括：总体评价成本、收益汇总重要心得管理总结技术总结总结图8-1项目阶段软件项目开发经历多个阶段，每个阶段包含多个任务，每个任务会产生相应的工件。需要相应的质量保证措施对任务进行监控，保证任务的执行。任务完成后也需要对任务进行评审，保证任务的质量。这些工作均由开发团队和相关人员按照工作流程执行。因此，合理的角色任务分配和沟通制度是软件项目成功的重要保障。图8-2列出几种比较普遍的角色和任务划分方案：图8-2角色和任务划分方案职责和角色不清楚往往是造成软件项目团队管理混乱的一个重要原因，一个好的软件团队必须根据团队规模的不同和项目本身的特点对项目成员的角色和岗位进行明确的划分，这样团队中的每个成员才可能有清晰的责任和目标。软件开发不管采用哪种生命周期模型和开发方法论，整个过程都会包含需求，设计，开发，测试，配置管理等各项活动。而这些活动会对应到项目中的不同角色，项目中进行岗位划分后每个岗位成员可以兼职多个角色。形成相关的角色岗位矩阵。方案一项目负责人总览全局对于小作坊的软件开发团队，可以由一个项目负责人总览全局。项目负责人承担从用户需求->软件需求->总体设计的所有工作。同时还需要做到整个团队进度规划，质量保证，配置管理和沟通协调等