软件过程

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。从定义来看，其实devops就是为了让开发、运维和QA可以高效协作的流程 来源： https://www.cnblogs.com/levin180425/p/11722329.html

0. 题型 0.1 内容要求 摘要字数在 400 字以内，可以分条叙述，但不允许有图、表和流程图。 正文字数为 2000 字至 3000 字，文中可以分条叙述，但不要全部用分条叙述的方式。 0.2 题目 第一题 介绍主题相关的项目 可以包含以下内容 开发背景 总体需求 采用的技术体制 （使用该技术/方法的、该项目的）动机与期望 介绍担任的主要工作 第二题 理论描述，因主题而异 第三题 如何应用到项目中的，比如用到里理论中提到的哪些概念，又是如何实现的，实施效果又如何。 遇到了哪些问题，又是怎么解决的，实施效果又怎么样？ 0.3 注意 细心审题，问的是什么 备考阶段要专心于自己最熟悉、最复杂、最高级的系统或项目，因此这个系统或项目中自己不熟悉的部分就不要准备了，免得到时候瞎扯。所以后面这种都加上了 删除线 。 1. 软件架构（体系结构）设计 2018，论软件体系结构的演化 软件体系结构的演化是在构件开发过程中或软件开发完毕投入运行后，由于用户需求发生变化，就必须相应地修改原有软件体系结构，以满足新的变化了的软件需求的过程。体系结构的演化是一个复杂的、难以管理的问题。 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。 软件体系结构的演化是使用系统演化步骤去修改系统，以满足新的需求。简要论述系统演化的6个步骤。

1 、问：你在测试中发现了一个bug ，但是开发经理认为这不是一个bug ，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试 可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试 可以包括但不限于一下几个方面： 页面是否风格统一，美观

基础题（65分） 1、什么是需求？需求有哪些来源？（3分） 答：需求的分类：直接需求（用户直接需求告知要求）和间接需求（行业需求要求）；需求的定义：准确的描述用户需求； 来源：行业、用户、团队、运营、客服、自己（调研反馈、数据分析、竞品分析）；数据分析：产品功能使用情况，如行业报告、产品后台数据等挖掘用户需求；调研反馈：通过市场调研或用户调研等方式挖掘用户真实需求；竞品分析：确立竞品分析的目的，然后分析竞品的功能和内容都有什么，通过与竞品的对比得出自身产品的需求； 直白点说：01：来源客户要求；02行业要求；03公司内部分析的需求； 2、为什么说需求需要测试，如何测试？（4分） 答：需求是标准，贯穿整个项目，是项目中最重要的标准，必须经过多方面（技术、角色：用户、产品、测试、开发）测试，才能合理安排项目进度和技术分析设计，确保需求符合用户要求和课实现。 测试方法：01评审，参加人员（用户、产品、测试、开发）；02场景和技术模拟，确保可实现；03行业调研； 3、单元测试的定义？测试意义是什么？（3分） 答：指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块

问题一： 第一章中陈述了软件工程的目标是创造足够好的软件 。那么，何种软件才是足够好的，是否有客观评价的标准，我们在开发过程中应以什么样的标准为参考？ 问题二： 第三章关于初级软件工程师的成长提到了五个方面的内容， 1.积累软件开发相关知识，提升技能技术，2.积累问题领域的知识和经验，3.对于通用的软件设计思想和软件工程思想的理解，4.提升职业技能，5.实际成果。 然而，作者又在49页的职业发展中提到了考级之路，两者在工程师的发展过程中，孰轻孰重？应以哪方面为主？两者之间又有怎样的关系？ 问题三： 第四五章中提到了两人合作以及团队模式的问题，面对一个软件项目如何选择团队模式，如果在开发过程中，团队里两两之间的磨合时间过长，导致开发速度缓慢，应如何应对？团队模式定下后，如果发现不合适，要不要及时更改，还是在观望一段时间？如何处理开发时间和团队磨合之间的矛盾？ 问题四： 第七章中讲了MSF的基本原则，不难发现，九条之中有三条和沟通有关，分别是第一条：推动信息共享与沟通，第八条：学习所有的经验和第九条：与客户合作。 然而，在实际的项目开发中，团队中人数越多，沟通所花费的时间成本越多，那么，最大的开发效率和人数有何种关系，是与人数正相关吗？如何达到开发效率的最优化？ 问题五： 书中第九章讲解了关于PM的相关知识，详细的阐述了PM的职责和能力要求，但在实际中

软件质量保障的体会 问题1答案 软件开发过程中的包含的风险控制，项目中间阶段的交付质量的代价，项目管理工具的因素，软件开发成本的控制，内部质量指标的完成情况。这些都是需要注意的！ 问题2答案 1、 计划： 项目范围、项目质量、项目时间、项目成本的确认。 项目过程/活动的标准化、规范化。 根据项目范围、质量、时间与成本的综合因素的考虑，进行项目的总体规划与阶段计划。 各项计划得到上级领导、客户方及项目组成员认可。 2、 组织： 组织项目所需的各项资源。 设置项目组中的各种角色，并分配好各角色的责任与权限。 定制项目组内外的沟通计划。（必要时可按配置管理要求写项目策划目录中的《项目沟通计划》） 安排组内需求分析师、客户联系人等角色与客户的沟通与交流。 处理项目组与其它项目干系人之间的关系。 处理项目组内各角色之间的关系、处理项目组内各成员之间的关系。 问题3答案 个人认为QA是必要的 QA是团队灵魂。 PS(没啥可说的了) 来源： https://www.cnblogs.com/papapa613/p/11580229.html

