澹台君落
谁能给我推荐几本软件工程的书
展开全部 1、《机械工业协会 》 出版社：机械工业2、《软件估算——“黑匣子”揭秘 》 本书中，著名的软件开发书籍的作者Steve McConnell揭开了围绕在软件估算周围的层层迷雾。
作者在深入浅出地介绍了与软件估算有关的主要概念之后，深入、全面地介绍了与软件估算有关的多种估算方法。
本书的主要内容包括：估算与计划和项目控制，以及估算与目标和承诺之间的关系；不确定性锥与估算中的误差来源以及影响估算的各种因素；先计数、再计算，无法可想时才依靠判断的基本估算原则；用于估算软件项目的三个重要部分——规模、工作量和进度估算的基本方法；与规模、工作量和进度估算有关的特殊问题；估算的概率论观点以及如何采用适当的方式来表达估算结果中的不确定性；如何进行与估算有关的沟通，从而使技术人员和非技术人员达成共识。
本书主要面向软件开发项目中要进行估算的开发人员和技术管理人员。
但本书所涉及的与软件估算有关的背景知识，以及有关估算谈判和表达方式的讨论，对于非技术人员出身的主管和项目的其他有关人员同样大有裨益。
3、《软件设计精要与模式》——张逸 著 “给我一个支点，我就能撬起地球”。
关键不在于力量有多大，而在于如何合理地利用力量。
软件设计同样如此。
思想的确立，技巧的把握，将在很大程度上决定软件架构的合理性。
基于这样的目的，本书围绕着软件设计的核心内容，结合大量的实例与代码，充分地展示了软件设计之美，以及设计“力量”的巧妙运用。
内容涵盖了设计模式、重构、测试驱动开发、极限编程、软件体系架构设计等重要的设计方法与技巧。
这些内容是软件设计中最重要的“流行元素”，是程序员向设计师“涅磐”的基石，是从小工到专家的修炼法门。
本书关注的焦点是软件设计，涵盖了大部分与设计有关的基本要素，包括面向对象编程思想、设计模式、重构、测试驱动开发、极限编程以及软件体系架构设计。
其中，尤以设计模式为主，深入探讨了软件设计过程中的原则与模式，并结合大量的实例与代码演示了如何合理运用设计模式，改善程序模块的可复用性、可扩展性，实现模块间的松散耦合。
全书将软件设计理论与项目实践完美地结合起来，使其告别了纯理论研究的空泛，具有现实的指导意义。
本书共分为5篇，包括：设计之要、.NET Framework与设计模式、媒体播放器的设计之旅、设计模式应用实践以及.NET体系架构设计。
本书力求讲解浅显明白。
在技术探讨上，尽可能地深入透彻；在每一字的描述上，尽可能地简单易懂。
本书适用于所有希望提高软件设计水平的程序员、软件工程师，同时，对于软件设计师与系统架构师也具有一定的参考价值。
4、《SOA 原理·方法·实践》——毛新生 主编 本书并不是关于Web服务的又一本开发手册，抑或是开发技术的宝典之类的读物。
本书的作者来自于IBM软件开发中心的SOA技术中心，作为最早的一批从事SOA相关产品和客户项目开发的软件技术人员，见证了SOA从诞生到发展壮大的全过程。
而本书的目的在于将作者在项目过程中的经验介绍给读者，通过分析SOA产生的根源，以及SOA对业务模式和开发模式带来的变革，帮助读者理解什么是SOA，以及如何科学的实施SOA。
本书的内容分为三部分，将从作者的实际经验出发，分析SOA理念产生的合理性，然后分析SOA的相关开发技术，最后结合一个实例片断，讲述一个完整的SOA项目是如何设计完成的。
本书针对的读者是有一定经验的开发人员，例如，信息系统架构师，企业决策人员，对Web开发感兴趣的高年级计算机或相关领域的学生，以及任何希望了解SOA的广大技术人员。
现任IBM中国开发中心Web 2.0首席架构师，此前他曾任IBM软件集团企业解决方案部大中华区和北亚地区首席架构师与IBM SOA中国设计中心技术主管，在企业级软件方面拥有广泛、扎实、深厚的理论功底和丰富的设计与项目实施经验。
5、《软件架构设计》——温昱 著本书紧紧围绕“软件架构设计”这一主题，立足实践解析了软件架构的概念，阐述了切实可行的软件架构设计方法，提供了可操作性极强的完整的架构设计过程。
另外，本书从思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节，为广大程序员的成长提供了切中肯綮的指导。
6、《大道至简——软件工程实践者的思考》 本书是在“思想方法学”这一软件工程尚未涉足过的领域中的实习之作。
作者亲历国内软件工程的英雄时代、泡沫时代，从失败中醒觉而创建独特的思考方法，对软件开发、工程中的现状深刻反思，从而完成这本专著。
在缺乏独立思维、对国外工程理论亦步亦趋的国内工程界、开发业界，该书无疑是一份激荡新思的佳作。
本书是第一本讨论软件工程思想本源的书籍，也是第一本从工程实践出发溯源而论的佳作。
本书提出了审视软件工程的全新视角和软件工程的体系模型（EHM，软件工程层状模型）用非工程的方式重新解析软件工程现象，全面、细致而深刻地分析了工程中各个环节的由来、价值及其内在关系。
软件的架构与设计模式之什么是架构
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
具体地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行具体设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点，一是建筑风格，二是建筑模式。
独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。
所有的数字都如日历般严谨，风格雄浑。
难以想象这是石器时代的建筑物。
图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。
（摄影：作者）软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。
与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。
英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。
英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。
丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。
Party这个词的原意就是＂方＂、＂面＂。
政党起源的要害就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。
与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。
最为闻名的，当然就是模式理论和XP理论。
架构的目标是什么正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。
软件系统对于用户的商业经营和治理来说极为重要，因此软件系统必须非常可靠。
·安全行（Secure）。
软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
·可扩展性（Scalable）。
软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。
只有这样，才能适应用户的市场扩展得可能性。
·可定制化（Customizable）。
同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性（Extensible）。
在新技术出现的时候，一个软件系统应当答应导入新技术，从而对现有系统进行功能和性能的扩展·可维护性（Maintainable）。
软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。
一个易于维护的系统可以有效地降低技术支持的花费·客户体验（Customer Experience）。
软件系统必须易于使用。
·市场时机（Time to Market）。
软件用户要面临同业竞争，软件提供商也要面临同业竞争。
以最快的速度争夺市场先机非常重要。
架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。
每一个层次都含有多个逻辑元件。
比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。
·物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。
首先，一个软件系统中的元件首先是逻辑元件。
这些逻辑元件如何放到硬件上，以及这些元件如何为整...
软件详细设计说明书
展开全部 中培教育-（详细设计专题）时间 上午 下午 第一天 1、软件详细设计概述 系统设计目标描述 系统文档描述 系统架构文档描述 软件详细设计实践流程与计划 2、面向对象设计工具及UML编程语言 EA工具及案例介绍 用例图 类图 顺序图 状态图 活动图 组件图 部署图 协作图 对象图 3、软件详细设计过程 健壮性分析（获得边界对象、控制对象与实体对象） 转换需求场景（使用时序图转述需求，获得对象行为细节） 整理分析类（获得对象间关系） 对象状态建模（使用状态图建模） 局部分析阶段成果提交 评审局部分析成果（发布局部分析基线） 第二天 4、从需求到设计的过程 案例概述 识别系统需求中的概念策略 通过需求建立概念模型的指导原则 概念模型的关联添加原则和方法 概念模型的属性添加方法 系统顺序图的建立 系统行为契约分析 通过协作图设计活动之间的协作关系 建立概念类图 通过具体案例进行指导和演练 5、系统类职责分配模式（GRASP）与案例应用 案例概述 专家（expert）模式与应用 创建者（creator） 模式与应用 高内聚（high cohesion） 模式与应用 低耦合（low coupling） 模式与应用 控制者（controller） 模式与应用 多态模式与应用 纯虚构模式与应用 中介者模式与应用 “不要和陌生人讲话” 模式与应用 CRC卡片与应用 第三天 6、用户界面规划设计 UCD（以用户为中心的设计）的概述 整体用户体验的重要性 设计师，程序员和用户的思维模型 UCD的主要原则 界面开发的过程及周期 建立符合标准软件产品 交互流程设计：概念草图，系统流程展示 视觉设计原则 图像制作技巧 、图文资源管理 功能的任务化与场景设计 用户界面方案设计 7、数据库详细设计 数据库基本设计原则 基于OO的数据库设计 数据库性能设计 数据库安全设计 数据库程序规划与业务混入问题 8.经典设计模式及其案例应用 1）创建型设计模式与案例使用 简单工厂模式 工厂方法模式 抽象工厂模式 单例模式 2）结构型设计模式与案例使用 适配器模式 组合模式 装饰模式 外观模式 代理模式 3）行为型设计模式与案例使用 命令模式 迭代器模式 观察者模式 状态模式 策略模式 模板模式 --更多百度搜：中培教育，tel：①⑧⑦零一三七84零零...
装修设计免费好用的软件有哪些
展开全部 其实软件非常多，常规大家用的就是3Dmax，草图大师等，但是还有很多其他的，下面详细说明：一、爱福窝软件特色：1、云设计、云存储、3-5分钟出效果图2、2D/3D视角自由切换设计3、效果图质量不错，全景图、VR图挺炫酷的4、设计方案可以直接进行水电布线5、可以用3Dmax上传模型，方案能导入AutoCAD6、购买福币来渲图。
软件不足：1、缺少室外环境比如庭院设计2、没办法设计商铺、办公楼一句话评价：上手简单、真实家具模型、设计能快速调整。
二、Sweet Home 3D软件特色：1、有离线和在线操作软件，但UI设计较为粗糙2、用户2D视角操作，3D视角浏览3、支持windows、mac、Linux 和 Solaris等系统4、支持java开发拓展插件软件不足：1、操作界面不够简明2、墙体是否封闭没有提示3、模型单一，户型需要自己绘制。
4、可以自己建模上传，需要一定的建模能力。
一句话评价：支持mac、但上手比较费时间。
三、VRHome软件特色：1、所有操作均在3D视角下进行2、支持VR眼镜浏览3、推荐配置：四核CPU/2G独立显卡/16G内存4、软件创建于2016年3月初，属于新生代家居设计软件软件不足：1、vrhome建议从官网下载，下载站的可能有插件缺失。
2、需要较高的电脑配置，不然会很卡。
3、户型与模型数量较少。
4、户型模型和家具模型都需要下载，网速不好的时候体验较差。
一句话点评：全3D视角设计，电脑配置要求高。
四、我家我设计软件特色：1、单个空间以步骤形式设计软件不足：1、模型少2、缺乏最核心的全户型设计3、户型与模型可调整程度低一句话点评：设计过程步骤化，缺少全屋设计。
注意事项：1、业主自己设计或一些简单的局部房屋改造可以用这些软件。
2、对于全屋装修，如果不清楚房屋设计规范与准则的，还是建议业主请设计师或装修公司。
3、上述这些软件用于业主和设计师之间沟通倒是不错。
4、暂时没有发现能在移动端使用并且功能全面的室内设计软件。
5、设计工具只是辅助，都是为了更好的做设计方案。
新手用容易上手的设计软件，设计从业者用3Dmax、AutoCAD、vray等，这并不冲突，反而更加容易交流...
软件设计的基本步骤是什么
展开全部 软件开发是指一个软件项目的开发，如市场调查，需求分析，可行性分析，初步设计，详细设计，形成文档，建立初步模型，编写详细代码，测试修改，发布等。
软件是怎么样开发出来的 第一个步骤是市场调研，技术和市场要结合才能体现最大价值。
第二个步骤是需求分析，这个阶段需要出三样东西，用户视图，数据词典和用户操作手 册。
用户视图 是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了 很多操作方面的流程和条件。
数据词典 是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了一半多。
用户操作手册是指明了操作流程的说明书。
请注意，用户操作流程和用户视图是由需求决定的，因此应该在软件设计之前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺序不分，开发工作和实际需求往往因此产生隔阂脱节的现象。
需求分析，除了以上工作，笔者以为作为项目设计者应当完整的做出项目的性能需求说明 书，因为往往性能需求只有懂技术的人才可能理解，这就需要技术专家和需求方（客户或公司市场部门）能够有真正的沟通和了解。
第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。
作为快速原型设计方法，完成概要设计就可以进入编码阶段了，通常采用这种方法是因为涉及的研发任务属于新领域，技术主管人员一上来无法给出明确的详细设计说明书，但是 并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和 经验教训的总结，还要重新进行详细设计的步骤。
第四个步骤是详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把 具体的模块以最'干净'的方式（黑箱结构）提供给编码者，使得系统整体模块化达到最 大；一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细 设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要 设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。
换言之，一个大型软 件系统在完成了一半的时候，其实还没有开始一行代码工作。
那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。
第五个步骤是编码，在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/ 2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提 高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都 出现过。
编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永 远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候 吗？从来没有！ 第六个步骤是测试 测试有很多种： 按照测试执行方，可以分为内部测试和外部测试 按照测试范围，可以分为模块测试和整体联调 按照测试条件，可以分为正常操作情况测试和异常情况测试 按照测试的输入范围，可以分为全覆盖测试和抽样测试 以上都很好理解，不再解释。
总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会又不可预料的问题存在。
完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营 状况并持续修补升级，直到这个软件被彻底淘汰为止。
什么是软件开发的核心问题 按照软件工程鼻祖，《人月神话》作者 Brooks 在“没有银弹——软件工程中的根本和次要问题”一章中阐述的思想，软件开发的核心问题就是如何从概念上对一个复杂的业务系统进行建模。
这个建模是含义广泛的，不仅仅包括对象建模，还包括数据建模、算法建模等等一系列的内容。
总而言之是要先找到解决复杂问题的突破口（先要搞明白需要做什么，然后再考虑如何做）。
至于采用什么表示方法（简单文本、UML 图、E-R 图）、采用什么高级语言、是否一定要用面向对象、使用什么开发工具都是次要的问题。
软件开发方法 软件开发方法（Software Development Method）是指软件开发过程所遵循的办法和步骤。
软件开发活动的目的是有效地得到一些工作产物，也就是一个运行的系统及其支持文档，并且满足有关的质量要求。
软件开发是一种非常复杂的脑力劳动，所以经常更多讨论的是软件开发方法学，指的是规则、方法和工具的集成，既支持开发，也支持以后的演变过程（交付运行后，系统还会变化，或是为了改错，或是为了功能的增减）。
关于组成软件开发和系统演化的活动有着各种模型（参见软件生存周期，软件开发模型，软件过程），但是典型地都包含了以下的过程或活动：分析、设计、实现、确认（测试验收）、演化（维护）。
有些软件开发方法是专门针对某一开发阶段的，属于局部性的软件开发方法。
特别是...
软件设计应先学习什么啊？
一个软件测试工程师的学习体验 我最初参加测试工作的时候，不知道什么是软件测试，集成测试和系统测试的概念经常混淆， CMM 是什么就更加不知道了。
那时候最简单的开关机也是通过直接拔插电源完成，安装系统对我来说简直是有史以来人类的最高技能，对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手，身具杀人于无形之绝世秘技。
拿破仑说不想当将军的士兵不是好士兵，我最初的梦想就是想成为软件测试的高手，傲视天下。
所以不断偷师，总结经验，自认为掌握了成为高手的几个秘技，这几年混迹 “ 江湖 “ 还算无往而不利。
不敢独享，望与吾辈测试人员切磋，早日总结成功密技之大成，助新进人员早日入门，也算不愧对东北活雷锋的称号。
第一招 学会利用网络 刚参加工作面对浩瀚的网络世界，当时如刘姥姥进大观园，什么都新奇，什么都想要，从网上下载很多源程序的代码，软件技术文档之类，恨不得把所有的好东西收集到手中，其实有些在他人看起来就是垃圾一堆。
当时觉得有了这些 “ 武林秘籍 “ ，成为高手指日可待。
最初参加工作由于自己工作努力有幸转为开发，加入项目组后我的习惯还是没有改，反而变本加厉，手中的资源更加多，上网的时间更加频繁。
一次项目经理分配任务，觉得依靠手中的秘籍加上自己的 “ 聪明才智 “ 很快会完成，不料短短的时间，所有的一切变成了马奇诺防线。
解决问题很慢，思路不清晰，项目经理在对我施压的过程中教会了我终身难忘的一招，学会利用网络寻找要解决问题的答案，从此 Google 成了我的最爱，关键字成了我变化的招数。
在软件测试工作中，他帮我解决了很多疑难问题，解答了很多令我迷惑的地方。
也是我帮助测试同行解决问题手段之一，很多软件测试新手，甚至老手都没有意识到自己手上就握有 “ 无敌秘籍 “ ，所以只要你耐心找，答案就在身边。
这里总结一下利用网络搜索引擎的技巧： ? 组合搜索 每次搜索某个文件，如果只给出一个单词进行搜索，经常会出现成千上百万计的匹配网页。
然而如果再加上一个单词，那么搜索结果会更加切题。
? 选择表述内容的词组 一般我在网页搜索引擎的时候，选择一些可以表达我要查找内容的关键词组，用来缩小搜索范围，从而找到搜索结果是最好的办法。
运用词组搜索涉可以先先简单地输入一个问题作为词组搜索，如果仍然找不到合适的，那就用多个可以表达要查询内容的关键字进行查询。
? 定位信息来源 有的时候用词组搜索不到或者无法准确表达所需信息。
可以用另一种方法直接到信息源，就是直接到到提供某种信息的站点去。
可以用公式 “www. 公司名 .com” 去猜测某一组织的特点。
从而得到所要搜索的信息的主要词组 其实网络上还有很多关于搜索技巧的文章，大家可以自行学习。
千万要记住搜索引擎是帮助你成功的有力武器。
第二招 学会动手 参加软件测试工作后，随着工作经验的增长自我感觉越来越好。
在公司里也逐渐受到同事领导的重视，一次针对公司的新的软件功能进行测试的时候，像往常一样 “ 随手 “ 测试出了几个 Bug ，然后 “ 仔细 “ 的填写了 Bug 单（这个 Bug 的现象已经出现了很多次了）。
这时候测试经理走过来，重新复查了一下填写的 Bug 。
他在重现我的 bug 的过程中，简化了我的输入变化， bug 神奇的又出现了，同样的现象，他关闭软件重新变化输入，扩展出 10 几个变化后，软件不动了，内存不断上升。
终于他找到了产生软件的 Bug 的原因，然后对我说 “ 寻找 Bug 要准确定位，我们开发团队是一个整体，时间是等量的，时间不在你身上浪费，就是在他身上浪费。
如果测试人员每次发现的 bug 描述不清楚，并且多个问题潜在的错误原因是一个，虽然操作可能稍微有些变化。
这样开发人员在重现 bug 的时候他要调试跟踪判断，很花费时间，而且效率低。
如果测试人员发现 bug 的时候多动手可以更加准确的定位 bug 步骤和原因，给开发人员最精确的步骤和准确的描述，这样整个团队才能高效，所以需要大家协作！。
“ 。
在以后的日子里，每次解决问题的时候我都记得多试验几次，多尝试。
网上很多朋友还有同事问我问题的时候，其实他们只是万里长征就差一步，只要再多动手实验一次就可以达到目的了。
所以多动手，多尝试。
第三招 思考自己所作的 刚开始入行的时候，总是思考如何做好软件测试。
认为公司的测试流程混乱总是很郁闷，认为自己学不到东西，如何才能测试好产品，常说心动不如行动，以前看到古龙小说中经常出现的场景无名小子不断挑战高手，总结积累。
我总结了有些经验是实战中得到的，所以不断尝试引入新的测试流程然后评估，这个过程虽然很痛苦，但是从中积累了不少经验。
这段时间让我学习到了很多东西，接触了 ISO,CMM ，测试管理工具，自动化工具（因为公司不正规给了我很多学习的机会，后来到了比较大的软件公司后，以前的经历给了我更多的发展机会，因为大公司非常正规了，公司内部人员分工明确，所以能力的锻炼反倒少了）。
由于工作中经常写报告反倒养成了总结教训的习惯，因为纸面上的东西是永远也忘不掉的。
在写的过程中可以不断补充扩展，整个过程...
软件开发有哪些模式
展开全部快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题）快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善）优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险缺点：A、 所选用的开发技术和工具不一定符合主流的发展B、 快速建立起来的系统加上连续的修改可能会造成 产品质量底下增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）优点：1、 人员分配灵活，一开始不需要投入大量人力资源2、 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）3、 增量能够有计划的管理技术风险缺点：1、 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析注：这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程原型模型：（样品模型，采用逐步求精的方法完善原型）主要思想：先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。
原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，采用方法：原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应优点： （1）开发人员和用户在“原型”上达成一致。
这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
（3）降低成本。
缺点：1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。
2、不宜利用原型系统作为最终产品。
采用原型模型开发系统，用户和开发者必须达成一致： 喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分无间隙：它在各项活动之间没有明显边界（如分析和设计活动之间）优点：1、 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程不便之处：1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况螺旋模型：（适合用于需求经常变化的项目）它主要是风险分析与评估，沿着螺线进行若干次迭代，过程：1、 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件2、 风险分析：分析评估所选方案，考虑如何识别和消除风险3、 实施工程：实施软件开发和验证；4、 客户评估：评价开发工作，提出修正建议，制定下一步计划。
优点：1、 它由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发中缺点：1、 难以让用户确信这种烟花方法的结果是可以控制的2、 建设周期长（而软件技术发展比较快，所以经常会出现软件开发完毕后，和当前的技术水平有很大的差距，无法满足当前用户的需求）3、 除非软件开发人员擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险瀑布模型：（从本质来讲，瀑布模型是一个软件开发架构，重复应用）（核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开，依照软件生命周期自上而下，相互衔接的次序）缺点：1、 在项目各个阶段之间极少有反馈，各个阶段的划分完全固定，阶段之间产生大量的文档，增加了工作量2、 用户只有在项目生命周期的后期才能看到结果，增加了开发的风险3、 需要过多的强制完成日期和里程碑来跟踪各个项目的阶段4、 在每个阶段都会产生循环反馈（如果有信息未被覆盖或是发现问题了，必须返回到上一个阶段并进行适当的修改，只有当上一阶段都被确认后才进行下一阶段）5、 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果优点：1、 为项目提供了按阶段分的检查点2、 当完成一个阶段后，只需要去关注后续阶段3、 可在迭代模型中应用瀑布模型按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试注：由于每个阶段都会产生循环反馈，...
转载请注明出处51数据库 » 《软件设计精要与模式》
