扫码阅读
手机扫码阅读
读<软件工程的事实与谬误>所得

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

本摘要基于一位读者分享的阅读体验,该读者偶然购买了一本关于软件工程的书籍,起初并未立即阅读,但最终在火车上完成了阅读。他深受启发,尤其是书中关于软件开发和维护的13个事实。以下是这些事实的总结:
- 在软件工程的核心三要素(人、过程、技术)中,人才是最关键的。
- 优秀的程序员的效率可以比较差的程序员高出28倍,但薪酬差距并不显著,因此重要的是雇佣最优秀的人才。
- 大多数软件工具对效率和质量的提升只有5%-35%。
- 在明确需求之前进行估算是不准确的。
- 在预测时应依据理性而非政治。
- 技术人员通常比管理人员更早地意识到项目失控的情况。
- 成功的大规模软件复用需要在特定领域内实施。
- 软件复用需要遵循3倍法则:开发可复用的组件要比使用这些组件难三倍,且在收录组件之前应在三个应用中进行试用。
- 问题的复杂性增加25%,解决方案的复杂性会增加100%。
- 软件开发80%的工作是智力活动,20%是文书工作。
- 应从最困难的部分开始设计软件。
- 设计和编码工作不应轻易分离。
- 软件维护成本占软件总成本的60%,而功能增强则占维护成本的60%。
这些观点提供了对软件开发和维护过程的深刻理解,读者计划重新阅读该书以进一步吸收和理解书中的概念。
想要了解更多内容?


麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 194.1K
麦哲思科技任甲林的其他文章
敏捷方法中采集的度量数据
在敏捷方法中,要求度量的数据少之又少,可谓简单实用:规模:(1)故事点:用以估算工作量、度量开发效率。工作量: (2) 计划的工作量:用以排定项目计划。 (3) 剩余任务的计划工作量:用以跟踪项目进展。效率:(4)开发速度:每次迭代完成的需求的规模(如故事点),用以估算项目需要的迭代次数。其他度量元根据项目组的实际情况,可以由项目组自己定义。
我说CMMI 2.0 之:原因分析与解决方案
原因分析与解决方案(CAR)是对选中的现象识别原因,并采取纠正措施或预防措施。 基本的思想:组织内的好事和坏事都可以做CAR,并非仅仅是对坏事做CAR。可以在计划阶段做CAR,也可以在事情发生后再做CAR, 前者是根据估计的结果做CAR,后者是根据实际执行的结果做CAR。在做原因分析时,是从现象,到数据,然后再到原因。数据准确刻画了现象,并有助于识别真正的原因。原因有浅层次的直...
快速学习COSMIC之六:如何识别触发事件
要度量功能点,就要先识别功能处理,要识别功能处理,就要先识别触发事件。 触发事件通俗地讲就是发生在被度量软件以外的,由其他事物所产生的,要求被度量软件响应的事件。 触发事件由功能用户所感知,然后功能用户产生一个输入,来激发功能处理响应这个事件,这个输入被称为触发输入,它要么仅仅起到通知功能处理、激发功能处理的作用,要么除此之外还移动了其他的数据给功能处理。除非在一个功能处理中只有一个输
度量体系建立与COSMIC方法应用36问
Q1:度量体系建设的难点有哪些?后来是采取哪些策略解决的?A1:难点:采集哪些数据是有用的?有了数据如何抓结论出来。Q2:故障解决闭环率,类似这种KPI考核指标,有什么好的方法可以高效推进闭环呢?A2: 分析故障解决的时间分布,看看哪个环节耗时最长,是否针对这个环节有改进措施。短期见效的措施最受欢迎。Q3:度量规模给传统公司带来了哪些价值啊?A3:有了规模才可以比较生产率和质量。从软件开发方的角度,通过生产率的度量,判断当前的生产率究竟是高还是低,比较不同项目组,不同部门..
图解APH之engaging合弄
图一:Engaging合弄的目的与性能等级图二:Engaging合弄的活动 图三:Engaging合弄使用的敏捷仪式与技术
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线