问题清单
第一次问题
1.当软件的行为与开发者的目标一致时，这个软件也是不成功的。为什么？
？
2.那我是不是要在软件开发中程序设计时尽可能的对程序代码进行优化？
是的
3.在做代码优化时，我是不是在通过测试时找到耗时最多的部分进行优化？
是也不是吧？先优化数据结构和算法
（1）主治医师模式：一人为主，其他人为此人服务。
（2）明星模式：主治医师模式到达极致，一人的光芒掩盖所有人。
（3）社区模式：每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。
（4）业余剧团模式：在不同项目中每个人扮演着不同的角色，可能随着项目的改变，自己的角色也会发生变化。
（5）秘密团队模式：一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。
（6）特工团队模式：有一些有特殊技能的专业人士组成的团队。
（7）交响乐团模式：人员工具齐全，准备充足的团队。
（8）爵士乐模式：相对自由，有风险，人少且不靠谱。
（9）功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。
（10）官僚模式：层层领导的团队模式。
团队的开发模式包括以下几种：
（1）写了再改模式：和一窝蜂团队模式比较像。
（2）瀑布模型及其各种变形。
（3）RUP统一流程。
（4）老板驱动的流程。
（5）渐进交付的流程。
（6）TSP的原则。
至于团队模式和团队的开发模式的关系，我个人的理解是一群人在一起做软件开发，总是要一些方式方法。而这里团队模式就是这一群人的定性，团队的开发模式则是这群人使用的方法的定性。
划分模块中，如何将紧密联系转换为松散联系，为什么要这样做？
A:联系越多，则独立性越少，如果一个出错，那么其他的都会出错
在代码性能分析中，如何选择要测试的数据？（比如：只是找一些边界数值吗，还有其他的什么方面）
A:边界值分析法是基于可靠性理论中称为“单故障”的假设，即有两个或两个以上故障同时出现而导致失效的情况很少。
对程序每个变量重复：每次保留一个变量，让其余的变量取正常值，被保留的变量依次取min、min+、nom、max-和max。
健壮性测试：是作为边界值分析的一个简单的扩充，它除了对变量的5个边界值分析取值外，还要增加一个略大于最大值（max+）以及略小于最小值（min-）的取值，检查超过极限值时系统的情况。
在代码性能分析中，首先要证明需要优化，如何证明（eg:难道就是使用代码性能工具来看每一个方法或者类的执行时间的长短吗？）
A:静态测试：通过人工分析或动态测试：程序正确性证明方式来确认程序正确性：通过动态分析和程序测试等方法来检查和确认程序是否有问题。
第四次问题
原型化模型适应于什么样的情况？
A:原型模型适用于那些不能预先确切定义需求的软件系统的开发，更适用于那些项目组成员（包括分析员、设计员、程序员和用户）不能很好的交流或者通信的情况下。
https://blog.csdn.net/qq_23381995/article/details/61622590
软件开发应该遵循严格受控的过程和详细的项目规划时敏捷开发的特点吗？为什么？
A:不应该 会有一些例会进行总结和改进
静态分析是不是没有动态分析效率高？一般采用动态分析？
第五次问题
scrum迭代是迭代模型和瀑布模型的结合？
A：感觉是的
原型化模型适用于需求难以定义的情况，那么其如何实现有助于明确需求和选择可行的设计策略？
软件测试是提高软件的决定性因素吗？
第六次问题
1.在对软件项目进行估算时使用的估算方法可以是几种估算方法的结合？
A：是的
2.一般在对软件项目进行估算时要结合哪些方面来进行考虑选择合适的估算方法
A：方程法、类比法和类推法。一般情况下估算软件项目工作量是由估算软件规模的结果作为输入，然后采用方程法来进行估算。但也有一些特殊情况，比如需求非常模糊而无法进行规模估算时，可以直接采用类比法或类推法来估算软件工作量。
https://wenku.baidu.com/view/a8aed8138662caaedd3383c4bb4cf7ec4afeb6ed.html
3.我看有一道题：为了将项目失败的风险减少到最小，项目经除了要顺利的开始还需要 要求更大的预算。这是为什么？
第七次问题
1.故事点是一个相对度量单位，它的作用是什么？
A：用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果
https://www.cnblogs.com/sophia194910/p/8334906.html
2.用例参与者应如何选取？
https://blog.csdn.net/ls1645/article/details/42969587?utm_source=blogxgwz7
3.造成需求获取困难的原因是什么？
https://www.csdn.net/gather_25/MtTagg3sNjgzNy1ibG9n.html
4.敏捷项目中如何进行需求分析?
A： 敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流，搞清楚客户到底需要什么，到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向，就可以不迷失方向。和客户进行交流，最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验，客户说，我要这个功能，我想要怎么怎么样。这时候要特别注意，他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么，挖掘出他真正的目标。
在这个目标下，商务分析师开始进行需求的分析：我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更? 搞清楚这些事情后，就可以写出用户故事。用户故事的书写遵循一定的原则，一般包括三部分："作为(系统的一个涉众)，我想要(做一件事)，从而(达到一个商业价值)"。在书写的时候格式比较随意，可以在故事卡背面写上注释或疑问，甚至画上界面原形图。 举一个最常见的用户故事例子，“作为一个普通用户，我希望能够用用户名和密码登录，以便我能享受到个性化的服务”。其中，用户是系统涉众，登录是他想要做的事情，而他的目标是获得个性化的服务。 从这个例子我们可以想象到，这个页面可能存在两个文本框，用于输入用户名和密码，有一个按钮来登录，并且不登录就不能看到个人资料，另外，如果用户输入错误需要提示“登录失败请重试”。这就是可见性，也可以称为可测试性。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。
第八次问题
用户故事与用例描述的区别？
A:用户故事可以用于估算；用例描述则不能用于估算
用例建模是对系统进行功能分解的过程？
A:用户故事可以用于估算；用例描述则不能用于估算
关联关系、依赖关系、包含关系之间的区别？
第九次问题
对几种类型关系中那个在UML类图使用最多？
A:关联>泛化>聚合>组合>依赖>实现
开闭原则的作用是什么？
A:要尽可能多地使用接口进行封装，利用多态技术，扩展时不需修改源代码
类的特征是什么？
A:相同的性质、相同的行为、相同的对象关系、相同的语义
