对"构建之法“的理解和困惑】的更多相关文章

对"构建之法"的理解和困惑        本人"学沫沫"一个,对于之前的编程学习虽不大"感冒",但秉着对自己负责的态度进行了基础学习.        在这个充满代码程序的大学生活中,从"Hello Word !"到一个小程序的完整运行,总有修改无数次代码仍ERROR让我抓狂的时候,相对的,也有几经波折才显示结果的时候,虽然有时就显示出来一部分,但那时的心情简直比新番(I'm 动漫迷)每周更新时还激动.Give them a t…
对于任何一个学计算机的人来说,软件都不陌生,甚至于一个普通的朝九晚五的上班族,他的每日生活工作也都与软件有着密不可分的关系.然而,程序又是如何从一行行指尖留下的代码,机器存储的数据变成快捷高效的软件的呢?这中间我们所经历的一系列过程的总和,我们称之为软件工程. 从本科开始学习计算机,我们就不可避免的接触了形形色色的软件,了解大量的软件开发工具,我那个时候甚至没有软件工程这个概念,只认为,我们所用的软件就是开发工具编译.执行.包装.发布的产物.后来,开设了软件工程这门课程,才开始系统地接受软件工程…
<构建之法>阅读有疑 在用将近五节课的时间将邹欣老师的书<构建之法——现代软件工程>第二版大致看完.虽然全书是以轻松的口吻与”移山公司”员工的一些趣味谈话来传输一些理念和思想的,但是读完并理解依旧不是一件很容易的事情,并且在这过程中我对书中的一些看法抱有怀疑的态度,现将问题所在列在下面. P68页:我不是很认同邹老师的“精通”魔方的判定方法.就好像在软件工程开发中,一个人解决了一个bug.解决了bug却不算是“精通”,还得能恢复bug,再现bug才算是懂得各中原理吗?我觉得作为一个…
<构建之法:现代软件工程>中第2章对效能分析进行了介绍,基于的工具是VSTS.由于我教授的学生中只有部分同学选修了C#,若采用书中例子讲解,学生可能理解起来比较困难.不过所有这些学生都学习过Python,因此我就基于书中对效能分析的介绍,结合Python效能分析工具的文档以及互联网上的博客,准备了一份关于效能分析的讲座,内容如下. 什么是效能分析? 这部分的讲解和书中类似.不过有两个问题: 为什么是效能不是效率,两者之间究竟有什么区别?这是学生提出的问题.个人觉得二者之间的差别不大. 效能分析…
哲学家的宗旨是:我思,故我在 科学家的宗旨是:我发现,故我在 工程师的宗旨是:我构建,故我在 ——<工程学--无尽的前沿> 序言:珍惜角色“人”,注重实践“物” <构建之法>,精读三曲,感触良多. 曲一,语言诙谐幽默,思维独具匠心:曲二,提问勾画,思考获益:曲三,豁然开朗,又困惑不解.软件工程与“人”有不解之缘,“人”用百花齐放的实践构建软件工程.三曲之后,知识概念,不必硬背,只需循序渐进,逐步实践体验,但不得不提出如下五惑. 核心:提出困惑点,分享你我他 第 0 章  目录: 1…
实验一 软件工程的前期准备工作 在前期的准备工作以及老师上课的讲解中,我懂得了"软件=程序+软件工程"这句话的基本含义,以前只是对软件工程有一个很浅显的概念,现在在读了<现代软件工程-构建之法>这本书之后,我已经对自己以前掌握的只是有了更深一步的提升,虽然不是特别懂,但是我会在后续老师讲解的过程中慢慢的消化这些知识,通过阅读老师的博客,我深深发现自己以前对于提问尽然不懂,所谓不懂就是自己不知道某个问题,但是不知道如何更够精确的提出问题的所在,让老师同学们能够为自己答疑解惑,…
注:本文档已提交Github,地址是这个 欢迎大家通过PR的方式或者在本博客下留言的方式随时补充意见和建议,我们会持续更新 书中7.2.4的表7-1 MSF团队模型和关键质量目标里面提到的"出口条件"是什么意思?比如开发的出口条件是:我们是否按照功能说明完成了各项功能. 书上8.8.3提到了一个软件团队一开始预计每次天做30小时工作量,做到一半时每天做15小时工作量.我自己在之前的软件编写和大作业上也常常有这样的烦恼.做到后面就要做大量的测试工作,很劳累.和针对测试出的错误修正并确保正…
十一章:软件设计与实现 工作时要懂得平衡进度和质量.我一直有一个困扰:像我们团队这次做 男神女神配 社区交友网,我负责主页的设计及内容模块,有个队友负责网站的注册和登录模块,有个队友负责搜索模块,有个队友负责活动查看模块.但是一个项目是一个整体的,每一个人所负责的每一个模块都必须关联起来才能成为一个整体,例如我的主页完成了50%后,为了查看整体效果, 发给队友与他的模块连接起来,如果对方在我的程序上修改了部分,然后同时我也继续编写我剩下的内容,双方都在我那个原本完成了50%的进度模块上做了修 改…
通过阅读<构建之法>P384~391以及参考阅读杜老师给出的链接,得出一个重要的结论:软件工程师的职业道德至关重要. 软件工程的动态性和需求的前后关系,要求一个规范能对出现的新情形有较强的适应性和适用性.但是即使在这种一般性原则下,本规范也只对那些以文档记录职业道德态度并采取积极行动的软件工程师提供支持:即提供相应开发组中的个人以及整个开发组都可以求助的道德基础.本规范也帮助定义哪些是对软件工程师提出的道德上不适当的要求. 原则1  公众 软件工程师的行为应与公众的利益一致. 原则2  客户与…
5.Scrum团队成立 5.1 团队名称:喳喳 团队目标:突破渣渣 团队口号:吱吱喳喳 团队照: 5.2 角色分配 产品负责人: 112冯婉莹 Scrum Master:109张鑫相 PM项目经理:103李康梅 用户:149麦锦俊 6. 团队项目选题 项目名:昵妆(一个有关化妆的平台). 7. 阅读<构建之法>第6~7章,并参考以下链接,发布读后感.提出问题.并简要说明你对Scrum的理解. 学习附录: Scrum中文网--什么是Scrum?  http://www.scrumcn.com/a…
身在大学,却想起了在高中的生活和初中的生活,特别是初中的生活,为什么这么说呢!因为<构建之法>,看了其中的两章的内容,为什么想到了初中和高中的生活呢,因为在高中和初三的时候看的最多的就是课本,虽然有时会看不进去,但是同样会硬着头皮去看,因为要想考一个好的高中所以就认真的学习,看书.但是到了大学,可以说很少去看课本了,都开始看电子版的书了,当然看的电子版的书,就分好坏了,(其实书都分好坏,主要是看你怎么去看待它,在书中看到的是什么,是主人公的坚持不懈的努力,还是一些其他的东西!)而我就看了好几本…
<构建之法>第8.9.10章读后感  第八章重点讲了需求分析,在一个项目中,需求分析是最基础也是最重要的,只有充分了解了用户需求,我们才不会走弯路,才能做出正确的规划,保证项目的进行是按照用户的需求进行的.其中,获取用户需求的方法即用户调查,常用的用户调研方法包括: 1.焦点小组           2.深入面谈 3.卡片分类           4.用户调查问卷 5.用户日志研究     6.人类学调查 7.眼动跟踪研究     8.快速原型调研 9.A/B测试 第九章重点讲了项目经理.其实…
<构建之法>里有一个16周的软件工程课程进度设计.本文在该基本设计的基础上,围绕github.com(源码管理).travis-ci.org(持续集成).单元测试工具.日志工具.少数实用UML类型等工具的使用注解每个环节的实践示例,并在每个环节部分,提到课本里相关章节强调的软件工程知识点.教师可以参考设计,助教可以参考点评和评分涉及的关键点.要组队开发好的软件,需要优秀的程序员,优秀的工程素养,虽然这里提的都是程序之外的所有事情,然而真正要做出好的软件,优秀的程序是关键的基石,唯此,工程/工具…
<构建之法>第五章用体育运动等团队例子引出软件开发团队的形式,用更加生活化.形象化的例子让读者更能理解软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.瀑布模式:当软件行业还在年幼的时期,它从别的成熟行业借用了不少经验和模型.在那些“硬”的行业中,产品…
[BUAA软工]第一次博客作业 项目 内容 这个作业属于哪个课程 北航软工 这个作业的要求在哪里 第1次个人作业 我在这个课程的目标是 学习如何以团队的形式开发软件,提升个人软件开发能力 这个作业在哪个具体方面帮助我实现目标 督促我阅读<构建之法>,了解软件开发的具体含义及流程 快速看完整部教材,列出你仍然不懂的5到10个问题 如果一架民用飞机上有需求,用户使用它的概率是百万分之一,你还要做这个功能么? 书的第一章使用民航飞机的安全功能举例,虽然这个功能的使用率不足百万分之一(可以理解为飞机出…
以下是我看<构建之法>1-5章列出来的知识点和一些自己对部分知识的理解以及一些吐槽...和感受 1.1 软件 = 程序 + 软件工程 (软件工程 = 软件 - 程序(我知道软件是什么,也知道程序是什么,但是就是不懂什么是软件工程啊...个人觉得 软件工程 - 程序 = 0 程序 = 数据结构 + 算法 (突然觉得至今为止我们所写的作业都只是程序而还没达到软件的程度啊..就缺软件工程了..软件工程到底是啥~?! ∴软件 = 数据结构 + 算法 + 软件工程 去百度百科看了一下:(有些就直接省略了…
通过这两天时间,我粗读了<构建之法>这本书.老实说,对于这样四百多页的一本书,刚开始把这样的任务当作是一种负担,然而当我开始真正接触它时却被它幽默有趣的风格所深深吸引,它不同于以往学习的教科书晦涩难懂,书中以“阿超”为代表举了很多有趣小例子,读完让人印象深刻,不到一会儿就读了小几十页,同时也让我对软件工程这个概念有了初步的认识. 问题一: 说起来,学习编程也已有两年多的时间,然而回想这段学习,自己似乎从未对编程的内容有过深入的思考,一直以来自己似乎都停留在完成布置任务,无论代码内容如何,只要能…
-首先浏览了一遍<构建之法>这本书的前言,其中通过客观的描述性介绍了学生与学习.老师与教学.以及学习的环境.方法等等.但是对于书中前言包括正文都频繁出现的一个词语 “文档” 深表疑问.何为文档,是指带代码?还是另有其他含义. -接着看下去,第一章用前言的风格,阐述了软件含义,软件工程与计算机科学,Bug.对于软件的阶段性,个人理解来说就是软件是要一步步来提升完善.由开始的感兴趣到动手出成品再到完善维护这都是一步一步来进行的.软件工程是为了某个特定的目的而专门建立的一个项目工程,所谓工程就有一定…
软工读书笔记  week 9                 ——<构建之法> 最近的三周我们正式开始我们的项目.然后我也把<构建之法>中的相关章节再拿出来读了一番.以下是一些感悟. 首先就是第十章“典型用户和场景”.书中提到,我们作为设计或者开发者,往往会以自己使用产品的习惯和熟悉程度来出发设计,但我们永远不能代表用户.搞一个“典型用户”会让我们考虑问题从用户的角度出发.由于我们正式开始项目后的第一周就是继续对用户做需求分析,这一章对我们有很大帮助. 我们也要考虑我们的典型用户.…
在阅读<构建之法>之前,我所认为的软件就是通过c,c++等语言编程,制作出的一个能满足人们操作需求的一些代码,认为一个好的软件工程师,就是能够在很短的时间之内,最快的根据需求写出几段代码程序的人,认为一个完美的软件就是能够满足人们的要求永远都不出bug. 而邹欣老师在<构建之法>绪论中提到,软件=程序+软件工程,程序是软件的基础,而软件工程师吧系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.简而言之,就是将软件开发.运营和维护的流程进行系统统一化,从而提高软件开发…
 <构建之法>第四&十七章读书笔记 一.         前言 再次阅读<构建之法>,愈发被其中生动有趣的举例吸引.作为一本给予软件工程学生的书籍,其不以枯燥的理论知识为核心,而是基于对知识和方法的引导.本次研读的这两章内容主要涉及了代码规范,两人结对与多人合作的团队方面等相关知识,从其中逐渐明白与人相处作业等方面的技巧与艺术.以下是我对这两章节的思考与疑惑. 二.        第四章<两人合作>. 本章主要涉及代码规范,极限编程,结对编程,两人合作不同阶段,…
这几天阅读了<构建之法>中的几章,受益匪浅,刷新了很多我对软件工程的认知.这本书让我很惊喜,阅读起来不像其他书一样枯燥,有很多人物的设计,以及对话的形式,非常有趣. 第一章.概述 读完第一章了解了软件工程具体是什么,以及它与类似计算机科学等的区别,还有对bug的定义,以前觉得软件工程和计算机差不多,看了书过后才发现其中的不同,一个比较偏科研,一个比较偏实践,悟清了许多之后,还有一些不太能明白的问题: 问题1: 我看了这一段文字 “中国大陆的高校中大致有下面三种将计算机软件的机构:计算机科学与技…
本周主要对<构建之法>中的一部分进行阅读. 一.软件与软件工程究竟是什么? 本书的概论部分就指出“软件 = 程序 + 软件工程”.而我们这门课的名字就叫“现代软件工程”.其实在上课之前,我对这门课存在一定的误解,我更多地把这门课归入“程序”部分.在我原来的理解中,像电设二一样,自己学新知识(当然很多在电设一已经学过),然好以团队的形式独立去完成一个项目,只不过电设属于硬件(也包含一部分软件),而软工则纯粹是软件了. 而上课之后却和我预想的不一样.首先每周读书笔记这个就让我非常不解,有些推荐书籍…
5.Scrum团队成立 5.1 团队名称:喳喳      团队目标:突破渣渣      团队口号:吱吱喳喳      团队照: 5.2 角色分配 产品负责人: 112冯婉莹 Scrum Master:109张鑫相 PM项目经理:103李康梅 用户:149麦锦俊 6. 团队项目选题  项目名字:昵妆(一个有关化妆的平台) 理由:“昵妆”这个平台主要是向用户提供化妆品.化妆学习视频和化妆上门服务. 我们这个平台比较多功能,它不但可以满足用户可以购买化妆品的需求.还可以 教初学者如何化妆.如果有一些用…
阅读构建之法有感 利用这一周的时间,我大致了解构建之法一书,这本书带我走进了一个全新的领域.它让我以一种新的视角去了解软件产业的发展和工作,领略软件工程的独特魅力,更给出了简单易懂的方式去理解何为软件工程,软件工程要做什么,它要达到的目标是什么? 笔者站在一个从业者的角度,以其对软件发展无比的热情,去指导学校中未曾有实践经历的在校学生,或是已有工作经验的社会人员实现软件工程的真正有效流程.该书将软件工程的各个步骤进行分章节讲述,叙述清晰,脉络清楚,向我们大家讲述笔者多年对软件开发的心得体会,同时…
构建之法读后感 由于时间和书的篇幅所限,所以我没能真正通读全书,只通过网上的介绍和书内前言及目录,大概了解了构建之法是一本怎样的一本书. 这本书是由具有长达20年一线软件开发经验的邹欣老师所撰写,他以简洁生动的语言向我们阐述了软件工程的真正内涵,让枯燥乏味的课程变得易于理解.幽默有趣. 全书共分为17章,从人员到项目,从个人的技术能力到团队合作,从软件需求到软件测试,最后讲述了业界最新的实践方法.这让我对你未来的学习之路充满憧憬,希望书中的确切内容能带给我更多的惊喜. 这本书的简介令人眼前一亮,…
上一次读后感涵盖前五章的内容包括个人技术,结对合作,小组项目等.本周作业的燃尽图以及站立会议是关于<构建之法>第六章的内容,所以关于这一章的读后感涵盖在上两篇博客中. 第七章 MSF 介绍MSF(微软解决方案框架),他有自己的九条思想框架,总结起来就是勤于客户交流,保证个人价值的同时要注意与团队共进退,相信合作的力量,在保持敏捷的同时将作品价值最大化.还有重要的一点就是总结前人经验,并且把自己的经验与他人分享,利用这些经验避免一些错误,这在团队合作中尤为重要. 第九章:项目经理 项目经理分为两…
git地址 https://github.com/microwangwei git用户名 microwangwei 学号后五位 62214 博客地址 https://www.cnblogs.com/westweishao/ 作业链接 https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign/homework/7584 声明: 本次博客部分排版以及内容参考了一些博客 博客地址:https://www.cnblogs.…
本周选读<构建之法>第8章——需求分析.由于有团队项目初期调研阶段做调查问卷的经历,这一章节中很多知识点我都比较有体会.对我而言,这一章节最有价值的内容就是厘清了关于需求分析的两个误解和近10个行之有效的调研方法. 第一个误解有关需求的内涵.需求不仅仅来源于用户(软件直接使用者)的需要,还可以是企业为维持生存.追逐利润的商业模式,或者开发者在考虑到代码迁移.架构演化.平台变化时提出的技术上的需求.另一个误解有关需求分析的实现.做需求分析是一个循序渐进.应时而变的过程,不只是简单地将用户所表达的…