构建之法5.3-=开发流程、第六章、第七章

第五章:(开发流程)

  书中介绍了六种开发流程:写了再改模式、瀑布模型、瀑布模型的各种变形、RUP模式、老板驱动模式和渐进交付的流程。

  书本介绍的几种开发流程中,对我们学生而言一开始大概就是写了再改这种模式,再一些经验之下,我们的流程会有些改变,会加入一些程序的简要分析和设计,能做到分析、设计、编写代码、测试等步骤了,不是仅仅是写了再改的模式。

 经过这一章节的学习,我觉得的选择一个好的开发流程对程序的编写有一个导航的作用,知道自己要干什么,有什么步骤,怎么一步一地编写出自己的程序,在开始代码编写前会多一些思考。

再瀑布模型后面的集中流程方法都是比较重计划、事先设计等这种开发流程比较适合开发团队。

然而对于我们学生独自编写的中小程序我觉得我们可以先按照简单的瀑布模型开始接触开发流程。

第六章:敏捷流程

  书中消息具体地介绍了敏捷流程,还有他的原则,以及他的步骤。并且还列出敏捷流程在每一个步骤可能出现的问题以及他的解决方法。这些知识点都是在书本里面有的P100~P108页。可以肯定的是敏捷流程是值得我们去运用,它具有很好的价值。

  因此我们需要的是学会敏捷的原则,打造敏捷的团队,敏捷的工作。敏捷其实并不是很特别,只不过是积累以往经验并且加以提炼出来的一个较为完整的能被大众所喜欢的开发流程,这是我认为的。每种流程都是大同小异,步骤不一样,效率功效不同。

或许我们还可以去普及一下敏捷的一些方法论:FDD(爱抚弟弟)、史克朗姆(SCRUM)、极限编程(XP)。好友他的适用范围,书本P114页也清晰地列出来了。

  我们现在的作业模式,每周定期发布的作业更新可以说是一种敏捷形式吗?我们应不应该引起一个学习的敏捷浪潮。敏捷的看法流程,对我们的在学习上是不是真的存在他所说的那种价值。。

第七章:MSF

  书中对MSF的介绍也是很详细的,MSF的历史,原则,团队模型还有开发模式都有介绍到。其中我觉得我们可以多了解一下他的原则,你会发现他的原则不是独立开来的,一条原则跟其他是有关联的。MSF敏捷开发模式跟以往的不同:更强调与用户交流、防止缺陷的发生、重视在实战条件下的质量还有精简过程,直奔主题。

  其中我觉得我们看到好多种开发流程,做软件的方法,总会感觉自己运用起来是那么遥远的事情~~以后在作业中多点尝试某种方式。或许对我们做小软件有用处。

  

  

时间: 2024-08-03 00:38:42

构建之法5.3-=开发流程、第六章、第七章的相关文章

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

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

构建之法第一、二、十六章

<构建之法>第一.二.十六章疑问 我通过阅读发现这是一本十分有趣的书.不同于别的书的晦涩难懂,<构建之法>利用浅显易懂的语言,贴近生活的例子向我们讲述了软件工程的内容. 第一章  概论 软件=程序+软件工程 扩展:软件企业=软件+商业模式 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营.和维护上的过程.软件的特殊性有a.复杂性 b.不可见性 c.易变性 d.服从性 e.非连续性.软件工程与计算机科学的区别:计算机科学中与实践相关的部分,都和数据以及其他学科发生关系:

0321《构建之法》现代软件工程第1、2、3章读后感

<构建之法>前三章之读后感 读完这本书的前三章,我深深的体会到这本书对我们的好处,这本书不仅仅适合我们学生,而且还适合老师,助教等等.这本书不仅把本章要学的知识点简洁明了的罗列出来,而且还有课后习题供同学们思考,最重要的是这本书总体的框架是以问答的形式出现在我们的视线中,让读者能够轻松的了解知识,这种让读者感到通俗易懂的书,我相信,很难再找出类似这种优秀的书了. 第一章,我知道了软件是怎么产生的,这还教会了我怎么去写好一个程序,然后一步一步的引导着我们怎么去制作一个软件来赚取自己应得的利益:我