一般情况下，企业开发软件时会按照基线和定制两块并行方式执行项目开发工作。无论什么公司，都需要遵从一套成熟的产品研发过程体系，才能做出质量较好的产品。因此，如果出现项目较多的情况，应该合理地安排基线和定制之前的里程碑，让基线产品能够尽量多地收集用户的通用型需求，为定制项目进度实现技术支撑，减少定制项目中大量更改代码、需要新增模块情况发生。此外，产品研发过程体系也需要按照业务实际时间要求变化，不要拘泥于一定要按照瀑布方式，或是敏捷方式进行管理，凡事都需要找到契合自己的方式。 【这里以一个基线产品开发过程作为流程解释基础，需要注意的是，以下说描述的各个阶段，在项目执行前要明确各个阶段的目标、指定计划、及时沟通，并确保各个时期所有成员对项目理解一致】 项目启动会 项目启动会的目标是明确该产品开发项目的目标。目标不是孤立存在的，目标与计划相辅相成，目标指导计划，计划的有效性影响着目标的达成。所以在执行目标的时候，考虑清楚自己的行动计划，怎么做才能更有效地完成目标，是每个人都要详情清楚的问题，否则，目标越是不清晰或是过高，都会影响项目的实际结果。 项目启动会需要说明项目目标、阶段划分、组织结构、管理流程等关键事项，并将这些内容写入 PPT（最好是有固定格式和范文，让团队内部或者公司内部共同遵守规范），需要大家达成一致。对于关键角色任命，事前也需要听取相关领导和项目主要干系人的意见。 用户需求

来源：https://blog.csdn.net/Rong_Toa/article/details/80771976 第一章 软件工程概论 1．什么是软件危机？ 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题表现在以下几个方面： (1)用户对开发出的软件很难满意。 (2)软件产品的质量往往靠不住。 (3)一般软件很难维护。 (4)软件生产效率很低。 (5)软件开发成本越来越大。 (6)软件成本与开发进度难以估计。 (7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。 2．为什么会产生软件危机？ (1)开发人员方面，对软件产品缺乏正确认识，没有真正理解软件产品是一个完整的配置组成。造成开发中制定计划盲目、编程草率，不考虑维护工作的必要性。 (2)软件本身方面，对于计算机系统来说，软件是逻辑部件，软件开发过程没有统一的、公认的方法论和规范指导，造成软件维护困难。 (3)尤其是随着软件规模越来越大,复杂程度越来越高,原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出，技术的发展已经远远不能适应社会需求。 3．怎样克服软件危机？ (1)充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法，特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训

软件 软件是计算机系统中与硬件相互依存的部分，它是包括程序、数据及相关文档的完整集合。 软件危机 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 软件工程 软件工程是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。 软件生存周期 软件生存周期是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程，一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段。 软件复用 软件复用就是利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统。 质量 质量是产品或服务满足明确或隐含需求能力的特性和特征的集合。在合同环境下，需求是明确的；在其他环境下，隐含的需求需要识别和定义。 质量策划 质量策划包括产品策划、管理和作业策划，以及质量计划的编制和质量改进的准备工作。 质量改进 质量改进是以最求最高的效益和效率为目标的持续性活动。 质量控制 质量控制是对流程和产品的符合性的评估，独立分析不足并予以更正使得产品与需求相符。 质量保证 质量保证是有计划的和系统性的活动，它对部件或产品满足确定的技术需求提供足够的信心。 软件质量 软件质量是指明确声明的功能和性能需求、明确文档化的开发标准、以及专业人员开发的软件所具有的所有隐含特征都得到满足。 正式技术复审

软件过程模型 分类： 瀑布模型、 增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型、形式化方法模型 瀑布模型： 优点： 容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。 不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或3个阶段中，很难评估真正的进度状态;当接近项目结束时，出现了大量的集成和测试工作:直到项目结束之前，都不能演示系统的能力。 在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。 缺点： （1）开发过程一般不能逆转，否则代价太大； （2）实际的项目开发很难严格按该模型进行； （3）客户往往很难清楚地给出所有的需求，而该模型却要求如此。 （4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。 适用于： （1）用户的需求非常清楚全面，且在开发过程中没有或很少变化； （2）开发人员对软件的应用领域很熟悉； （3）用户的使用环境非常稳定； （4）开发工作对用户参与的要求很低。 它是以文档作为驱动、适合于软件需求分明的软件项目的模型 增量模型： 优点： 作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点: （1）第一个可交付版本所需要的成本和时间很少; （2