网站建设收费标准教程,百度应用app下载,网站运营管理主要内容,近三天发生的大事此博客用于记录2020年9月26日每日分享#xff0c; 软件工程中的集中常见模式#xff0c;瀑布模型#xff0c;敏捷开发等 日期#xff1a;2020年9月26日 主题#xff1a;
讨论讨论怎么使用软件工程的思想来解决问题软件工程中的集中常见模式#xff0c;瀑布模型#xff… 此博客用于记录2020年9月26日每日分享 软件工程中的集中常见模式瀑布模型敏捷开发等 日期2020年9月26日 主题
讨论讨论怎么使用软件工程的思想来解决问题软件工程中的集中常见模式瀑布模型敏捷开发等 文章目录软件工程常见的开发模型瀑布模型敏捷开发小结软件工程 软件工程是一门用工程化方法解决软件项目问题的学科其本质也是一门工程学科这门课的知识在学完后不仅可以应用在软件项目中还可以应用于日常生活中遇到的一些问题。 Everything is a project。 有目的、有计划、有步骤地解决问题的方法就是工程方法。 想法想法阶段通常是想要解决问题。最开始问题通常是模糊的所以需要清晰地定义好问题研究其可行性检查是否有可行的解决方案。概念概念阶段就是用图纸、草图、模型等方式提出一些概念性的解决方案。这些方案可能有多个最终会确定一个解决方案。 计划计划阶段是关于如何实施的计划通常会包含人员、任务、任务持续时间、任务的依赖关系以及完成项目所需要的预算。设计设计阶段就是要针对产品需求将解决方案进一步细化设计整体架构和划分功能模块作为分工合作和开发实施的一个依据和参考。开发开发阶段就是根据设计方案将解决方案构建实施。开发阶段通常是一个迭代的过程这个阶段通常会有构建、测试、调试和重新设计的迭代。发布将最终结果包括文档发布。 常见的开发模型
瀑布模型 严格按照一定的流程开发需求分析-设计-编码-测试部署这样的流程开发每个阶段都有相应的产出。但是当客户的需求变化了就不得不重新来一次从头到尾的分析灵活性较差。 瀑布模型的优缺点 你会发现瀑布模型其实跟我们传统的建筑建造方式非常类似。我们拿盖房子的过程来看看瀑布模型。
客户想要盖一栋房子初步的想法。
客户一开始可能没想清楚想要什么样子的房子。客户对需求还不清楚施工方开始找客户确认用途是什么要个几层的房子什么建筑风格希望什么时间完工预算多少。问题定义施工方根据客户提的需求对比工期和预算评估是不是值得做。可行性研究施工方评估后觉得可行于是和客户签订合同约定价钱和工期。立项制定项目计划施工方开始跟客户沟通确认需求例如每层户型如何将来的装修风格等。需求分析确认完需求后施工方开始出建筑施工图还画了漂亮的建筑效果图。系统设计和 UI 设计施工方按照设计图开始施工。程序编码这期间如果客户去参观施工情况客户只能看到毛胚只有最后施工完成才能看到最终样子。在中间客户看不到结果只有最后能看到结果原定二层是两个卧室在房子施工过程中突然客户说两个卧室不够要改成三个卧室。这意味着施工方要对施工图重新设计很多已经建好的房间要拆掉重建。瀑布模型是很难响应需求变更的而且越到后期代价越大工程质量检查人员对施工结果进行质量检测如果不满足质量要求需要修改。测试最后验收通过后客户入住。上线 所以你看用瀑布模型开发软件就像建筑工程里盖房子一样简单和自然。每个阶段都有侧重的事情就像需求阶段专注于搞清楚需求编码阶段专注于实现。 最重要的是这种编码前先设计、编码后测试、整个过程重视文档的方式开发出来的产品质量相对是有保障的。 但用瀑布模式开发也存在一些问题。 最大的问题就是不能及时响应需求变更越到后期变更代价越大。另外通常要到最后阶段才能看到结果是什么样子。 敏捷开发
你如何理解敏捷开发 敏捷开发更多的是一种思想开发当中注重“人”作用更多的关心客户合作团队之间的交流之类的 各种敏捷框架、方法论和工具就像是“术”告诉你敏捷开发的方式而敏捷则是“道”是一套价值观和原则指导你在软件项目开发中做决策。
什么是敏捷开发详解2
如果用敏捷的方式盖房子 客户想要盖一栋房子初步的想法。
产品经理和客户进行了初步的沟通把用户的需求写成了一个个用户故事用简单的用户故事代替繁重的需求文档例如 作为一个上班族我想要一个卧室以便于休息 作为一个家庭主妇我想要一个厨房以便于做饭。 施工人员根据用户故事和客户进一步沟通客户合作高于合同谈判然后对用户故事进行设计和实现每个用户故事开发时还要给一个测试机器人编写测试脚本让机器人可以自动测试大量采用自动化测试并且做好的用户故事可以随时被测试验收随时发布持续集成每个 Sprint 四个星期时间时间盒子迭代时间固定第一个 Sprint 搭了个草棚一张床就是卧室厕所就挖了一个坑厨房还来不及搭建每个 Sprint 会选择高优先级的用户故事屋顶还在漏水每个 Sprint 会定期发布客户可以随时看到可用版本即使还不完整第二个 Sprint 有了简易厨房同时修复了屋顶漏水的毛病每个 Sprint 不仅完成用户故事还会修复 Bug第三个 Sprint 升级成了小木屋但是忘记加上窗户敏捷推崇自动化测试但可能会测试不完备第四个 Sprint 升级成了砖瓦房窗户也开好了客户可以入住。但是这时候客户发现一家三口的话完全不够用需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室响应变化高于遵循计划第五个 Sprint升级成了 3 个卧室升级过程中把厨房下水道弄坏了迭代过程中可能会导致质量不稳定第六个 Sprint修复了下水道的问题房子也装修好了迭代中不断完善 客户验收使用上线。 敏捷开发对团队成员的要求较高可能某个小功能从需求分析设计编码测试都需要你独立开发如果客户不愿意配合你那么敏捷开发也很难运行起来 其他几个模型因为用的不是特别多增量模型螺旋模型用的不是特别多所以这里只简单地列出他们在哪些场景常见其他的会把部分资料发到群里大家有空的时候一起学学吧。
小结 根据项目特点选择好合适的开发模型可以让你事半功倍降低项目风险提高项目开发效率控制项目成本。比如说
一个以确认需求为主要目的的项目就可以不用花太多时间在代码质量上面低成本、高效做出来才是最重要的一个高风险的项目则可以采用螺旋模型出现问题及时止损一个很长时间加班加点却一直没法上线导致士气低落的项目可以改成增量模型先上线一个小模块让大家看到成绩提升士气然后再迭代逐步上线其他模块。 快速原型模型不见兔子不撒鹰。期初不考虑质量、架构用最快的速度见效并向用户确认需求。经过几轮直观、快速的反馈把需求确定下来。接下来既可以抛弃原型用瀑布精密重构也可以在模型基础上完善。优点是快速有效的确认需求。不足难以有效应对后续的需求变更。 增量模型分而治之。将大系统横向拆分成相对独立的若干小模块每个模块采用瀑布模式分批次交付。优点是较快见到成果且能够及时了解项目进展。不足是存在需求明确、系统可拆分、交付可分批等适用条件。 迭代模型罗马不是一天建成。把软件项目纵向划分成若干阶段从核心功能入手逐渐深化、细化直到满足用户的全部需求。每个阶段都是一个瀑布都要在前一阶段成果基础上加工、打磨。优点是快速满足基本需要并体会软件演进的快感。不足是需求演化具有不确定性会导致代码冗余、系统重构风险、项目周期不可控。
