软件工程详细设计师竞聘演讲稿

分别结合成功和失败的案例，讲述需求分析的作用；

分别结合成功和失败的案例，讲述总体设计的作用；

分别结合成功和失败的案例，讲述详细设计的作用；

分别结合成功和失败的实际案例，讲述项目开发中，排除bug、减少项目返工的经验和教训；

分别结合成功和失败的案例，讲述验收环节方法的重要性；

讲述如何领导和管理好一个软件工作室/部门；

1.1需求分析

分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。

1.1.1失败的需求分析：

系统分析员进驻需求方时，不知道从何入手，希望需求方各部门能够配合他们完成需求分析的调研。但由于需求方部门繁忙，无暇顾及提出需求，导致需求分析无法完成。双方互相推诿，需求方各部门说开发商不懂业务需求，开发商说需求方各部门不配合。最后需求方以信息中心以红头文件的形式强制命令各部门上交需求，但是需求方各部门上交的需求既没有流程，也没有说明，有的只是几条干巴巴的需求。需求方只强调需求分析是开发商的事情，需求方只是配合。系统分析员无奈只能把需求方提出的所谓需求带回公司。经过漫长时间的讨论分析，开发商终于完成了需求分析文档，有着完整的业务流程图，数据流图，包括数据字典。拿给需求方各部门希望他们给出意见进行修改，结果需求方各部门基本上没有反馈就应付过去了，需求分析认定之后，开发商进行开发，经过漫长的开发周期，产品终于成型，给需求方演示。需求方信息中心领导希望各部门专家给做好的系统提出意见，但万万没想到的是，需求方生产部主任说这种软件根本不能用，根本不符合现有的管理流程，开发商据理力争说因为业务流程是经过你们的确认，你们是认可的了，无奈需求方信息中心的领导只好让开发商把已经开发的程序安装在各部门计算机上，参照已有的程序，重新提出需求。

造成的影响：

需求分析的不断变更，需求分析的不确定性，出现了返工的问题。
需求方的用户参与的不多，会造成产品流程无法被用户接受。
模棱两个的需求会造成项目的返工。
（用户需求增加导致过度耗费和降低质量，一般来说一个产品的真正有用的功能之后20%），画蛇添足的需求导致时间和资源的浪费
不完善的需求会导致项目计划和跟踪失误。

软件工程的理论认为，在软件的生命周期中，需求分析(Requirements Analysis)是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的，高质量的需求对软件开发往往起到事半功倍的效果，所谓”磨刀不误砍柴工”。在后续阶段改正需求分析阶段产生的错误将付出高昂的代价。”万丈高楼平地起”，需求分析设计得越好，返工率越低，开发效率越高。

在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。追求这些目标有助于提高软件产品的质量和开发效率，减少维护的困难。

1.1.2成功的需求分析案例：

2020年末我们智慧产业团队给中国移动淄博分公司设计的协同办公平台的需求分析就是一个比较完美的需求分析。开发设计之初，销售团队就把协同办公平台的模块进行了详细的模块划分，并且以静态页面的形式向客户进行了演示，客户根据实际的业务流程对系统进行了积极的反馈，极大地促进了需求分析的进度，给研发人员的总体设计，详细设计，开发奠定了很好的基础，在我们后续进行开发设计的时候，严格按照需求分档和用户反馈来开发，极大的促进了软件开发的效率。

1.2总体设计

如果说需求分析是讨论做什么的问题，那么总体设计就是讨论怎么做的问题。总体设计的任务是以需求分析为依据，着手实现软件的需求，并将设计的结果反映在总体设计的文档上。总体设计是软件开发阶段的第一步，它最终影响软件实现的成败和软件维护的难易程度。总体设计根据软件需求，设计软件系统结构和数据结构，确定程序的组成模块与模块之间的相互关系。站在全局的角度，以比较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从而用较低成本开发出较高质量的软件系统。

