第一次问题
1.程序、数据和文件是否代表了软件的真正含义呢？
百度百科：软件，国标中对软件的定义为：与计算机系统操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据。
其它定义：
(1)运行时，能够提供所要求功能和性能的指令或计算机程序集合。
(2)程序能够满意地处理信息的数据结构。
(3)描述程序功能需求以及程序如何操作和使用所要求的文档。
以开发语言作为描述语言，可以认为：软件=程序+数据+文档
我认程序、数据和文件代表了软件的真正含义
2.在编写C程序代码时，对文件的访问是影响程序速度的一个重要因素，那提高文件的访问速度除了常见的使用内存缓冲区之外还有什么方法？
解：内存映射文件，使用内存缓冲区方法的好处主要是便于移植，占用内存少，便于硬件实现等。如果内存比较大的时候，采用内存映射文件可以达到更佳性能，并且编程实现简单。
第二次问题
1.我们一定要学习Python吗？
不一定，但是多学点东西总是好的
2.Python和JAVA有什么区别？学哪个更好些？
解：对人工智能、深度学习这些有浓厚的兴趣就去学Python，单纯为了就业的话不管是web还是软件开发，或者是移动开发都建议Java。但是如果你学会Python了，你去做个互联网公司的运营什么的，也是很吃香的，因为你会各种数据的爬取和分析等。（有关知乎链接：https://www.zhihu.com/question/323460473/answer/681740736 ）
3.编程一定要写注释吗
解：不一定要写注释，但一定要思考这个问题；如果不确定，那就先写上。
第三次问题
1.如何有效地提高代码的执行效率？
答：尽量使用局部变量，少定义静态变量或方法，尽量重用变量，减少线程，减少循环嵌套，减少循环层数，减少函数调用，及时释放内存
2.什么是代码的健壮性？
答：健壮性是指软件对于规范要求以外的输入情况的处理能力。健壮性是指程序可以适应正常和非正常的运行环境，都可以正确地运行；随着业务量的增加，不会出现阻塞和不可用的情况。
第四次问题
1、分析如何选择恰当的黑盒测试方法。
答：黑盒测试的具体技术方法主要有边界值分析法、等价类划分法、因果图法、决策表测试法等。
（1）边界值分析法是基于可靠性理论中称为“单故障”的假设，即有两个或两个以上故障同时出现而导致软件失效的情况很少，也就是说，软件失效基本上是由单故障引起的。因此，边界值分析利用输入变量的最
小值、略大于最小值、输入值域内的任意值、略小于最大值和最大值来设计测试用例。
（2）等价类划分法是把程序的输入域划分为若干部分，然后从每个部分中选取少数代表性数据当作测试用例。经过类别的划分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值。
（3）因果图方法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变），将因果图转换为决策表，最后为决策表中的每一列设计一个测试用例。这种方法考虑到了输入情况各种
组合以及各个输入情况之间的相互制约关系。
（4）在所有的黑盒测试方法中，基于决策表的测试是最为严格、最具有逻辑性的测试方法。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不
同的操作。决策表法很适合测试这类问题。
通常在决定测试策略时，有以下的参考原则：
（1）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强；
（2）必要时采用等价划分类方法补充测试用例；
（3）采用错误推断法再追加测试用例；
（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当在补充更多的测试用例；
（5）如果程序的功能说明中含有输入条件的组合情况，则应在一开始就选用因果图法。
2、黑盒测试的优缺点；
优点：
（1）比较简单，不需要了解程序的内部的代码及实现
（2）与软件的内部实现无关
（3）从用户的角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题
（4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能
（5）在做软件自动化测试时较为方便
缺点 ：
（1）不可能覆盖所有的代码， 覆盖率较低，大概只能达到总代码量的30%
（2）自动化测试的复用性较低。
3、白盒测试的优缺点。
优点：
帮助软件测试人员增大代码的覆盖率。 提供代码的质量，发现代码中隐藏的问题
缺点 ：
（1）程序运行会有很多不同的路径，不可能测试所有的运行路径
（2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计是否正确，可能会漏掉一些功能需求
（3）系统庞大时，测试开销会非常大。
第五次问题
1、什么是软件过程
答：软件过程为一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。
2、软件过程与软件工程方法有何关系
答： 软件过程：是一个为了获得高质量软件所需完成的任务的框架，也就是说软件过程规定了软件产品开发时完成各项任务的一系列工作步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。
软件工程方法学：通常把在软件生命周期的全过程中的一整套技术方法的集合称为方法学，也称范型。软件工程方法学包含三个要素：方法、工具和过程。
从这些两个定义可以看出，软件过程是软件工程方法学的一个要素而已！软件过程是软件工程方法学的3个重要组成部分之一。
3、软件过程模型的优缺点
答：1.瀑布模型
它提出了软件开发的系统化的、顺序的方法。其流程从系统开始，随后是需求分析、设计、编码、测试、支持。这种模型是最早也是应用最广泛的软件过程模型(虽然这种模型会引起“堵赛状态”)。
优点：
（1）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。
（2）虽然有不少缺陷但比在软件开发中随意的状态要好得多。
缺点：
（1）实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。
（2）经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。
（3）客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。
（4）采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去，有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。
2.增量模型
这种模型融合了线性顺序模型的基本成份和原型实现模型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往
往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都做为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断从复，直
到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
优点：
（1）采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源
（2）如果核心产品很受欢迎，则可增加人力实现下一个增量
（3）可先发布部分功能给客户，对客户起到镇静剂的作用
缺点：
（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构
（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性
3.螺旋模型
这是一个演化软件过程模型，它将原型实现的迭代特征和线性顺序模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。在每一个迭
代中，被开发系统的更加完善的版本逐步产生。螺旋模型被划分为若干框架活动，也称为任务区域
优点：
（1）设计上的灵活性,可以在项目的各个阶段进行变更
（2）以小的分段来构建大型系统,使成本计算变得简单容易
（3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
（4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互
（5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
缺点：
（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
（2）过多的迭代次数会增加开发成本，延迟提交时间
（3）很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求
4.RAD模型
快速应用开发(RAD)是一个线性顺序的软件开发模型，强调极短的开发周期。RAD 模型是线性顺序模型的一个“高速”变种，通过使用基于构件的建造方法获得了快速开发
优点：
（1）开发速度快，质量有保证
（2）对信息系统特别有效
缺点：
（1）对大型项目而言，RAD需要足够的人力资源
（2）开发者和客户都要实现承诺，否则将导致失败
（3）并非所有系统都适合：不能合理模块化的系统、高性能需求并且要调整构件接口的系统均不适合
5.迭代模型
迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工
作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集
优点：
（1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费
（2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙
（3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率
（4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些
缺点：
在项目早期开发可能有所变化 ，需有一个高素质的项目管理者和一个高技术水平的开发团队
第六次问题
1、敏捷开发过程的优缺点？
解：优点：
(1)敏捷开发的高适应性，以人为本的特性。
(2)更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
缺点：
由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。
2、敏捷开发有哪些管理工具？
解：git，leangoo，MyCollab,DevCloud,Odoo,OrangeScrum...
3、敏捷开发流程？
解:(1)挑选一位产品负责人
这个人必须知道带领的团队需要做什么、制造什么产品以及取得什么成果，必须会面考虑到风险与回报、什么具有可行性、什么能做以及他们对什么富有热情。
(2)挑选一个团队
真正做事的是谁？这个团队必须能够落实产品负责人的愿景。团队规模宜小不宜大，一般3~9人较为合适。
(3)挑选Scrum主管
主管为Scrum过程负责，负责培训团队其他成员，确保Scrum得到正确运用，帮助团队消除一切障碍。
(4)拟定待办事项清单，并确定优先顺序
这个清单高屋建瓴地列出为了落实产品负责人的愿景而需要完成的所有事项。在产品的整个研发过程中，这个清单一直在，并有所演变，相当于产品研发的“路线图”。无论在任何时间，要想知道一个团队要做的所有事项（按照优先顺序排列），待办事项清单都是唯一具有决定性的参考依据。待办事项清单只有一份，意味着产品负责人从头到尾必须不断地对优先顺序加以调整。产品负责人应该与所有利益相关者和团队进行协商，以确保产品待办事项清单既能反映用户的需求，又不会超出团队的能力范围。
(5)改进和评估待办事项清单
让负责实际开发工作的团队对待办事项做出评估，是一个至关重要的环节。团队应该审视每个事项，看看是否切实可行。但要完成这些事项，现有的信息足够吗？该项目是否细分到了可以评估的程度？团队是否具有了每个成员都能接受、用于评定一个事项已完成的标准？一个事项能否带来显著的价值？各个事项在完成后必须产生能够用来展示的成果，如果这个成果能交付给客户试用会更好。不要用所需小时数去去评估，因为人们根本不擅长做出这么精确的评估。要用相对难度去评估，比如，难度是小、中、大。更好的采用斐波那契数列的数字（1、2、3、5、8、13.。。。）
(6)冲刺规划会
这个第一场Scrum会议。团队成员、Scrum主管以及产品负责人坐到一起，规划冲刺的内容。冲刺周期一般是固定的，不超过一个月，大部分是一至两周。团队要从待办事项清单的顶端着手，看看一个冲刺阶段中能完成多少。如果团队已经开展过好几个冲刺，那就记录下每个冲刺阶段中提高这个数字。这个数字相当于团队的速度。Scrum主管与团队成员应努力在每个冲刺阶段中提高这个数字，团队成员和产品负责人也可以借助“点数”确保每个人都能了解待办事项对于落实最终愿望的作用。对于冲刺目标，即在这一冲刺阶段完成哪些事项，所有人都应该形成共识。
Scrum的基石之一在于，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。在冲刺的过程中，没有人能够变更冲刺内容。团队必须在冲刺阶段自主工作。
(7)工作透明化
在Scrum中，最常见的做法是准备一块白板，上面分成三栏：待办事项、在办事项、完成事项。把待办事项写在便笺上，随着进度的推进，将相应的便笺纸转移到其他栏目。
让工作透明化的另一个工具是燃尽图。在这张图中，一个轴代表工作量，另一个轴代表时间。每天，Scrum主管都会记录待完成的剩余点数，而后画在燃尽图上。
(8)每日立会
这是Scrum的活力源泉。团队每天在固定时间进行内部沟通，时间一般不超过15分钟，且站立进行，Scrum主管向团队成员提出下列问题：
你昨天做了什么去帮助团队完成冲刺？
今天你打算做什么来帮助团队完成冲刺？
什么因素阻碍了团队的前进之路？
Scrum主管要问的问题就是那么多！整个会议的内容就是这么多！如果会议时间超过15分钟，那就说明开会的方法存在问题。这样做的意义在于让整个团队清楚地知道在这一个冲刺周期内各项任务的进展。所有任务都能按时完成吗？有没有机会帮助其他团队成员克服障碍？团队的任务都不是自上而下分派的，而是自主决定的、自主完成的，也不需要向上司做详细的汇报。
Scrum主管负责消除团队面对的障碍。
(9)冲刺评估或冲刺展示、
在冲刺结束前，给产品负责人展示成果，也就是展示哪些事项可以挪到完成事项那一栏，并接受评价。这是一场公开的会议，任何人都可以是参与都，不仅仅包括产品负责人、Scrum主管及开发团队，还包括利益相关者、管理人员与客户。
团队应该只展示那些符合完成定义的事项，也就是全部完成，不需要再做工作就能交付的成果。这个成果或许不是完成的产品。但至少是一项完整的、可以使用的功能。
(10)冲刺回顾
团队展示之前冲刺中创造的成果，也就是展示已完成的事项，看看可以为顾客传递哪些价值，并征求反馈意见，大家就会坐下来想想哪些事执行得很顺利，哪些事应该做得更好，以及在下一个冲刺阶段中可以做出什么改善。那么，如何发现流程中的哪个环节需要改善？
要让这个冲刺回顾过程有效，团队需要相互信任。必须记住关键的一点，即大家不要团队中找一个人当成责备的对象，而是要将注意力集中在流程上，认真分析以下几个问题：为什么会发生那件事？为什么我们当时忽略了？怎样才能加快工作进度？作为一个团队，大家要对自己的流程和结果负责，要集思广益，共同寻求问题解决之道。
与此同时，团队必须有勇气把真正的障碍台面上来，这样做是为了解决问题，而不是为了指责某个成员。团队成员必须能认真探讨问题，并虚心接受他人反馈的意见和建议，以便寻求问题解决之道，而非只想为自己辩解。
然后进行关键环节。团队确定一个最值得改善的地方，将其设定为下一个冲刺阶段的首要任务，当然，改善的结果必须通过验收测试。你如何证明自己成功地完成了改善？你需要用具体的、可操作的方式界定什么是成功，这样，在下一个冲刺回顾会议中才能很快判断出是否完成改善。
(11)上一个冲刺阶段结束之后，立即开始新的冲刺阶段
利用在之前的冲刺过程中，团队在消除障碍、改善流程方面积累的经验。
第七次问题
1、软件团队的重要性？
今天的社会无论什么行业想要做出一番成就，靠一个人打拼天下已经不现实了。所谓人多力量大，三个臭皮匠顶个诸葛亮；同样，软件开发也是一样。不可否认，有相当部分牛人确实可以独自扛起大梁，独自完成一项任务。但是，一个人的精力毕竟有限，很难面面俱到，而且软件开发有许多突发事件和难以预料的情况发生。对需求的理解稍微偏差就可能导致项目的失败。 因此团队显得很重要，社会分工可以促进生产力的发展，同样，一个开发团队做好分工就可以很好地完成任务，提高效率。一个好的，高效的团队，它的队员需要具备以下几点品质。 一、协作，既然是团队，那就是分工完成任务，每人独自负责一部分，然后达到合作完成的目的。因此这需要 二、贡献，既然作为一个团队的一份子，就应该有奉献精神，因为管理者最终要看整个团队的贡献，一个队员即使能力很高但是不能为团队做贡献，不能融入团队，也是会被管理者所不容的。 三、分享，团队的每一个队员应该即使分享自己的知识，促进大家共同进步。 在整个团队中，每个人需要不断进步，虽然整个团队的进步很重要，但是个人能力不断地提高了，才能更有所作为。
2、项目沟通采用何种方式沟通比较好？
我觉得口头沟通比较好
3、沟通的目的是什么？
解：(1)第一个也是最明显的一个目的就是交换关于项目的信息。从最高层面讲，这主要指的是就项目的目标和可交付成果、项目背景(例如假设与约束等)以及项目的主题等有关项目的方面达成一致。从更低的层面讲，这还包括与工作包成果、未解决的问题和风险等相关的信息的沟通。
(2)第二个目的是项目决策的沟通，这与第一个目的紧密相关。这些包括战略决策的沟通(如通过/不通过及其他里程碑决策的沟通)，以及工作包决策和任务分配的沟通。对于前一类沟通，重点是让每一个人都能知晓，而对于后一类沟通，
即使在高度民主的文化背景下，某一方(例如项目发起人、指导委员会或项目经理)也会在决策后要求他人(例如团队成员)执行。
(3)前两个沟通目的还可能会伴随着另外一个目的，即获得对自己或他人想法的认可。这尤其常见于启动会过程中，这时，所有上述三个目的相互影响：告知团队成员有关项目的信息，沟通项目的战略决策(例如项目目标和范围定义)，使项目获得团队的认可。
(4)交流意见是沟通的另一重要目的。
这不仅指项目经理应为其项目团队成员的工作情况提供反馈，也包括批准或拒绝，以及接收来自项目团队成员和利益相关方的反馈。
(5)最后，广泛的软性沟通还有另外一个目的，即建立相互信任、相互尊重和相互理解的氛围，这是构建项目团队的前提。
第八次问题
1、每日站立会议时间应控制在多长时间？
解：每日站立会议应该控制在15分钟之内。
2、除了敏捷扑克还有哪些用户故事估算方法？
解：(1)T 恤尺码:用 T 恤的尺码来估算用户故事大小：XS、S、M、L、XL。每个尺码代表多大，需要团队进行开诚布公的讨论。这个办法很简单快捷，可以粗线条地估算产品需求列表的大小。
小贴士：这种方法适合估算大型用户故事的海量需求列表，尤其是几个 Scrum 团队都围绕一个产品工作的情况。
(2)点投票:这种方法适合估算小用户故事，且方法本身十分简单有效。「点投票」本是一种决策方式，但你也可以把它用在估算用户故事上。方法是：每个人分到几张便利贴，自由选择为哪些用户故事投票。一个用户故事得到的点数越多，代表着它体量越大。
小贴士：这种方法在大小团队里都可以使用，但你要去限制被估算用户故事的数量。
(3)水桶体系:如果你要找一种比计划扑克效率高的估算方式，则非「水桶体系」莫属了。如果需要估算多人参与的多个用户故事时，「水桶体系」就可以发挥优势。首先，按照「计划扑克」的顺序，用棕色的纸张折几个「水桶」。然后，团队把待估算用户故事写在便利贴上，放入「水桶」估算。
小贴士：如果你打算忽略掉已经讨论过的用户故事，也可以在估算过程里使用真正的水桶。
(4)五、三分法:「大、不确定、小」三分法是一种非常快捷的粗略估算方法，这种方法要求团队把每个用户故事都归于这三类之一。首先，把容易确定的用户故事归位到大、小两个类别下；然后，再集体讨论剩下难以归类的用户故事；最后，为这三个类别确定各自的大小。
小贴士：这个办法实际上是「水桶体系」的简化版，特别适合那些手头用户故事有可比性的小团队。
(5)找相似:乍一看，你可能以为这种方法像那种「连连看」、「找茬儿」的小游戏。其实也没有错，这种方法是要找到待估算用户故事的相似点，团队的任务就是把相似的用户故事分组。「找相似」的最好做法是把这个过程可视化，并把分的过小的组合并成大组。
小贴士：这种方法在一小群人和少量用户故事中效果最好，你要给不同组别分配不同的估算值。
3、软件配置管理过程？
解:一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。
第九次问题
1、软件工程需求分析怎么做？
(1)自悟
(2)交谈
(3)观察
(4)小组会
(5)提炼
2、软件需求管理的重要性是什么？
解：一个项目成功与否往往取决于它是否符合要求,对于需求及其变更的管理是否正确已是项目成功最为关键的因素。
一、需求管理的概念
Rational把需求定义为“系统必须符合的条件或具备的功能”。著名的需求工程设计师Merlin Dorfman和Richard H.Thayer提出了一个包容且更为精炼的定义：软件需求可定义为用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
二、需求管理的目标和原则
需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。
需求管理的目标有两个:第一，使软件需求受控，并建立供软件工程和管理使用的需求基线；第二，使软件计划、产品和活动与软件需求保持一致。
在需求管理过程，为实现第一个目标，必须控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制盒版本控制；为实现第二个目标，必须就变更和软件项目各小组达成共识，对软件项目计划作出调整，其中包括人员的安排、用户的沟通、成本的调整、进度的调整等。
为进行有效的需求管理，一般要遵循如下五个原则：
第一，需求一定要分类管理。进行软件项目管理的时候，一定要将软件需求分出层次。不同层次需求的侧重点、描述方式、管理方式是不同的。
第二，需求必须分优先级。在软件项目中，如果出现过多的需求，通常会导致项目超出预算和预定进度，最终导致软件项目的失败，因此需求的优先级可能比需求本身更加重要。
第三，需求必须文档化。需求必须有文档记录。该文档必须是正确的、最新的、可管理的、可理解的，是经过验证的，是在受控的状态下变更的。
第四，需求一旦变化，就必须对需求变更的影响进行评估，这是基本原则。
第五，需求管理必须与需求工程的其他活动紧密整合。进行需求管理一定不能脱离需求工程，需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理，因而需求管理必须与前面的几个需求阶段保持密切相关。
三、需求管理的内容
需求管理在需求开发的基础上进行，贯穿于整个软件项目过程，是软件项目管理的一部分。在软件项目进行的过程中，无论正处于哪个阶段，一旦有需求错误出现或者任何有关需求的变更出现，都需要需求管理活动来解决。需求管理是一个对系统需求变更了解和控制的过程。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求活动就开始了。需求活动的具体内容如下所示：
总之，软件工程管理的核心思想是：有效的对软件开发整个过程进行合理的规划和控制，到在用户可接受的软件功能、可靠性、性能等前提下尽可能的低成本、低风险和较高的效率完成软件开发。
3、需求研讨会的目的？
解：(1)介绍项目成员和干系人
(2)收集需求列表
(3)在会议过程中，运用头脑风暴、故事板、角色扮演、现有系统评估等方法获取需求
第十次问题
1、用例建模识别参与者？
用例建模的首要任务是识别系统中的参与者。
2、用例建模的步骤包括哪些步骤？
解:(1)识别并描述参与者（actor）
通过以下问题识别Actor：
谁使用这个系统的功能？
谁从该系统获得信息？
谁向该系统提供信息？
该系统需要访问(读写)那些外部硬件设备？
谁来负责维护和管理这个系统以保证其正常运行？
该系统需要与其他系统进行交互吗？
(2)识别用例（use case），并给出简要描述
寻找用例可以从以下问题入手(针对每一个参与者)：
参与者使用该系统执行什么任务？
参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？
参与者是否会将外部的某些事件通知给该系统？
系统是否会将内部的某些事件通知该参与者？
(3)识别参与者与角色之间的通讯关联
(4)给出每一个用例的详细描述
(5)细化用例模型
3、使用用例建模系统需求的主要优点是？
解：促进并鼓励用户参与
第十一次问题
1、面向对象分析的特点
2、面向对象分析三种模型
解：(1)功能模型：状态模型，表达系统的详细需求，为软件的进一步分析和设计打下基础。在面向对象方法中，由用例图和场景描述组成。描述系统功能、完成数据值的变化、做什么数据变换。
(2)对象模型:类模型,表示静态的、结构化的系统“数据”性质。描述现实世界中实体的对象以及它们之间的关系，表示目标系统的静态数据结构。在面向对象方法中，类图是构件对象模型的核心工具。描述系统数据结构,静态结构。
(3)动态模型：交互模型，描述系统的动态结构和对象之间的交互，表示瞬时的、行为化的系统的“控制”特性。面向对象方法中，常用活动图，状态图、时序图、协作图构件系统的动态模型。描述系统控制结构、执行操作、什么时候做、在何种状态下接受了什么事件的触发、交互次序。
3、面向对象设计的原则
解：(1)单一职责原则
定义：
一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
单一职责原则是实现高内聚、低耦合的指导方针，是最简单却最难运用的原则，需要设计人员发现类的不同职责并将其分离
(2)开闭原则
定义：
软件实体应当对扩展开放，对修改关闭。
指软件实体应尽量在不修改原有代码的情况下进行扩展。
(3)里氏替换原则
定义：
所有引用基类的地方必须能透明地使用其子类的对象。
里氏替换原则表明，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。
在运用里氏替换原则时，应该将父类设计为抽象类或者接口，让子类继承父类或实现父类接口，并实现在父类中声明的方法。
(4)依赖倒转原则
定义：
高层模块不应该依赖底层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
依赖倒转原则要求：要针对接口编程，不要针对实现编程。
(5)接口隔离原则
定义：
客户端不应该依赖那些它不需要的接口。
在使用接口隔离原则的时候，需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来不方便。
(6)合成复用原则
定义：
优先使用对象组合，而不是继承来达到复用的目的。
一般而言，如果两个类之间是"Has-A"关系应使用组合或聚合，如果是"Is-A"关系可使用继承。
(7)迪米特法则-又称最少知识原则
定义：
每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
第十二次问题
1、顺序图有哪些组成？
解：顺序图由类角色、生命线、激活期和消息组成
2、顺序图的建立有哪些步骤？
解：（1）确定交互过程的上下文。
（2）识别参与交互过程的对象并设置生命线。
（3）从引发该交互过程的初始消息开始，在生命线之间自顶向下依次画出随后的各个消息。
（4）若需要表示消息的嵌套或消息发生时的时间点，则采用控制焦点。
（5）若需说明时间约束，则在消息旁加上约束说明。
（6）如果需要，可为每个消息附上前置条件和后置条件。
3、状态图建立有哪些步骤？
解：（1）确定状态机的上下文，它可以是一个类、子系统或整个系统。
（2）选择初始状态和终结状态。
（3）发现对象的各种状态。注意应当仔细找出对问题有意义的对象状态属性，这些属性具有少量的值，且该属性的值的转换受限制。状态属性值的组合，结合行为有关的事件和动作，就可以确定具有特定的行为特征的状态。
（4）确定状态可能发生的装移。注意份已从一个状态可能转移到那些状态，对象的哪些行为可引起状态的转移并找出触发状态转移的事件。
（5）把必要的动作加到状态或转移上。
（6）里要超状态、子状态、分支、历史状态等概念组织和简化一个复杂的状态机。
（7）分析状态的并发和同步情况。
（8）绘制状态图。
（9）有一个死端状态，对象不能从该状态转移出来。
第十三次问题
1、软件体系结构的研究范畴有哪些？
解：研究范畴：非形式化的框图，形式化建模符号、体系结构说明的分析与开发工具，体系结构再工程。其中典型的例子是美国卡耐基梅隆大学的Robert J．A11en于l997年提出的Wright系统。
2、分析和比较B/S，二层C/S和三层C/S，指出各自的优点和缺点。
解：二层C/S体系结构将应用一分为二，服务器负责数据管理，客户机完成与用户的交互任务。优点:（1）C/S体系结构具有强大的数据操作的事务处理能力，模型思想简单，易于人们理解和接受。（2）对软硬件的变化有极大的适应性和灵活性，易于对系统进行扩充和缩小。（3）系统中的功能构建充分隔离，节约大量费用。缺点:（1）开发成本较高。（2）客户端程序设计复杂（3）信息内容和形式单一（4）用户界面风格不一，使用繁杂不易推广。（5）软件移植困难（6）软件维护和升级困难（7）新技术不能轻易应用。
三层CS在上面的基础上进行了改造，并增加了一个服务器，其优点：（1）允许合理的划分三层结构的功能，能提高系统和软件的可维护性和可扩展性。（2）具有良好的可升级性和开放性。（3）应用的各层可以并行开发，可以选择各自最适合的开发语言。（4）为严格的安全管理奠定了坚实的基础。
B/S风格就是上述三层应用结构的一种实现方式，其具体结构为：浏览器/Web服务器/数据库服务器。优点:（1）基于B/S体系结构的软件，系统安装，修改和维护全在服务器端解决。（2）提供了异种机，异种网，异种应用服务的联机，联网，同意服务的最现实的开放性基础。缺点:（1）缺乏对动态页面的支持能力，没有集成有效的数据库处理能力。（2）在数据查询等响应速度上，要远远低于C/S体系结构。（3）数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理应用。
3、软件设计过程的主要步骤?
解： 需求确认——概要设计——详细设计——编码——单元测试——集成测试——系统测试——维护