《构建之法》第八、九、十章读后感

第八章 需求分析

通过看了本章的内容,知道了软件需求的步骤:

不同角度的划分:对产品功能性的需求:要求产品必须实现某些功能 ,对产品开发过程的需求:要求软件的开发流程必须满足某些约束条件,非功能性需求:这也叫“服务质量需求”(Quality of Service Requirement) ,综合需求:有些需求并不是单单一个软件模块就能满足

获取用户需求——用户调查

第九章   项目经理 

  在这一章节里面主要讲的是微软的PM(Programe Manager)和其他团队PM(Project Manager)的区别,个人觉得微软的PM给团队成员带来的感觉是很不一样,就好像是战友一样,工作起来也很有感觉。我们现在就缺乏那种感觉,因为有其他的作业和课程,不能完全把精力放在这个团队上面,大家要相互协调一下。

  还有介绍了PM的能力要求以及人物,不同的PM有不同能力,一个项目有多个PM我觉得还是挺科学的毕竟每个人能力是有限,找到优秀的战斗力很重要,适当运用人才。我们有人才,可是他的其他任务也比较多,我们这边照顾得少点,所以我们的工作进度比较慢。

第十章:典型用户和场景

  书本中提到的典型用户和场景这种方式来为用户考虑,我觉得很生动,可行性也很大。书本中吴石头的例子也是很生动,马上就能理解大概,还有场景也是。

提出的问题:定义典型用户和场景可以主要依靠哪一方面?

时间: 2024-10-17 04:58:07

《构建之法》第八、九、十章读后感的相关文章

阅读《构建之法》八九十章

第八章(P142 8.3) 问题:从书上可以看出用户的想法项目经理往往掌握不到,甚至南辕北辙.而程序员和项目经理的想法有时候也会有一些出入,那么是否让程序员和用户之间有一点的互动? 第九章(P173 9.1) 问题:可否理解产品负责人就是项目经理,因为他们两者就是做同一种工作. 第十章(P183 10.1) 问题:看了书,感觉用户的需求很难掌握,有时候用户的真实需求会随时间或是用户的想法而改动,那么我们要如何正确的把握住用户的真实需求?

《构建之法:现代软件工程》读后感

<构建之法:现代软件工程>读后感    邹欣老师的<构建之法:现代软件工程>书中文笔优美,图文并茂.读者可以通过这些图片加深对相关概念的理解:再次,书中内容层次分明,作者将很多知识点通过几个小点顺序列出,让读者阅读和理解起来更加的容易.语言幽默.诙谐.书中用“阿超”.“国栋”.“小飞”.“小李”等角色之间的对话来揭示一个概念的本质.这让读者觉得十分的“接地气”,同时通过他们之间风趣的对话又加快了对相关概念的理解. 这学期看了下构建之法,感觉有了许多收获.     首先,理论与实践并

《构建之法》第四章读后感--软件工程

<构建之法>第四章读后感--两人合作 1.代码风格很重要,因为良好的代码风格,有益于两人的合作甚至多人的合作. 个人认为 : 良好的代码风格的培养就是 多去阅读别人的优秀代码 ,用于提高并且培养自己的代码风格. 2.关于结对编程的重要性 2.1 结对编程能提高设计质量与代码质量 2.2 结对有益于学习交流 3.如何结对编程 3.1 主动参与讨论,提出设计方案或者问题的解决方案 4.代码的复审 复审可以提高代码质量,优化项目性能.

&lt;&lt;构建之法&gt;&gt;第八、九、十章的读后感

阅读不是仅仅为了阅读,读书的可贵之处在于思考和领悟.由于之前六.七章博文的疑问,并没有得到好的回复,于是,我将阅读的重点放在读后的心得体会,从中的收获.以及在<<构建之法>>一书学习到的处事方法. 对于软件开发的意义就是满足用户的需求,这点我非常赞成,如果一个产品没有任何用户基础,再高深的技术也是胡闹.书中详细的写到获取用户需求的种种方法和过程.因为这个快餐文化的时代,绝大部分没有耐心会慢慢地和你反映他的需求是什么,并且,即使面对面的交谈,也会出现表达和理解的误差,所以,需求分析这

构建之法的八、九、十章读书笔记

构建之法读书笔记 第八章  需求分析 这一章主要是讲需求的分析,对于一个程序项目来说,我觉得,需求是这个项目的向导,他可以决定程序项目会发展成什么样子.书里面需求这里大致分为两个:软件需求和用户需求. 软件需求:我们不仅仅要考虑到项目功能的需求,要实现的功能,还要考虑到开发过程以及非功能方面的需求,还有综合需求. 用户需求:是针对在用户这个角度,用户最需要的东西.我觉得用户需求在需求分析中较为重要,毕竟每一个要做的程序的根本目的是满足用户的要求.      所以书里面野介绍了九种获取用户需求的调

《构建之法》第七八章读后感

读<构建之法>第七八章有感 今天我读了<构建之法>的第七八章,对MSF模型和开发模式,以及需求分析有了进一步的认识. 其中第七章主要讲了一些MSF方面的知识.MSF是微软公司关于软件开发的方法论——微软解决方案框架,是微软推荐的软件开发方法.而且MSF有自己的基本原则.1>推动信息共享与沟通,这就是说把所有信息保留并公开. 2>为共同的远景而工作,要做到这一点,就要确定一个明确的目标,并且这个目标对成员每天的工作有指导作用 3>充分授权和信任,这就要我们团队成员之

构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程: 软件团队的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式: 开发流程包括:写了再改模式.瀑布模型.瀑布模型的变形(生鱼片模型.大瀑布带着小瀑布): Rational Unified Process统一流程(RUP):包括业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境: RUP的四个阶段包括:初始

《构建之法》第十七章读后感

通过阅读<构建之法>第十七章,不能说对我造成了什么深远的影响,但是还是感触颇深: 第一,工作分配的重要性,说道工作分配,不得不说我们个小组的组长们,组长不仅仅是一个团队的领导者,更是这个团队的灵魂.它不仅需要了解随时掌握各组员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去非陪相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,有时甚者能更创造出以外的效果,达到更完美的状态.这不仅是组长的能力  其实其无时无刻也体现着我们这个小组的团结力和创造力.当初选

《构建之法》阅读梳理篇读后感

我通过老师发的链接读了“<构建之法>阅读梳理篇”,我从中懂了很多,我懂了软件与程序的区别,明白了作为一个程序员是要掌握的基本能力,更明白了一个软件或项目是由一个团队完成的,个人的能力再强也强不过一个团体.在这篇文章中我明白了很多,同时我也对我日后可能要做的工作有了更全面的了解,也令我看清了程序员这个工作的前景和工作方式,更令我看清了自己的缺点和不足.我要以这篇文章里的要求去要求自己,向真正的程序员努力. http://www.cnblogs.com/lwr-/p/5199030.html?fr

软件工程构建之法第八,九,十章读后感

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