2016.2.24. 《构建之法》开始阅读

第一章:概论

开发过程:

一个简单的程序?一个满足各种功能的应用软件?一个能保证维修的软件服务。

软件=程序+软件工程

软件企业=软件+商业模式

软件开发的不同阶段:玩具阶段(纸飞机)?业余爱好阶段(氢气球)?探索阶段(实验飞机)?成熟的产业阶段(民用飞机、航空业)

????????????写程序练习数据结构/算法?用Javascript、ASP.NET、Ruby写网站?钻研新技术、应用新技术创新?银行软件系统,搜索引擎,操作系统

软件的特殊性:

  1. 复杂性Complexity 。代码、文件量巨大,模块之间有各种隐性或显性的依赖关系(且随程序规模的增长指数式增长),而软件工程师的阅读能力并不异于常人。
  2. 不可见性 Invisibility。 工程师无法知道程序即源代码是如何在具体的机器上运行的。即使商业软件在出错时会留下痕迹(错误代码,大致目标代码位置,错误信息),但无法完整重现。
  3. 易变性
  4. 服从性
  5. 非连续性

?
?

初步掌握软件工程的要求:

  1. 研发符合用户需求的软件。
  2. 通过一定的软件流程在预计的时间内发布足够好的软件。
  3. 并通过数据和其他方式展现所开发的软件是可以维护和继续发展的。
时间: 2024-10-09 21:46:16

2016.2.24. 《构建之法》开始阅读的相关文章

《构建之法》阅读有疑 与 个人Week1作业

<构建之法>阅读有疑 在用将近五节课的时间将邹欣老师的书<构建之法——现代软件工程>第二版大致看完.虽然全书是以轻松的口吻与”移山公司”员工的一些趣味谈话来传输一些理念和思想的,但是读完并理解依旧不是一件很容易的事情,并且在这过程中我对书中的一些看法抱有怀疑的态度,现将问题所在列在下面. P68页:我不是很认同邹老师的“精通”魔方的判定方法.就好像在软件工程开发中,一个人解决了一个bug.解决了bug却不算是“精通”,还得能恢复bug,再现bug才算是懂得各中原理吗?我觉得作为一个

《构建之法》阅读笔记一

1.程序=数据结构+算法 2.构建管理,源代码管理,软件设计,软件测试,项目管理是软件工程的核心部分. 3.软件=程序+软件工程 4.软件企业=软件+商业模式 5.软件开发的不同阶段:玩具阶段,业余爱好阶段,探索阶段,成熟的产业阶段 6.软件工程是把系统的,有序的,可量化的方法应用到软件的开发,运营和维护上的过程 7.软件工程包括:软件需求分析,软件设计,软件构建,软件测试和软件维护等领域 8.软件的特殊性:复杂性,不可见性,易变性,服从性,非连续性 9. 软件工程的目标--创造"足够好&quo

《构建之法》阅读梳理篇读后感

我通过老师发的链接读了“<构建之法>阅读梳理篇”,我从中懂了很多,我懂了软件与程序的区别,明白了作为一个程序员是要掌握的基本能力,更明白了一个软件或项目是由一个团队完成的,个人的能力再强也强不过一个团体.在这篇文章中我明白了很多,同时我也对我日后可能要做的工作有了更全面的了解,也令我看清了程序员这个工作的前景和工作方式,更令我看清了自己的缺点和不足.我要以这篇文章里的要求去要求自己,向真正的程序员努力. http://www.cnblogs.com/lwr-/p/5199030.html?fr

《构建之法》阅读笔记01

这一学期,开始了健民老师的软件工程概论课,早就听闻健民老师的软件工程概论课很牛,听了两节课下来,果然如此. 老师引用了<构建之法>书中的理念,认为软件不是靠着理论堆积而成,而是一个个实发的项目组成的,在课上,老师引用了书中的例子来形容学生和老师的关系. 1.餐馆服务员/食客 2.老板/雇员 3.保姆/幼儿:像保姆一样操办一切 4.哥们/哥们:一起混吧 5.路人甲/路人乙 6.狱警/犯人:想法点名/想法逃课 7.健身教练/健身学员:鼓励成长 当然,大家都更加喜欢7,希望能够获得更多的编程技能和知

《构建之法》阅读笔记(1)

<构建之法>第一章阅读笔记 大马哈鱼洄游模型 软件工程按照经典的瀑布模型 1. 需求分析 2. 设计阶段 3. 实现阶段 4. 稳定阶段 5. 发布阶段 6. 维护阶段 事实上在现实世界中,软件工程师的职业发展与瀑布流程刚好相反 毕业进入公司(或者实习生),开始学习并维护一些已有的软件(维护阶段),主要由自己的师傅(Mentor)带领 能够在项目中改一些 Bug,然后发现发布小规模的更新版本(稳定/发布阶段),联系重构,开始和其他同事打交道 有机会负责重写一个较小的模块,没有多少文档,自己要写

《构建之法》阅读笔记(一)

阅读第一章所得: 就像上半学期学到的那样:程序=数据结构+算法,通过阅读<构建之法>的第一章后,更加清晰的认识到:软件=程序+软件工程.也清楚的意识到我现在的水平也只是略懂皮毛,书中也提到了软件开发的4个阶段,分别是玩具阶段.业余爱好阶段.探索阶段.成熟的产业阶段.我现在就是处于玩具阶段向业余爱好阶段的过渡阶段,即写程序练习,并用新的语言如JAVA尝试C语言的程序,这么说来......大一至今是处于玩具阶段的状态.如果大学时期好好学习,按部就班,即精通老师教授的语言,那么等到毕业时,就像书中说

《构建之法》阅读笔记04

今天,我阅读了构建之法10-12章.总结出了自己以前一些不对的思想和做法. 以前认为对软件需求最大的人肯定就是我们的典型用户了呀.于是就可以为这些人打造一款软件就等于软件成功了.可是大多数时候我们软件已做完发现这些人根本不用我们的软件.为什么呢?因为不会用.所以我们定义典型用户的时候首要条件就是会用这款软件,然后和需求有关系的用户. 以前认为工程师做软件就是先把要做的任务分分类,然后大家把自己的任务文成,最后链接起来就可以了,可是这样做出来的软件真的解决了需求了吗?软件设计是首先要把需求先搞清楚

《构建之法》阅读笔记1

最初接触软件工程时仅仅以为软件工程就是写代码,只要编写的代码能够符合题目要求.运行成功就算是成功.<构建之法>用生活中的一个实例启发我什么是程序,什么是软件,什么是软件工程.程序指的是源程序,就是一行行的代码.能满足各种功能的是应用软件.写代码并不等于软件开发.软件的开发也是复杂的,需要经过:构建管理.源代码管理.软件设计.软件测试.项目管理等相关活动.概括为:软件=程序+软件工程.在阅读中我明白软件开发中应用工程化原则的重要性. 在读第二章阅读时我更是一头雾水,到底什么是单元测试,具体应该如

《构建之法》阅读提问

快速阅读完<构建之法>后的几个疑问: 1.成长与代码量是什么关系?代码量与工程师的水平呈现什么关系? 2.课本上对结对编程很赞赏,而实际工作中,两个人结对编程是不是浪费了一个人的工作量,有多少比例公司或者部门领导允许两个员工结对编程? 3.书中讲的敏捷流程变化大,效率高,但我感觉这只适用于小团队,人少才好管理,如果很多人的团队,能否在用敏捷流程? 4.如何避免产品开发后期有重大修改? 5.如何进行风险管理?能否用更多的例子来讲解它.

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

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