附加题1--我想搞懂的软工问题

2. 程序员必须测试过代码。什么叫测试过？最好的方法是在调试器中单步执行。

问：有些错误处理的分支我不能执行到怎么办？

答：如果作者都不能让程序执行到那些分支，那谁能保证那些错误处理的正确性呢？

同时，也可以加上 OutputDebugString 等输出来监视程序的控制流。

3. 程序员必须提供新的代码，以及文件差异分析工具。用 Windi? 或 VSTS 自带的工具都可以。VSTS 中可以通过 Shelveset 来支持远程代码复审。

4. 复审者可以选择面对面的复审、独立复审或其他方式。

5. 在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提出自己的意见。

6. 复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问 题，复审者不必每一件事都要亲自调查，开发者有义务给出详尽的回答。例如：

复审者：

你在这里申请了这个资源，你是如何保证它在所有路径下都能正确释放的？

开发者：

这个……我要再检查一下。

或者 —

开发者：

这个是这样保证的，我用了 SmartPointer，然后这里有 try/catch/?nally……

要记住复审者是通过问这些问题来确保软件质量的，而不是有意找碴儿。

7. 开发者必须负责让所有的问题都得到满意的解释或解答，或者在 TFS 中创建新的工作项以确保这些问题会得到处理。例如：

复审者：

这一段代码可能会被多个线程调用，代码是线程安全（thread-safe）的么，我怎么没有看到对共享资源的保护？

开发者：

我一时得不出结论，让我在 TFS 中开一个“任务”来跟踪此事。

8. 对于复审的结果，双方必须达成一致的意见。

1） 打回去 — 复审发现致命问题，这些问题在解决之前不能签入代码；

2） 有条件地同意 — 发现了一些小问题，在这些问题得到解决或记录之后，代码可以签入，不需要再次复审；

3） 放行 — 代码可以不加新的改动，签入源码控制服务器。要注意避免不必要的繁文缛节，我们做代码复审的目的是为了减少错误的发生，而不是找一个人来对着你的代码点头。一些简单的修改不是非得要一个复审者来走一遍形式。在项目开发的早期斤斤计较于一些细枝末节（例如：帮助文件里的拼写错误，数据文件格式不够最优化等）也是于大局无补的，但是，这些问题并不是不用处理了，我们可以建立一些优先级较低的工作项来跟踪处理。

http://www.guokr.com/post/629393/focus/0260544234/

问题三.第七章第4节

MSF过程模型的基本元素？

答：MSF过程模型的基本元素是阶段和里程碑。

“阶段”，就是在这一段时间里团队集中精力做某一类事件，每个阶段的结束都代表了项目的进展和团队工作重心的变化。

“里程碑”团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。里程碑标志着每个阶段的结束，此时团队应该引导成员转移工作重心，并鼓励队员以新的视角来看待下一阶段的目标，在上一个阶段产生的各种交付内容，将成为下一阶段的起始点。

问题四.第八章第3节

获取用户需求的常用方法和步骤？

答：1）用户访谈

用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组合议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照——定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列以一个粗糙的想法，根据访谈的民体情况来进行发挥。

2）用户调查

在进行用户防谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项日涉及的客户面较广。不可能——一访谈。因此，就需要借助用户调杏的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求倍息，这样就可以克服上述的问题。

用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。

3）现场观摩

俗话说，百闻石如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之合效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随用户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记；建造软件系统不仅仅只是为了模拟客户的手下操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界而等作为软件设计的目标。

4）文档考古

文档考古是指对历史存在的—些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。

5）建立联合分析小组

在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。

用广提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获地。

6）原型法

原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个祖糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方向上存在缺陷。建造这样一个系统的目的是为了看，考察某一方面的可行性。如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于文物的有效沟通，从而帮助人们尽早解决软件开发个存在的各种不确定性。

7）模型驱动

前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统，尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通道一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法。

8）基于上下文的方法

软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题，满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境，因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比，它更加注重用户在—定环境下表现出来的行为，通过分析用户的行为得到信息。

总之。进行需求分析时，应注意一切信息与需求都应站在用户的角度上，尽量避免分析员的主观想象，并尽量将分析进度提交给用户，让用户进行检查与评价，从而达到需求分析的准确性当然，在需求人员进行需求获取的过程中，往往可能是多种方法的结合，取长补短，从而达到更好地获得系统需求的目的。

http://www.sytm.net/ruanjiankaifa/20131105133049.html

问题五.第十四章第1节

衡量软件质量的指标有哪些？

