本人的问题清单！
第一次上课
Q：
- 1.软件工程学习的方向是什么？
- 2.我们开发的软件需要系统的工程的，那么之后的学习是不是也会非常的规范？
- 3.现在已经发展到了互联网的阶段，物联网的发展是不是会非常依赖软件工程？
A：
- 1.https://blog.csdn.net/weixin_43813848/article/details/84563970，有详细的、系统的说法。
- 2.软件工程：涉及程序设计语言、数据库、软件开道发工具、系统平台、标准、设计模式等方面。
- 3.没有明确的关联。
第二次上课
Q:
- 1.要是自己写的软件代码自己觉得很好看咋办！
- 2.怎么样能够熟练掌握软件开发对于模块的精准应用？
- 3.Python的集成开发环境软件适合我们现在使用吗？
A:
- 1.这应该不算是一个问题吧，哈哈哈哈
- 2.需求分析能力、项目设计方法和流程处理能力、复用设计和模块化分解能力、整体项目评估能力、团队组织管理能力。https://www.sohu.com/a/387331351_120418174
- 3.适合大三的我们没问题。
第三次上课
Q：
- 1.优化代码的时候，修改了大量代码这算是优化还是重写呢。
- 2.代码的审查过程中，需要完全依赖于缺陷检查表嘛？
- 3.在我们现实生活的编程中，有结对编程嘛，不都是每个人有自己的负责模块吗？
A：
- 1.概念不一样，优化是针对代码，而重写对于一个程序员来说，最好是不要重写。
- 2.大部分可以依赖，其他的需要看情况而定。
- 3.现实生活中存在结对编程，可以提高效率，以及降低编程的乏味性。
第四次上课
Q：
- 1.单元测试越早越好嘛，是不是在代码后期如果发现问题，解决的成本是不是越来越高了。
- 2.测试覆盖是不是要完全覆盖是最好的。
- 3.黑.白盒子的测试针对的东西不一样，现实工作中我们开发软件，是不是两种测试都需要使用。
A：
-
1.单元测试并非越早越好，单元测试对我们的产品质量是非常重要的。单元测试是所有测试中最底层的一类测试，是第一个环节，也是最重要的一个环节，是唯一一次有保证能够代码覆盖率达到100%的测试，是整个软件测试过程的基础和前提，单元测试防止了开发的后期因bug过多而失控，单元测试的性价比是最好的。据统计，大约有80%的错误是在软件设计阶段引入的，并且修正一个软件错误所需的费用将随着软件生命期的进展而上升。错误发现的越晚，修复它的费用就越高，而且呈指数增长的趋势。作为编码人员，也是单元测试的主要执行者，是唯一能够做到生产出无缺陷程序这一点的人，其他任何人都无法做到这一点。
-
2.在测试里面，一般会将测试覆盖率分为两个部分，即”需求覆盖率“和”代码覆盖率“。可以看到，代码覆盖率其实是测试覆盖率的一部分而已。其中，最常讨论和关心的是”代码覆盖率“，代码覆盖率又分为程序语句和代码行覆盖，分支覆盖和条件覆盖。对于这些概念，我们逐个解释。
需求覆盖率：如果需求已经定义好，这个时侯我们就需要考虑需求覆盖率了。这个时候需要注意的是，这里的需求不仅仅是指功能需求，还要包括性能需求。衡量需求覆盖率的最直观的方式是我们有多少功能点，我们有多少性能点要求，这些将作为分母；我们写了多少测试用例，覆盖了多少模块，多少功能点，我们的性能测试用例考虑了待测程序多少性能点，这些作为分子。
代码覆盖率：为了更加全面的覆盖，我们可能还需要测试程序的流程，我们可能会考虑到一个函数的数据的输入与输出，甚至是每一行代码的执行情况，代码的每一条逻辑和分支，这个时候我们的测试执行情况就以代码覆盖率来衡量，这也是我们常在单元测试中念叨的覆盖率覆盖率的问题。 -
3.黑盒测试的优点：
1.对于子系统甚至系统效率要比白盒测试高
2.测试人员不需要了解实现的细节（特定编程语言）
3.测试人员和编程人员彼此独立
4.从用户的角度进行测试很容易理解和接受
5.有助于暴露规格的不一致或有歧义的问题
6.测试用例可以在规格完成后马上进行。
黑盒测试的缺点：
1.只有一小部分输入被测试到，要测试每个可能的输入几乎不可能。
2.没有清晰、简明的规格，测试用例很难设计。
3.如果测试人员不被告知开发人员已经执行过的用例，在测试数据上会存在不必要的重复
4.有很多程序路径没有被测试到。
5.不能直接针对特定程序段测试，而这些程序段可能很复杂，有可能隐藏更多的问题。
6.大部分和研究相关的测试都是直接针对白盒测试的。
白盒测试的优点：
1.能仔细考虑软件的实现2.可检测代码中的每条分支和路径 3.揭示隐藏在代码中的错误4.对代码的测试比较彻底。
白盒测试的缺点：
1.昂贵2.无法检测代码中遗漏的路径和数据敏感性错误3.不验证规格的正确性。
第五次上课
Q：
- 1.瀑布模型在现代还有生存的环境嘛？
- 2.软件开发过程有什么特点？
- 3.有没有软件使用迭代和可变化的模型？
A：
- 1.1970年WinSTon Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 - 2.https://blog.csdn.net/m8396017/article/details/51355757，看博客解决心中疑惑哈哈哈，打一波广告。
- 3.有的，多的去了哈哈哈。
第六次上课
Q：
- 1.敏捷开发的快速性适用所以开发过程吗？
- 2.scrum的方法需要的用户体验基数大吗？
- 3.如何做好团队开发过程中自己的位置。
A:
- 1.不是适用于所有的，比如说不适用于互联网+产品。
- 2.https://blog.csdn.net/cxxfk23456789/article/details/48498313
- 3.多沟通、多交流、找准自己的定位，实事求是，脚踏实地。
第七次上课
Q：
- 1.沟通之中存在刺头我们改如何下手？
- 2.预算与实际出现偏差我们如何协调？
- 3.自身怎么找到自己在团队的位置和价值？
A：
- 1.了解性格，引导错误、调整心态、给予鼓励。
- 2.首先应该确定是否在做预算时，作了管百理储备，即为潜在变化预留了部分预算，如果度有，那么因该是动用它的时候了。
如果没有额外问的资金支持，那么超支的后你能做的只能是推迟工期、答降低项目项目的回质量标准、或缩小项目的工作范围
这三项重要选择一项，或者在答三项中做协调，协调彼此要降低或推迟的程度 - 3.多沟通、多交流、找准自己的定位，实事求是，脚踏实地。
第八次上课
Q：
- 1.Scrum的核心特征是什么?
- 2.哪类项目可以使用Scrum?
- 3.怎样更好的使用tower
A：
- 1.Scrum是一个框架，人们可以在其中解决复杂的自适应问题，同时有效且创造性地提供具有较高价值的产品。它用于管理软件项目和产品或应用程序开发。它的重点是适应性产品开发战略，其中跨职能团队作为一个单元在2-4周内达成共同目标。它由一系列价值、文物、角色、仪式、规则和交加实践组成。
- 2.http://blog.sina.com.cn/s/blog_e349337f0101okx3.html
- 3.自我体会了。
第九次上课
Q：
- 1.需求类型是如何定义的？
- 2.用户的需求我们怎么分析？
- 3.系统过程的解决？
A：
- 1.需求分析是对软件系统的后期分析，需要进行一系列的活动，包括：分析用户需求、建立 需求原型、分析系统需求和进行需求验证等
- 2.用于描述系统功能组织结构的层次模型，用于描述系统中数据加工流程的数据流模型，用于描述数据实体及其 关系的数据关系模型，用于描述系统行为过程的系统状态模型等。
- 3.这个问题提出的不是很好。