总体设计的具体任务是根据用户需求分析阶段得到的目标系统的逻辑模型确定一个合理的软件系统的体系结构。包括划分组成系统的模块，模块间的调用关系及模块间的接口关系，软件系统所用的数据结构或者数据库结构。关于模块的设计主要设计模块的高内聚，低耦合，独立性，安全性，抽象问题和信息隐蔽等属性。

2019年-2020年团队开发的淄博市工业信息综合平台用的是前后端没分离的springboot+thymeleaf架构。前后端开发人员都在一个项目中写业务逻辑，后端处理前后端的业务逻辑，前端只能在项目中写vue代码，开发效率相对低下。随着部门和工作室的划分，更多前端人员的加入，该系统不适合再继续用该架构开发维护，而是用springboot+vue前后端分离的架构，这样就彻底解放了前后端开发人员的思路，使其专注于自己的业务逻辑。前端不再需要向后台提供模板或是后台在前端HTML中嵌入后台代。提高工作效率，分工更加明确。前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的JSON文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。局部性能提升。通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。降低维护成本。通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。实现高内聚低耦合，减少后端（应用）服务器的并发/负载压力。即使后端服务暂时超时或者宕机了，前端页面也会正常访问，但无法提供数据。可以使后台能更好的追求高并发、高可用、高性能，使前端能更好的追求页面表现、速度流畅、兼容性、用户体验等。

1.3详细设计

根据“由外向里”的思想方法，概要设计完成之后，就要进行详细设计。详细设计确定每个模块的内部特征，即每个模块内部的执行过程。一般的详细设计主要包括模块内的场景推演，接口设计，页面设计，关联数据库表等。

由于详细设计的蓝图是给其他人看的，所以模块的逻辑描述要清晰易读、正确可靠，这样别人才能读懂。这也是常说的清晰第一的设计风格。采用结构化设计方法，改善控制结构，降低程序的复杂程度，从而提高程序的可读性、可测试性、可维护性。详细设计的原则主要采用自顶向下、逐步求精的程序设计方法。在详细设计过程中，采用逐步求精的方法降低处理问题的复杂度。使用顺序、选择和循环三种控制结构构造程序。

成功的详细设计就是相当于研发人员的开发手册，是研发人员代码逻辑的主要依据。好的详细设计可以让各个研发人员统一内部思路，达成共识，专注于自己的任务，写代码时一气呵成，同时也便于后期的维护。失败的详细设计逻辑不清晰，不严谨，它的详细设计文档读了让人似是而非，降低开发效率，增加返工率。

1.4项目开发

关于减少bug出现的经验或教训：

在日常的项目开发中，最容易出bug的逻辑那就是判断。考虑的越充分，判断的逻辑越完善，出bug的概率那便越低。在过去的工作中，我也渐渐养成了判断每一个返回值的习惯。在处理返回值的时候，必须要充分考虑返回值的状态，数据，结构等情况，在充分判断的基础之上，再对其进行处理。在java后台代码中，最常见的错误那便是空指针异常。当对空进行处理的时候，不仔细就容易出一系列的bug。如对象为空，为null的异常，数组，列表越界的异常等等都要对其进行判断处理，在写业务逻辑的基础之上，要充分考虑顺序，判断，循环等控制结构，降低出现bug的概率。

前段使用vue时，要充分考虑到组件的生命周期，数据驱动视图的渲染方式。必须充分了解beforeCreated，created，beforeMount，mounted，beforeUpdate，updated，beforeDestory，destroyed这些钩子函数作用和性质，能够最大程度的使前端代码逻辑变得清晰优美。除此之外，无论是接口的返回值还是对变量进行业务处理，都要对其进行充分的判断。只有前后端都对传递的参数进行最大程度的校验，才能最大程度的减少bug出现的可能性。

Java后台考虑到安全性，我们要对接口进行最大程度的保护。使用第三方安全框架，接口的鉴权信息，参数传递的隐蔽性等等。Java后台考虑到可扩展性和维护性，我们在接收变量的时候尽量使用实体类接收，而不是使用参数接收，这样能最大程度的减少代码的变动。除此之外，我们也把常用的函数和变量进行封装，抽取成公共的类，增加代码的复用性。

