2020软件工程作业00——问题清单

软件工程	https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1
作业要求	https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10618
作业目标	列出问题清单
作业正文	https://www.cnblogs.com/lucky-6127/p/12468025.html
参考文献	无

第一章

• 如何才能开发一个“足够好”的软件？
  • 尽可能提高用户满意度
    如果用户在使用中发现软件存在许多问题，那么会很大程度影响用户的使用效率，用户的满意度自然会下降。
    而为了提高用户满意度，首先就是要了解用户的需求，研发出符合用户需求的软件是首要目的。
    通过实际的工作收集、推导、提炼需求，并在软件发布后通过实际数据验证需求的确被满足了。需求来自与
    实际，而不是自己想象出来的“需求”或者人云亦云的需求。
  • 保证软件可靠性和软件流程的质量
    软件可以正常运行，而不是经常崩溃或者无法正常使用，这也会影响用户对软件的评价。软件团队和开发流
    程的问题太多，会导致团队内部无法正常相互协作，延长软件开发周期，会影响用户的时间，也不能称作好
    的软件。软件开发不是一个人的事情，也不是几天完成的。而应该是一个团队一段时间的精诚合作完成的，
    每个人都有不可取代的地位和作用，每个人都是软件的一部分，不能有个人英雄主义，一切必须以团队为主
    题，一切把团队价值放在第一位。团队必须全面协调一致，才能在预定时间内做出相对好的软件。
  • 确保软件的可维护性
    如果一个软件完成后不可更改，那么就不是一个好的软件，应该可以根据实际中的问题随时进行更新和维护，
    不断解决存在的问题。应该根据用户需求建立需求分析的文档说明，包括对将来发展的分析和计划。主要动
    能的设计文档说明和软件的实际行为一致。源代码完整，能用软件管理软件看到源代码的每次修改记录，
    Bug的修改过程。关键模块设立修改权限，并且配套可以正常执行的单元测试、压力测试的脚本，以适应随
    时可能进行的维护。
• 怎样才可以提升团队的能力和效率？
  • 团队成员人数最好在3-7人之间，最多不超过10人。
  • 选择性格互补的团队成员而不是一味地看中技术。
  • 选择适合项目的团队开发组织模式。
  • 团队成员间多多沟通，面谈是最有效的方式。
  • 定时召开项目阶段进展会议、项目组工作例会。
• ISO9126质量模型中功能性的子特性适合性与可移植性的子特性适应性如何区分？
  • 适合性：提供了相应的功能。
  • 适应性：适应不同平台。
• 一个团队怎样才可以在耦合大家所做的部分呢？
  • 选择相同的设计模式。
  • 遵守公司的代码编写规则。
    
    

第二章

• 现实中维护需要70%的成本，那么维护的都是哪些方面呢？

  • 改正性维护：对程序使用期间发现的程序错误进行诊断和改正的过程；占维护工作量17-21%。
  • 适应性维护：配合变化了的环境进行修改软件的活动；占维护工作量18-25%。
  • 完善性维护：满足用户在使用过程中提出增加新的功能或修改已有功能的建议而进行的改进工作；
    占维护工作量50-66%。
  • 预防性维护：为了改善未来的可维护性或可靠性而修改软件的工作；占维护工作量4%左右。

• 好的注释重在质量而不在数量，那怎么样才算好的注释呢？

  • 好的注释，即有用的注释。何为有用的注释？增加知识点、帮助别人理解相应代码的注释。

• 模块化设计是将一个复杂的程序划分成一系列小模块，且尽量减少模块间的 耦合性，但只要是一个
  大的程序，模块间就避免不了互相调用，究竟该如何划分才能尽可能的减少模块间的耦合性呢？基于易变和
  稳定划分的时候如何分辨模块是易变还是稳定的呢？是后续维护中可能会修改的次数还是其他？

  • 在软件设计中有一个原则：高内聚低耦合，体系结构设计中的分层设计就可以帮助解决，将相互联系
    比较多的模块放在同一层，层与层之间通过接口联系，可以减少模块间的耦合性。
  • 基于易变和稳定部分是针对模块内部的，分离易变部分的其中一种方法是参数化。

