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

第五章:(开发流程)

写了再改模式:不需要太多的知识,直接上手写代码,一直改,直到发布。

瀑布模型:单向不可逆,最终产品直到最后才出来。按照需求分析-编码测试-发布一步步走下来。力求一次完成。

RUP统一过程:在大的尺度上像瀑布模型,在每个阶段内像迭代模型。初始阶段:分析系统大概的构成,和什么样的外部实体打交道,大致的成本和预算是多少。细化阶段:编制项目计划,确认主要的功能,性能。构造阶段:把所有的功能集测试并发布为Beta版。交付阶段:基于用户的反馈,不断进行修改。

6.敏捷流程

Scrum方法论是敏捷过程的一种,敏捷过程的精髓在于快速交付。第一步:找出完成产品需要做的事情,每一项工作用天为单位计算。第二步:把整个产品分为几个相互联系的冲刺,也就是sprint,团队成员主导任务的估计和分配,各取所长,能动性得到较大发挥。第三步:冲刺阶段各个团队相互独立,所有的问题都只能在这个冲刺完成之后进行交流。冲刺期间,每天需要开一个站立会议,告诉队友我昨天所做,今天将做,遇到问题。第四步:得到增量版本,交付。

敏捷方法用时间来管理,来驱动每一个冲刺,积少成多,最后形成不断迭代增量的版本。这种时间驱动彻底断除了我们延期完成工作任务的想法。

7.需求分析

我们开发软件是为了解决现实社会和生活中的各种问题。人们的需求各种各样,我们该如何找到需求呢?

1.获取和引导需求。需求是需要挖掘的,我们既可以引导客户,结合自身行业经验,得到需求,也可以分析技术的发展趋势和全球产业变化社会发展的大趋势分析需求,如大数据云计算移动互联网。

2.分析和定义需求。规整需求,定义需求的内涵,从各个角度量化需求。

3.验证需求。如果需求分析没有做好直接开工的话,容易做无用功,造成返工。软件团队要跟利益相关者沟通,通过分析报告,用户调查或演示等形式向他们验证软件团队对于这些需求的认知。

4.需求管理。如上所说,需求会不断变化,或者说解决需求有了新的捷径和方式,这些都要求我们因地制宜,跟着变化而变化。

5.需求的分类:功能性需求要求产品必须实现某些功能,开发过程需求要求开发流程必须产生哪些文档在什么时间交付,非功能性需求要求服务质量例如12306网站要做到实时响应。

那么,作为一个开发者,需不需要到需求中来呢,非常需要,因为软件的各种约束各种技术实现会影响到他们的工作过效率。我们一定要让相关角色在需求分析阶段有机会提出他们的需求和一件。

时间: 2024-10-19 08:39:08

构建之法5.3、第六章、第七章读后感的相关文章

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

<构建之法>读第六.第七章有感 第六章: 第六章主要详细介绍了敏捷流程,在软件工程范畴里,“敏捷流程”是一系列价值观和方法论的集合.这一章以敏捷流程的Scrum方法论而展开,Scrum 采用迭代.增量的方法来优化可预见性并控制风险,并且SCRUM 是一个用于开发和维持复杂产品的框架. 敏捷开发的流程如下: 1.找出完成产品需要做的事情,每一项工作用天为单位计算. 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog. 3.冲刺阶段各个团队相互独立,所有的问题都只能在

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

<构建之法>第8.9.10章 读后感 第八章:需求分析 软件开发团队就是为了用户着想,于是总会在程序项目开发前进行项目的需求分析 本章节讲述软件需求的4个步骤,(1)获取和引导需求(2)分析和定义需求(3)验证需求(4)在软件产品的生命周期中管理需求 .在软件工程中分析软件需求需要考虑相关者的利益关系,例如用户.顾客.市场分析师.监管机构.软件工程师等之间的关系. 讲述了9种用户调研方法:(1)焦点小组(2)深入面谈(3)卡片分类(4)用户调查问卷(5)用户日志研究(6)民族志/人类学调查(7

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

读完第六和第七章,我学会了敏捷流程和MSF的一些知识,总的来说,这两种模式就是一种团队的不同方式和不同的发展流程. 敏捷流程有十二条原则,这十二条原则主要涉及客户,市场,对手,团队,技术创新还有自我管理等各方面.敏捷流程的步骤主要有三步: 第一,找出完成产品需要做的事情——Product Backlog; 第二,决定当前的冲刺(Sprint)需要解决的事情——Sprint Backlog:团队成员能主导任务的估计和分配,他们的能动性得到较大的发挥. 第三,冲刺(Sprint):一切交流只能通过S

构建之法阅读心得(六)

构建之法第六章,本章为敏捷流程,主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论,各种软件开发方法论的优缺点,选择软件流程根据等. 敏捷开发:是一系列价值观和方法论的集合 敏捷开发的原则: 1.尽早并持续地交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分

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

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

0321《构建之法》第1、2、3章读后感

<构建之法>这本书满满的理论知识,但是它并不具有我们认为学习理论过程的那种乏味感.这本书都有很多有趣而且很有联系性的例子,让人有种很想去深入探讨的想法.也可以说是这本书完全可以把你带入思维的世界,让你有那种想彻底了解透它. 第一章 对于第一章,和其他书都差不多,都是以文字铺满整章书.在本章内容中,我们可以很清楚地了解到软件工程是什么,软件工程的发展史等等.一个实用的软件需要经过一段长期的更改和迎合客户的需求不断完善的.比如在本书中的一个很好的例子,阿超通过写一个小程序来解决了老师让家长每天出3

阅读&lt;构建之法&gt;第三10、11、12章并提出问题

<构建之法>第10.11.12章 第10章: 问题:对我们了解了用户的需求后,但是我们想法和做出来的软件会和用户的需求有偏差,比如风格.界面的修饰等等,那么我们程序猿怎样才能让自己的想法更加靠近用户的想法呢?是设身处境么? 第11章: 问题:我们现在这个阶段是在做四则运算APP,如果按照这章的步骤走下去,每天都要进行进度更新,和每日会议还有每日构建的,会不会不太符合我们现在的处境?毕竟我们的所有时间不能只为一门课程服务,还要大量的时间花在其他的课程上呢. 第12章: 问题:在实际的项目中,我们

《构建之法》第10,11,12章

第10章问题(10.2):Spec分为软件功能说明书(黑盒子)和软件技术说明书(又叫设计文档,白盒子),Spec是不是真的有需要写?要如何写?写了是不是一定要发布? 第11章问题(11.2.2):书上提到“每日构建”很重要,但是一忙起来都没有时间去管构建,那么应该如何改善呢? 第12章问题(12.1.3):用户如果提出错误或者无理的要求时,该如何帮助用户改正?

第九章 前七章总结考试答案

前七章总结测验见附件内容

《构建之法》第十六章读后感更正

第十六章IT行业的创新 1.关于灵感.灵光闪现固然重要,很多伟大的发明依靠的就是灵光一现的基础,但是灵光闪现的前提是个人的思考,长时间的思考.完成这一灵光的基础是不断的尝试,提高自己的技术.这样才会将自己的灵光变成一个实物而不是空想. 2.关于喜好.并不是人人都喜欢创新,因为创新本来就是个长耗时又难以被认可的东西.创新有需要考虑的因素有许多,个人.面子.优先级等等,现在人们更多的是支持在原有材料技术上的"线性发展"--扩充功能等. 3.关于想法.人们接受的并不是好的想法而是他们所需要的