问题集
学习时的问题集
|
这个作业属于哪个课程 |
https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
|---|---|
|
这个作业要求在哪里 |
https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10618 |
|
这个作业的目标 |
解决自己在学习中遇到的疑问 |
|
作业正文 |
|
|
其他参考文献 |
百度和思考 |
第1章 初始软件工程（第1次课）
1.软件工程和平常编程有什么重要区别吗？
软件工程不但要有编写程序代码的能力而且更重要的是要懂得如何去开发一个软件，怎样去学习实际的UI的观念。
2.软件工程在日常生活中有什么重要作用吗？
软件最大的目的是能够给社会带来前进的动力！ 生活自然就能用到软件来提升了！
3.软件工程还有进一步的提升和发展吗？
软件工程的深入钻研和更为广泛的使用，以及我国无论是从国家级别还是社会发展的进一步发展，就必须是理论和实践相结合的，既要有专业的理论支持，也要有真正有技术的人才来实践和推进，所以整个软件行业的发展空间是巨大的，专业的前景是光明的，这也是为什么社会上的软件工程培训行业是如此火爆。
第2章 编写高质量代码（第2次课）
1.为什么要拿Python来作范例？对于我们一些不懂Python的人来说有点偏了！
2.软件编程规范除了ppt上的，还有其他的吗？
3.ppt上的那些范例对于其他语言是全部适用的吗？
（真的不知道怎样回答！！）
第2章 编写高质量代码（第3次课）
1.结对编程中，两个人解决问题的方法一点都不一样，要怎样协作呢？
2.代码检查具体的检查方法和依据？
-
ncsim检查主要是一些编译检查，保证代码能够正确编译。
-
nlint检测会检查代码的语法语义错误，可实现对代码的时钟、命名规则的检查，确保了程序的健壮性。
-
cdc主要是做跨时钟域路路径的分析。
3.代码静态优化具体有什么措施？
-
改进算法。
- 在源程序级上等价变换。
- 充分利用系统提供的程序库。
-
编译时优化等。
第3章 单元测试（第4次课）
1.单元测试的重要性？
单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。领测国际提示从如下几个方面就可以看出单元测试的重要性在何处。
- 时间方面：如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。
- 测试效果：根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。
- 测试成本：在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。
- 产品质量：单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。
综上所述，单元测试是构筑产品质量的基石，我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间，我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来!
2.测试用例的设计标准是什么？
-
需求点100%被覆盖
-
被测功能点或控件100%被覆盖
-
必须验证正确性操作、正常数据和可能导致出错的数据、操作
-
有数据值域的必须考虑数据值域覆盖：边界值、等价类
-
所有边界值都必须覆盖
-
等价类必须包含有效和无效等价类
-
等价类各子类不存在交错以避免冗余
-
等价类的使用避开边界值
-
所有等价类都必须覆盖(等价类数量过多导致超过测试成本的，优先考虑有效等价类，然后根据数据使用频率、几率高低分优先级，高级优先覆盖，同时考虑自动化测试)
-
用例可以直接执行或易于准确执行
-
用例中的数据或描述不存在二义性或多义性，不会因执行人不同而产生不同执行结果
-
用例有明确的预期结果能够用于准确判断是否符合要求
-
集成用例必须包含打开系统和退出系统的验证
-
业务用例必须考虑不同模块数据和业务的一致性
-
含数据库部分必须包括数据库的验证
-
核心功能点必须被覆盖多次
-
用例设计必须提供设计思路、策略以便于评审和将来复用(含用例设计方法思路、数据分类等)
3.黑盒测试与白盒测试有共同处吗？有就写出来。
-
测试方式不同
-
测试目的不同
-
测试原则不同
第4章 软件开发过程（第5次课）
1.软件过程模型中各模型的适用类型？
-
瀑布模型
适用范围：
-
用户的需求非常清楚全面，且在开发过程中没有或很少变化
-
开发人员对软件的应用领域很熟悉
-
用户的使用环境非常稳定
-
开发工作对用户参与的要求很低
-
增量模型
适用范围：
-
进行已有产品升级或新版本开发，增量模型是非常适合的
-
对完成期限严格要求的产品，可以使用增量模型
-
对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的
-
螺旋模型
适用范围：对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更，螺旋模型只适合于大规模的软件项目
-
RAD模型
适用范围：
-
不适合技术风险很高的开发，不适合系统需求是高性能，并且需要通过调整构件接口的方式来提高性能的产品开发。
-
适用于工期紧张，又可细分功能，还要有合适的构件
-
迭代模型
适用范围：
-
在项目开发早期需求可能有所变化
-
分析设计人员对应用领域很熟悉
-
高风险项目
-
用户可不同程度地参与整个项目的开发过程
-
使用面向对象的语言或统一建模语言
-
使用CASE工具
- 具有高素质的项目管理者和软件研发团队
2.软件过程模型中各模型的优点？
- 瀑布模型
优点：
-
它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。
-
虽然有不少缺陷但比在软件开发中随意的状态要好得多。
- 增量模型
优点：
-
采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源
-
如果核心产品很受欢迎，则可增加人力实现下一个增量
-
可先发布部分功能给客户，对客户起到镇静剂的作用
- 螺旋模型
优点：
-
设计上的灵活性,可以在项目的各个阶段进行变更
-
以小的分段来构建大型系统,使成本计算变得简单容易
-
客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
-
随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互
-
客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
- RAD模型
优点：
-
开发速度快，质量有保证
-
对信息系统特别有效
- 迭代模型
优点：
-
降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费
-
降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙
-
加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率
-
由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些
3.软件维护和管理的内容？
软件维护的内容 有四种：校正性维护，适应性维护，完善性维护和预防性维护。
-
校正性维护：指为了识别和纠正错误，修改软件性能上的缺陷，进行确定和修改错误的过程。占整个维护工作的21%.
-
适应性维护：为了使本软件适应硬件和软件的变化而修改软件的过程称为适应性维护。占整个维护活动的25%。
-
完善性维护：增加软件功能、增强软件性能、提高运行效率而进行的维护活动称为完善性维护。占整个维护工作的50%.
-
预防性维护：为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。只占4%。
第4章 软件开发过程（第6次课）
1.敏捷开发的特点？
-
精确要求，精准成果。
-
质量有保障。
-
客户合作胜过合同谈判。
-
投资回报率高。
-
较高的速度是敏捷开发最显著的优点之一。
2.敏捷开发的要求？
-
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
-
即使到了开发的后期，也欢迎改变需求。
-
经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
-
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
-
围绕被激励起来的个人来构建项目。
-
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
-
工作的软件是首要的进度度量标准。
-
敏捷过程提倡可持续的开发速度。
-
不断地关注优秀的技能和好的设计会增强敏捷能力。
-
简单使未完成的工作最大化。
-
最好的构架、需求和设计出自于自组织的团队。
-
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
3.敏捷开发方法有哪些？介绍一下。
-
极限编程（eXtreme Programming，XP）
极限编程的思想源自 Kent Beck 和 Ward Cunningham 在软件项目中的合作经历。在这里，“eXtreme”的意思是希望将软件开发过程中一些好的方法发挥到极致。XP 注重的核心在于“沟通、简明、反馈和勇气”，用一句话来概括 XP 的这 4 个核心价值观就是：通过充分的交流和沟通，使产品的设计尽可能简单明了；同时通过客户经常性的反馈，生产出符合客户要求的软件产品，并且有勇气迎接需求的改变。
-
RUP（Rational Unify Process，Ratioanl 统一过程）
RUP 试图总结现代软件开发过程中所有好的实践经验，形成一种有很强适应性的软件开发过程。它包括了软件开发中的 6 大经验，分别是：迭代式开发、管理需求、可视化建模、使用基于组件的软件体系结构、验证软件质量、控制软件变更。
-
Lean（精益软件开发方法）
精益生产的概念首先出现在制造业中，由日本的丰田公司提出。大规模制造理论认为，一定程度的浪费、一定程度的废品是正常的和被允许的。而在软件开发中，资源浪费、成本居高不下也同样成为软件开发的一大障碍。处于变革的十字路口的软件开发行业，总是能不断地从其他行业中寻找可借鉴的理论。这种借鉴来的思路就被称为精益编程（Lean Programming）。
-
Scrum
Scrum是一种灵活的敏捷软件开发管理过程，这个名词来源于英式橄榄球。Scrum 方法由 Ken Schwaber 和 Jeff Sutherland 提出，它将软件开发团队比作橄榄球队，全队有明确的最高目标——发布产品的重要性高于一切，团队高度自治，成员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着最高目标推进，而且每隔 2～4 周，每个团队成员都能看到能实际工作的软件，并且据此决定是发
布这个版本还是继续开发以加强它的功能。
第5章 团队开发管理 （第7次课）
1.怎样才能减少沟通的复杂程度？
-
明确沟通目的
-
多听、多看对方的反馈
-
沟通一定要闭环
-
传达的观点要明确、佐证要清晰
-
别让情绪掩盖了信息
2.软件项目估算的方法有哪些？
-
自顶向下的估算方法
-
自底向上的估算方法
-
差别估算法
-
根据实验或历史数据给出软件项目工作量或成本的经验估算公式。
3.怎样才能组成高效率的软件开发维护团队？
-
选拔或培养适合角色职责的人才
-
建立共同的工作框架、规范和纪律约束
-
自我管理
-
学习国外成功经验
第6章 敏捷开发与配置管理（第8次课）
1.敏捷估算扑克的步骤？
-
分牌：为每名参与估算的成员分一组牌，每副牌可供4人估算使用；
-
讲解：产品负责人为大家讲解需要估算的任务，团队成员可针对该任务进行讨论并提出问题，对该任务有一定的了解；
-
估算：团队每个成员同时出牌，代表自己的估算工时，估算过程不可互相商讨，团队结合项目自身情况选用合适的估算规则，取得估算值。
2.用户故事的重要性？
-
因为故事展示出用例或者传统需求方法的一些相同特征，故事区别于这些早期的需求技术就变得非常重要。这些差异使得故事具有很多的优势：用户故事强调口头交流。字面语言经常是含糊的，无法保证客户和开发者以相同的方式理解。有时我们认为文字是准确的，但是实际上不是。
-
对计划有益，故事的另一个益处是使项目计划能够被容易的使用。每个用户故事都进行了困难程度和时间上的估计。另一方面，用例通常太大以致于难以给出有用的估计。故事一般在敏捷项目中的单个迭代实现，而用例一般会分成若干次迭代。
3.Scrum框架包括哪些内容？
-
3个角色
-
产品负责人（Product Owner）
-
Scrum Master
-
Scrum团队
-
3个工件
-
产品Backlog（Product Backlog）
-
SprintBacklog
-
燃尽图（Burn-down Chart)
-
5个活动
-
Sprint计划会议（Sprint Planning Meeting）
-
每日站会（Daily Scrum Meeting）
-
Sprint评审会议（Sprint Review Meeting）
-
Sprint回顾会议（Sprint Retrospective Meeting）
-
产品Backlog梳理会议（ Product Backlog Refinement）
- 5个价值
-
承诺 – 愿意对目标做出承诺
-
专注– 把你的心思和能力都用到你承诺的工作上去
-
开放– Scrum 把项目中的一切开放给每个人看
-
尊重– 每个人都有他独特的背景和经验
-
勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
第7章 需求获取（第9次课）
1.需求的分类及其介绍？
-
业务需求 （Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
-
用户需求 （user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
-
功能需求 （functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
-
系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
2.需求工程师的目的？
需求工程师的主要任务为以下5条：
-
根据产品规划或者项目要求，协同市场、销售策划等部门分析、明确、优化用户需求，并根据原始需求编写需求分析报告,并协同技术部设计原型；
-
识别需求必要性，并能提出合理的改进建议，为业务部门提供性价比更好的解决方案；
-
在用户和研发之间协调需求细化；
-
评估需求的成本与效益；
-
收集用户对系统的满意度及各种反馈意见，定期汇总并建议改进方案
3.需求获取技术有哪些？各有什么好处
-
用户访谈：这是最基本的需求获取方法，包括结构化与非结构化两种。结构化就是指事先准备一些问题，有针对性地进行，而结构化只列出粗略的想法，根据访谈的情况进行发挥。事实上要结合两者。
-
用户调查：如果客户面较广，则不可能一一访谈。这就要借助于“用户调查”了。通过事先精心准备的问题，发到有关人员手中。缺点是用户可能不太重视，而且问题的设计不能面面具到，不够灵活，获得的信息不够全面。缺乏面对面的交流。
-
现场观摩：走到客户的工作现场，一边观察，一边听用户的讲解。甚至可以安排人员跟随客户工作一段时间。这样使得分析人员可以更直观地理解需求。
-
文档考古：对于一些数据流比较复杂，工作表单较多的项目，难以通过解说或者观察来了解需求细节，这就可以借助于“文档考古”的方法。
-
联合讨论会：这是相对成本较高的需求获取方法。但也是十分有效的一种，它通过联合各个关键客户代表、分析人员、开发团队代表，通过有组织的会议来讨论需求。
