关于 《构建之法》

1.关于《构建之法》:

看了第一章,关于《构建之法》的概述,通过一定的软件流程,在预计的时间内发布好的软件,软件工程对于开发一个好的软件很重要,在开发中,程序很重要,软件开发流程也很重要。

软件具有:复杂性,不可见性,易变性,服从性,非连续性。还有其他特性。

软件工程的目标:创造“足够好”的软件。

构建之法的目标:

研发出符合用户需求的软件;

通过一定的软件流程,在预计的时间内发布“足够好”的软件;

能证明所开发的软件是可以维护和继续发展的。

可行性分析->项目立项->需求分析->概要设计->详细设计->编码->单元测试->系统测试->集成测试->验收测试->项目上线。

在每个流程尽量减少错误,就会在预计的时间完成足够好的软件。

单元测试:让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的,量化的保证。

创建单元测试函数的主要步骤:

1.设置数据;

2.使用被测试类型的功能;

3.比较实际结果和预期的结果

回归测试的目的:

1. 验证新的代码的确改正了缺陷;

2.同时要验证新的代码有没有破坏模块的现有功能,有没有Regression。

回归测试最好要自动化,因为这样就可以对于每一个构建快速运行所有回归测试,以保证尽快发现问题。单元测试是回归测试的基础。

个人软件开发流程(PSP):

1.不局限于某一种软件技术,而是着眼于软件开发的流程,这样,开发不同应用的软件工程师可以相互比较。

2.不依赖于考试,而主要靠工程师自己收集数据,然后分析,提高。

3.在小型,初创的团队中,很难找到高质量的项目需求,这意味着给程序员的输入质量不高。在这种情况下,程序员的输出往往质量也不高,然而这个并不能全部

由程序员负责;

4.psp依赖于与数据;

5.psp的目的是记录工程师如何实现需求的效率,而不是记录顾客对产品的满意度。

软件工程包括了开发,运营,维护软件的过程中的很多技术,做法,习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中,叫做软件开发流程;软件开发流程的目的是:提高软件开发,运营,维护的效率,以及提升用户的满意度,软件的可靠性和可维护性。

初级软件工程师的成长:

1.积累软件开发相关的知识,提升技术技能;

2.积累问题领域的知识和经验;

3.对通用的软件设计思想和软件工程思想的理解;

4.提升职业技能;

5.实际成果。

工程师必须要做到以下几点:

1.阅读:4-6 篇经典文献的深入分析和阅读;

2.工作经验:要参与并完成6个具体的项目;

3.课程:要参加3个专门的课程。

从瀑布模型开始的各种模型都有有一个共同点:重计划,重事先设计,重文档表达。

敏捷开发的原则是:

1.尽早并持续地交付有价值的软件以满足顾客需求;

2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势;

3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短;

4.业务人员和开发人员在项目开发过程中应该每天共同工作;

5.以有进取心的人为项目核心,充分支持信任他们;

6.无论团队内外,面对面的交流始终是最有效的沟通方式;

7.可用的软件是衡量项目进展的主要指标;

8.敏捷流程应能保持可持续性的发展。领导,团队和用户应该能按照目前的步调持续合作下去;

9.只有不断关注技术和设计,才能越来越敏捷;

10.保持简明--尽可能简化工作量的技艺——极为重要;

11.只有自我管理的团队才能创造优秀的架构,需求和设计;

12.时时总结如何提高团队效率,并付诸行动。

MSF(微软解决方案框架)基本准则:

1.推动信息共享和沟通;

2.为共同的远景而工作;

3.充分授权和信任;

4.各司其职,对项目共同负责;

5.交付增量的价值;

6.保持敏捷,预期和适应变化;

7.投资质量;

8.学习所有的经验;

9.与顾客合作。

MFS团队模型:测试,项目管理,用户经验,测试,发布管理,开发,交流。

MFS过程模型:构思->远景/范围认可->计划->项目计划认可->开发->开发完成->稳定->发布就绪认可->部署->部署完成。

软件需求:

1.获取和引导需求;

2.分析和定义需求;

3.验证需求;

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

PM(项目经理)的能力要求和任务:

1.观察,理解和快速学习能力;

2.分析管理能力;

3.一定的专业能力;

4.自省的能力。

用户体验要素:

1.用户的第一印象;

2.从用户的角度考虑问题;

3.软件服务始终都要记住用户的选择;

4.短期刺激和长期影响;

5.不让用户犯简单的错误;

6.用户体验和质量;

7.情感设计。

Bug:软件的缺陷;

Test Case:测试用例;

Test Suite:测试用例集;

软件测试分为:黑箱和白箱。

也可分为功能测试和非功能测试。

程序的质量体现在软件外在功能的质量。

问题:

1.如何才能创新,怎样才能锻炼自己的创新意识?

2.软件工程怎样才能学好?

3.每个软件都需要完整的开发流程吗?如果没有会怎么样?

4.关于《构建之法》怎样读才能抓住核心?

5.在自身没有多少编程能力时怎样将书中的知识运用到实践中?

时间: 2024-10-10 10:50:49

关于 《构建之法》的相关文章

构建之法——读书笔记(8)

