首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >软件工程中的开发模型

软件工程中的开发模型

作者头像
阿杜
发布2019-03-15 14:32:05
6470
发布2019-03-15 14:32:05
举报
文章被收录于专栏:阿杜的世界阿杜的世界

学习笔记

今天分享的是我在学习《软件工程之美》时候记录的最新的笔记,关于软件项目开发中的开发模型。

关于软件开发模型,宝玉老师用两节课时间为我们分享了以下内容:

软件工程中的开发模型.png

瀑布模型的价值相当于工业界第一次提出流水线作业:让软件开发过程有序可控、让分工协作变得可能、让软件质量更有保障

瀑布模型最大的问题就是不能及时响应需求变更,越到后期变更代价越大。为了应对瀑布模型的问题,软件工程界衍生除了很多其他模型:快速原型模型、增量模型、迭代模型、风险模型等等。

我的感想

开发模型,就是我们开发软件的步骤和方式。

在学校做一些项目的时候,完全没有开发模型的概念,并没有很好得将软件工程课程上上学到的理论知识应用到实践中,但是我们自己摸索出了一条路——边写边改模型。

工作以后,刚开始接触的都是一件成型的系统,我们接到的任务也是BUG FIX、新功能添加等等,运气好一点能赶上系统重构的任务,但是很少有机会能从0到1构建一个软件项目。

我经历的项目比较多,这些类型的项目我都经历过:处于迭代中的项目、处于维护期的项目、对老系统进行重构、从0到1构建一个项目。在这个过程中我遇到了很多痛点:

  • 对于新入行的程序员,刚开始就进入一个迭代项目中,没有很好的全局观
  • 老系统重构的时候,如何处理好新老系统的关系
  • 如何平衡项目的周期和任务拆分
  • 如何控制和管理需求的变更
  • 如何把控项目的质量
  • 我过去使用过的开发模型又哪些,是瀑布模型,还是其他模型
  • 如何在将来的软件项目中选择合适的开发模型。

这次学习这门课的时候,我也在思考如何解决上述的疑惑。

现在很多团队都在强调自己是敏捷开发,但是敏捷开发其实不是一个开发模型,很多团队使用的其实是披在敏捷外衣下的瀑布模型,或者是迭代模型。

从需求方的角度来看,尤其是创业团队,如果一件事情已经想得很清楚,那么久说明已经有其他人做过了,那么他的价值也就不大了,因此在一个项目中,需求的变更是可以接受的,但是需要考虑时间成本、人力成本,不能将变更需求的成本一味得压到技术团队上,让技术团队用加班来应对需求的变更。

对于需求不明确或后期可能变化比较大的情况,宝玉老师给出的建议是:要看客户的情况,如果有客户,那么就可以先采取快速原型模型,挖掘和明确客户的真实需求,然后再近些重新开发或迭代;如果没有客户,也就是需要有一定的质量,那么最好采用迭代模型,先验证核心逻辑的可行性,然后在后面的迭代中近些优化。

根据宝玉老师课程中给的案例,我总结了几条开发模型选择的标准:

  • 有没有客户
  • 客户的需求是否明确
  • 项目当前的状态
  • 系统是否支持模块化
  • 客户对质量的要求
  • 客户对软件交付时间的要求

实际工作中,常常需要根据时间情况,组合使用几种模型来解决问题,因为不同的阶段有不同的需求。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019.03.04 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 学习笔记
  • 我的感想
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档