软件团队里除了能写代码.测试代码和画图做设计的成员,还有一类角色,不做上面这些事情但也很重要,我们叫他们项目经理--PM. PM 的M 就是 Manager: P有这几种: Product Manager, Project Manager, Program Manager   在不同的行业和公司它们的作用不一样. Product Manager: 产品经理----正确地做产品. Project Manager:  项目经理----正确地做流程. Program Manager:  微软的职位名称…

今天浅读了<构建之法>的前四章,稍微有一些个人的见解与感受 第一点即是开篇提及到的算法与数据结构这门学科开设的必要,大二上学期学习了这门课程,就我个人目前接触到的层面来看,几乎可以说用不太到课上学习的一些算法相关的知识.但是这也并不意味这算法.数据结构这门课不重要,如同一句其他行业的玩笑话所说,没有人会按书上说的情况生病,那就代表着医学不需要教科书教学吗,必然是不对的.用一个拿到多家大厂offer的学长的话来说,刷题是我们和其他竞争者拉开差距的一个重要途径,尤其是对于我们这样一所学校的学生来说…

第九章:项目经理 是讲项目经理的作用功能和重要性,书里面主要讲的是微软的PM(Programe Manager)和其他团队PM(Project Manager)的区别,还介绍了PM的能力要求以及人物,不同的PM有不同能力,一个项目有多个PM我觉得还是挺科学的毕竟每个人能力是有限,找到优秀的战斗力很重要,适当运用人才.我们的团队作业也有一个PM,作为一个PM得到大家支持很重要也要带动大家一起参与.一个无法得到团队成员支持的项目经理,大概也无法得到领导的支持. 第十章:典型用户和场景 这一章主要讲诉…

对于书中所提到的结对编程我还是有些许感受的,在大二上学期我就有和同学合作,共同完成编码.有时候可能是我来做非常非常简易的前端页面部分,然后给同学一个基础框架,让同学往框架里面填充,时而遇到问题我再来沟通解决:也有时候是我来完成与数据库的交互部分,让同学完善service层.总之就是把一个问题分解,共同完成目标,相较于个人,这种方式完成速度更快,发现问题后解决的效率也更高.其次就是老生常谈的需求分析,我自己而言做不好这方面,不太会提取主干,更多的还是根据别人的经验,需要在架构分析设计上下一定的功夫…

在阅读<构建之法>之前,我所认为的软件就是通过c,c++等语言编程,制作出的一个能满足人们操作需求的一些代码,认为一个好的软件工程师,就是能够在很短的时间之内,最快的根据需求写出几段代码程序的人,认为一个完美的软件就是能够满足人们的要求永远都不出bug. 而邹欣老师在<构建之法>绪论中提到,软件=程序+软件工程,程序是软件的基础,而软件工程师吧系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.简而言之,就是将软件开发.运营和维护的流程进行系统统一化,从而提高软件开发…

最开始听见杨老师说邹欣老师这个名字总觉得很熟悉,后来看见博客上老师的头像恍然大悟,原来机缘巧合已经在微博上关注邹老师许久,一直觉得邹老师是个很有意思的人,兴趣一定十分广泛,看了老师的书确实能感觉到邹老师是个很独特的作者. 这本书与以往的软件工程书籍相比确实不同.<构建之法>首先让我明白了软件工程到底是什么,也让我第一次觉得要对自己做出来的东西负责,让我的想法突然从一个学生变成了一个知道对自己东西负责的人(此处不敢说自己是工程师).作者前面的篇幅一直在强调团队合作,我虽然一直觉得合作很重要,但是…

对<UML>撒站需求分析的阅读现在已到达尾声,虽然读这本书是应老师的要求,但是在后期的阅读中也逐渐喜欢上这本书,在阅读的过程中不断领会需求分析与UML之间的联系,让在软件需求分析阶段有了更深的理解.在前几次的阅读中已经将全部的UNL图的概念和用法进行了学习,学习这些的根本目的还是要勇于实践.在后面的两章中组注重告诉我们具体应如何应用.学会如何从零基础开始组织需求分析工作,如何在需求分析过程中清理你的思路.体会在什么情况下使用什么样的UML图.做以前的知识做出了系统的实践. 在分析阶段自己也是该…

