软件工程问题清单
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
|---|---|
| 这个作业要求在哪 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10618 |
| 这个作业要求在哪 | 在学习软件工程过程中发现并解决自己存在的问题 |
| 作业正文 | 下文 |
| 参考文献 | CSDN、哔哩哔哩、学堂在线、名华在线、百度文库······ |
第一章 初识软件工程
Q:软件开发的四个基本策略
A1:
- 软件复用
- 分而治之
- 逐步推进
- 优化分析
Q: 使用Python语言对学习软件工程的作用？
A1:
- 简单易学，容易操作
- 学习在于培养自己勤思考、善于思考的能力。能力包括的方面有很多，有逻辑能力、思维能力、判断能力、动手操作能力等。
Q: 目前有哪些开发模式是在实战中获得许多好评的？
A1:
- 迭代模型（stagewise model）、敏捷软件开发 (Agile development) 、混合模型（hybrid model）又叫过程开发模型，或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。
- 要开发一个商业价值高的软件，符合用户功能需求又控制成本，而且还要高效，那么肯定需要详细的完善，怎么避免结构庞杂呢？
- 调整以“合”为主，架构最精简。
Q: 软件的生命周期可以分为哪些阶段？
A1:
- 三个阶段：软件定义、软件开发、运行维护。
其主要活动阶段包括:可行性分析与计划制定、需求分析、软件设计(概要设计和详细设计)、软件实现(编码)、测试、维护等活动，其中软件开发阶段包括软件设计、实现与测试。
Q: 软件开发的基本策略中的分而治之还是有些不清楚？
A1:
- 分而治之是指把大而复杂的问题分解成若干个简单的小问题，然后逐个解决。这种朴素的思想来源于人们生活与工作的经验，也完全适合于技术领域。诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。
第二章 编写高质量代码
Q: 学习Python的就业前景？
A1:
- 相关岗位多，人才就业率高
- Python由于其简洁优美和极高的开发效率，得到了越来越多公司的青睐，公司选用Python进行网站Web、搜索引擎(Google)、云计算(OpenStack)、大数据、人工智能、科学计算等方向的开发。Python或将成为继C++和Java之后的第三个主流编程语言，因此，Python的人才就业率高
- 就业方向广
- Python强大之处就是应用比较广泛，广泛应用于：Web应用开发、图形界面开发、系统网络运维、网络编程、科学与数字计算、3D游戏开发等，其应用领域足以说明Python很牛，不得不让人感到它的强大。从事Python开发，工作机会和工作岗位及工作内容可选择的余地很多，未来发展的空间也很大。
- 人才需求量大
- 据统计，Python人才需求量每日高达5000+，但目前市场上专业Python程序员供不应求， 竞争小，很容易快速高薪就业。
Q: JAVA和Python有什么相同和区别 ?
A1:
- python虚拟机没有java强，java虚拟机是java的核心，python的核心是可以很方便地使用c语言函数或c++库。
- python是全动态性的，可以在运行时自己修改自己的代码，java只能通过变通方法实现。python的变量是动态的，而java的变量是静态的，需要事先声明，所以java ide的代码提示功能优于python ide。
- python的产生几十年了，几十年前面向过程是主流，所以用python有好多程序用的是面向过程设计方法，很多概念从c语言过来的，class在python中是后加入的，而java是为了实现没有指针的c++（当年com组件用的引用记数，java用的虚拟机），主要采用面向对象的设计方法，很多概念是oop的概念。面向过程，相对简洁直观，但容易设计出面条程序，面向对象，相对抽象优雅，但容易过度抽象。
- 在实际使用的python入门简单，但要学会用python干活，需要再学习python各种库，pyhton的强大在于库，为什么python的库强大，原因是python的库可以用python，c语言,c++等设计，再提供给python使用，所以无论gpu运行，神经网络，智能算法，数据分析，图像处理，科学计算，各式各样的库在等着你用。而java没有python那么多的开源库，很多库是商业公司内部使用，或发布出来只是一个jar包，看不到原始代码。python虚拟机因为编译性没有java的支持的好（或者说故意这么设计的），一般直接使用源码（linux），或源码简单打个包（如pyexe）。
- python有很多虚拟机实现，如cython,Pyston,pypy,jython, IronPython等等，适合用于业务语言，或插件语言，或面向领域语言，而java因为虚拟机巨大，很少用于插件语言，发布也不方便。
- java主要用于商业逻辑强的领域，如商城系统，erp，oa,金融，保险等传统数据库事务领域，通过类似ssh框架事务代码，对商业数据库，如oralce,db2,sql server等支持较好，软件工程理念较强，适合软件工程式的多人开发模式。python主要用于web数据分析，科学计算，金融分析，信号分析，图像算法，数学计算，统计分析，算法建模，服务器运维，自动化操作，快速开发理念强，适合快速开发团队或个人敏捷模式。
java的商业化公司支持多，如sap,oracle,ibm等，有商业化的容器，中间件，企业框架ejb。python的开源组织支持多，如qt,linux,google,很多开源程序都支持python， 如pyqt,redis,spark等。- python用途最多的是脚本，java用途最多的是web，pyhotn是胶水，可以把各类不相关的东西粘在一起用，java是基佬，可以通过软件工程组成几百个人的团队和你pk，商业化气息重。不过我认为还是python强大，因为可以方便调用c或c++的库，但软件工程和商业化运作没有java好，适合快捷开发。
Q: 代码静态优化具体有什么措施？
A1:
- 改进算法
- 在源程序级上等阶变换
- 充分利用系统提供的程序库
- 编译时优化
第三章单元测试
Q:单元测试的定义是什么？
A1:
- 单元测试是对软件中的最小单元进行测试和验证，通俗来讲就是代码中的一个函数或一个类，单元测试一定是白盒测试。
重要性
- 单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。领测国际提示从如下几个方面就可以看出单元测试的重要性在何处。
- 时间方面：如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。
- 测试效果：根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。
- 测试成本：在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。
- 产品质量：单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。
综上所述，单元测试是构筑产品质量的基石，我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间，我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来!
Q: 单元测试中的输入输出有哪些呢？
A1:
- 输入：被测试函数的输入参数、被测试函数需要的全局变量、被测试函数的内部私有变量、函数内部调用子函数的数据、函数内部调用其他模块的数据、函数内部调用外部服务的数据等。
- 输出：被测函数的返回值、被测试函数的输出参数、被测试函数修改的全局变量、被测试函数修改的内部变量、被测试函数增删改的数据库数据等、被测试函数进行的文件更新、被测试函数进行的消息队列的更新等。
Q:在项目中如何进行单元测试？
A1:
- 并不是所有的项目都适合进行单元测试，即使进行单元测试，也应该是一些基础底层模块或者核心模块进行单元测试；
选择合适的单元测试框架，Java中的TestNG、JUnit，Python中的Unittest、Pytest，PHP中的PHPUnit；
将单元测试集成到CI流程当中。
Q:软件单元测试和软件测试有什么区别和联系?
A1:
- 区别：软件单元测试：是指对软件中的最小可测试单元进行检查和验证。软件测试：是指使用人工或手动的方法来运行软件的过程
- 联系：软件测试包括了软件单元测试。
Q:白盒测试和黑盒测试与静态测试和动态测试之间是不是有着对应的关系?
A1:
- 静态测试：不运行被测程序，仅通过检查和阅读等手段来发现程序中的错误。
- 动态测试：实际运行被测程序，通过检查运行的结果来发现程序中的错误。
- 动态测试可能是黑盒测试，也可能是白盒测试。
Q: 测试用例的设计标准是什么？
A1:
- 需求点100%被覆盖
- 被测功能点或控件100%被覆盖
- 必须验证正确性操作、正常数据和可能导致出错的数据、操作
- 有数据值域的必须考虑数据值域覆盖：边界值、等价类
- 所有边界值都必须覆盖
- 等价类必须包含有效和无效等价类
- 等价类各子类不存在交错以避免冗余
- 等价类的使用避开边界值
- 所有等价类都必须覆盖(等价类数量过多导致超过测试成本的，优先考虑有效等价类，然后根据数据使用频率、几率高低分优先级，高级优先覆盖，同时考虑自动化测试)
- 用例可以直接执行或易于准确执行
- 用例中的数据或描述不存在二义性或多义性，不会因执行人不同而产生不同执行结果
- 用例有明确的预期结果能够用于准确判断是否符合要求
- 集成用例必须包含打开系统和退出系统的验证
- 业务用例必须考虑不同模块数据和业务的一致性
- 含数据库部分必须包括数据库的验证
- 核心功能点必须被覆盖多次
- 用例设计必须提供设计思路、策略以便于评审和将来复用(含用例设计方法思路、数据分类等)
第4章 软件开发过程
Q: 软件过程模型中各模型的适用类型？
A1:
瀑布模型
适用范围：
用户的需求非常清楚全面，且在开发过程中没有或很少变化
开发人员对软件的应用领域很熟悉
用户的使用环境非常稳定
开发工作对用户参与的要求很低
增量模型
适用范围：
- 进行已有产品升级或新版本开发，增量模型是非常适合的
- 对完成期限严格要求的产品，可以使用增量模型
- 对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的
螺旋模型
适用范围：对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更，螺旋模型只适合于大规模的软件项目ARD模型
适用范围：
- 不适合技术风险很高的开发，不适合系统需求是高性能，并且需要通过调整构件接口的方式来提高性能的产品开发。
- 适用于工期紧张，又可细分功能，还要有合适的构件
迭代模型
适用范围：
- 在项目开发早期需求可能有所变化
- 分析设计人员对应用领域很熟悉
- 高风险项目
- 用户可不同程度地参与整个项目的开发过程
- 使用面向对象的语言或统一建模语言
- 使用CASE工具
- 具有高素质的项目管理者和软件研发团队
Q: 模块化设计的优劣性？
A1:
优点
可维护性
1.灵活架构，焦点分离
2.方便模块间组合、分解
3.方便单个模块功能调试、升级
4.多人协作互不干扰
缺点
性能损耗
1.系统分层，调用链会很长
2.模块间通信,模块间发送消息会很耗性能
Q: 软件过程模型中各模型的优点？
A1:
瀑布模型
- 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。
- 虽然有不少缺陷但比在软件开发中随意的状态要好得多。
增量模型
- 采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源
- 如果核心产品很受欢迎，则可增加人力实现下一个增量
- 可先发布部分功能给客户，对客户起到镇静剂的作用
螺旋模型
- 设计上的灵活性,可以在项目的各个阶段进行变更
- 以小的分段来构建大型系统,使成本计算变得简单容易
- 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
- 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互
- 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
RAD模型
- 开发速度快，质量有保证
- 对信息系统特别有效
迭代模型
- 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费
- 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙
- 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率
- 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些
Q: 敏捷开发的特点？
A1:
- 精确要求，精准成果。
- 质量有保障。
- 客户合作胜过合同谈判。
- 投资回报率高。
- 较高的速度是敏捷开发最显著的优点之一。
Q: 敏捷开发的要求？
A1:
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。
经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个人来构建项目。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单使未完成的工作最大化。
最好的构架、需求和设计出自于自组织的团队。
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
Q: 敏捷开发方法有哪些？
A1:
- 极限编程（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章 团队开发管理
Q: 软件项目估算的方法有哪些？
A1:
- 自顶向下的估算方法
- 自底向上的估算方法
- 差别估算法
- 根据实验或历史数据给出软件项目工作量或成本的经验估算公式。
Q: 怎样才能减少沟通的复杂程度？
A1:
- 明确沟通目的
- 多听、多看对方的反馈
- 沟通一定要闭环
- 传达的观点要明确、佐证要清晰
- 别让情绪掩盖了信息
第6章 敏捷开发与配置管理
Q: Scrum框架包括哪些内容？
A1:
- 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章 需求获取
Q: 需求的分类及其介绍？
A1:
- 业务需求 （Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
- 用户需求 （user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
- 功能需求 （functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
- 系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
Q: 需求获取技术有哪些？各有什么好处
A1:
- 用户访谈：这是最基本的需求获取方法，包括结构化与非结构化两种。结构化就是指事先准备一些问题，有针对性地进行，而结构化只列出粗略的想法，根据访谈的情况进行发挥。事实上要结合两者。
- 用户调查：如果客户面较广，则不可能一一访谈。这就要借助于“用户调查”了。通过事先精心准备的问题，发到有关人员手中。缺点是用户可能不太重视，而且问题的设计不能面面具到，不够灵活，获得的信息不够全面。缺乏面对面的交流。
- 现场观摩：走到客户的工作现场，一边观察，一边听用户的讲解。甚至可以安排人员跟随客户工作一段时间。这样使得分析人员可以更直观地理解需求。
- 文档考古：对于一些数据流比较复杂，工作表单较多的项目，难以通过解说或者观察来了解需求细节，这就可以借助于“文档考古”的方法。
- 联合讨论会：这是相对成本较高的需求获取方法。但也是十分有效的一种，它通过联合各个关键客户代表、分析人员、开发团队代表，通过有组织的会议来讨论需求。
