项目范例思拓sipp软件过程

绪 第一章概 SIPP模 第二章产品规 介 产品估 实施建 第三章产品介 产品计划控制偏 实施建 第四章风险管 介 实施建 第五章需求管 介 需求确 需求 实施建 第六章需求开 介 用户需求 实施建 第七章技术预 介 实施建 第八章系统设 介 模块设 实施建 第九章实现与测 介 准 实施建 第十章系统测 介 实施建 第十一 介 BETA测试规 实施建 第十二章产品验 介 实施建 第十三章技术评 介 实施建 第十四章配置管 介 版本控 实施建 第十五章质量保 介 实施建 第十六章培训管 介 实施建 第十七章服务与介 客户服 产品实施建 术语与缩写的解释术解 文档说明第一章概述（Siplified它由众多的过程规范和文档模板组成。SIPP主要用于指导公司持续的改进其软件过程能力。此处，“精简迭代并行”的含义在产品生命周期中，产品研发过程反复“迭代”，不断近用户需求在产品生命周期之内，产品管理过程、产品研发过程和机构支撑过程“并行SIPP 产品开发阶段，记为PH2 产品阶段，记为PH5SIPP模型中，软件产品的过程有三大类：产品管理过程、产品研发过程和机构支撑过程。上述三类过程可以细分为15个主要过程域，分布在PH1~PH5的各个阶段。6）Beta测试7）产品发布1-SIPP过程域的目的表1- SIPP过程域的目产品管理过程域目为产品的研发和管理工作制定全理的行动（即产品计划以便所有相注：三个月以上的产品有此风险管理过程产品研发过程域目注：视产品 机构支撑过程域目表1- SIPP规范细产品管理过程域主要规程文产品研发过程域主要规程文机构支撑过程域规程与关键活动文 角色与职责表表1- 角色与职责简常设角色职责简述产品管理过程角监督产品经理的工作，产品经理的各种申向公司汇报工监督产品开发成员的工作，产品开发成员的各种请产品研发过程角(2)机构支撑过程角创建并配置库，如分配权限、清除文件、备份完善性：在资源允许的情况下，不断改善产品功能临时角色第二章产品规划。产品规划过程域是 模型的重要组成部分阐述了产品规划过程域的 个主要规程。产品介在产品规划过程域阶段，公司首先任命一位产品经理，之后公司协助产品经理筹备““按计划执行研发按计划执行研发图2- 产品规划流程产品估计软件硬件资源、技术水制定产品计划产品计划产品计划变更控目角色与职责启动准输主要步 估计产品范围WBS2-2WBS仅用产品估计而非用于2-2用于产品估计的产品WBS示意 估计产品规模代码类（对象）文档页开发小组各成员根据产品的WBS于10%，则取平均值。如果差额大于10%，则转向上一步，开发小组各成员重新10%为止。2-1产品的组件新开发组件的规（代码行、类、文档页数复用或自动生成的组件的规模（代码行、类、文档页数…总 估计工作量1人年=121人月≈221人天=7.5人小时（根据我公司情况开发小组各成员根据［Step2］产生的产品规模估计表，独立地估计工作量，０％，则取平均值。如果差额大于10%，则转向上一步，开发小组各成员重新估计工作量，直到个人估计的差额小于10%为止。2-2估计产品研发的工作量估新开发组件的规难度系数人均生产率产品研发工作量编程工作量测试工作量估计产品管理的工作量估比例系数产品管理工作量估计机构支撑的工作量估比例系数机构支撑工作量配置管理工作量≈质量保证工作量≈培训管理工作量[Step4] 输结束准度制定产品计划目角色与职责启动准输主要步 确定目标与范围 确定过程模型构支撑过程等。例如裁减SIPP模型。行面向对象分析与设计，采用ConcurrentVersionsSystem进行配置管理，采用Office制作文档等。[Step3]多个角色2-3所示。2-3角职人工作说明 制定软硬件资源计划划，如表2-4所示。主要内容包括：资源级别（普通”两种详细配获取方式（如“已经存在“可以借用、或“需要”等）与获取时用途（如“谁”在“什么”时候使用2-４软硬件资源计划软硬件资源名称级详细配置获取方式与时间用 制定财务计划2-5开支类别主要开发项、用金时 分配任务并制定进度表 制定下属计划表2- 主要的下属计下属计划的名称建预计产生时间 …输结束准度产品计划目角色与职责启动准输主要步 申请 与修 批准生效输结束准度产品计划变更控制目角色与职责启动准输主要步 变更申请变更原变更的提示：如果是合同产品，可能还要向客户提出变更申请，视具体情况而定 变更申如果同意变更，转向 修改产品计划 新的产品计公 新的《产品计划》，参见规程2-４输结束准度配置管理，使用Excel或project工具进行计划管理。第三章产品产品的目的是通过周期性的产品计划的各种参数如进度、工作量、费用、资源、工作成果等，不断的了解产品的进展情况，以产品实际进展状况显著偏离计划时能够及时采取产品计划控制 产品过程域包含３个主要规程，流程如图3-1所示。产品计划偏差控制产品进展汇报《产品数据表图3- 产品流目角色与职责启动准输主要步[Step1]的数据保存在《产品数据表》之中。任务表的参考格式如表3-1所示。表3- 任务任务名称实际起止时间日期、当前进度实际工作量实际工作成果[Step2]存在《产品数据表》之中。工作成果表的参考格式如表3-4所示。表3- 工作成果及其规模工作成果名称新开发的成果规（代码行、类、文档页数复用或自动生成的成果规模（代码行、类、文档页数总输结束准3.PAGE3.PAGE2.8度量目角色与职责启动准输主要步[Step1]“产品计划”，找出显著偏差项（20。[Step2][Step3]2-5产[Step4]纠正偏差的过输结束准产品进展汇报目角色与职责启动准输主要步[Step1][Step2]输结束准度第四章风险管理介为了便于量化管理，我们给风险定义了3个参数： 表4- 风险严重性等参等值描风险严重性54321表4- 风险可能性等参等值描风险可能性54321表4- 风险系数等风险系数风险可能性风险严重性963864254321风险：风险减缓过程，记录风险的状态图4- 风险管理示意风险管理规程目角色与职责启动准输主要步[Step1][Step2][Step3][Step4]输结束准度第五章需求管理 需求确 需求 介需求开发，另一类属于需求管理。图5-1为需求工程的结构图。图5- 需求工程结构需求确认需求需求变更控制 《需求报告 目角色与职责启动准输主要步[Step1][Step2]产品经理邀请专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力[Step3]本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，按照“需求变更控制规程”执行。我明白需求的变更导致双方重新协商成本、资源和进度等。乙方签字输结束准度需目角色与职责启动准输 需求文 主要步[Step1]建立与需求矩表5- 简单的需求矩阵格序需求文档（版本、日期设计文档（版本、日期代（版本、日期测试用例（版本、日期１明２[Step2]使用需求矩阵的优点是很容易发现需求文档与后续工作成果之间的不一致之处，例如：令后续工作成果没有实现需求文档中的某些需求。令后续工作成果实现了需求文档中不存在的需求。令[Step3]输结束准度需求变更控制目提示：本规程中的“原需求文档”是指已经通过了评审并获得承诺的需求文档角色与职责启动准输主要步[Step1]变更原[Step2]需求变更申[Step3][Step4]重新进行需求确认重新进行需求评审，参见需求确认规程中的[Step2]重新获取的需求承诺，参见需求确认规程中的[Step3]输结束准度第六章需求开发 需求与分 介求管理的流程如图6-1所示。需求变更图6- 需求开发与需求管理流程需求需求分析需求定义用户需求目角色与职责启动准输主要步[Step1]向用户群体发问卷与、专家交谈，听取他们的意见从Internet

[Step3] 细化并分析用户需求提示：建模分析的技术难度比较高，需求分析员应当根据自身的水平进行取舍。提示：过程中获取的需求信息可以作为《用例规约》的附件。[Step5]输结束准度用户界面原型设计目角色与职责启动准输主要步设计图6- 用户界面设计流[Step1] 用户界面设计 原型创 [后续活动输结束准度第七章技术预研介一般说来，在设计或实现阶段遇到了，才去攻克问题，其代价通常比较高。因为其他人防止开发进程被技术打断，导致大量的相关工作被阻塞 技术预研规程目角色与职责启动准输主要步[Step1][Step2]开展技术预研[Step3][后续活动输结束准度第八章系统设计 介设计。如图8-1所示。图8- 系统设计过程域示意 体系结构设计目角色与职责启动准输主要步8-2设确确系撰设准因策设文评[Step1]

体系结构设计人员准备相关的设计工具（RationalRose）和资料。软件、硬件环境（包括运行环境和开发环境）的约束接口/隐含约束。有一些假设或依赖并没有在需求文档中明确，但可能会对系统设计[Step3][Step4]系统分解与设计[Step5]设计系统总体结[Step6]合适性该体系结构是否适合于产品需求是否可在预定计划内容内实现系统的综合能力。例如“时-空”效率（性能，容量等，可扩展性，可管理[后续活动输结束准度用户界面设计目角色与职责启动准输主要步2.22.2设计设计2.32.1[Step3]软件主界面（如主窗体、主页面）软件子界面（如子窗体、子页面）[Step4] 界面创 评 细说明：设计界面视图、未通过产品经理确认，便直接在实现界面上修改视图[Step5][Step6]合适简洁易一致美命名规动态反功能和出错处用户控（兼容性和可移植性适应性（针对各种用户[后续活动输结束准度目设计软件的数据库,产生《数据库设计报告》，并不断完善“用户界面原型”角色与职责启动准输主要步档设计设计[Step1逻辑设计规则（或指南物理设计规则（或指南安全性设计规则（或指南优化规则（或指南数据库管理与规则（或指南[Step2] 逻辑设（ERD。如果采用面向对象方法(OOAD)，这里的实体相当于类（CLASS

对用户帐号的进行加理，确保在任何时候都不会出现的明文

分析“时－空”效率的瓶颈，找出优化对象（目标，并确定优先级。当优化对象（目标）]数据库名规逻辑设物理设安全性优数据库管理与说[Step4]安全“时[后续活动注：在进行数据库设计，针对具体情况，并不断完善“用户界面原型”输结束准度目角色与职责启动准输主要步Step2Step2.审设计设计2.2[Step1[Step2技巧：由于现代的软件开发工具越来越先进，模块的详细设计和编程可以很好地融合一起而且效率相当高，有些工具甚至具有代码自动生成功能。所以在系统设计阶段，模块设计究竟要详细到什么地步，应当视问题复杂性以及所采用的开发工具而定，一般地，只要确定了每个模块的主要接口、数据结构与算法，能够清楚地指导模块编程即可。总之，不必花太多 接口与（OOAD 数据结构与算[Step3]信息隐藏（独立性[后续活动输结束准度第九章 准 实现与测介实现与测试的流程如图9-1所示。一般地，编程、代码、单元测试、集成测试大致存在工具（VSTS、TD）来管理，开发人员应当及时消除缺陷（改错。系系统图9- 实现与测试流程 准目角色与职责启动准输主要步[Step1编程代码计单元测计集成测计缺陷管与改产品经理实现与测试计划果批准则转向[Step3]；如果不批准则退回[Step1][Step3][Step4[Step5]输结束准度目角色与职责启动准输主要步[Step1]开发人员在编写完成每个模块时，必须对自己的代码进行必要和测试[Step2代码[Step3[Step4[Step5]输结束准度第十章系统测试介缺陷（即改错。系统测试流程如图10-1所示。定计行陷测测系管试试统理计用测与改错图10- 系统测试流程令《系统测试计划》令《系统测试用例》令《系统测试报告》令系统测试规程目角色与职责启动准输主要步[Step1]测试范围（内容测试方[Step2]设计系统测试用例[Step3][Step4]输结束准功能性测试用例通过率达到100%非功能性测试用例通过率达到80%度第十一 Beta测介纠纷。解决这个问题的好方法是Beta测试。发方和Beta用户达成互利的协议。流程如图11-1所示。图11- Beta测试流 《Beta测试协议 《Beta测试报告Beta目角色与职责启动准输主要步[Step1联系Beta[Step2签约与[Step3将此信息记录在《Beta测试报告》中。[Step4对于Beta输Beta结束准度第十二 产品验注：产品验收应根据客户的要求而定介图12-1 客户验收流程说明：“产品验收”是针对合同产品而言的，对于非合同产品，请参照“Beta产品验收规程目角色与职责启动准输主要步[Step1开发方和客户方共同制定《产品验收计划》（，。开发方和客户方共同设计“验收测试用例”。[Step2]成果与验收测成果。验收人员根据计划开发方应当交付的成果，如代码、文档等。确保这些成果是完整的。并且是正确的。验收人员将结果记录在《产品》[Step3[Step4输结束准度复杂的问题应当立即有关，不可拖延。在验收期间不可与客户争吵，给客户留对验收过程中产生的所有有价值的文档进行配置管理(这里可能需要开发方的配第十三 技术评 介 （FTRITR图13-1 技术评审过程域示意图制定技术评审计划目角色与职责启动准输主要步[Step1]确定需要评审的工作成果[Step2]低”3个等级。重要性-复杂性组合与技术评审方式的对应关系如表13-1所示。13-1重要性-重要性-复杂性组合技术评审方式式 预定评审时间、地点以及相关人员[Step4]计输结束准度正式技术评审目角色与职责评审应当具备比较高的技术水平和比较丰富的评审经验，能够控制评审会议的进程。评审可以是产品内的技术骨干，也可以是产品外的技术专家。评审审来确定。评审员应当根据“检查表”认真地查找工作成果中的缺陷，并和评审小组的总人数一般在3~7人之间启动准输主要步2.12.12.1图13- 正式技术评审的流程[Step1评审首先确定评审会议的时间、地点、设备和参加会议的人员（包括评[Step2] 宣 [Step3]修正与审 修正与评审（或者指定员）每个缺陷的状态 修正后的工作成果仍然不合格，需重新修改，重复输结束准度非正式技术评审目角色与职责评审员：由作者的同伴或者专家担任评审员，通常一两个人即可。评审员应当根据启动准输主要步 介 识别缺 讨论缺陷解决方案 给出评 修正与评审（或者指定员）每个缺陷的状态[Step3.2][Step3.3]修正后的工作成果仍然不合格，需重新修改，重复输结束准度第十四 配置管 配置库管 介CItone，鉴于配置管理的重要性和复杂性，机构还应当设立配置管理（ConfigurationControlBoard,CCB求等。对于配置管理而言，CCB是决策者，而配置管理员是执行者。品可以设立各自的CCB。CCB的决策采取“少数服从多数”的原则。图14- 配置管理流程制定配置管理计划、交付计划、备份计划等。CCB该计划。配置库管理版本控制变更控制配置审计 制定配置管理计划目角色与职责CCB《配置管理计划》。CCB的人数视产品的规模而定。通常CCB由产品经理、资深产品开发成员等人组成，产品经理为CCB。CCB的决策采用“少数服从多启动准输主要步[Step1]确定配置管理的软硬件资源]表14- 配置项计划参考格类主要配置项标识符预计正式[Step3线计划的参考格式如表14-2所示。表14- 配置项计划参考格基线名称（或标识符基线所包含的主要配置项预计建立时间[Step4CCB意见修改《配置管理计划》，直到该计划被批准为止。输结束准度目角色与职责启动准输主要步[Step1] [Step2][Step3]“索取人”向CCBCCB该申请。如果该申请不合理，则交付配置项。如果同意交付，CCB配置管理员依据CCB“索取输结束准度目角色与职责配置项状态变迁规则图14- 配置项状态变迁配置项版本号规则 YZ数字范围为01-99 随着草稿的不断完善，“YZ”的取值应递增“YZ”的初值和增幅由用户自己把握 本升级幅度比较大时，才允许增大X值。 见规则（2。配置项版本控制流程[Step1]0.YZ。 修改处于“草稿”状态的配置项更控制规程约束0.YZ。[Step3]划”这类文件，则需要产品经理（或上级）的。若配置项通过了技术评审或，则转向[Step4],否则转向[Step2][Step4]号为X.Y。[Step5]：项，版本号格式为X.YZ。修改完成后，该配置项要重新接受技术评审或，转向[Step3]配置项变更控制目角色与职责启动准输主要步[Step1][Step2]变更申说明：一个配置项的变更可能导致其他配置项也发生变更，CB在变更申请时一定要考虑这[Step3说明：变更执行人可能是变更申请人，也可能不[Step4 对更改后的配置项重新进行技术评审（或划”这类文件，则需要产品经理（或上级）的。若配置项通过了技术评审或，则转向[Step6],否则转向[Step4]（即重新修改[Step6]变迁为“正式发布”。CCB在《配置项变更控制报告》中签字，结束变更。输结束准度第十五 质量保 问题与质量改介测试。通过运试用例来找出软件中的缺陷，例如单元测试、集成测试、系统测试、客观地检查和产品的质量。这是质量保证方法富有成效的一面。但是“工作过程以及工作成评审和测试能弥补质量保证的不足，三者是相辅相成的方法。我们在实践中不能将质量保证、技术评审和测试混为一谈，也不能把三者孤立起来执行。让质量保证人员参加并监督重要的技术评审和测试工作，这是很好的方法。把三者有机地结合起来，可以提高工作效率，降低成本。质量保证小组（QAG）有如下特色：令质量保证小组在行政上独立于任何产品。这种独立性有助于质量保证小组客观地检查和令质量保证小组有一定的权利，可以对质量不合格的工作成果做出处理。这种权利使得质15-1所示。制定质量保证计 过程与产品质量检查问题与质量改图15-1 质量保证过程域示意图 制定质量保证计划目角色与职责启动准输主要步[Step1]制定过程与产品质量检查计划时间和人员。注意，对某些过程域的检查应当是周期性的而不是的，例如配置管[Step2]制定“参与技术评审”的计划[Step3]制定“参与测试”的计划[Step4]质量保证计输结束准度过程与产品质量检查目角