IT行业的创新: 1.创新的迷思: 灵光一闪现,伟大的创新就紧随其后:大家都喜欢创新:好的想法会赢:创新者都是一马当先:要成为领域的专家,才能创新:技术的创新是关键:成功的团队更能创新 2.创新的时机: 赢者通吃.螳臂当车.只先一步. 我们要遵从技术成熟度曲线:技术触发期.期望膨胀期.迷茫期.低调发展期.主流发展期 3.创新的招数: SWOT分析框架.动量和加速度.技术产品的发展周期.效能过剩和竞争的各个阶段.影响产品竞争的各种因素(产品行业的因素.公司和市场因素.团队执行因素.产品的价值因素)…

状态机图和活动图在样子比较相似,但状态机图是用来为对象的状态及造成状态改变的事件建模.我们大二学习UML统一建模语言状态机图模块时了解到,UML的状态机图主要用于建立对象类或对象的动态行为模型,描述系统中某一个对象所经历的各个状态.引起状态或活动转移的事件,以及因状态或活动转移而伴随的动作.但在以前的学习过程中,我们并没有学到过"伪状态",后经查阅知:伪状态是指在一个状态机中具有状态的形式,同时具有特殊行为的顶点.它是一个瞬时状态,用于构造转换的细节.当伪状态处于活动时,状态机还没有完…

上文中我们学习了bean加载的整个过程,我们知道从spring容器中获取单例bean时会先从缓存尝试获取,如果缓存中不存在已经加载的单例bean就需要从头开始bean的创建,而bean的创建过程是非常复杂的,本文就开始研究bean加载这部分的源码. 1. bean创建流程分析 在Spring中bean加载的逻辑是在getSingleton的重载方法中实现的: public Object getSingleton(String beanName, ObjectFactory<?> singlet…

第八章:需求分析 软件需求 人们(用户)的需求五花八门,作为一个软件团队要准确而全面地获取这些需求主要有以下四个步骤: 获取和引导需求.这一步骤也被叫做“需求捕捉”.软件团队需要为用户着想,设身处地,为用户引导出需求. 分析和定义需求.从各个方面获取的需求进行规整,定义需求的内涵从各个角度将需求量化. 验证需求.软件团队要跟利益相关者沟通,通过分析报告.技术原型.用户调查或演示等形式向他们验证软件团队对于这些需求的认知. 在软件产品的生命周期中管理需求. 对软件的需求,也可以从不同角度做以下的划…

通过阅读<构建之法>P384~391以及参考阅读杜老师给出的链接,得出一个重要的结论:软件工程师的职业道德至关重要. 软件工程的动态性和需求的前后关系,要求一个规范能对出现的新情形有较强的适应性和适用性.但是即使在这种一般性原则下,本规范也只对那些以文档记录职业道德态度并采取积极行动的软件工程师提供支持:即提供相应开发组中的个人以及整个开发组都可以求助的道德基础.本规范也帮助定义哪些是对软件工程师提出的道德上不适当的要求. 原则1  公众 软件工程师的行为应与公众的利益一致. 原则2  客户与…

1.阅读<构建之法>读后感 第八章:需求分析 需求分析,我觉得需求分析挺重要的,一个需求分析是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么.可以说,在软件工程当中的"需求分析"就是确定要计算机"做什么",要达到什么样的效果.可以说需求分析是做系统之前必做的.需求分析确定了整个团队的方向,那么怎么做好需求分析呢?有以下几个步骤:1.获取和引导需求:2.分析和定义需求:3.验证需求:4.在软件产品的生…

 <构建之法>第四&十七章读书笔记 一．         前言 再次阅读<构建之法>,愈发被其中生动有趣的举例吸引.作为一本给予软件工程学生的书籍,其不以枯燥的理论知识为核心,而是基于对知识和方法的引导.本次研读的这两章内容主要涉及了代码规范,两人结对与多人合作的团队方面等相关知识,从其中逐渐明白与人相处作业等方面的技巧与艺术.以下是我对这两章节的思考与疑惑. 二.        第四章<两人合作>. 本章主要涉及代码规范,极限编程,结对编程,两人合作不同阶段,…

本周主要对<构建之法>中的一部分进行阅读. 一.软件与软件工程究竟是什么? 本书的概论部分就指出“软件 = 程序 + 软件工程”.而我们这门课的名字就叫“现代软件工程”.其实在上课之前,我对这门课存在一定的误解,我更多地把这门课归入“程序”部分.在我原来的理解中,像电设二一样,自己学新知识(当然很多在电设一已经学过),然好以团队的形式独立去完成一个项目,只不过电设属于硬件(也包含一部分软件),而软工则纯粹是软件了. 而上课之后却和我预想的不一样.首先每周读书笔记这个就让我非常不解,有些推荐书籍…

这段时间我阅读了<构建之法>的大部分章节,包括个人技能.软件测试.用户体验和需求分析等相关内容.之前的个人作业和结对作业结束后,我们的工作重心终于转向了团队项目,作为团队中前端组的组长,我和组员们每周碰面.共同商讨团队项目细节并一起实现.因此,书中与团队项目开发有关的第五章.第六章的“团队和流程”“敏捷开发”两部分内容最令我印象深刻.受益匪浅,本次读书笔记主要记录阅读这两章的心得体会. 1.团队模式和开发流程: 团队项目的开发与团队工作模式(分工模式)和整体开发流程息息相关.我们的团队在决定开…

注:本文档已提交Github,地址是这个 欢迎大家通过PR的方式或者在本博客下留言的方式随时补充意见和建议,我们会持续更新 书中7.2.4的表7-1 MSF团队模型和关键质量目标里面提到的"出口条件"是什么意思?比如开发的出口条件是:我们是否按照功能说明完成了各项功能. 书上8.8.3提到了一个软件团队一开始预计每次天做30小时工作量,做到一半时每天做15小时工作量.我自己在之前的软件编写和大作业上也常常有这样的烦恼.做到后面就要做大量的测试工作,很劳累.和针对测试出的错误修正并确保正…

项目 内容 这个作业属于哪个课程 2021春季计算机学院软件工程(罗杰 任健) 这个作业的要求在哪里 个人阅读作业#2 我在这个课程的目标是 阅读思考教材,调研软工工具 这个作业在哪个具体方面帮助我实现目标 泛读.提问.实践 Part1:阅读提问 Q1:单元测试与自动测评机相比有何优劣,能否在一定条件下被替代,或者说互补? 软件的很多错误都来源于程序员对模块功能的误解.疏忽或不了解模块的变化.如何能让自己负责的板块定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能够得到稳定的.量化的…

<构建之法>阅读有疑 在用将近五节课的时间将邹欣老师的书<构建之法——现代软件工程>第二版大致看完.虽然全书是以轻松的口吻与”移山公司”员工的一些趣味谈话来传输一些理念和思想的,但是读完并理解依旧不是一件很容易的事情,并且在这过程中我对书中的一些看法抱有怀疑的态度,现将问题所在列在下面. P68页:我不是很认同邹老师的“精通”魔方的判定方法.就好像在软件工程开发中,一个人解决了一个bug.解决了bug却不算是“精通”,还得能恢复bug,再现bug才算是懂得各中原理吗?我觉得作为一个…

[BUAA软工]第一次博客作业 项目 内容 这个作业属于哪个课程 北航软工 这个作业的要求在哪里 第1次个人作业 我在这个课程的目标是 学习如何以团队的形式开发软件,提升个人软件开发能力 这个作业在哪个具体方面帮助我实现目标 督促我阅读<构建之法>,了解软件开发的具体含义及流程 快速看完整部教材,列出你仍然不懂的5到10个问题 如果一架民用飞机上有需求,用户使用它的概率是百万分之一,你还要做这个功能么? 书的第一章使用民航飞机的安全功能举例,虽然这个功能的使用率不足百万分之一(可以理解为飞机出…

软工读书笔记  week 9                 ——<构建之法> 最近的三周我们正式开始我们的项目.然后我也把<构建之法>中的相关章节再拿出来读了一番.以下是一些感悟. 首先就是第十章“典型用户和场景”.书中提到,我们作为设计或者开发者,往往会以自己使用产品的习惯和熟悉程度来出发设计,但我们永远不能代表用户.搞一个“典型用户”会让我们考虑问题从用户的角度出发.由于我们正式开始项目后的第一周就是继续对用户做需求分析,这一章对我们有很大帮助. 我们也要考虑我们的典型用户.…

总时长近两周的结对项目终于算是结束了,马上要重新开启团队项目.于是这几天决定对<构建之法>一书中与团队项目及需求分析有关的章节进行重点阅读,希望能够从中得到启发,并运用到接下来的团队项目中去.        团队模式 团队这一部分提到了软件团队的很多模式.我认为,就我们目前的团队项目而言,更合适的应该还是“交响乐团模式”和“功能团队模式”. 先说“交响乐团模式”(吐槽一下书上给交响乐团配的图真是错误百出,当然这不是重点,只是觉得应该还是要严谨一些),我自认对一个乐团还是非常了解,在一个乐团中,…

关于阅读<构建之法>第1.2.16章的疑问与感悟 术语解释: 第2章,23页 什么是代码覆盖率? ———————————————————— 在测试中的代码覆盖率是指,你运行测试用例后,走过了多少句代码,拿这个走到过的代码除以你这个测试对象的代码行数,就是你这次测试的代码覆盖率了. 参考博客:http://blog.csdn.net/Kesa_Kong/article/details/1652341 第2章,29页 什么是“自动化”回归测试?如何实现? ————————————————————…

从chapter4至chapter6,围绕着构建过程的合作讨论构建之法,而合作与个人工作的区别却以一个微妙的问题为开端:阅读别人的代码有多难? 两人合作:(驾驶员与领航员) 合作要注意代码风格规范与设计规范,如语句分行便于单步执行.使用“匈牙利命名法”等等.这里有趣的一点是,书中认为goto为函数提供单一出口,有助于程序逻辑的清晰体现,但是一些从事教学的教授认为goto语句影响代码的可读性,尽量减少使用,二者均有一定道理.之所以如此注重代码规范,非常重要的一个因素就是错误处理往往需要项目80%的…

项目 内容 课程班级博客链接 https://edu.cnblogs.com/campus/xbsf/nwnu2020SE 这个作业要求链接 https://www.cnblogs.com/nwnu-daizh/p/12369881.html 我的课程学习目标 通过学习能够了解软件工程这门学科并且能够应用它进行简单的软件开发 这个作业在哪些方面帮助我实现学习目标 在学习时要带着问题去学习并且要及时地去解决它 一.初识软件工程   上个星期我们开始了新一学期的学习,这学期的课中有一门很重要的专业课…

|||||||||||||| |:--|:--| |项目|内容| |软件工程|https://www.cnblogs.com/nwnu-daizh/| |作业要求在博客里|https://www.cnblogs.com/nwnu-daizh/p/12369881.html| |作业学习目标|通过学习<构建之法--现代软件工程>初步了解软件工程的相关知识| markdown编辑器简要教程 目录 问题一:在软件工程的整个生命周期中,软件需求分析起什么作用?软件团队是满足用户的各种需求最终保证软件的…

项目 内容 课程:北航-2020-春-软件工程 博客园班级博客 要求:阅读<构建之法>并回答问题 个人博客作业 我在这个课程的目标是 提升团队管理及合作能力,开发一项满意的工程项目 这个作业在哪个具体方面帮助我实现目标 阅读<构建之法>,了解软件工程构建过程的宏观理念 一.读<构建之法>有疑 1. 科学与工程 概论P14 希望读者看了这一节之后,不再纠结"科学"和"工程"的问题,而是在不同的学习与工作阶段,投入到最适合的项目类型中…

项目经理是负责软件项目的总体把控的角色.项目经理在项目中是一个管理者的角色,他需要对项目的9大领域进行学习,同时针对项目的范围.进度.沟通和风险进行处理,让项目能够按时保质保量的完成. 项目经理需要学习的知识很多,除了项目管理经验外,还需要根据项目情况对项目各个业务领域知识进行学习,更好的对项目的业务进行处理,这样才能够写出更好的项目解决方案说明书,更好的服务于项目.下面将项目经理需要阅读的书籍提供下载: http://pan.baidu.com/s/1hsoBYJi…

系统集成项目经理主要对弱电等项目负责.一般包括计算机网络系统,计算机设备系统,智能楼宇,机房建设等.在软考中,系统集成项目经理放在了中级,这个只能说明系统集成项目经理需要的经验没有高级信息系统项目管理师那么多. 系统集成项目管理也包括了项目管理知识体系指南中涉及到的9大领域内容.从整体.范围.时间.成本.质量.人力资源.沟通.风险和采购9个方面内容都有进行相关的描述.这个方面跟高级的信息系统项目管理师是一致的.只不过系统集成项目经理更多的是对弱电等硬件及建筑等方面进行负责,而高级信息系统项目经理…

<构建之法>第十三章到十七章有感 第13章:软件测试方法有哪些? 主要讲了软件测试方法:要说有什么问题就是哪种效率最高? 第14章:质量保障 软件的质量指标是什么?怎么样能够提升软件的质量? 第15章:稳定和发布阶段 软件的发布是要有很多步骤的,需要注意哪些问题呢? 第16章:IT行业的创新 创新一般是要有一定的基础才行的,那么怎么样能够让自己的创新能力发挥出来? 第17章:人,绩效和职业道德 我们以后如果从事这个行业的,那么需要有什么职业道德? 我读了<一个程序员的生命周期>之后…