问题清单

软件工程	https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1
作业要求	https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10618
作业目标	做一个学习工程中的问题清单
作业正文	如下所示
其他参考文献	https://blog.csdn.net/juiceda/article/details/7522239 https://blog.csdn.net/weixin_33788244/article/details/93035281 http://www.woshipm.com/pmd/2396563.html https://baike.sogou.com/v57039002.htm?fromTitle=%E7%87%83%E5%B0%BD%E5%9B%BE https://mp.weixin.qq.com/s?src=11×tamp=1586585252&ver=2271&signature=I6wgBlRaBtIBtCJeWTbbZ6So6g6E9V5rHmlpmiTLm*DffqWNqpq*6ENlFhjGH0EnHAxtO7rJezV4B9bwEZjy9Zs*q5RPX0zZfDShsj9A1w4sj0Jm*H9uYKBHtb0qosK*&new=1 https://www.sogou.com/link?url=hedJjaC291OfPyaFZYFLI4KQWvqt63NBTSsxLNVqV0Q73d0TWaCjfA..

 

 

 

 

 

1.代码源不是软件本身，那软件本身是什么？

  答：

国标中对软件的定义为：与计算机系统操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据

其它定义

1．运行时，能够提供所要求功能和性能的指令或计算机程序集合。

2．程序能够满意地处理信息的数据结构。

3．描述程序功能需求以及程序如何操作和使用所要求的文档。

以开发语言作为描述语言，可以认为：软件=程序+数据+文档

 

2.为什么修改软件会导致软件退化？

答：

并没有在网上找到答案，个人理解：每次修改之后，软件都变得更复杂，给下一次修改增加了难度，慢慢积累，就慢慢不易修改了，最后无法满足用户新增需求，被淘汰。

 

4.如果代码可读性很高，不是很容易被攻击吗？

答：

没有找到答案，个人理解，代码只有内部人才能看到，可读性高也是为了后续人员的修改维护方便。

 

5.刘贺前辈说要写容易修改的软件，那游戏一类的外挂不就很容易制作了吗？

答：

制作外挂使用需要付出相对应的代价。

 

6.迭代模型与维护的区别。

答：

 

7.增量模型与迭代模型实质上的差别是什么？

答：

迭代是不能并行的，迭代的并行是指迭代任务，比如从3.1-3.31号是一个迭代计划，该迭代计划需求人员可以分析功能点5-功能点10，设计人员可以做功能点3-功能点7的设计，开发人员可以做功能点2-功能点4的开发，测试人员可以做上个迭代周期发布的代码。  迭代的并行是指工作流的并行。
大家看到迭代计划是比较复杂的，因此对项目经理的经验要求很高。

增量模型一般是指具有底层框架和平台的项目，在该稳定的框架和平台上，来开发和增加具体的业务功能。每个增量之间相对独立，各个增量可以并行开发，比如：3.1-31号实现增量1（包含5的功能点），3.20-4.15开发增量2（包含另外的4个功能点）。增量内部是瀑布模型。

两种类型的区别在于迭代是基于IBM的RUP的以架构为核心，用例为驱动，角色职责划分不同，在同一时刻项目内部需求、设计、编码、测试的活动都在发生。迭代适合需求不明确、架构风险大的项目，增量适合需求比较明确，架构比较稳定，而且增量功能的实现基本不影响架构。
还有一个不同就是迭代计划是基于角色的，增量计划是基于任务的。

两种类型的相同之处，每个迭代和增量结束后都有产品发布。

快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

 

8.敏捷开发的优点是什么？

答：

       1. 精确要求，精准成果。敏捷开发不似瀑布模式的开发，从一个点开始却会以一大片结束。这样的开发会导致成果与出发点严重偏离，重点无法被作为重点开发出来，而是与原来的构想相差甚远。敏捷开发似接力比赛，每一段赛道都不长，并且还能把握好每次交接棒的时机，遵循计划更响应变化，这使成果变得十分精准。

　　2. 质量有保障。敏捷方法对每一次迭代周期的质量都有严格要求。敏捷开发团队拥有高水平的开发方法，有的会在正式开发功能代码之前先开发该功能的测试代码，质量可保证。

　　3. 客户合作胜过合同谈判。好的团队会更在乎与客户合作的这个过程。

　　4. 投资回报率高。在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。

　　5. 较高的速度是敏捷开发最显著的优点之一。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。

 

9.为什么说好的产品是长出来的，不是设计出来的？

答：

http://www.woshipm.com/pmd/2396563.html

 

10.迭代过程中，为什么不能添加新工作？

答：

个人理解：迭代时是按照计划进行的，如果添加新的工作，可能会导致一些新的没有预料到的问题出现。

 

11.主程序员模式中，主程序员的任务是否过重了？

答：

 

12.燃尽图存在的意义是什么？

答：

燃尽图是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。这个词常常用于敏捷编程。由于燃尽图是对于剩余时间的统计，在工作人数不变的情况下，我们可以通过该图推断出目前工作的大致进度与趋势，管理层就可以通过这个图实时把握住开发的进度并作出正确的决策，而且还可以预计风险，同时随之调整计划。

 

13.理想时间与故事点哪一个更好？

答：各有优点，根据情况选择

选择

• 故事点是更为纯粹的对规模的估计，它比较客观，无论是熟练的高级工程师还是不熟练的初级工程师，估算的故事点应该都是类似的。即使团队在技术上或者领域知识上取得了进步，也并不需要对用户故事进行重估。

• 理想时间的优势在于更容易向团队之外的人进行解释，同时它更容易开始。但如果一个成员认为某用户故事他需要4个理想时间，而另一个成员认为他只需要1个理想时间，也许他们都是对的，但他们缺乏讨论的共同基础，无法建立一个单一的估计。技术的熟练程度、知识的掌握程度，会影响每个人对理想时间的判断。一般来说，对同一个用户故事，熟练的高级工程师会比不熟练的初级工程师估算的理想日要少。

优点

故事点的优势：

• 有助于驱动跨功能的行为

• 故事点估计不会因为技术或知识进步而过期、失效

• 故事点是对工作量大小的纯粹度量

• 故事点估算通常更快

• 不存在“我的理想人天不等于你的理想人天”的问题

理想时间的优势：

• 理想时间估算更容易开始

• 理想时间便于预测进度

• 更容易对团队外的人进行说明，而故事点更加抽象，对团队外的人来说比较难理解

• 理想时间迫使公司正视浪费时间的活动，并着手解决

 

14.为什么要重新编译历史版本？

 

15.向前引用是什么意思？

答：

在定义类、接口、方法、变量之前使用它们