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

构建之法读书笔记

第八章  需求分析

  这一章主要是讲需求的分析,对于一个程序项目来说,我觉得,需求是这个项目的向导,他可以决定程序项目会发展成什么样子。书里面需求这里大致分为两个:软件需求和用户需求。

  软件需求:我们不仅仅要考虑到项目功能的需求,要实现的功能,还要考虑到开发过程以及非功能方面的需求,还有综合需求。

  用户需求:是针对在用户这个角度,用户最需要的东西。我觉得用户需求在需求分析中较为重要,毕竟每一个要做的程序的根本目的是满足用户的要求。

     所以书里面野介绍了九种获取用户需求的调研方法:

  焦点小组  深入面谈  卡片分类  用户调查问卷  用户日志研究  

  民族志/人类学调查   眼动跟踪研究  快速原形调研  A/B测试

  在收集完需求后我们还要对需求进行分析,对功能的确立,还要对项目程序进行计划和估计。

  这看的出来对一个项目的需求分析是很重要,那么我们是不是要在每次的项目开展示写一份需求分析的文档,这样可能会让编程者更清楚了解自己程序的目的,需要什么?

第九章   项目经理 

  在这一章节里面主要讲的是微软的PM(Programe Manager)和其他团队PM(Project Manager)的区别,个人觉得微软的PM给团队成员带来的感觉是很不一样,就好像是战友一样,工作起来也很有感觉。

  还有介绍了PM的能力要求以及人物,不同的PM有不同能力,一个项目有多个PM我觉得还是挺科学的毕竟每个人能力是有限,找到优秀的战斗力很重要,适当运用人才,没人发挥各自优势,那就完美,是鞋子就不能假装一个帽子,不是吗?

  我们的团队作业也有一个PM,但是感觉我们的PM就是一个较为积极的团队战友,会带动大家一起参与,这样的PM可以吗?

第十章  典型用户和场景

  我们要开发一个软件,用户是必须的,我们会想到用户使用我们的软件时,他是想干嘛?还有不同的人使用软件的目的是不同的。

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

  老师让我们回去也写一份针对自己项目写一份典型用户跟场景Story的文档。这样或许可以让我们更清晰了解明白接下去我们该怎么做。

  前面需求分析,还有后面体到的典型用户以及Story,都是针对自己的程序来进行一种分析,可见开发软件是,需求的分析很重要,还有Specifition(需求分析文档)规格说明书。

  书本195页有详细介绍。我们在下学期的课程设计也要设计这一类文档的编写。

总结:软件的需求分析很重要,需求是你软件的向导,你的初衷。做好需求的分析,做好计划,那么接下去就技术了~我们的开发需要一个好的开头。就从需求分析做起。

时间: 2024-10-15 11:28:17

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

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

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

《构建之法:现代软件工程》读书笔记

第一章 软件工程就是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.包括软件需求分析.软件设计.软件构建.软件测试和软件维护几个过程.涉及计算机科学.计算机工程.管理学.数学.项目管理学.质量管理.软件人体工学.系统工程.工业设计和用户界面设计等学科.不只是软件工程,其他工程(如机械工程)也可分为需求分析.设计.构建.测试和维护这几个阶段. 对其中的软件开发的不同阶段和航空产业的比较感觉挺有趣的.从玩具阶段的纸飞机到业余爱好者阶段的气球再到探索阶段的莱特兄弟,最后成熟产业阶段

《构建之法》第13-17章读书笔记

第13章: 软件测试有许多种测试方法,有单元测试.代码覆盖率测试.构建验证测试.验收测试.回归测试.伙伴测试.效能测试.等等.还要写测试设计说明书,告诉别人如何测试,测试报告说明书该怎么写呢? 第14章: 质量保障软件的开发过程有三个主要的特性“好”“快”“便宜”.通俗的软件在功能.成本.时间三方面满足利益相关的需求.理解是测试的角色要独立出来么?独立出来的测试角色怎么才能发挥作用? 第15章: 稳定和发布阶段.一个里程碑结束了,团队接下来要干什么?产品怎么才能做得更好? 第16章: IT行业的

构建之法(CH1~CH3)-读书笔记

