构建之法—阅读随笔

第一次听说《构建之法:现代软件工程》是源自于我的老师的推荐。

本人教授软件工程也有一段时间了,在这段时间里,有过思考,有过激情,有过创新,有过尝试,有过失败,有过反思。

学情分析,课程分析,专业分析,行业分析   考虑过,思考过,但最终却只能一声长叹。这个时候看到了这本《构建之法》,在欣喜之余又些许庆幸,希望它能重新燃起我的希望。

快速浏览了一遍之后,主要是吸收理解中,结合我目前的困惑提出几个疑问

1.邹老师默认的前提是学生对编程有足够的练习量,对代码有2000行以上的基础前验并能理解一定的开发概念,但在实际教学过程中,由于课程的设置问题,由于学生学习状态的问题等诸多元素,可能有很大一部分学生很难保证这点,那么针对这样的学生如何能有个折中的教学方案让学生也能有所收获?

2.如果假设按照书中的做中学方式完成整个流程,那么学生最终体会了个人编程,体会结对编程,体会团队开发   可以说是体会了我们制定的软件工程,这其中又如何加入变化的轴线?这又何尝不是另一种的“银弹”?

3.如何在大班150人的课堂中践行这种方式?

4.需求分析放在第八章的考量是什么呢?如果放在前面是不是可以提前让学生考虑到需求的重要性呢?

5.第7章的MSF在公司中的应用多么?这种方式是否具有广义的通用性?

因为想在马上的秋季学期中尝试这种软件工程课程教学,所以希望在教学中多做探讨。

原文地址:https://www.cnblogs.com/pengxinyi/p/11194214.html

时间: 2024-10-10 00:22:25

构建之法—阅读随笔的相关文章

构建之法阅读随笔一

<构建之法>一书已完成了第一遍的阅读,接下来,我将随机抽取其中的一段进行精读. 移山公司的项目进行了一段时间,TFS上也积累了不少数据.大栓做了"数据挖掘",整理出来一些统计信息,向各位领导汇报. 大牛:哇!前端组的这位开发人员是冠军呀,他导致的Bug总量约等于所有其他成员的总和. 二柱:那是有客观原因的,你可能不知道他的工作量是最大的. 大牛:那也不能因此产生这么多Bug,而让整个团队的进度停下来吧. 二柱:别人工作得这么辛苦,我倒是不太忍心再批评他.阿超,其实我觉得我们

构建之法阅读随笔二

谁不喜欢创新呢?然而细细想来,创新就是做和以前不一样的事,并不是所有的人都喜欢"不一样".当你提出一个创新的想法时,你会得到什么回答呢?为什么我辛辛苦苦想出来的点子得不到领导或同事的赞赏?这里面有好几个原因: 个人自负/嫉妒 这个想法居然被你想出来了,老子不能接受 面子或政治因素  这个东西要是搞成了,我很没面子 优先级  我已经有10个创新的点子,没有时间和资源去处理新的想法 安全  不创新,我没有风险:要创新,我可能要失去一些东西 习惯  这不是我们做事的习惯,不符合我们一贯的原则

构建之法阅读笔记三—结对编程

构建之法阅读笔记三——结对编程 何谓结对编程,结对编程就是程序员肩并肩,平等的,互补的进行开发工作,他们使用同一台电脑,编写同样的程序,一起分析,一起设计,一块交流想法. 然而我以前却并不是这样做的,我以前喜欢在没人打扰的环境下写代码,我觉得有人在我身边看着,会影响我的思路,还有我个人自尊心比较强,不太喜欢被人指指点点,所以每次都是,我写完代码之后,自己先找自己的bug,每当自己实在找不到之后,才会请教大神,但是有时候可能由于自己的能力不足,往往一个很简单的问题,我自己发现就会花费很久的时间,让

构建之法阅读笔记四—团队开发

构建之法阅读笔记—团队开发 软件开发过程中有团队和非团队之分.其区别就在于目标利益的不同,团队中每个人的目标是一致的.共同的,会根据实际情况给每个人分配不同的任务,不会计较个人利益的得失.非团队每个人的目标都是不同的,大家都为自己的利益而奋斗. 在阅读了构建之法后,我了解到团队开发有以下的特点:1.团队开发有一致的集体目标,团队要完成这个目标.一个团队成员不一定要同时工作.2.团队成员有各自的分工,互相依赖合作,共同完成任务.还有完成一个项目开发的工作流有业务建模,需求,分析和设计,实现,测试,

构建之法阅读笔记6--敏捷开发2

构建之法阅读笔记—敏捷开发2 敏捷开发并不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发:而这种开发方式的主要驱动核心是人:它采用的是迭代式开发:敏捷开发并不是瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据:而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心.而所谓的迭代开

构建之法阅读计划

1.本学期我打算阅读关于软件工程的三本书. 在第1-4周先把构建之法阅读完成 5-9周把人月神话阅读完成 10-16周重新寻找新的书刊阅读 2.速览构建之法中的问题 (1).在之后的团体项目中,我们几人如何分配任务,分配任务之后,如果有一些比如我编程能力缺乏,如何才能真正使这个团队最后的软件质量得到保证 (2).还有如果因为分配之后你学习到只有一部分的知识,另一部分如何学习熟练 (3).我们学习的知识只是基础,到了一些企业中,所用的软件不同,会不会白学. (4).在学校的时候用什么样的团队模式最

03构建之法阅读笔记之一

构建之法阅读笔记03 遇到问题总是想弄清楚所有细节.所有依赖关系之后再动手,想的太多,没法前进,分析的就会出现错乱,或者直接动手,慢慢发现偏离的一开始的轨道,忘记了目标,这样就会产生"分析麻痹"和"不分主次,想解决所有问题",以后遇到问题应该时刻记住自己的目标,在解决问题的时候不断提醒自己,应该如何思考.越早对自己有一个清晰的定位,对自己越好,很多人只是把软件工程师当成一个工作,当成一个能挣钱养家的营生,而我想把它的当成自己投身的事业,把软件项目相关的目标作为长期的

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

构建之法阅读笔记05

2017.5.20 今天阅读的是<构建之法>第8章需求分析的阅读笔记,我们如果要开始做一个软件,最先要进行的就是需求分析,我们应该充分的了解我们这个软件是否具有前景,我们为用户提供的服务是不是用户所需要的,这一章详细的叙述了如何进行需求分析. 首先是获取和引导需求,我们应该找到软件的利益相关者,了解挖掘他们对软件的需求,引导他们表达出真实的需求.然后分析和定义需求,对各个方面的需求进行规整,定义需求内涵,从各个角度将需求量化,然后估计实现这些需求所需要的时间和资源,确定各个需求的优先级.紧接着