精华内容
下载资源
问答
  • 2008-09-06 18:20:00
     

    神话的破灭

    但是随着软件规模的扩大和软件复杂度的提高,无序的开发过程开始显示出它的弱点,首先,开发质量没有保证。软件错误随着软件复杂度的增加而增加。几次恶性的软件错误导致的巨大损失导致软件危机的出现,软件危机让人们开始怀疑到底能不能开发出可靠的软件。其次,开发进度经常拖延,由于开发过程的随意性和无序性,软件产品更像是软件开发者兴之所至的手工作品,而不是拥有标准质量的工业产品,bug的不断增加和修改bug难度的增加,导致开发进度经常拖延,并且无法确定最后的交付时间。因为没有办法为寻找bug设定时限。软件产业面临迷茫。

     

    软件设计变身软件工程

      

    为了摆脱困境,一些软件工程专家开始借鉴建筑,机械和汽车工业的流程的概念和方法试图建立软件工程方法和过程控制及管理模式。一大批软件开发的模型,瀑布模型,螺旋模型等等被提了出来。这些方法的共同特点就是采用严格的开发计划指导设计过程,并控制过程的执行,所以这些方法被统称为计划驱动的工程方法,简称计划驱动方法,也就是传统软件开发方法。计划驱动方法的共同思想根基就是传统工业的生产方法和过程。传统工业生产过程是典型的计划驱动模式,它已经被证明是行之有效的产品质量控制和管理方法和过程,它可以大规模的生产具有一致质量的大量工业品。一大批软件专家坚信它能够被移植到软件生产中来并且能够给软件生产带来革命性的变革。

     

    这种方法随后得到了大规模的推广和实施。自上个世纪60年代以来,软件工程思想逐渐形成与发展,也出 现了很多软件开发模型与方法,例如瀑布模型、快速原型、增量模型和螺旋模型等。而在90年代以后,卡耐基梅隆软件学院推出的CMM,更是对于软件开 发的过程管理,提出了确切的衡量指标。这些方法取得了一些成果,软件的及时交付和质量有了一定的保证。但是这种方法并没有像传统工业方法那样取得巨大的成功,计划驱动方法从来没有被充分证明总是有效的,最近的研究表明,依然有50%的项目会拖延交付,有30%以上的项目会超出预算,软件开发领域的项目情况比软件工 程刚刚提出的时候相比,只是有很小的提高。软件开发的生产率依然很低。

     

    这是什么原因呢?答案就在于软件生产的特殊性。生产软件不是生产汽车,软件工程也不是机械工程。完全借鉴工程方法不合“国”情。因此注定要失败。软件开发还处于初级阶段,远没有达到靠一套什么工程方法就可以达到大规模生产出具有一致质量的软件产品的程度。软件生产过程和传统工业生产过程至少存在以下几点区别:1,设计需求特点不同。传统工业的设计需求比较固定。因为设计一旦确定就很难改变,传统工业的设计基本上是一次完成的,所以生产过程才可以按照固定计划和方案进行,当然,新的,更加灵活多变的工业生产模式也已经悄然出现,但是整个工业生产模式还没有发生根本改变;而软件的特征之一就是软件的灵活性,软件需求的可变性,适应性很强,这也是软件被称之为“软”的原因。即使没有接触过软件开发的人也认为只要修改几行代码就可以轻易改变软件,所以软件的客户更容易改变需求,并不断提出新的需求。这样一来,依照事先的计划进行设计就很难满足用户快速变化的要求。2,人在过程中的作用不同。传统工业比如建筑和机械行业,设计过程在产品生产过程只占很少的部分,可能占所有工作量的10%左右,因此,依靠人完成的设计工作很少,大量的工作可以依靠机器和生产线完成,大量的工人只需要很少的技能就可以辅助机器完成工业生产工作;而软件生产是一种智力密集的活动。设计活动几乎是软件生产的全部过程,而设计工作,包括编码都要靠人,即程序员完成。在软件生产中,能够自动化完成的生产工作只有编译,链接和安装等工作,这些工作和设计编码工作比起来微乎其微。在传统建筑行业中,设计人员只要设计出图纸就可以交给任何一个工人完成实际工作;而在软件生产中,类似的各种设计工具,设计语言比如UML,不可能达到这样的程度,更多的设计决策只有在编码时才能确定。因此在软件生产中,一般我们认为的设计和编码不可能完全的分开,初期的设计在后期不断修正是司空见惯的。下面我们再详细地讨论软件设计的这些特殊之处。

     

    需求是可以预测的吗?是固定的吗?

    计划驱动方法的一个重要假设就是设计过程是可预测的,需求是可以预测的,工作量是可以预测的。为了过程的可预测,就必须实现固定设计需求,然后根据设计需求,制订开发计划,分配设计资源,最后按照开发计划完成开发任务。

    这个假设和过程设计在传统机械行业是行得通的,但是,对于软件设计,这个前提很少成立,软件设计的需求是固定的吗?不是,软件设计的目标就是要适应不同的情况,弹性应对不同的需求,否则就不要成为“软”件了。因此变化的需求才是软件设计的一般假设,软件必须要适应变化才是软件的真理,而不是相反。

    是不是存在需求固定的软件呢?可能神州七号宇宙飞船的软件设计需求是固定的,并且有充足的经费保证完成它。但是,对于大多数商业软件来说,需求必须适应千变万化的商业市场的实际,而不是坐在办公室里的所谓规划出来的需求。正所谓“树欲静而风不止”,就是客户想固定需求,有时候也不得不根据市场的新动向改变需求,以应付市场竞争的压力;还有一点是,由于软件的非直观可见性,客户在设计初期可能根本不能说明他到底要什么功能,或者什么东西是适合的;只有等待产品出来之后,经过试用,客户才真正了解他到底要什么东西,因此软件的改动基本上是不可避免的。因而采用计划驱动方法实施的项目基本是延误的,或者说基本上是失败的。

     

    软件过程中人的作用

    计划驱动方法的核心就是设计出一个标准化的,不依赖于特定人的流程。在计划驱动方法中,个人的作用弱化了,程序员变成了可以任意替换的机器零件。一个项目只要有项目经理,客户经理,软件架构师,程序员,测试员等等各种角色并且各自扮演好各自的角色就可以保证开发出符合要求,满足进度,高质量的软件。这个方法非常符合管理者的要求和熟悉的思路,通过这样的过程,卖白菜的也可以管理软件项目,只要他严格地按照事先的计划和管理的流程执行就行了;通过这样的流程,原来高贵的软件设计者现在变成了蓝领工人,就象生产线上的工人。管理者重新控制了软件产品的生产。这是管理者梦寐以求的结果。

    但是,人真的是无足轻重的吗?艾克·卡文曾经帮助 IBM做关于OO(面向对象)方面的研究工作。他在做这些工作的时候,最主要的任务是访问不同的开发项目,发现成功的项目到底是哪些因素使得这个项目成功。他发现最后 得到的结果非常奇怪,所有的成功的项目他们之间没有一点在过程方面共通的地方。这些项目所共通的唯有一点共通:他们拥有能力非常强、交流非常好的开发团 队。

    在软件开发的过程当中,其实最核心的部分应该是开发人员本身。但是,计划驱动的开发方法喜欢把编程人员当成传统工业中的机器来对待,以机器为中心的传统机械生产模式相对来说是静态的,一成不变的,容易控制的。而软件设计是一种智力活动,必须依靠人而不是“编程机器”完成,人与人是有差异的,人是有感情的动物,人的生产率和他自身的状态情绪有很大关系。希望通过过程管理把人变成统一的,没有差异的机器是不可能的。

     

    更多相关内容
  • 本文来自于云栖社区,本文主要介绍了行为驱动开发BDD,如何确保达成共识,以及BDD的方法介绍,希望对您的学习有所帮助。行为驱动开发(Behavior-DrivenDevelopment,BDD),是一种敏捷开发的技术,想必大多数同学都对...
  • 行为驱动开发(BDDBehaviorDrivenDevelopment)指开发者站在客户的角度来观察系统,思考系统应该具有什么样的行为才能满足客户需求的这样一种开发过程。BDD基于一种“通用语言”定义了同时能被客户和开发者理解的...
  • 这意味着开发过程中的任何阶段只有在前一个阶段完成时才会开始。瀑布方法没有定义返回到上一个阶段来处理需求变化的过程。 瀑布模型适合于不注重改变需求的项目,例如:   1.由提案请求(RFP)发起的项目,客户有...

    =======================================================================
                  Software Engineering notebook

    参考资料:
    [1]:https://melsatar.blog/2018/02/16/the-waterfall-model-a-different-perspective/
    [2]:Software Engineering Tenth Edition

    对于软件工程而言,没有放之四海而皆准、适用于所有不同类型软件开发的过程模型。正确的过程取决于客户和管理需求、软件使用所处的环境,以及所开发的软件类型。

    =======================================================================

    在这里插入图片描述
    瀑布模型是一个线性顺序流。在这个过程中,进展被看作是通过软件实现阶段稳定地向下流动(像瀑布一样)。这意味着开发过程中的任何阶段只有在前一个阶段完成时才会开始。瀑布方法没有定义返回到上一个阶段来处理需求变化的过程。

    瀑布模型适合于不注重改变需求的项目,例如:
      1.由提案请求(RFP)发起的项目,客户有非常清晰的文档化需求
      2.关键任务项目,比如航天飞机
      3.嵌入式系统。

    下面是使用瀑布模型时需要考虑的事项:

    • 项目要求是明确的和固定的。
    • 工程团队对于在不同项目中所使用的技术有清晰的认识。
    • 项目不能以迭代的方式交付。
    • 文档是至关重要的。
    • 专业的项目管理技能。
    • 项目成本已定。

    waterfall model的优缺点:

    优点缺点
    易于向用户解释。向客户交付可行的解决方案需要完整的生命周期。
    结构方法。它完成后很难再返回到任何一个阶段
    阶段和活动定义明确。它假设可以冻结系统的需求而不进行任何更改或增强。
    项目经理更容易计划、安排项目、利用资源和定义项目周期。一点灵活性和调整范围是困难和昂贵的。
    每个阶段的审批可确保及早发现错误/误解。它需要更多的时间在项目的前期进行详细的计划,因为需求是清晰的和固定的,并且将详细的计划交付给客户应该是可见的。
    每个阶段都有具体的可交付成果。它延迟了在需求、设计和实现中发现许多问题的测试阶段。

    原文作者:Mohamed Sami,将waterfall model称为SDLC模型之父,不是因为它是第一次引入的,而是因为所有其他模型都是基于瀑布模型进行设计而设计的,以增强其功能并消除其不足,从而确保更好的交付。

    Mohamed Sami认为瀑布模型的主要缺陷是,它关注的是项目实现,而不是客户,不能实现对客户的快速业务价值。客户应该等待整个生命周期看到结果,这可能是好事,也可能是灾难。我认为我们不需要在开发生命周期的不同角度上达到上面图片中描述的困境,这就是为什么选择合适的模型对于能够根据需要交付预期的业务价值是非常重要的。

    展开全文
  • 在本文中,笔者将介绍VisualStudio2010UltimateBeta2版本中的MSFforAgile的Scrum和XP敏捷思想与VSTS2010强大的测试功能,通过对这些内容的阐述,让读者了解在VSTS2010中的敏捷测试驱动开发方法,以便于.NET开发人员...
  • 方法改进以"原型法"为基础,通过在软件界面原型的基础上增加了"成员属性信息"、"成员约束信息"和"非功能...它能够有效的对软件设计和开发过程进行定义和限制,避免出现在需求分析过程中信息缺失而导致的开发风险。
  • DDD领域驱动开发

    千次阅读 2021-09-15 14:46:02
    文章目录DDD(Domain Driving Design)领域驱动开发架构对比微服务的问题战略设计(业务层面-业务架构)战术设计(技术层面-系统架构):DDD和微服务 DDD(Domain Driving Design)领域驱动开发 架构对比 单机架构...

    DDD(Domain Driving Design)领域驱动开发

    1、微服务设计为什么选择DDD

    1、架构对比
    • 单机架构:数据驱动架构

    • 集中式架构:面向对象的方式(三层架构)

    • 分布式微服务架构:应用之间解藕,解决单体用扩展性和弹性伸缩能力不足问题

    2、微服务的问题
    • 微服务粒度

    • 怎样拆分

    • 边界是什么

    DDD 核心思想是通过领域驱动设计方法定义领域模型,从而确定业务和应用边界,保证业务模型与代码模型的一致性。

    img
    3、战略设计(业务层面-业务架构)

    建立领域模型、划分领域边界,从业务的视角来划分微服务边界(收敛的过程)

    • 实体
    • 命令
    • 事件

    领域模型:指导微服务的设计和拆分。事件风暴是建立领域模型的主要的方法,

    事件风暴:

    • 从发散到收敛的一整个过程
    • 采用方法:用例分析、场景分析、用户旅程分析
    • 产出:产出实体、命令、事件等领域对象,将领域对象从不同维度进行聚类形成聚合限界上下文等边界,建立领域模型

    逻辑边界、物理边界

    4、战术设计(技术层面-系统架构):

    侧重于领域模型的实现,侧重于代码逻辑的设计和实现

    实现层面

    • 逻辑边界
    • 物理边界
    5、DDD和微服务

    DDD:主要关注从业务领域视角划分领域边界,通过业务抽象建立领域模型,维持业务和代码层面的一致性

    微服务:主要是从技术层面,实现去中心化数据管理和去中心化服务治理,关注微服务的独立开发、测试、构建和部署

    总结:DDD是一种架构设计方法,微服务是一种架构风格。DDD是一种从业务视角去分离系统建设复杂度的手段,应用于微服务中,DDD解决微服务设计过程中边界难以界定的问题

    2、领域、子域、核心域、通用域、支撑域

    • 领域:指一种特定的范围。用于限制业务边界和范围的。

    • 子域:对应更小的业务范围

      • 核心域:决定产品和公司核心竞争力的子域,业务成功的主要因素和公司的核心竞争力
      • 通用域:需要用到的通用系统
      • 支撑域:具有企业特性,但不具有通用性

    复杂问题拆解细分,建立子域

    • 研究对象
    • 研究对象细分

    领域的核心思想就是将问题域逐级细分,来降低业务理解和系统实现的复杂度。通过领域细分,逐步缩小微服务需要解决的问题域,构建合适的领域模型,而领域模型映射成系统就是微服务了。通过领域划分,区分不同子域在公司内的不同功能属性和重要性(核心域、通用域、支撑域),从而公司可对不同子域采取不同的资源投入和建设策略

    3、限界上下文

    • 通用语言定义上下文含义,限界上下文则定义领域边界

    • 限界上下文就是用来细分领域,从而定义通用语言所在的边界

    • 一个限界上下文理论上就可以设计为一个微服务

    4、实体和值对象:从领域模型的基础单元看系统设计

    DDD 引入值对象是希望实现从“数据建模为中心”向“领域建模为中心”转变。实体和值对象是微服务底层的最基础的对象。DDD 提倡从领域模型设计出发,而不是先设计数据模型。

    实体对象(业务层面)
    • 实体和值对象是组成领域模型的基础单元。

    • 在代码模型中,实体的表现形式是实体类,这个类包含了实体的属性和方法

    值对象(数据层面)

    在领域建模时,我们可以将部分对象设计为值对象,保留对象的业务涵义,同时又减少了实体的数量;在数据建模时,我们可以将值对象嵌入实体,减少实体表的数量,简化数据库设计

    img
    实体对象VS值对象
    • 实体一般对应业务对象,它具有业务属性和业务行为;而值对象主要是属性集合,对实体的状态和特征进行描述。

    总结:值对象的引入,保留了业务层面的含义,减少了实体数量,并且在数据建模层面,简化了数据库设计

    5、怎样设计聚合?聚合和聚合根

    • 聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的,聚合是数据修改和持久化的基本单元,每一个聚合对应一个仓储,实现数据的持久化。

    • 聚合在 DDD 分层架构里属于领域层,领域层包含了多个聚合,共同实现核心业务逻辑

    聚合根解决了什么问题?

    聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制,而导致聚合、实体之间数据不一致性的问题

    聚合根承担的角色是什么?

    如果把聚合比作组织,那聚合根就是这个组织的负责人。聚合根也称为根实体,它不仅是实体,还是聚合的管理者。

    如何判断一个实体是否是聚合根?

    可以结合以下场景分析:是否有独立的生命周期?是否有全局唯一 ID?是否可以创建或修改其它对象?是否有专门的模块来管这个实体?

    6、领域事件

    用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作,在实现业务解耦的同时,还有助于形成完整的业务闭环。领域事件来驱动业务的流转

    7、中台

    img
    展开全文
  • 敏捷中出现各种”XX驱动开发“的实践。起源主要是来自Kent在极限编程中提出的测试优先编程(Test-First Programming)。现在出现了(除了行为驱动开发以为,相关的还有像实例驱动开发(EDD-Example Driven ...

    敏捷中出现各种”XX驱动开发“的实践。起源主要是来自Kent在极限编程中提出的测试优先编程(Test-First Programming)。现在出现了(除了行为驱动开发以为,相关的还有像实例驱动开发(EDD-Example Driven Development),特性驱动开发(FDD-Feature Driven Development)等。

    各种驱动开发之间的关系众说纷纭这里我们来聊一聊测试驱动开发(TDD)、验收测试驱动开发(ATDD)和行为驱动开发(BDD)。

    测试驱动开发

    Kent Beck最早在其极限编程(XP)方法论中,向大家推荐“测试驱动”这一最佳实践,还专门撰写了《测试驱动开发》一书,详细说明如何实现。

    测试驱动开发(TDD)使用自动化测试用例来指导开发代码。TDD 过程包含下列活动:

    • 新增一个测试(成生测试用例并自动化),用于描述在代码内的某一小片段所期望的功能(程序设计的思路);
    • 此时因为相应的业务代码还没有编写,测试无法通过;
    • 编写业务代码并运行测试直到测试通过;
    • 在测试通过后,如果代码又有变更,例如对业务代码进行重构,则需再次运行测试以确保变更后的代码仍然可以通过测试;
    • 对代码内的下一小片段继续执行上述过程,需要运行之前的测试(回归测试)以及新加入的测试。

    行为驱动开发和测试驱动开发介绍: https://www.itsource.cn/web/news/1933.html

    虽然“测试驱动开发”里面有测试的字眼,但是这个其实还是个开发活动,通常都不是由测试人员负责的,即使其中的驱动开发的测试的代码也不是测试人员编写的,至于里面涉及到的代码的重构这些内容,就更是开发人员而不是测试人员编写的。

    狭义的测试驱动开发一般指的就是单元测试级别的测试驱动开发。但是广义的测试驱动开发不仅仅可以用于单元测试级别,还可以用于集成测试或者系统测试级别。当然也可以用于验收测试级别,此时就是后面要讲的验收测试驱动开发。

    敏捷中很多思想都是建立在个人或者团队能力成熟度很高的基础上的。很多团队在实施测试驱动开发的时候无法顺利的进行下去,有很大一方面是实施的团队的技能还没有跟上。你很难想象一个开发团队,在单元测试都无法高质量的完成的情况下,转型采用TDD能够成功。

    验收测试驱动开发

    验收测试驱动开发(ATDD),在用户故事的创建阶段就定义验收准则及其相关的测试。ATDD 强调协作,各个利益相关者(开发、测试、业务代表等)不仅要理解软件组件应该有何种行为,还要理解如何做才能确保可以通过验收。

    验收测试驱动开发是一种测试优先的方法。

    首先需要再实施用户故事之前创建测试用例。测试用例由包括开发人员、测试人员和业务代表在内的敏捷团队创建,可以是手工测试用例也可以是自动化测试用例。第一步是开展一个由开发人员、测试人员和业务代表一起参与分析、讨论和撰写的规格说明研讨会。任何在用户故事中不完整、不清楚或者错误的地方都会在这个过程中得到修复。

    下一步是创建测试。这一活动可以由团队一起完成或者由测试人员单独完成。在任何情况下,测试都应该由一个独立的个人(如业务代表)来确认。这里的测试是描述用户故事中特性的例子。这些例子会帮助团队正确地实施用户故事。由于例子和测试是相同的,二者经常可以互换使用。这项工作从基本的例子和开放的问题开始。

    一般而言第一次测试都是正向测试,在没有意外或错误条件下确认正确的行为,比较执行的活动的顺序,判断是否如期望的那样进行。在正向路径测试完成后,团队应该撰写逆向测试并且覆盖非功能属性(如性能,易用性)。测试须以利益相关者都能理解的方式表述,包含以自然语言表达的语句,这些语句应该包括必要的前提条件以及任何可能的输入和相关输出。

    例子必须覆盖所有用户故事的特性,并且不应该添加新内容到用户故事中。这意味,不应存在那些描述没有被写在用户故事中的例子。另外,不应该有两个例子描述用户故事中的相同特性。

    行为驱动开发

    行为驱动开发(BDD)使开发人员聚焦于测试软件行为是否符合预期。由于测试是以软件行为的形式展示出来的,测试对于团队成员和其他利益相关者来说更容易。单从BDD的概念来说,它不仅仅是针对测试,它使得在业务团队和开发之间达成共识。在软件项目中涉及多人紧密协作,由产品业务讲解功能需求,开发负责代码实现,测试保证软件质量,高质量的沟通对项目成功至关重要。如果在一个项目中业务人员用自己行话,开发人员用技术语言、技术思维去理解业务,在沟通过程难免出现分歧,开发人员就可能按自己的理解去实现了一个错误的功能。

    BDD用通用自然语言描述实例(系统行为)。团队成员使用统一、易读的语言明确实例,作为验收测试标准。一方面可以消除理解上的歧义,一方面可以激发思考没有考虑到的场景。这里的实例是可以随时运行,反馈系统运行真实结果,如果运行失败,要么文档过时需要更新,要么系统出现问题需要修复。

    在讨论BDD和TDD、ATDD的关系时,有些地方把BDD看成一个新的完整的开发流程,也有些地方把BDD看成是TDD的延伸,ATDD的一种落地的实例。这只是从不同的角度来看待BDD,并不影响BDD的本质。

    典型的 BDD 框架将验收准则用 given/when/then 的格式表示:

    Given(给定)某些初始上下文,

    When(当)一个事件发生,

    Then(则)确保某些输出。

     

     

    行为驱动开发,让开发做正确的事: https://yq.aliyun.com/articles/594347
    行为驱动开发(BDD) - 一个快速的描述和示例: https://www.cnblogs.com/Javi/p/7158573.html
    五分钟让你彻底了解TDD、ATDD、BDD&RBE: https://mp.weixin.qq.com/s/KCrkL4NeuZeZvTu5Sc6B_g

    小结

    TDD、ATDD和BDD通过在开发之前清晰的描述系统行为和开发详细的测试用例来帮助开发人员更好的开发出高质量的代码。 测试从以前的破坏性的方法转换到建设性的方法中来。 给整个开发带来的新的思想上的变化。但是这些新的思想在实践过程中的具体能够带来多大的好处,也受到使用的组织和人的各方面条件的限制。没有一劳永逸的技术,只有持续不断的改进。这才是敏捷思想的内涵。

    展开全文
  • 前面我们学习I2C、USB、SD驱动时,有没有发现一个共性,就是在驱动开发时,每个驱动都分层三部分,由上到下分别是: 1、XXX 设备驱动 2、XXX 核心层 3、XXX 主机控制器驱动  而需要我们编写的主要是设备驱动...
  • 第一个:鸿蒙系统驱动开发过程中,首先要清楚驱动框架是如何布局的,鸿蒙系统內部为开发者提供了驱动框架能力,包括驱动加载、驱动服务管理和驱动消息机制。这样做也是为了,构建一个驱动架构平台,为驱动开发者...
  • 摘要极限编程是适应于中小型团队在需求不明确或迅速变化的情况下进行软件开发的轻量级方法学测试驱动开发作为极限编程思想的一种主要实践可以有效地让程序开发人员开发出更高品质的经过完整测试的程序文中介绍了测试...
  • 摘要:本文介绍了一种适用于面向对象的J2EE应用系统的开发方法,其核心思想是MDPB-ModelDrivenPatternBased即基于蓝图的模型驱动设计。概述一般的软件的分析设计过程为:需求调研,需求分析,概要(架构)设计,...
  • 谈谈对测试驱动开发思想的体会

    千次阅读 2017-11-11 13:44:05
    最近学习了一本书《Python Web开发:测试驱动方法》,贯穿全书的便是测试驱动开发的编程思想。有点儿兵马未动,粮草先行的兵家思想。先简单总结一下这本书带给我的收获:1.学习了测试驱动开发的一种编程思想,与传统...
  • 企业研发项目管理--集成产品开发(IPD)流程管理 - IPD(集成产品开发)的思想来源于美国PRTM公司的PACE理论,在这套理论中详细描述了业界最佳的产品开发模式所包含的各个方面。 - 经过IBM公司的实践,IPD已经成为...
  • 数据模型驱动开发.doc

    2020-07-20 00:19:51
    数据模型驱动开发 对于新手来说书是看得够多了不过书上的东西一般都是介绍一些语法工具框架之类的东西对于新人来说都是被忽悠到一个见是见过但不会用的一个状态对于说说开发思想的书还是偏少的就算是有也是很高级的...
  • 树莓派基于Linux内核驱动开发详解

    千次阅读 2021-08-23 18:03:29
    狭义上驱动程序就是专指操作系统中用来操控硬件的逻辑方法的部分代码。而我们这里讲的驱动就指的是这个狭义上的驱动。 2、Linux驱动的体系架构 分离、分层思想 驱动的上面是系统调用API 驱动的下面是硬件 驱动本身...
  • 为什么要学习 Linux 环境下的编程 Linux 是一个开放、灵活、跨平台的操作系统,上至庞大的...可以说,上世纪70年代学习的 Unix 知识和技巧,在今天仍然大有用武之地,这与 Windows 平台的开发形成了鲜明的对比。程序
  • 而Linux操作系统也只是一个简单的操作系统,简单的使用对于嵌入式开发人员来说价值并不很高,真正有价值的是掌握Linux的基本服务和Linux的设计理念、思想,这对于嵌入式开发人员的长期发展是很极其重要的。...
  • 测试驱动开发

    万次阅读 2018-11-24 14:14:00
    测试驱动开发 概述 极限编程是一个轻量级的、灵巧的软件开发方法,同时它也是一个非常严 谨和周密的方法,它从 4 个基本方面对软件项目进行改善:交流、简易、反馈 和勇气。测试驱动开发则是极限编程的最佳...
  • 敏捷开发思想

    千次阅读 2019-04-12 22:52:55
    敏捷开发的模式分类(摘抄至互联网):SCRUM 的工作流程(摘抄至互联网)流程: SCRUM 是什么? Scrum是敏捷开发中的名词。 敏捷开发是什么? 敏捷开发(Agile Development) 是一种以人为核心、迭代、循序渐进的开发方法...
  • 二、为什么需要嵌入式Linux驱动开发 三、驱动程序框架大致演变过程 总结 前言 随着去嵌入式设备资源不断丰富,主频不断升高,搭载操作系统可以更好的利用MPU资源,更容易实现其复杂功能。 作者也是小白,只学过韦...
  • 软件开发过程与项目管理(8.软件项目质量计划) 课件 软件质量基本概念 质量定义 质量是满足要求的程度,包括符合规定的要求和满足顾客隐含需求。 软件质量定义 软件质量是软件满足明确说明或者隐含的需求的程度 ...
  • 附件里有关于java Tdd ppt介绍和源代码,大家可以参考这个学习tdd核心思想,相信大家受益匪浅,里面有测试代码,通过测试代码驱动出相关代码过程
  • 基于树莓派驱动开发详解

    千次阅读 2020-08-09 20:15:49
    1、驱动开发思想 要想进行驱动开发首先我们应该知道,上层到底层是如何进行的,上层调用c库的open函数,首先会发生一次软中断,从用户空间进入内核空间,触发系统调用接口函数sys_call,然后通过open函数的设备名...
  • 树莓派开发简单是因为有库,实现超声波,实现继电器操作,做灯的点亮 未来换一块板子,不用树莓派,只要能拿到linux内核源码,拿到芯片手册,电路图 主设备号与次设备号 一切皆为文件 cd /dev open为什么能够区分是...
  • 在这个进化的过程中,有一种设计思想在2004年的时候就被提出来了,也被作者写成书出版。到现在为止经过了18年了,但依然炙手可热。而且逐渐变成了行业内微服务设计的标准实践。他就是“领域驱动设计”,今天小蒋就...
  • 关于嵌入式驱动开发,这篇文章让你了解透彻!

    千次阅读 多人点赞 2020-09-27 16:48:38
    嵌入式驱动开发到底学什么 嵌入式大体分为以下四个方向: 一、嵌入式硬件开发:熟悉电路等知识,非常熟悉各种常用元器件,掌握模拟电路和数字电路设计的开发能力。熟练掌握嵌入式硬件知识,熟悉硬件开发模式和设计...
  • 介绍了嵌入式操作系统WinCE6.0下的流接口驱动模型及USB驱动模型结构,以使用流接口驱动模型开发的通信模块的USB转串口驱动程序为实例,详细介绍并分析了基于流接口驱动模型设计USB设备驱动程序的过程。实验证明所...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 115,325
精华内容 46,130
关键字:

计划驱动的开发过程的思想的方法