<构建之法>第十&十一章 主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为"典型用户和场景"以及"软件设计与实现". 其中第十章大部分内容包含: 用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

简读《构建之法》,所想问题展示

1,<构建之法>这本书全局语言通俗,学生很容易读懂,但是存在一个隐患:学过软件工程,我们只是笼统的理解,而对这方面的专业知识很少了解,该怎么办? 2,书中提到的软件结构,软件设计与实现具体是怎样的?怎么理解它们之间的关系? 3,软件在不断更新和增加功能的负担下,一定程度下会崩溃.若有一个软件,即将考虑添加下一个功能,但是在添加这个功能之后,系统一定会崩溃,但是这个功能对这个软件的市场前景起着至关重要的作用,这是该怎么办? 4,软件设计和软件构建有区别吗?不同之处是什么? 5,当软件中的依赖关系

构建之法阅读笔记05

2017.5.20 今天阅读的是<构建之法>第8章需求分析的阅读笔记,我们如果要开始做一个软件,最先要进行的就是需求分析,我们应该充分的了解我们这个软件是否具有前景,我们为用户提供的服务是不是用户所需要的,这一章详细的叙述了如何进行需求分析. 首先是获取和引导需求,我们应该找到软件的利益相关者,了解挖掘他们对软件的需求,引导他们表达出真实的需求.然后分析和定义需求,对各个方面的需求进行规整,定义需求内涵,从各个角度将需求量化,然后估计实现这些需求所需要的时间和资源,确定各个需求的优先级.紧接着

《构建之法》学习(5)——团队和流程

<构建之法>学习(5)--团队和流程 1.非团队和团队   团队共同的特点: 团队有一致的集体目标,团队要一起完成这目标 团队成员有各自的分工,互相依赖合作,共同完成任务 2.软件团队的模式       一窝蜂模式       主治医师模式 有首席程序员,他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作.       明星模式 主治医师模式运用到极点,可以蜕化为明星模式,在这里,明星的光芒盖过了团队其他人的总和.       社区模式 社区由很多志愿者参与,每个人参与自己

《构建之法》学习(3)——软件工程师的成长

<构建之法>学习(3)--软件工程师的成长 1.1个人能力的衡量与发展 积累软件开发相关的知识,提升技术技能 积累问题领域的知识和经验 对通用的软件设计思想和软件工程思想的理解 提升职业技能 实际成果      衡量软件开发的工作量和质量 项目/任务有多大? 花了多少时间? 质量如何? 是否按时交付? 1.2软件工程师的职业发展 职业发展--考级之路 职业成长--Steve McConnell版本 职业成长--大公司版本 职业成长--自我评估 1.3技能的反面 通过玩魔方的例子说明了技能提升的

《构建之法》——软工学习进度(2)

如何衡量一个软件工程师 如何衡量一个软件工程师?这是<构建之法>第三章的核心问题.第一章讲述了团队的流程,第三章则是对第一章的具体描述,从笼统的团队具体到个人.软件开发流程不光指团队的流程,还包括了个人开发流程,因为软件团队是由个人组成的,简而言之,个人在团队中也有独立的流程.那么问题来了,如果我们去面试,该如何定义我们自身呢?又或者说,看到一个同行的软件工程师,该如何形容他的技术? 第三章通过对足球的比喻,向我们形象的阐述了这个问题的关键.足球中有传接.盘带.射门等具体技术,映射到软件工程上

《构建之法》---软件工程师的成长&amp;两人合作

本周学习了<构建之法>第三.四章的内容. PSP对软件开发的工作质量的衡量简单指标为:项目/任务有多大.花多少时间.质量如何.是否按时交付共4个因素.而要成为一名合格的软件工程师,要对上述4个因素尽量在用户需求上做到尽善尽美. 软件工程师的职业发展有: 职业发展---考级之路 计算机等级考试 (http://sk.neea.edu.cn/jsjdj/index.jsp) 全国计算机技术与软件专业技术资格考试 (http://www.rkb.gov.cn/  ) 职业成长---Steve McC

构建之法--第二篇

构建之法--第二章 在这一周中,我计划学习了<构建之法>的第二章,我认为从第二章开始,才算真正进入到了这本书的主题.这一章讲到的是个人技术和流程.首先,个人技术是衡量你是否能成为一名合格的软件工程师.而想要组建一个优秀的软件开发团队,就必须要有一名软件工程师.流程则是团队来管理开发活动的经过. 个人技术:其中就包括了三点,即单元测试.回归测试.效能分析. 单元测试:我们为什么需要做单元测试呢?这是为了让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的.

《构建之法》读书笔记二

这周读了<构建之法>的第二章.第二章主要讲到了个人技术和流程. 软件是由多人合作完成的,不同人员的工作相互有依赖关系.一个团队需要一定的流程来管理开发活动,每个工程师在软件生命周期所做的工作也应该有一个流程.所以就引进了一个新的名词叫做PSP--个人软件开发流程.但是要做到每个人的模块的质量得到稳定.量化的保证,单元测试就是一个很有效的解决方案.我们可以用vsts写单元测试,这是一个新的软件,我从来没有接触过,所以也不会用.只看了一下代码. 好的单元测试应该准确.快速地保证程序基本模块的正确性