扫码阅读
手机扫码阅读
读<软件工程的事实与谬误>所得
8 2024-10-03
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:读<软件工程的事实与谬误>所得
文章来源:
麦哲思科技任甲林
扫码关注公众号
本摘要基于一位读者分享的阅读体验,该读者偶然购买了一本关于软件工程的书籍,起初并未立即阅读,但最终在火车上完成了阅读。他深受启发,尤其是书中关于软件开发和维护的13个事实。以下是这些事实的总结:
- 在软件工程的核心三要素(人、过程、技术)中,人才是最关键的。
- 优秀的程序员的效率可以比较差的程序员高出28倍,但薪酬差距并不显著,因此重要的是雇佣最优秀的人才。
- 大多数软件工具对效率和质量的提升只有5%-35%。
- 在明确需求之前进行估算是不准确的。
- 在预测时应依据理性而非政治。
- 技术人员通常比管理人员更早地意识到项目失控的情况。
- 成功的大规模软件复用需要在特定领域内实施。
- 软件复用需要遵循3倍法则:开发可复用的组件要比使用这些组件难三倍,且在收录组件之前应在三个应用中进行试用。
- 问题的复杂性增加25%,解决方案的复杂性会增加100%。
- 软件开发80%的工作是智力活动,20%是文书工作。
- 应从最困难的部分开始设计软件。
- 设计和编码工作不应轻易分离。
- 软件维护成本占软件总成本的60%,而功能增强则占维护成本的60%。
这些观点提供了对软件开发和维护过程的深刻理解,读者计划重新阅读该书以进一步吸收和理解书中的概念。
想要了解更多内容?
查看原文:读<软件工程的事实与谬误>所得
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
379 篇文章
浏览 58.9K
麦哲思科技任甲林的其他文章
四段论提问让ChatGPT更懂你心!
请记住这个四段论的提问模式:场景-目的-任务-验收标准!试着用这种方式来优化你的提问吧。
一个本色的朋友
有个朋友,是项目经理,我的客户,很喜欢自由,很有自己的思想,很直率,很有能力,很幽默,做项目很忙,经常出差。每次访谈他,都为他的坦率、他的幽默而大笑。很正式的访谈,都是在很轻松的氛围进行,笑过之后,却又让你去深思,他给我一种举重若轻的感觉。每次到他们公司做CMMI的运行检查,见到他的机会并不多。有一次约好了半天的访谈,结果他在外边出差,无法及时返回来,让我怅然若失。他是规矩的打破者,他喜欢按自己的
聊聊故事点背后的故事
聊聊故事点背后的故事Q1、敏捷项目能不能不估算故事点,直接估算工作量?【观点一】:在策划扑克法中先估算故事点有其固有的优点,最无法替代的优点是故事点不是绝对的工作量,避免了团队在迭代早期盲目的承诺,第一个迭代可以只估故事点不估工作量,是一种保护团队的行为,体现了敏捷以人与团队为本的文化,多数策划扑克法没用起来的团队往往也是这种文化薄弱甚至背道而驰的。此时策划扑克就不是最适合的方法...
需求人员的图解力
需求描述方法是专业的需求分析人员必须掌握的技能,在众多的方法中,图形化描述需求是重中之重,一图胜千言。在没有文字之前,人与人之间的沟通是通过图形来表达的,象形文字是造字的最主要的手段。随着时间的推移,人们越来越依赖于文字,反而弱化了用图形表达思想的技能。做为需求人员,应该将图形化表达思想的能力重新捡起来,形成自己的技能,我们称之为图解力。需求人员应该掌握哪些图形的使用方法呢?请参见下边的不完全列表
软件度量始于规模,终于规模
1 项目初期的度量 无论是甲方还是乙方,希望在项目初期,能够做出一个合理的预算,确定项目的报价。当我们有了初步需求之后,可以对需求进行快速的功能点估算,估算出功能点后,根据历史的单位规模的成本基线,得到本项目的预计成本值,然后再加上一定比例的利润得到项目的报价。 当完成了需求调研之后,我们可以采用精确的功能点度量方法度量软件的规模。有了规模,可以根据历史的生产率基线或规模与工作量之间的回归...
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线