关于减少项目返工的经验或教训：

要想最大程度的减少项目返工的比例，就要从系统设计之初做好需求分析，总体设计，详细设计等。造成系统返工的因素有

隐含需求的变更；

2. 由潜在的需求引起的变更；

3. 架构选型不当引起的移植、变更；

4. 需求或设计的理解错误造成的变更；

5. 在项目范围、技术平台、技术路线决策失误造成的变更；

6. 设计的抽象不够，造成的开发过程中的浪费、合并、再抽象等工作；

7. 评审遗漏缺陷造成的变更；

8. 测试遗漏造成的反复修复工作量。

返工的因素有客户不成熟，拼命要求进度，导致项目赶进度，前面工作做的不到位，返工是必然的；项目中做需求和设计的人员的能力和经验，经验的欠缺往往导致后期才发现隐含的需求和设计的不到位；项目管理经验如果不成熟，一个重要的表现就是进度狂。要减少返工就要做到胸有成竹、处乱不惊、从容应对。按照计划行事是很重要的，项目过程中突发事情和压力是很多的，做到项目组内部阵脚不乱是非常重要的。要想在开发阶段减少项目返工的比例，就要在写业务逻辑之初充分考虑到接口的扩展性，维护性。所谓“万丈高楼平地起”，“磨刀不误砍柴工”说的就是这个。一味地追求进度，只会使得项目的健壮性越来越弱，面对bug和新需求不堪一击，甚至需要重构代码。

1.5测试验收

在写代码的过程中，bug的出现是避免不了的。我们通常为了赶项目进度，在写完业务员逻辑之后，运行测试代码能够通过，就匆匆进入到下一个模块。我们研发人员所填写的测试样式是按照我们自已预想中的来的，但是这也意味着自己的测试样例与系统的使用用户不同。为了减少项目部署之后的bug，就需要验收测试人员对系统进行各种不同的，甚至于奇怪的测试样例对系统进行测试，在项目上线之前测出bug总比项目上线之后测出bug好。

软件验收的方法主要分为白盒测试和黑盒测试，考虑到现实中验收人员的水平和测试效率，公司一般采用部署在服务器上进行黑盒测试。主要测试系统中各个模块的功能是否能正常实现，各个模块的是否能够正常关联。

验收测试是软件工程项目最关键的环节，也是决定软件开发是否成功的关键。在系统开发过程中，为了保证软件的质量，提高可靠性，必须分阶段对软件进行测试，目的是尽可能找出软件存在的错误，并加以改正。不仅要测试软件的功能和性能，还要测试软件的通用性，操作便捷性甚至于系统的界面友好型。一般的软件测试有文档审查、功能测试、性能测试、安装测试、界面测试、配置测试、加载测试、恢复测试、安全测试等，凡是需求规格说明书中有要求的，都要进行测试，确认是否满足。

1.6领导部门

关于如何领导好一个部门，我们要做好以下几点。

友好团结。在项目开发中，我们是一个team，团队的荣誉和成就是属于我们每一个人的，这也就要求我们必须互相合作。只有建立起互帮互助的良好人际关系，我们才能把更多的时间和精力投入到项目的研发当中去。
建立良好的工作学习氛围。在友好团结的基础之上，我们还要建立良好的工作和学习氛围。正如我们公司现在的代码评审，同事之间互相分享自己的代码，开拓自己的眼界，扩展自己的知识点，达到触类旁通的效果。任何系统的开发过程中都不是一蹴而就的，也有我们的知识盲点，我们只有互相团结，建立良好的工作和学习氛围，才能攻坚克难，开发出理想的系统。
以身作则，互相成就。除了以上两点，我们还要以身作则，积极学习。我们万总就是鼓励我们互相学习，每个人都有自己擅长的一面，取长补短；除此之外，也鼓励我们考证，开拓自己的眼界，丰富我们的知识点。只有每个人发挥出自己的长处，我们相互合作，项目竞争，才能建立起一个积极向上的部门和工作室。