软件过程与管理(第2-4章PSP)(共9页).doc

精选优质文档-倾情为你奉上第24章 个体软件过程（PSP）l 个体软件过程（Personal Software Process，简称PSP）：包括了数据记录表格、过程操作指南和规程在内的结构化框架，个人级用于控制、管理和改进软件工程师个人工作方式的持续改进过程；最早由卡内基梅隆大学软件工程研究所（CMU/SEI）的Humphrey领导开发；与后续的TSP很好的弥补了CMM的缺陷，形成了个体软件工程师、小组再到组织的完整的过程改进体系。l PSP基本原则n 软件系统的整体质量由该系统中质量最差的某些组件所决定；n 软件组件的质量取决于开发这些组件的软件工程师，更加确切的说，是由这些工程师所使用的开发过程所决定；n 作为合格的软件工程师，应当自己度量、跟踪自己的工作，应当自己管理软件组件的质量；n 作为合格的软件工程师，应当从自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的开发实践中，也就是说，应当建立持续地自我改进机制。l PSP成熟度级别l PSP过程度量：仅仅考虑最基本的三个度量项，即时间、缺陷和规模，并由这三个基本度量项衍生出数个统计指标，如PQI、A/FR等。度量时间和度量缺陷见下面给的考题的第1题，缺陷再看一张表书P53表2-2，英文不想改了，需要的看下书对应上就好。n 度量规模：PSP对于规模度量没有明确的定义，可以定义并且使用任何合适的规模度量方式；但PSP对于规模度量方式的选择提供了参考的标准，即u 选择的规模度量方式必须反映开发成本；u 选择的度量方式必须精确；u 选择的度量方式必须能用自动化方法来统计；u 选择的度量方式必须有助于早期规划；n 规模度量这块注意一个问题：代码行（LOC）分为逻辑行和物理行和功能点（FP）的对比；精确的度量方式往往不便于早期规划；有助于早期规划的度量往往难以产生精确度量结果；LOC可以很精确的度量软件产品规模，也方便开发相应的规模统计工具，但是，在项目初始阶段，往往很难估算程序的代码行；FP在项目早期容易识别，但是，一来功能点的度量往往比较粗略，而且几乎不存在可以对功能点进行自动化统计的方法。n 早期规划问题：PSP使用一种称为代理（Proxy）的方式来解决，寻找一种便于早期规划的规模度量的代理，建立这种代理与精确度量之间的关系，即PROBE（PROxy Based Esitimation）方法的由来。l PROBE方法n 估算原理：相对大小矩阵，从统计不同用途的房子（不同用途的代码段）数目和其相对大小（规模，一般为代码行）入手，例子就是建房子的例子，想不起来的话看书P55的表2-5n 通用计划框架（如果不能理解这个图再看字书P56，感觉图示记忆容易）n 估算流程u 这里给出了一堆的公式，个人认为主要理解这个流程，记住2个最基本的公式就可以了，那么复杂不会手算的。理解下面两个式子里E都是为代理规模（和最终的计划规模一般是不相等的）。 n 应用u 整理历史数据：相关大小矩阵作用很重要，三种计算方法简单方法、正态分布、对数正态分布l 简单方法：统计每个方法代码行数，最小的作为VS，最大的为VL，中值为M；S为VS何M的均值，L为VL和M的均值l 正态分布：选择所有数据均值为M，计算标准差；则S = M-，VS = M-2，L = M+，VL = M+2l 对数正态分布：和正态对比，小规模的明显比大规模多，且正态可能算出负值，不符实际；所以，以e为底计算所有数据的自然对数；计算取对数之后的值的均值作为M，计算相应标准差 ；则S = M-，VS = M-2，L = M+，VL = M+2；再取反对数l 对比：简单方法计算简单，但是，不稳定；正态分布法相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵；对数正态分布法更加符合人们对于程序的规模的直观感觉u 有限历史数据：两个统计学概念，相关性和显著性。前者描述两组变化数据之间相关程度，后者描述两组数据的相关关系出现的偶然性。公式不用看，记住前面那个写法是rx，y，后面那个通常记为s，具体的估算规模的方法分类和指标要求看下面给出的试题的第4题或书P62和P63的两张表u 处理极端数据：极端数据会造成相关性的假象，此时就需要看显著性这个指标，剔除极端数据重新选择PROBE方法。l 质量与质量策略n PSP的质量观：PSP中采用了面向用户的视图，定义质量为满足用户需求的程度。n PSP质量策略：用缺陷管理来替代质量管理；高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷。n 不同缺陷消除方式消除缺陷的平均时间：具体的时间不用记，记住缺陷消除的平均代价随着开发过程的进展会显著增加。l 评审和测试：个人评审（Review）和团队评审（Inspection）在发现缺陷的效率上往往高于系统测试。n 测试消除缺陷的典型流程：u 发现待测程序的一个异常行为；u 理解程序的工作方式；u 调试程序，找出出错的位置，确定出错原因；u 确定修改方案，修改缺陷；u 回归测试，以确认修改有效n 评审消除缺陷的典型流程：u 遵循评审者的逻辑来理解程序流程；u 发现缺陷的同时，也知道了缺陷的位置和原因；u 修正缺陷；l 评审过程质量：接上面的质量策略，各个组件的高质量是通过高质量评审来实现的n 评审检查表：一份个性化的用于有效指导软件工程师开展评审活动的表格；两个步骤，建立和维护；使用n 质量指标（这里很值得注意，名词解释和计算都有可能涉及这部分）：Yield、A/FR和PQI见下面给出的往年考试题的第2题u Review Rate：评审速度，恰当不是太快不是太慢；在实践中，代码规模一般以LOC为单位，文档一般以页（Page）为单位，时间单位为小时，给出统计数据表明的速度，代码评审速度小于200LOC/小时，文档评审速度小于4Page/小时。u Defect-removal Leverage：缺陷消除效率比，DRL，度量不同缺陷消除手段消除缺陷的效率；其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础（通常选择单元测试作为基础），其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRL。n 评审其他考虑因素：u 打印后评审：单个屏幕可以展现的内容比较有限；评审人员的注意力u 评审时机选择：编译（UT）之前 VS. 之后u 个人评审和小组评审：小组评审意义；先后顺序u 组织形式u 缺陷预测&预防l 设计与质量：低劣的设计是导致在软件开发中返工、不易维护以及用户不满的主要原因；充分设计可以显著减少最终程序的规模，提升质量；设计本身也是一种排错的过程。l 设计过程n 设计什么：u 设计目标程序在整个应用系统中的位置；u 设计目标程序的使用方式；u 设计目标程序与其他组件以及模块之间的关系；u 设计目标程序外部可见的变量和方法；u 设计目标程序内部运作机制；u 设计目标程序内部静态逻辑； n 设计内容l 设计模板（对应设计信息内容归类）：具体四个模板的全程概念内容见下面给出的试题的第4题，不会让你真的去写。l 设计的考虑n UML与PSP设计模板的关系：书P91表4-7和上面那张表对应一看就够了。需要注意的是有一个模板在UML中没有体现，LST。n 设计的层次基本思想：大型系统划分为若干子系统，每个子系统划分为若干组件，每个组件划分为若干模块。在不同设计层次上开展设计工作，记录设计的表示方法也需要适应多层次要求，就是在每个不同层次上使用4个模板，不理解看书P93页两幅巨图l 设计验证方法：简单评审不足以发现复杂缺陷。方法：状态机验证、符号化执行验证、执行表验证、跟踪表验证、正确性验证。具体每种方法是怎么验证的需要就看书吧，不好整理，也不好考，这里个人认为问到各种验证方法的对比还是有可能的。n 可能的题目：罗列验证设计方法，简单描述，比较优势和不足u 状态机验证：检验状态机检查状态转换评价状态机；适用于有较复杂的状态转换的场合，可以清晰的展示状态机的内部结构，但是验证方法较为复杂难掌握，结果有时是不明显的，难以修正，纯手工的验证方法容易引入一些人为错误；u 符号化验证：将描述设计的逻辑风格（一般用伪代码程序表示）用代数符号来表示，然后系统开展分析和验证；通常用在验证一些复杂算法中，特别是遗留系统的改造，往往应用这种方法来识别和理解原有的设计；实施简单，可给出一般化的验证结果，很多时候往往是唯一提供全面验证的方法，但是不适用于有复杂逻辑的场合，纯手工的验证方法容易引入一些人为错误；u 执行表验证：执行表用一种有序的方法来跟踪伪码程序的执行状况，分析程序行为，从而验证设计；执行表验证可以用以复杂逻辑的验证，实施简单，结果可靠，但这种方法也有一些不足，比如每次只能验证一个用例，手工验证既耗时，也容易出错等；u 跟踪表验证：跟踪表验证方法是对执行表验证方法的一种扩充，执行表一般只能用以验证单独的用例，跟踪表应用符号化以及用例识别等方法，对程序的一般化行为进行验证；优缺点与执行表一致；u 正确性检验：正确性检验将伪码程序当成数学定理，采用形式化方法加以推理和验证；该方法是几种验证方法中最严密的，但是也因此是最复杂最难掌握的，手工验证也有出错的可能。给出以前某些PSP考试的题目，基本都是大概念，看了这些概念基本可以了，其中的名词和术语答卷时建议用英文，叙述性语言建议用中文。1. 描述时间日志和障碍日志的内容在两个日志的头部分有关于项目的一些通用信息；Ø 时间日志（Time Recording Log）：时间日志用来记录时间数据。关于时间数据需要填写的内容有：l Phase：选择你正在工作的这条时间记录是属于哪个阶段。l Start:：记录你开始工作的日期时间。双击即可在工具中输入现在的日期和时间。l Int.：以分钟为单位输入中断时间。l Stop:：记录你结束工作的日期时间。双击即可在工具中输入现在的日期和时间。l Delta Time：该条记录的合计时间，将被自动计算。l Comments：用于描述中断，你正在做的任务或者其他任何对你的工作有显著影响的事情。Ø 缺陷日志（Defect Recording Log）：缺陷日志用来记录时间数据。关于障碍数据需要填写的内容有：l Type：记录缺陷类型，该缺陷类型为缺陷类型标准中定义的十种缺陷类型之一。l Date：记录发现该缺陷的日期时间。双击输入现在的日期时间。l Phase Injected：选择或者输入你判断该缺陷是在哪个阶段引入的。l Phase Removed：记录你发现并修复该缺陷的阶段。l Fix time：记录你找到和修复该缺陷总计花费的时间。你可以精确计时，或者使用你的最佳估计值。l Fix defect：如果这个缺陷是在修复另一个缺陷时引入的，记录那个缺陷的编号。l Description：记录有关缺陷是什么的解释（不是解释症状，是解释这个缺陷！）。2. 解释下面的指标，描述计算方法和应用这些指标来提高最终产物的质量水平：Yield、A/FR、PQI（Process Quality Index）。l Yield：n Phase yield 度量产品中某阶段发现和移除的缺陷的百分比。Yield 能用于度量设计和编码复审，审查，编译以及测试的有效性。计算式如下：l Yield (for a phase) = 100 * (defects found) / (defects found + not found)n Process yield 是在这个阶段之前引入的缺陷is the percentage of defects injected before a phase that were found before that phase.。例如，系统测试之前的yield是系统测试的process yield。当不带阶段名使用时，process yield指的是在编译和测试之前的phase yield。n Yield可以用来估算但是直到已经通过测试和产品使用找到所有缺陷后才能准确计算。Yield度量在开发者和测试者记录所有缺陷的时候最有用。n design and code review defectsn compile defectsn test defects通过使用过程控制度量，你更可能进行高yield（high-yield）的复审l A/FR（Appraisal to failure ratio）：n A/FR = (appraisal COQ) / (failure COQ)u A/FR经验：A/FR 度量是与项目相关的；对于PSP练习，A/FR的目标是2.0或更高。高A/FR与测试缺陷的数量少以及高产品质量相关。项目应当基于估算的无缺陷测试次数设置A/FR目标。n 由于提到A/FR，这里必须解释一下COQ（Cost of Quality）。u COQ 度量 以一种对于管理有意义的方式处理质量。COQ元素是failure, appraisal和prevention costs.u Failure cost 是花在修复和返工上的时间加上所有小块时间。在PSP中，即为编译和测试时间。u Appraisal costs是为发现缺陷所做的审查花费。在PSP中就是设计和编码复审时间。u Defect-prevention cost 是识别和解释缺陷原因的时间。通常在小组或团体中完成，并由其中一名支持部门成员完成。对于PSP defect prevention 行为包括收集缺陷数据，改善设计手段和原型。l PQI（Process Quality Index）：n PQI = (design quality) * (design review quality) * (code review quality) * (code quality) * (program quality)u Design quality = minimum(1.0, design time/coding time)u Design review quality = minimum(1.0, 2 * design review time/design time)u Code review quality = minimum(1.0, 2 * code review time/code time)u Code quality = minimum(1.0, 20/(10 + compile defects/KLOC)u Program quality = minimum(1.0, 10/(5 + unit test defects/KLOC)n PQI低于0.4在单元测试后已经没有缺陷了，但PQI的目标是1.0。3. 使用PROBE方法估算时间总共有几种方法。请分别描述各种方法的使用条件（Criteria）。答：（这里只问了时间，规模只在回归参数的标准上稍有不同，其他可以类推，可见书上表格）PROBE是PROxy Based Esitimating的简称。PROBE方法使用proxy来估算程序规模和开发时间。（PROBE stands for PROxy Based Estimating. PROBE uses proxies to estimate program size and development time.）Method简要A使用estimated proxy size进行回归B使用plan added and modified size进行回归C一般方法D工程师判断（猜）l PROBE-A：n 使用estimated proxy size (作为proxy E)和development time 之间的关系。n 使用此方法的条件是u 三组或以上相关数据（R2 > 0.5）u 合理的回归参数 (table 6.6 on pg. 96)：beta0接近0（大体上小于新程序期望开 发时间），beta1不大于1/历史生产效率的50%u 至少完成三个PSP1级别以上的练习l PROBE-B：n 使用plan added and modified size和development time 之间的关系。n 使用此方法的条件是u 三组或以上相关数据（R2 > 0.5）u 合理的回归参数 (table 6.6 on pg. 96)：beta0接近0（大体上小于新程序期望开发时间），beta1不大于1/历史生产效率的50%u 至少完成三个PSP0.1级别以上的练习l PROBE-C：n 基于历史平均水平使用一个比值ratio调整时间。n 使用此方法的条件是u 只需要一组历史数据即可，使用简单。分下列三种情况设置回归参数的值。u 如果有一组estimated added and modified size和development time的历史数据，beta0为0，beta1为actual total development time to date比estimated total added and modified size to dateu 如果有一组plan added and modified size和development time的历史数据，beta0为0，beta1为actual total development time to date比plan total added and modified size to dateu 如果你只有actual time and size数据，beta0为0，beta1为actual total development time to date比actual total added and modified size to datel PROBE-D：n 没有历史数据，使用自己的判断根据estimated added and modified size估算开发时间。n 当无法使用A、B、C方法的时候使用D方法。4. PSP中使用的设计模板有哪些？简要说明各自用途。l 答：PSP包含四个设计模板：操作说明模板（operational specification template）、功能说明模板（functional specification template）、状态说明模板（state specification template）、逻辑说明模板（logic specification template）。n OST：操作说明模板描述用户与系统的正常和异常交互。包含主要的用户行为和系统反应，预期的错误和恢复条件。OST能用来定义测试场景和测试用例，解释关于操作的开发问题并可用来与用户讨论需求。n FST：功能说明模板使你能够无歧义地定义产品提供的外部功能。包含类和继承（classes and inheritance）、外部可见属性（externally visible attributes）、给出的外部函数（external functions provided）、与其他类和部分的关系（relationships with other classes or parts）。n SST：状态说明模板准确定义了必需的程序状态，状态间的转换以及转换时采取的行动。利用SST可以定义状态机结构，分析状态机设计并识别错误和遗漏。n LST：逻辑说明模板准确定义了程序的内部逻辑。目的是使用一种简洁方便的记号描述逻辑。与实现语言兼容的伪码描述经常比较合适。形式化记号也是可取的。设计者和实现者都必须熟悉使用的记号。专心-专注-专业