• 代码优化中，限制效率的“瓶颈”该如何去找？

  • 通过代码分析工具找到耗时最多的部分进行改进。

• 在刘贺的讲述中谈到，软件工程的关键是怎么写出修改地更快的软件，那么究竟什么样的软件才是修改的更快的软件呢？

  • 代码可读性较强，容易理解。
  • 模块与模块间的耦合性较低，容易修改。

• 在刘贺的总结中谈到，简单的东西不要写复杂，又复杂的东西不要写简单，如何区分？

  • 自认为比较难理解的部分做详细注释。
  • 一眼看去就能知道用来干嘛的部分简单注释就好。
    
    

第三章

• 为什么测试用例既要有正确输入又要有错误或异常输入？

  • 正确的输入用例可以测试系统功能是否正确实现。
  • 因为用户不一定会按照你的输入规范输入，错误的输入用例可以检查当用户输入不合法时，系统是否会崩溃。

• 正面测试用例与负面测试用例怎么理解？

  • 正面测试用例：用于证明该需求以满足。
  • 负面测试用例：反映某个无法接受，反常或以外的条件或数据，用于论证只有在所需条件下才能满足该要求

• 判定覆盖和条件覆盖怎么区分？

  • 判定覆盖只关心判定表达式的值（真/假），而条件覆盖涉及到判定表达式的每个条件的值（真/假）。

  • 举个最简单的例子，方便理解：

    判定表达式：a>1 or b>1
    

    用判定覆盖设计的测试数据：

    a＝5 （判定表达式的值为“真”）
    
    a＝0 （判定表达式的值为“假”）
    
    这里不需要管b的取值，就已经满足判定覆盖的条件了。
    

    用条件覆盖设计的测试数据：

     a＝5 （条件a>1的值为“真”）
    
     a＝0（条件a>1的值为“假”）
    
     b＝5 （条件b>1的值为“真”）
    
     b＝0 （条件b>1的值为“假”）
    
    这里不考虑 a>1 or b>1 这个表达式的取值的情况，但必须把a>1  和 b>1 这两个条件的取值考虑全。
    

第四章

• 瀑布模型每个阶段的测试在什么时候做？测试报告又是在什么时候编写的？

• 迭代模型与原型有些相似（都是先提交一个可运行但不完整的系统），具体如何区分？

• 形式化的描述以及形式化转换具体怎么实现？

• 敏捷开发中，仅对Scrum做了详细说明，XP极限编程具体又是什么？

• 虽然听了视频，但是对于敏捷开发的具体实现还是比较模糊，所以~敏捷开发的过程是什么？

• 微软公司的成功之道总结来说是什么？
  
  

第五章

• 开源系统是什么？

  • 开源，(Open Source)全称为开放源代码。市场上开源软件层出不穷，很多人可能认为开源软件最明显的特
    点是免费，但实际上并不是这样的，开源软件最大的特点应该是开放，也就是任何人都可以得到软件的源代
    码，加以修改学习，甚至重新发放，当然是在版权限制范围之内。
  • 开源系统其实面向的用户有两个群体，一是程序员，他们最关心源代码,能不能进行二次开发利用;二是普通
    终端用户，他们只关心软件功能够不够强。开源系统的重点应该是在"开放"，是接纳、包容和发展，求同存
    异，互利共赢，才是开源的本质。
  • 用户在使用开源产品时，不但需表明产品来自开源软件和注明源代码编写者姓名，而且还应把所修改产品返
    回给开源软件，否则所修改产品就可视为侵权。

• 在功能点方法中提到五个软件信息域具体是什么？

  • 外部输入。
  • 外部输出。
  • 外部查询。
  • 外部接口文件。
  • 内部逻辑文件。

• 调整因子是什么？

  • 大概是可调整的范围吧。
    
    

第六章

• 每日站立会议是为了什么？梳理工作任务？

• 敏捷扑克估算法中，Delphi估算原理是什么？斐波纳契数是什么？

• 我们之后的团队项目则需要用到团队协作工具么？
  
  

第七章

• 分布式约束是什么意思？

• 四世界中，风险怎么分析？

• 概念建模中的语言有哪些？具体怎么使用？