《构造之法》8、9、10

第八章

只要是介绍需求分析,在这章里讲到了软件需求,软件产品的利益相关者,获取用户需求————用户调查,竞争性需求分析的框架方面,功能的定位和优先级,计划估计及分而治之,通过这章的学习,我学会了如何在弄产品之前该怎样去了解用户需求,例如了解软件需求只要有:

1.获取及引导需求

2.分析和定义需求

3.验证需求

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

第九章

本章 主要介绍项目经理(PM)的由来和要求,以及项目经理的重要性。PM和大家平等地工作,推动团队完成软件的功能。一个团中可以有多个很多个PM,和其他团队常成员一起形成决议,管事不管人,也要做具体的工作。这里PM是促进一个团队快速工作,高效率的重要角色,但是也需要可其他人一起工作,平等。一个好的PM要需要较强的要求和能力:1.观察、理解和快速学习的能力2.分析的能力3.一定的专业能力4.一定的专业能力5.自省的能力。这些是团队成功的关键,非常重要。

第十章

本章主要介绍典型用户与场景。典型用户可以包含一下内容:

1.名字(越自然越好)。

2.年龄。

3.收入4.代表的用户在市场上的比例和重要性5.使用软件的典型场景6.使用本软件/服务的环境7.生活/工作情况8.知识层次和能力9.用户动机10.用户的偏好。用例需要有规划说明书和功能说明书。
时间: 2024-10-29 19:10:25

《构造之法》8、9、10的相关文章

构造增量法生成子集

题意: 生成 1~n 集合的子集, 先按元素从小到大再按字典序排列输出 分析: 所谓构造增量法, 就是每次都输出当前数组的元素, 然后再给当前数组最大元素一个增量, 看是否仍然在集合内, 如果在就把他继续放进数组, 输出. 这种方法不需要显式确认递归边界, 如果无法添加元素, 自然就不会再递归了. 数据结构我选用了string , 因为字典序比较容易排序出来. #include <bits/stdc++.h> using namespace std; string ans[1 <<

阅读《构造之法》1、2、3章有感

<构造之法>和其他接触过的教材有所区别,不像别的教材那样呆板,无趣,让人读着想睡觉,感觉像是在听笔者在讲述他的所见所闻,或者像在读一本小说,让人可以一直跟着读下去,而且能学到一些东西. 在第一章中,有许多生动有趣的例子(事实整本书都有许多),让我能很有兴趣的慢慢读下来,也比较明白了软件工程什么,它所包含的方面以及意义,软件工程与许多的学科都有联系,这些联系或多或少,也说明了软件工程不单单只是涉及到一方面.软件工程的目标也比较明确,看这些可以解决自己对这一专业的迷惑.第二章则深入一些的讲到了对于

Reaction to 构造之法 of Software Engineering From The First Chapter toThe Fifth Chapter(补充版)

几个星期前,我阅读过一篇文章,一位老师教导自己的学生要积极地去阅读文学文献,其中,我很欣赏他的一句话:“Just think of liturature as if you're reading a long text-message”.引申到这里,对比后才发现自己在现实生活中真的很少在课后花时间来细看自己的专业书籍,说来惭愧,这种情况出现的频率最多的就是在学期末备战考试了.因为这次的作业,我似乎告诉自己这是一个非常“恰当”的理由去让自己提前去完成未完的“任务”.阅读一本书,就要认真,要对得起自

现代软件构造之法

现代软件工程方法之所以超出传统方法,主要是因为它针对的是具体对象,即面向的是具体存在的问题和弊端,这一点,完全克服了传统软件工程方法的缺点和不足.现代软件工程方法包含五部分,分别是分析.设计.编码.测试.维护.这几部分虽与传统工程方法大同小异,但细比较便可发现现代工程方法的优点.在分析部分,传统工程方法主要是笼统地分析,没有具体的面向对象,而现代工程方法则是分析现实事件的具体问题,因此,具体问题的性质可以更好地反映事件的性质.在设计部分,面向对象主要是系统中的具体时间.构造之法的主要作用--提高

《构造之法》第四章

通过阅读<构造之法>第四章,我知道了程序员写的代码要规范,代码虽然是给机器看的,让机器来运行,但是更要给人看,代码是人写的,都会有各种各样的缺陷,必然要去修复.改进,若代码不规范,带来的影响是比较严重的,会让人感到烦躁,看不下去了.或者因为看懂代码的缺陷在哪里而花费了大量的时间.在代码上要4个空格来缩进.为了调试起来方便,需要断行,每个“{”和“}”都独占一行,一行代码不要定义多个变量,由多个单词组成的变量名需要有大小写,其中每个单词的开头第一个字母大写,不要多余的注释. 代码复审是有必要的,

Reaction to 构造之法 of Software Engineering From The First Chapter toThe Fifth Chapter

几个星期前,我阅读过一篇文章,一位老师教导自己的学生要积极地去阅读文学文献,其中,我很欣赏他的一句话:“Just think of liturature as if you're reading a long text-message”.引申到这里,对比后才发现自己在现实生活中真的很少在课后花时间来细看自己的专业书籍,说来惭愧,这种情况出现的频率最多的就是在学期末备战考试了.因为这次的作业,我似乎告诉自己这是一个非常“恰当”的理由去让自己提前去完成未完的“任务”.阅读一本书,就要认真,要对得起自

阅读《构造之法》第4章有感

<构造之法>简明.易懂,第4章讲到了两人结对合作来完成代码的编写,这也是当今软件工程师经常接触的事情,一个人完成项目是好,但未必不会出现错误,而且自己检查起代码来也难免出现疏忽的地方,而结对则有多人进行代码的复审,出现错误的几率就会大大减低,而且结对可以优势互补,尽量发挥出各人的长处. 第4章一开始就讲的是代码的规范问题,其实这个很重要,对于一个比较大量的代码,如无意义的命名方式,可能编写者自己都会一时想不起它有何作用,更不用说别人了,所以代码规范对于一个团队来说,可以让团队里的人更清晰明了的

《构造之法》问答

 构造之法 第一章里面的软件工程的知识领域的1.Software Requirements,软件工程的需求分析,概括了我不懂的东西. 第二章里面的个人开发流程,职业工程师和大学生的软件开发耗时表对我启发很大,不同方面的时间分配反映出来了各自质量要求的不同,在此我有一个问题:只有时间沉淀出来的工程师才是一个好的软件工程师吗?岂不是我们大学生一定要等到40多岁才能熬出头了? 第三章里面的个人能力的衡量和发展,我觉得里面举的足球队例子不是很好地说明了个人能力的衡量度,在我看来工程师开发团队里面的开发维

读《构造之法》8、9、10章有感

第八章 书本第八章重点讲了需求分析,在一个项目中,需求分析是最基础也是最重要的,只有充分了解了用户需求,我们才不会走弯路,才能做出正确的规划,保证项目的进行是按照用户的需求进行的.其中,获取用户需求的方法即用户调查,常用的用户调研方法包括: 1.焦点小组: 2.深入面谈 3.卡片分类 4.用户调查问卷 5.用户日志研究 6.人类学调查 7.眼动跟踪研究 8.快速原型调研 9.A/B测试 第九章 介绍的是PM,在这章里,我知道了: 1.PM是啥 2.微软PM的来历 3.PM做开发及测试之外的所有事