三个简单的方程式解释了什么是现代软件工程:1.程序=算法+数据结构 2.软件=程序+软件工程 3.软件企业=软件+商业模式 软件开发的不同阶段可以类比为航空产业:从玩具阶段的纸飞机,到业余爱好的飞屋,再到探索阶段的 莱特兄弟的飞机,最后成为成熟的产业.软 件开发从简单的"Hello World",到我们现在用js写写网站,再到我们一直追寻的新技术与创新,并为着成熟的工业而奋斗,这就是软件工程的"软件开 发流程". 在个人技术和流程方面,有三个非常重要的概念: 单元测

《构建之法》第三章读书笔记

看到第三章,发现软件工程开发一直强调团队的重要性,但同时,每个人也发挥着重要的作用,在一个开发团队中,每个人都是一个环,环环相扣才能实现软件的开发.在大部分成功的软件团队模型中各个角色考虑问题的出发点是有区别的.不同意见的冲突在所难免,一个好的团队流程能把冲突的积极方面(各自尽力把自己的工作做好,说服别人)释放出来,避免消极方面(因为冲突而产生的消极.抵触情绪等). 在团队中,IC需要做到:通过交流.实验.快速原型等方法,理解问题.需求或任务:提出多种解决办法并估计工作量:与相关角色交流解决问题

《构建之法》第六章读书笔记

一.敏捷的流程简介 敏捷开发的原则是: 1.尽早并持续地交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分支持信任他们 6.无论团队内外,面对面的交流始终是最有效的沟通方式 7.可用的软件是衡量项目进展的主要指标 8.敏捷流程应能保持可持续的发展.领导.团队和用户应该能按照目前的步调持续合作下去 9.

《构建之法》第四章读书笔记

本章理论和知识点有:代码规范.极限编程.结对编程.两人合作的不同阶段.影响他人的技巧 一.代码规范 1.代码风格规范.主要是文字上的规定,看似表面文章,实际上非常重要. 代码风格的原则是:简明,易读,无二义性 .包括了:缩进.行宽.括号.断行与空白的{}行.分行.命名.下划线.大小写.注释. 2.代码设计规范.牵扯到程序设计.模块之间的关系.设计模式等方方面面的通用原则. 包括:函数.goto.错误处理. 二.代码复审 包括:自我复审.同伴复审.团队复审 代码复审的目的: 1.找出代码的错误.

构建之法 第七章 MSF 读书笔记

MSF 9条基本原则: 1.推动信息共享与沟通 2.为共同的远景而工作 3.充分授权和信任 4.各司其职,对项目共同负责 5.交付增量的价值 6.保持敏捷,预期和适应变化 7.投资质量 8.学习所有的经验 9.与顾客合作 在一个高效的团队中,所有的成员都应该能得到充分的授权,他们有权在职权范围内按照自己的承诺完成任务,同时,他们也充分信任其他同事能实现各自的承诺.类似的,团队的顾客(包括内部和外部的顾客)也认为团队能兑现承诺,并进行相应的规划.

《构建之法》第五章读书笔记

第5章 团队和流程 一.非团队和团队 团队的共同特点: 1.团队有一致的集体目标,团队要一起完成这目标.一个团队的成员不一定要同时工作,例如接力跑. 2.团队成员有各自的分工,互相依赖合作,共同完成任务. 二.软件团队的模式 软件团队的模式最初是混沌的一窝蜂的形式:一群人开始写代码,希望能写出好软件.随着团队的成熟和环境的变化,团队模式会演变成下面几种模式之一. 1.主治医师模式:这样的软件团队中有首席程序员,他负责处理主要模块的设计和编码,其他成员从各种角度支持他的工作(后备程序员.系统管理员

构建之法4,17章读书笔记

一.前言 经过上一次的阅读经验,这一次再阅读起来便顺畅得多了,顾名思义,这两章就是在讲我们如何在项目开发合作过程中更加顺利,软件工程既然有着"工程"二字,那就说明它并不是一个人的事情,软件工程离不开团队合作,而团队合作的最简形态就是两人合作. 二.分析与问题 引用:               既然代码复审能发现这么多问题,有这么好的效果,如果我们每时每刻都处在代码复审的状态,那不是很好么?事实上,极限编程(Extreme Programming)正是这一思想的体现--为什么不把一些卓