《构建之法》之第8、9、10章读后感

第8章

第8章主要介绍了软件需求的类型、利益相关者,获取用户需求分析的常用方法与步骤、竞争性需求分析的框架NABCD,四象限方法以及项目计划和估计的技术。

软件需求的步骤为:1.获取和引导需求(Elicitation);

2.分析与定义需求(Analysis&Specification);

3.验证需求(Validation);

4.在软件产品的生命周期中管理需求(Management)。

获取用户需求——用户调查:1.焦点小组(Focus Group);

2.深入面谈(In-depth Interview);

3.卡片分类(Card Sorting);

4.用户调查问卷(User Survey);

5.用户日志研究(User Diary Study);

6.人类学调查(Ethnographic Study);

7.眼动跟踪研究(Eye Tracking);

8.快速原型调研(Quick Prototype);

9.A/B测试(A/B Testing)。

NABCD模型:1.N(Ned,需求);

2.A(Approach,做法);

3.B(Benefit,好处);

4.C(Competitors,竞争);

5.D(Delivery,推广);

第9章

第9章主要介绍了团队角色分工、项目经理的由来和要求、项目经理和其他经理的区别、软件项目中的风险和风险管理、PM的专业能力。

PM的能力要求和任务:1.观察、理解和快速学习的能力;

2.分析管理能力;

3.一定的专业能力;

4.自省的能力。

第10章

第10章主要介绍了典型用户(Persona)和场景(Scenario)、软件功能说明书(Functional Spec)和技术说明书(Design Doc)、功能驱动的设计(FDD)、用例(Use Case)。

典型用户可以包含以下内容:1.名字(越自然越好);

2.年龄(不同年龄和收入的用户有不同的需求);

3.收入;

4.代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要);

5.使用软件的典型场景;

6.使用本软件/服务的环境(在办公室/家里/沙发/床上/公共汽车/地铁......);

7.生活/工作情况;

8.知识层次和能力(教育程度,对电脑、互联网的熟悉程度);

9.用户的动机、目的和困难(困难=需要解决的问题);

10.用户的偏好。

功能驱动的设计:1.构造总体模型(Develop an Overall Model);

2.构造功能列表(Build a Feature List);

3.制定开发计划(Plan by Feature);

4.功能设计阶段(Design by Feature);

5.实现具体功能(Build by Feature)。

时间: 2024-10-29 19:06:05

《构建之法》之第8、9、10章读后感的相关文章

《构建之法》第8,9,10章读后感

第8章  需求分析 在第六次作业中,我们组讨论完毕准备做一个关于零食推荐的网站,在开始动手打代码做网站之前,我们首先做的需求分析.也体会到了需求的重要性.在软件产品利益相关者中,我觉得对于零食推荐网站,真正会登录网站评论收藏的人相对比较少,而大多数使用该网站的人都是直接浏览网页而懒得登录(使用方法参考“礼物说”网站),这就感觉“登录/注册”功能需求相对来说不那么重要.于是,我们决定以后会使用第三方软件登录而取消注册功能.(当然对于网站功能目前还未完成,完成部分为前台界面布局.) 软件团队需要设身

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

<构建之法>第六第七章读后感 阅读<构建之法>第6~7章,并参考以下链接,发布读后感.提出问题.并简要说明你对Scrum的理解. 学习附录: Scrum中文网--什么是Scrum?  http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1 Scrum认证体系 http://www.scrumcn.com/agile/scrumtraining/scrum-certification-progr

《构建之法》第1.2.3章读后感以及《硅谷传奇》观后感

阅读教材<构建之法>第1.2.3章之后,满满的对话,生动形象.其中第一章写到软件=程序+软件工程,程序=数据结构+算法,这也反馈出我们要学好数据结构以及算法.软件工程这方面的内容.我们要做出"足够好”的软件,并且不要忽视软件的每一个小部分,因为软件的每一部分都有可能成为关键的致命部分,犹如飞机或小车的安全带.我们做出的软件要符合客户的要求,软件分析需求分析至关重要,要花费很长的时间和精力.而且,软件维护是一个漫长的历程.在个人软件开发过程中,单元测试.回归测试以及效能分析虽然花费大量

读构建之法8、9、10章有感

第八章.需求分析 书中介绍了一些获取需求的常用方法.流程.及分析框架,看了后才发现原来需求分析还有着者这么多的学问. 以前听人说,需求分析在实际项目开发中所占分量很重,甚至往往需要花的精力比敲代码要多.我听到时不以为然 ,认为需求分析不就是看一下软件要什么功能,要做成什么样而已吗.再后来,我真的接手了一个小商业项目的需 求分析任务,才明白需求分析是一件多么让人崩溃的事情,客户对软件编程一无所知,只是含糊地给我一些文档, 而我又不清楚他们的业内流程.业内术语等,不知道如何去获取对需求,只能像只无头

阅读《构建之法》第8,9,10章

第八章:需求分析 本章节讲述软件需求的4个步骤,讲述了9种用户调研方法,以及提供了两种竞争性需求分析的框架,分别是NABCD模型和四象限方法,个人觉得这两种框架对于我们在编程一个应用程序非常有用,先计划后编程. 提出的问题:(8.6.1节)我觉得目标.估计和决心这三个很类似,只是表达的语气不同 第九章:项目经理 本章节主要讲述项目经理(PM)的来历.Project Manager(产品经理)和Program Manager(项目经理)的不同.PM存在的优缺点以及成为一个团队的PM需要什么能力等.

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

 概论: 敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.在敏捷开发中, 软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视.可集成和 可运行使用的特征.换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目, 并分别完成,在此过程中软件一直处于可使用状态. 遵循原则: 我们最优先要做的是通过尽早的.持续的交付有价值的软件来使客户满意. 即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势. 经常性地交付可以工作的软件,

03-20 《构建之法》第1,2,3章读后感

第一章读后感: 看了大概了解软件从一个想法到最终成品的一个过程.软件先是由一个想法引出的,有那个想法,你需要一个工具去做什么,然后根据自己想要的功能大概做一个能实现基本功能的软件,再对客户提出的要求进行完善,实现了功能后对软件进行维护.还有做的软件要符合客户的要求,而不是只根据自己的想法去做,要满足大部分的需要,满足客户的需求,在使用过程中发现有bug对其进行修复. 软件工程在社会发展处于什么地位,发展潜力在未来究竟有多大? 第二章读后感: 看完第二章后知道软件是需要单元测试的,之前对这个没什么

《构造之法》第8,9,10章读后感

第八章.需求分析 本以为需求分析是很简单问题,画画逻辑图之类的,但是现在才发现原来需求分析需要和甲方做大量的沟通,如果需求分析做得不好, 导致需求改动频繁,那么程序员是是会打人的哦.开个玩笑,但是万事开头难,一个好的需求是一个项目的重要保障. 第九章.项目经理 项目经理的职责 1.确保项目目标实现,保证业主满意 这一项基本职责是检查和衡量项目经理管理成败.水平高低的基本标志. 2.制定项目阶段性目标和项目总体控制计划 项目总目标一经确定,项目经理的职责之一就是将总目标分解,划分出主要工作内容和工

软件工程《构建之法》第6,7章读后感

1.成功的变革不是完全自上而下或者自下而上,而是通过结合两者的变革相关要素. 2.如果我们不能预见到Scrum转型的结束状态,便无法确定当前状况和结束状态之间所有的差距. 3.变革与过去培训的内容往往产生冲突,软件开发人员很难在短时间适应这种变化,导致转型的失败. 4.人进行改变的能力是有限的,因此企业进行改变的能力也是有限的-———要求人们在同一时间内做太多改变,他们是无法承受的,毁坏性的压力和未来的冲击产生的迷惑会随之而来.加之,当代技术革新的速度之快,人们无法快速跟上,导致人们工作和交互方

教材《构建之法》第1.2.3章读后感

  问题 思考 第一章 什么是bug? 课本29~31页有说到bug的大概概念,简单来说就是软件的行为和用户的期望值不一样,这就叫bug.这使我很困惑,世界上那么多人,肯定每一个软件都会和很多人的期望不一样的啊,这样岂不是每一个软件都是一个bug?不过课本后面又说到一个软件是否是bug,取决于用户和开发者的不同角度.虽然课本也举了例子说明,但是还是不太明白. 第二章 什么是单元测试? 单元测试是在软件开发过程中要进行的最低级别的测试活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离