答：  最近，资深软件工程师Cagdas Basaraner在博客中总结了软件开发实践过程中常用的几个衡量软件质量的指标，包括源代码行数、代码段/模块/时间段内的平均Bug数、代码覆盖率、设计/开发约束等。
    
    源代码行数（SLOC）
    
    计算源代码行数也许是最简单的办法。它主要体现了软件的规模，并为项目的发展和规划提供了有用的信息。比如，如果我们每月计算一次源代码行数，那么就可以绘制一个项目成长图。当然，这种方式并太不可靠，原因是重构和设计阶段等因素会对此产生影响，但是至少可以为项目描绘一个趋势。
    
    源代码行数的统计如果只计算逻辑代码行，那么会得到比较准确的信息。逻辑代码行不包括空行、单个括号行和注释行等等。统计源代码行数的工具有很多，比如Metrics等。
    
    代码行数不应该用于评估开发人员的效率，这可能会导致重复的、无法维护和不专业的代码。
    
    Shahar Yair和Steve McConnell早己指出，首先，使用代码行数之和无法有效评估一个项目的实际进度，因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量，这也是代码行数无法说明的。因此，聚焦于此实际上是非常有限的工作效率测量方式。SLOC无法表明要解决的问题的复杂性，也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量，它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数，同时提升代码质量。代码量大，可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。
    
    代码段/模块/时间段内的Bug数
    
    缺陷跟踪对于更好的测试和维护是必不可少的。通过缺陷跟踪，我们可以利用报告工具（如Mantis）计算出每个代码段、模块或者特定时间段内的bug数量。凭借这些数据，我们可以尽早的查出和解决缺陷起因。
    
    Bug数量可能会作为衡量开发人员效率的指标之一，但是必须非常谨慎。如果把这项指标看得太重，那么开发人员和测试人员可能会成为敌人。在一个高效率的公司，所有的员工必须团结协作。为了更好地实现评估，bug可以被分为低、中、高等，因为这些缺陷的重要性和解决成本不是相同的。
    
    此前，InfoQ中文站曾经针对“Bug统计是否在浪费时间”做了讨论，大家的看法包括：
    
    其实我一直都不低调：bug统计到底有没有用见仁见智，关键要看怎么统计，想得到什么。从来没有认真分析过bug数据的人，肯定不会知道数据里面隐藏着什么。抛开bug统计这个问题，缺陷追踪工具到底是一个什么地位？一个项目2000bug,如果没有工具辅助，所有人估计要崩溃了。没有人直接反对这个想法，应该这是DEV的内部会议，与测试无关。
    
    双子的天马行空-Adey:其实我觉得他说得很有道理的， 真正的敏捷应该不需要bug track system.Facebook的开发模式，就是dev直接面向客户，它有多个直接面向客户的开发团队，只要有需求，开发后直接上线。如果后面有issue,是有second tier的dev team来support fix.tier one的dev永远在敏捷快速状态。
    
    柴阿峰：回复@双子的天马行空-Adey:三五个人的成熟团队敏捷也许不需要，大部分还是需要的。否则各种基于bug trace的管理系统就不需要开发持续集成、变更驱动测试的功能了。好的软件可以帮助实施敏捷，而不是反过来，不可能什么都靠嘴和白板的。
    
    Sab866:敏捷的基础是团队成员都是自律自发且积极的，不需要用报告来鞭策，但是简单易用的缺陷管理工具还是必须的，不然还真是会一片混乱。
    
    代码覆盖率
    
    代码覆盖率反映了程序当中源代码被测试的程度。有许多自动化工具可以完成该功能，比如Cobertura.
    
    代码覆盖率不能完全代表单元测试的整体质量，但是可以反映出测试覆盖率的问题。它可以和其他测试指标一起作为软件质量的指标。同时，单元测试代码、集成测试场景和结果应该经常地被审查。
    
    有关质量模型的问题，支付宝SQA团队的西剑提出有效的代码度量模型应具备以下特征：
    
    ● 与组织的目标一致：代码度量模型的底线要与组织的要求一致，和业务相关的东西会体现在规范里。在支付宝，代码安全规范、敏感信息处理规范被作为代码质量最基本的要求。
    
    ● 有针对性：要做针对性分析，比如对线上故障的研发原因进行分析，分析的规则会有周期性变动的，但不要太频繁，而且规则会随着组织的成熟度而改变。
    
    ● 可操作性：要对度量维度做进一步分解，比如测试要有明确的检查点，覆盖要完整，可重复运行。支付宝就制定了具体的度量维度，从多个维度对系统加以度量。
    
    ● 有工具支持：这不是必要条件，工具不能解决所有问题！能用工具最好，不行的话就人工检查。工具检测维度要按照优先级和操作性，逐步增加精细化维度。这一点上，支付宝将一些编码规则的检查放入了持续集成工具之中，以求尽早检查、频繁检查。
    
    设计/开发约束
    
    在软件开发过程中，存在许多设计约束和准则，其中包括：
    
    ● 类和方法的长度
    
    ● 单个类里方法和属性的个数
    
    ● 方法或者构造函数的参数个数
    
    ● 代码中的魔数、字符串用法等等
    
    ● 注释行比例等

http://www.educity.cn/se/524206.html