《构建之法》现代软件工程第1、2、3章读后感

---恢复内容开始--- 读完<构建之法>的前三章,确实跟老师所说,这本书相比其他书能相对看的下去,简洁明了,理论与实际相结合. 第一章,阐述了软件工程是什么,阐述了计算机科学和软件工程的关系. 问题:对学好软件工程的建议有哪些? 第二章,普及了一些基本概念和技术,也就是单元测试和效能分析工具.单元测试,为了准确,快速的保证程序基本模块的正确性:效能分析工具,能跟清楚的知道程序锁消耗的时间与调用次数.通过这章的学习,让women了解到如何去管理好我们的程序. 问题:如何更好的实践利用单元测试.

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

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

软件工程-构建之法 Visual Studio开发平台的安装与单元测试

一.前言 自从开始了大三下的生活,学校开设一门课程“软件工程”,刚好我们是第一届进行课程改革,不在像以前那样背背概念,考前进行好好突击,然后考试就能过,最后毕业了发现软件工程课程到底我们在其中学习了什么. 我自己觉得改革,会不会让自己觉得考的不好,能学到啥?在老师的第一节课上,老师把整个学习蓝图描述一下,我大约感觉到这才是一个大学的课堂,不仅仅子啊 课堂上听老师讲课,最重要的是自己在课后自己在学习,自己在网上自己寻找知识,进行学习.自己才是这门课程的主人,主动学习课程,不是被动听老师讲. 喜欢编

构建之法第三次作业(11,2,3,4章)

首先在第11章的学习中,我了解到:要试着通过各种途径了解客户.俗话说,知己知彼才能百战不殆,才能为自己与客户的成功洽谈提升概率.绝对不要盲目地去见一个客户,这是一大忌讳.哪怕是只知道一些客户小道消息也好,至少会从侧面反映客户的一些性格等,要学会求同存异,学会使用行业语言特点.. 而在第二章学习中,知道了软件是需要单元测试的,之前对这个没什么概念,而且单元测试要跟软件更新同步,单元测试要覆盖所有代码路径,单元测试可以把你的软件能做的不能做的事都在“单元”中表达出来.如果没有单元测试的话有时候有些隐

阅读&lt;构建之法&gt;13、14、15、16、17章

13章 这么多测试为什么不能整理出一个包括所有功能的测试呢?看着那么多测试都感觉奇怪了. 14章 怎样才能体现一个测试人员的工作价值呢?这样的判断又是否会太独断了? 15章 在时间上,会不会因不同功能板块完成快慢有影响?在后期的问题解决又有何保证措施? 16章 创新并不是每个人都行的,但有时候太执着于此是否进了死胡同呢? 17章 作为领导者的话,做到公平公正也并不像口头上那么简单,有时候是向规则妥协呢还是坚持自己的主见?

Android深度探索与HAL驱动开发(卷1)-- 第七章随笔

应用程序.库.内核.驱动程序的关系   从上到下,一个软件系统可以分为:应用程序.库.操作系统(内核).驱动程序.开发人员可以专注于自己熟悉的部分,对于相邻层,只需要了解它的接口,无需关注它的实现细节.以点亮LED为例,这4层软件的协作关系如下: 1.应用程序使用库提供的open函数打开代表LED的设备文件. 2.库数据open函数传入的参数执行“swi”指令,这条指令会引起CPU异常,进入内核. 3.内核的异常处理函数根据这些参数找到相应的驱动程序,返回一个文件句柄给库,进而返回给应用程序.

如何构建自动化的前端开发流程

我们先来看下前端开发可能存在的问题: 我们有许多的第三方库的依赖需要管理: 我们有独立的前端测试需要自动运行: 我们还有很多代码需要在发布时进行打包压缩: ?? 所以构建一个自动化的前端开发流程是非常必要的,但现在前端开发流程的构建是百花齐放,没有一个统一的标准,还有很多依赖于后端的架构来做前端开发管理.例如在Rails开发中,就有各种前端库的gem包.但是这种依赖于后端框架的管理方式有许多问题: 许多gem包的维护者并不是前端库的维护者,所以更新不一定即时: 不利于前端代码与后端代码做分离: