构建之法第十章学习

第十章讲的是关于典型用户和场景的内容。

在第一节当中,为我们介绍了Visual Studio的典型用户、典型用户的价值、怎样定义典型用户还有从典型用户到场景到任务的转变,还简单介绍了场景故事story的模板;

在第二节当中,为我们介绍了用例(Use Case),用例的基本元素包括标题、角色、主要成功场景、步骤和扩展场景;

在第三节当中,为我们介绍了规格说明书(Spec),它可以分为两种:软件功能说明书(Function Spec)和软件技术说明书(Technical Spec);

在第四节当中,为我们介绍了关于怎样设计功能驱动,功能驱动的设计(FDD)由几个步骤构成:构造总体模型、构造功能列表、制定开发计划、功能设计阶段、实现具体功能。

时间: 2024-11-13 14:18:56

构建之法第十章学习的相关文章

构建之法第八章学习心得

今天,我学习了构建之法第八章软件需求,人们为了解决现实社会和生活中的各种问题,要求助于软件.人们的需求五花八门,那么软件团队如何才能准确而全面地找到这些需求呢? 需求分析1.获取和引导需求 软件团队需要找到 软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 不同的项目需要不同的手段,这一步骤也被叫做"需求捕捉",形容真正的需求稍纵即逝,需要靠火眼金睛和敏捷的身手来发现并抓住它们.另外,很多时候用户并不知道自己确切的需求,或者不愿意表达完整的需求,软件团队需要设

《构建之法》小组学习心得

baba爱你小组  组长:阮俊  组员:钱洪章.黄维.光萍.张启飞.王学飞 这周我们小组学习了<构建之法>第八章需求分析的内容. 人们为了解决现实社会和生活的各种问题,要求助于软件.人们的需求五花八门,那么软件团队如何才能准确而全面的找到这些需求呢?主要有这几个步骤: 1.获取和引导需求 软件团队需要找到软件的利益相关,了解和哇挖掘他们对软件的需求,引导他们表达出真实的需求.另外,很多时候用户并不知道自己确切的需求,或者不愿意表达完整的需求,软件团队需要设身处地,替用户着想,引导出需求. 2.

构建之法 第十章 典型用户和场景

作为软件,最大的目的不是考验"软件工程",而是"用户至上"的使用性好坏.所以多了解一些"用户之法"多有裨益.另外,关于spec也在本章中有所涉及 1.典型用户 what?[典型用户就是互不相同的.最可能使用软件的若干类用户:要作为"典型",还要完善他们的使用诉求.习惯以及本身的软件操作水平] why?强迫我们考虑问题的时候从用户的角度出发 how?先定义典型用户,再从典型用户到(用户使用软件的)场景 参考http://www.

构建之法第二周学习体验

首先我学习了个人能力的衡量与发展.软件工程中有一项是软件开发流程,目的是为了提高软件开发.运营和维护的效率.但是软件开发流程不光是指团队的流程,还包括个人开发流程,因为软件团队是由个人组成的.单个成员在团队中的流程包括:1.通过交流.实验.快速原型等方法,理解问题.需求或任务2.提出多种解决办法并估计工作量3.与相关角色交流解决问题的提案,决定一个可行的方案 4.执行,把想法变成实际中能工作的代码,同时验证方案的可行性和其他特性5.在测试环境中测试实现方案,修复Bug6.在解决方案发布出去后,对

《构建之法》第三、四、五章学习总结

第三章讲的是关于如何成为一名合格甚至优秀的软件工程师.第一节主要讲的是个人能力的发展与团队合作的关系:第二节讲的则是关于软件工程师的职业发展:最后一节通过用魔方举例向我们讲述了怎样提升自己的技能. 第四章讲的是关于软件开发时两个人该怎样合作.这一章的前三节讲的都是关于代码规范,包括风格规范和设计规范:第四节讲的是关于代码复审时的问题,代码复审的正确定义是看代码是否在"代码规范"的框架内正确地解决了问题:第五节讲的是结对编程 :第六节介绍了两人合作的不同阶段和需要了解的相关技巧. 第五章

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

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

《构建之法》阅读笔记04-团队合作

现代软件产业经过几十年的发展,一个软件由一个人单枪匹马完成,已经很少见了,软件都是在互相合作中完成的.所以团队合作尤为重要. 在学习构建之法之前,学习的大部分编程都是自己编的,对团队合作不是很了解.通过阅读构建之法让我了解到团队的合作是尤为的重要,团队的团结合作,众志成城是成功的关键. 团队共同的特点: 1.团队有一致的目标,团队要一起完成这个目标.一个团队的成员不一定要同时工作,例如接力赛跑. 2.团队成员有各自的分工,互相依赖合作,共同完成任务. 在团队中,我们应该各司其职,努力为团队的目标

《构建之法》快速阅读后的几个问题。

1.软件=程序+软件工程,是程序更加重要还是软件工程更加重要? 2.软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.软件工程当中哪一步骤是最为重要的? 3.在编程工作学习当中,是快而有bug好还是慢而bug少更加优秀? 4.个人技术与软件工程有什么关系? 5.一个职业软件工程师如何衡量?写得代码越多就可以认为越成熟吗? 我相信,在细细阅读<构建之法>和学习了<软件工程>后会对上面的问题有更深层次了理解.

《构建之法》读后感和团队项目杂谈

<构建之法>将软件工程的各个组件分门别类,横向地介绍了软件工程这一体系.然后又在每个类别中纵向地由浅入深,逐步递进, 较为完整地让我们这些菜鸟初识软件工程. 经过一个学期的学习,<软件工程>搭配着<构建之法>进行学习,我也对软件工程有着一定的了解.软件=程序+软件工程,个 人认为,如果说程序意味着实现,那么软件工程更加侧重“方法”和“规则”.似乎软件工程是一个新兴的学科,它的方法论是一群富 有经验的大牛从他们丰富的编程经历中提炼的精华和吸取的教训(我个人的臆想),没有特