Fork me on GitHub

软件工程认知

软件工程学习【Everything is a project】

记录极客时间学习要点

  • 想法: 想法阶段通常是想要解决问题。最开始问题通常是模糊的,所以需要清晰地定义 好问题,研究其可行性,检查是否有可行的解决方案
  • 概念: 概念阶段就是用图纸、草图、模型等方式,提出一些概念性的解决方案。这些方 案可能有多个,最终会确定一个解决方案
  • 计划:计划阶段是关于如何实施的计划,通常会包含人员、任务、任务持续时间、任务 的依赖关系,以及完成项目所需要的预算。
  • 设计:设计阶段就是要针对产品需求,将解决方案进一步细化,设计整体架构和划分功 能模块,作为分工合作和开发实施的一个依据和参考。
  • 开发:开发阶段就是根据设计方案,将解决方案构建实施。开发阶段通常是一个迭代的 过程,这个阶段通常会有构建、测试、调试和重新设计的迭代
  • 部署:将最终结果包括文档发布。

    什么是工程方法?

    有目的、有计划、有步骤的解决问题的方法就是工程方法。

    #瀑布模型及软件周期
  1. 用户需求文档&可行性分析
  2. 需求分析文档
  3. 架构设计文档【系统架构文档,数据库文档】
  4. 软件开发
  5. 测试报告
  6. 运行说明和维护
    需求、设计、编码、测试 无论是瀑布模型还是其他的scrum 模型 都归根结底离不开这四个核心环节。

##瀑布模型优缺点
最大的问题就是不能及时响应需求变更,越到后期变更代价越大!
瀑布模型简单易用,前期需求明确,能开发出高质量的软件产品。

瀑布模型的衍生模型

快速原型模型

快速原型模型,就是为了要解决客户的需求不明确和需求多变的问题。
思考: 在一些公司,如果产品对于需求不是特别明确的情况下或者能预见性的以后会多变的需求,是否可以采用这样的方式呢?
虽然快速原型模型能适应多变的需求,但是代码质量往往是致命的,那么其实就需要一种方法解决。

###解决快速原型的策略

通常有两种处理策略:抛弃策略和附加策略。
抛弃策略很好理解,就是废弃掉,重新来过。附加策略则是在这个基础上进行完善。
快速原型模型即使到现在还一直有在用,用于低成本快速的确认需求。个人感觉快速原型模型主要还是集中在需求特别不确认的情况下,用于做产品交付类型的小公司,主要集中在产品经理外加点开发的基础上,有时候仅仅是产品利用axure 原型工具就能搞定。

【大瀑布-》小瀑布模型理念】 增量模型 和 迭代模型

增量模型——按模块分批次交付
每个模块有按照原有的瀑布模型,需求分析、设计、编码、测试、交付,多个开发模块可以并行。

适应场景

增量模型主要适用于:需求比较清楚,能模块化的软件系统,并且可以 按模块分批次交付。

Tip: 个人感觉在企业中,一般需求都能比较清楚,当然也不排除垃圾的产品经理,至于模块化,如果系统架构不理想也大致能从系统拆分出模块的概念,例如 用户模块、订单模块等。

迭代模型——每次迭代都有一个可用的版本

迭代模型每次只设计和实现产品的一部分,然后逐步完成更多功能。每次设计和实现一个
阶段叫做一个迭代。其实也是类似于增量模型,增量模型个人感觉模块是针对的关键点,迭代应该能上线的一个最原始的版本,虽然不完善,但是应该有好多模块。

迭代模型和增量模型的区别

增量模型是按照功能模块来拆分;而迭代模型则是按照时间来拆分,看单位时间内能完成
多少功能。

迭代模型最难的部分,在于规划每次迭代的内容和要达到的目标,如果你做的是小项目的话,并不建议使用迭代模型来开发。
个人理解: 但是感觉大部分的领导还是趋向于所谓的“结果导向” ,所以可能迭代模型偏重。

如何更好的选择过程模型?

  1. 外包的话建议采用V型瀑布模型,因为每个阶段可能都需要和甲方进行确认。

  2. 项目风险高 ,随时可能中断

    增量模型和迭代模型,同时注意风险控制!

  3. 山寨一款软件产品,希望能快速上线发布
    增量模型,但是个人感觉迭代模型也可以进行,可能原因是需求比较明确所以不太需要通过迭代模型来适应吧。

  4. 一个大型的系统

  5. 产品已经上线,需要持续的更新 迭代模型比较合适

本文欢迎转载,但是希望注明出处并给出原文链接。 如果你有任何疑问,欢迎在下方评论区留言,我会尽快答复。 如果你喜欢或者不喜欢这篇文章,欢迎你发邮件到 alonecong@126.com 告诉我你的想法,你的建议对我非常重要。

------ 本文结束感谢您的阅读! ------
0%