精华内容
下载资源
问答
  • 项目生命周期 项目的生命周期是描述项目从开始到结束所经历...项目设阶段的目的是为了管控的需要,每一个阶段都可以当成是一个子项目,每一个阶段中都可以执行项目管理生命周期定义的五大过程组。阶段结束时要进行阶段

      接受项目管理培训至今已经有三年时间了,一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头,从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验,希望可以帮助到从事项目管理的人!

      在前面的博文项目管理 之一 软件开发生命周期(软件开发过程、瀑布模型、敏捷开发等) 中我们说过 软件开发生命周期 ≠ 项目的开发周期。接下来就再进一步,站在整个项目的角度来了解一下软件项目管理。

    注意:

    1. 这部分仅仅是自己学习记录的一些总结,所以内容大多数都是来自互联网或者各种书籍。如果您发现对您构成了侵权,请随时联系我进行处理。
    2. 这部分内容都是一些理论,实际项目中往往与理论有所不同。例如,阶段划分更加详细,项目活动可裁剪等

    项目管理

      项目这个概念非常的广泛,项目管理同样是个范围很大的概念。项目管理是管理学的一个分支学科 ,对项目管理的定义是:指在项目活动中运用专门的知识、技能、工具和方法,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望的过程。所谓管理包含领导、组织、用人、计划及控制等五项主要工作。

    项目(Project)是为完成某一独特的产品、服务或成果所做的临时性工作。临时性是指计划有确定的开始日期和结束日期。独特意味着项目的最终结果不重复。

      作为一门学科,项目管理从土木施工、工程、重型国防等多个应用领域发展而来。20 世纪 50 年代项目管理被公认为具有工程模式的管理学科所产生的一门独特的学科。1969 年,项目管理研究所(PMI)在美国成立。PMI 于 1996 年出版了第一版《项目知识管理机构指南》(PMBOK 指南)。这本书是必看的!本文的有些内容就是来自这本指南。

    • PMBOK 每 4 年会更新一次,目前中国使用的官方教材为第六版
    • 全球项目管理业界定义的最重要的价值观是责任、尊重、公正和诚实
    • PMBOK 指南为项目经理提供了指导方针和最佳实践,定义了从项目生命周期到项目管理策略和概念的一切内容。项目管理知识体系指南详细描述了在整个项目生命周期中相互作用和重叠的各种项目管理过程。

      项目管理方法可应用于任何类型的项目。它通常根据项目规模、性质、行业或部门为特定类型的项目量身定做。例如,以建筑、道路和桥梁等工程的交付为重点的建筑行业已经发展了自己的专业项目管理形式,称为建筑项目管理;我们软件行业则有我们的软件项目管理。

    接下来,我们来区分一下三个比较容易混淆的概念:项目生命周期、项目管理生命周期、产品生命周期
    在这里插入图片描述

    项目生命周期

      项目的生命周期是描述项目从开始到结束所经历的各个阶段。通常由 启动阶段、组织与准备阶段(规划阶段)、实施阶段、结束阶段 这四阶段个组成。每个阶段确定了开始和结束点,每个阶段都有质量保证 QA / 质量测试 QC 人员对阶段的里程碑点进行检查并进行相应的阶段评审。
    在这里插入图片描述
      项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。 阶段通常有先后的顺序(如瀑布型),也可以有阶段的交叠。不同行业,不同规模的项目,项目生命周期可以不同。

    项目活动 是确认和描述项目的特定活动,它把项目的组成要素加以细分为可管理的更小部分,以便更好地管理和控制。

      项目规划阶段的目的是为了管控的需要,每一个阶段都可以当成是一个子项目,每一个阶段中都可以执行项目管理生命周期定义的五大过程组。阶段结束时要进行阶段评审。由于项目有特定的目标,在产品生命周期中,一般产品完成后通过验收则项目生命周期即结束。

      项目阶段并没有严格的划分标准。这里所说的 4 个阶段仅仅是指的一般情况。一个具体的项目可以根据项目所属专业领域的特殊性和项目的工作内容等因素划分成不同的项目阶段。

    启动阶段

      启动阶段是整个项目生命周期的第一阶段。这一阶段的目标是确定项目,并获得批准。在此期间,通常有以下项目活动需要项目经理来处理:

    • 需求调研
    • 进行可行性研究
    • 创建项目章程
    • 确定关键利益相关者
    • 选择合适的项目管理方法
    • 选择项目管理工具

    通常,从项目启动会议开始,项目经理向所有相关利益相关者概述项目目标。在会议召开之前,项目经理必须执行以下工作:

    1. 建立目标和可交付成果
    2. 识别团队成员并分配任务
    3. 制定项目计划草案
    4. 定义用于衡量项目成功的指标
    5. 识别和准备潜在的路障
    6. 建立团队沟通的物流和时间表
    7. 选择首选的项目管理方法
    8. 确保您的团队能够访问相关工具并了解相关工具
    9. 安排会议
    10. 设置议程并准备幻灯片

    启动会议议程可能如下所示:

    • 简介:谁是谁?
    • 项目背景:您为什么要进行这个项目? 目标是什么?
    • 项目范围:涉及哪种工作?
    • 项目计划:路线图是什么样的?
    • 角色:谁负责项目的哪些元素?
    • 交流:将使用哪种交流渠道? 您的团队应该期望什么样的会议或状态报告?
    • 工具:将使用哪些工具来完成项目,以及如何使用它们?
    • 后续步骤:需要完成哪些立即行动项目?
    • 问答(Q&A):现场答疑

    到此阶段结束时,项目经理应对项目的目的、目标、要求和风险有更深入的了解。

    规划阶段

      规划阶段对于创建整个团队可以遵循的项目路线图至关重要。为了满足组织提出的要求,所有的细节和目标都在这里列出。在此阶段,通常有以下项目活动需要项目经理来处理:

    • 创建项目计划
    • 制定资源计划
    • 评估项目预算
    • 定义目标和绩效衡量指标
    • 向团队成员传达角色和责任
    • 构建工作流
    • 预测风险并制定应急计划
    • 制定沟通交流计划(可能是会议、交流工具)

    执行阶段

      这个阶段是项目投入时间最多的阶段。可交付品的构建是为了确保项目符合要求。这也是大多数时间、金钱和人被投入的阶段。

      在执行阶段必须时刻对项目进行控制和监测(严格来说,项目的每个阶段都可以控制和监测)。随着项目的推进,项目经理必须确保所有活动的部分都朝着正确的方向无缝地进行。如果由于不可预见的情况或方向的改变而需要对项目计划进行调整,则可能会在这里进行调整。在控制和监测中,项目经理(有可能是公司中专门的 QA 人员)可能需要做以下工作:

    • 管理资源
    • 监控项目性能
    • 风险管理
    • 质量管理
    • 成本管理
    • 变更管理(更新项目计划、修改项目计划)
    • 执行状态会议和报告
    • 协作、沟通

    项目关闭

      结束阶段是项目生命周期的关键一步。它标志着项目的正式结束,并为反思、总结和组织材料提供了一段时间。通常有以下项目活动需要项目经理来处理:

    • 盘点所有可交付成果
    • 处理好任何零碎的事情
    • 将项目移交给客户或负责项目日常运营的团队
    • 进行事后分析,讨论并记录从项目中学到的任何东西
    • 集中组织所有项目文件
    • 与利益相关者和主管沟通项目的成功
    • 庆祝项目完成并感谢团队成员

    阶段关口

    阶段关口在项目阶段结束时进行,将项目的绩效和进度与项目和业务文件比较,这些文件包括 (但不限于):

    • 项目商业论证
    • 项目章程
    • 项目管理计划
    • 效益管理计划

    根据比较结果做出决定(例如继续/终止的决定),以便:

    • 进入下个阶段;
    • 整改后进入下个阶段;
    • 结束项目;
    • 停留在当前阶段;
    • 重复阶段或某个要素。

    在不同的组织、行业或工作类型中,阶段关口可能被称为阶段审查、阶段门、关键决策点和阶段入口或阶段出口。

    项目管理生命周期

      项目管理生命周期是对项目目标的实现进行管理的过程。项目生命周期每个阶段都是通过一系列项目管理活动进行的。这些管理活动被称为项目管理过程。 每个项目管理过程通过合适的项目管理工具和技术将一个或多个输入转化成一个或多个输出。

    项目生命周期的每个阶段都要执行项目管理生命周期
    项目管理的输出一般都是些项目标准文档

      项目管理过程组指对项目管理过程进行逻辑分组,以达成项目的特定目标。过程组不同于项目阶段。项目管理过程可分为以下五个项目管理过程组:

    • 启动过程组: 定义一个新项目或现有项目的一个新阶段,授权开始该项目或阶段的一组过程。
    • 规划过程组: 明确项目范围,优化目标,为实现目标制定行动方案的一组过程。
    • 执行过程组: 完成项目管理计划中确定的工作,以满足项目要求的一组过程。
    • 监控过程组: 跟踪、审查和调整项目进展与绩效,识别必要的计划变更并启动相应变更的一 组过程。
    • 收尾过程组: 正式完成或结束项目、阶段或合同所执行的过程。

      但是,需要注意 阶段 ≠ 过程组。不同行业,不同规模项目的项目管理生命周期大致相同。项目管理生命周期的过程是 PMP(Project Management Professional​) 考试的主要考试范围。

    除了过程组,过程还可以按知识领域进行分类,分为 10 个知识领域(其中始终关注的是范围、进度、成本和质量):

    • 项目整合管理: 包括为识别、定义、组合、统一和协调各项目管理过程组的各个过程和活动而开展的过程与活动。
    • 项目范围管理: 包括确保项目做且只做所需的全部工作以成功完成项目的各个过程。
    • 项目进度管理: 包括为管理项目按时完成所需的各个过程。
    • 项目成本管理: 包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程
    • 项目质量管理: 包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求,以满足相关方的期望的各个过程。
    • 项目资源管理: 包括识别、获取和管理所需资源以成功完成项目的各个过程。
    • 项目沟通管理: 包括为确保项目信息及时且恰当地规划、收集、生成、发布、存储、检索、管理、控制、监督和最终处置所需的各个过程。
    • 项目风险管理: 包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。
    • 项目采购管理: 包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。
    • 项目相关方管理: 包括用于开展下列工作的各个过程:识别影响或受项目影响的人员、团队或组织,分析相关方对项目的期望和影响,制定合适的管理策略来有效调动相关方参与项目决策和执行。

    下图显示了管理过程朱与知识领域的对应关系以及在过程中需要的工作:
    在这里插入图片描述

    裁剪

      由于每个项目都是独特的,所以有必要对项目管理过程进行裁剪;并非每个项目都需要《PMBOK® 指南》所确定的每个过程、工具、技术、输入或输出。裁剪应处理关于范围、进度、成本、资源、质量和风险的相互竞争的制约因素。各个制约因素对不同项目的重要性不一样,项目经理应根据项目环境、组织文化、相关方需求和其他变量裁剪管理这些制约因素的方法。

    产品生命周期

      产品生命周期管理的是产品,包括一系列产品阶段:市场调研、产品研发、试产、量产、运营、维护和退市。产品生命周期通常包含顺序排列且不互相交叉的一系列产品阶段。

    产品生命周期指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

      产品生命周期由一个或多个项目生命周期组成,也可能分为多个迭代周期来实现。 而项目生命周期也可开发一个或多个产品。一个项目生命周期通常只包含在一个产品生命周期中。在项目生命周期结束即项目完成后,而产品生命周期还需进行产品的运营、维护和退市等阶段。

      与产品生命周期相对应的成本概念是全生命周期成本,包括一次性的项目软硬件投入(一次性成本),以及 3 - 5 年运营或运维成本(持续成本)。

    三重关系

      三重约束,又称项目管理三角,是指适用于每个项目的时间、质量和成本界限。负责控制这些限制的项目管理流程包括进度管理、成本管理和质量管理。下图显示了软件项目的三个限制的关系。
    限制

    我在学习中发现,有部分文章中,质量 被替换为 范围,即:时间、范围和成本。

    软件项目管理

      到目前为止,仍然有很多人有疑问:软件开发项目到底能不能称为项目?这与对于软件工程能不能算是工程的疑问类似。在某些人的认识中,项目或者说工程更多的是指工业建筑中的专有名词。

      自 20 世纪 60 年代以来,软件制造商自行开发了几种专有的软件项目管理方法。今天,软件项目管理方法仍在不断发展,但是当前的趋势已从瀑布模型转移到了模仿软件开发过程的更具周期性的项目交付模型。

      软件项目管理(Software Project Management)就是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。通常,可以将软件开发项目可以分为两大类:

    • 软件项目: 运行于已有通用硬件上的软件系统。例如,PC 上运行的软件,服务器上运行的网站。
    • 系统项目: 运行于特定硬件上的软件系统,除了要开发软件,还要开发对应的硬件。例如各种嵌入式设备。

    如果没有特殊说明,后文我们所说的软件项目管理均指这两种类型的统称。

      软件工程项目管理不同于传统的项目管理,因为软件项目具有独特的生命周期过程,需要多轮测试、更新和客户反馈。目前,大多数 IT 相关项目都以敏捷的风格进行管理,以跟上业务增长的步伐,并根据客户和利益相关者的反馈进行重复。

    过程方法

    2017 年的一项研究显示,任何项目的成功取决于四个关键方面,这些方面被称为 4P :

    1. 计划(Plan):指所有涉及规划和预测的活动。在这个阶段,项目或项目的要素尚未实现;
    2. 过程(Processes):项目管理知识体(PMBOK, Project Management Body of Knowledge)指南中记述,项目主要由一系列预定和结构良好的过程所组成;
    3. 人员(People):人员是项目动态的重要组成部分,一些研究表明,人员是某些项目特有问题的核心。所谓“可怕的结合”,特别是指规划不善和不适当人员的构成;
    4. 权责(Power):描述当局所有的权力与责任、决策者、组织图,执行政策和喜好。

      组织与完成项目活动有许多方法,包括:分阶段、精益、迭代和增量等;也有一些对项目规划的几个扩展,例如,针对结果(基于产品)或活动(基于流程)。不论采行何种方法论,必须精心缜密地考虑项目总体的目标,时程和成本,以及所有参与者和利害关系人的作用和责任。

      对于软件开发项目,在博文 项目管理 之一 软件开发生命周期(软件开发过程、瀑布模型、敏捷开发等) 中介绍的各种过程模型,基本就是指导我们软件开发的方法。但是,由于项目具有独特性,因此标准的生命周期模型往往难以满足项目的特殊需要。通常项目在定义生命周期时,可首先选择一种标准的生命周期模型作为基础,然后指定出适合自己的方法。

    传统的顺序方法

    瀑布式管理方法

      规划项目的最常见方法是对导致最终交付的任务进行排序,并按顺序进行工作。这个过程也被称为瀑布方法——管理项目的传统方法,也是最容易理解的方法。

      这种方法的强大之处在于,每一步都是预先计划好的,并按照适当的顺序安排好。虽然这可能是最简单的最初实现方法,但涉众需求或优先级的任何更改都会破坏一系列任务,使其很难管理。这种方法在可预见性方面很出色,但缺乏灵活性。

    关键路径方法(CPM)

      关键路径方法(Critical Path Method)是在 20 世纪 50 年代开发的,其基础是,有些任务在完成上一个任务之前无法启动。当您从头到尾将这些依赖任务串在一起时,您会绘制出关键路径。

      确定并关注这一关键路径后,项目经理就可以确定优先级并分配资源,以完成最重要的工作,并重新安排可能会阻塞团队的所有低优先级任务。 这样,如果您需要更改项目进度表,则可以在不延迟结果的情况下优化团队的工作流程。

    关键链项目管理(CCPM)

      关键链项目管理(Critical Chain Project Management)将关键路径方法更进一步。CCPM 是一种方法,它侧重于通过在关键路径中增加资源可用性来完成项目任务所需的资源。它还在项目计划中围绕这些任务建立时间缓冲,确保项目满足其最后期限。

    敏捷家族

      由于竞争激烈的商业环境和不断创新,敏捷的项目管理方法越来越受欢迎。一般来说,敏捷方法优先考虑更短的迭期周期和灵活性。

    Scrum

      Scrum 是最受欢迎的敏捷发展框架,因为它的实现相对简单。它还解决了软件开发人员过去遇到的许多问题,例如复杂的开发周期、不灵活的项目计划以及更改生产计划。

    详细介绍见 项目管理 之二 敏捷开发方法 Scrum 最全指导 .

    看板

      看板是基于团队能力实施敏捷的另一个框架。它起源于 20 世纪 40 年代的丰田工厂。各部门使用可视化的卡片系统(“看板”)来表示他们的团队已经为更多的原材料做好准备,并拥有更多的生产能力。

    极限编程 (XP)

      极限编程 (Extreme Programming) 是敏捷的另一个分支。XP 是一种旨在提高软件质量(和简单性)和开发团队适应客户需求的能力的方法。与原始的敏捷开发非常类似,XP 具有工作冲刺短、迭代频繁以及与利益相关者不断协作的特点。变化可能发生在冲刺阶段。如果特定功能的工作尚未开始,则可以将其更换为类似任务。

    自适应项目框架(APF)

      自适应项目框架(Adaptive Project Framework)源于由于不确定和不断变化的需求而难以使用传统项目管理方法来管理大多数 IT 项目的情况。

      APF从需求分解结构(RBS)开始,以根据产品需求,功能,子功能和功能定义战略项目目标。 该项目分阶段进行,在每个步骤的最后,团队都会评估以前的结果以改善性能和实践。

    变更管理方法

    有些方法论用于管理项目,但更侧重于变更管理,尤其是风险规划和在变更发生时进行控制。

    事件链方法(ECM)

      事件链方法(Event Chain Methodology)背后的基本理念是,潜在风险往往不在项目范围之外。必须做好应对这些风险的准备,并计划您的应对措施,因为意外事件会影响您的项目的进度、交付成果以及潜在的成功。

    极限项目管理(XPM)

      极限项目管理 (Extreme Project Management) 与瀑布正好相反。它为您提供了一种管理大规模变革的方法,并且仍然朝着项目完成的方向前进。在 XPM 中,无论项目进展有多远,您都可以更改项目计划、预算,甚至最终交付,以满足不断变化的需求。

    基于过程的方法

    其中每种方法都侧重于将工作作为流程的集合。

    精 益

      精益(Lean)是一种专注于精简和减少浪费的方法(精益求精)。第一步是创建工作流程分解,以识别和消除瓶颈和延迟。目标是用更少的人力、更少的钱和更少的时间为客户提供价值。

    Six sigma

      Six Sigma 于20 世纪 80 年代中期由摩托罗拉的工程师介绍,通过识别项目中不起作用的内容来提高质量。

      Six Sigma 是一种基于统计的方法,旨在通过测量存在的缺陷并消除尽可能多的缺陷来提高过程质量。 如果 99.99966% 的最终产品(您的项目可交付成果)没有缺陷,则该过程可以达到 Six Sigma 等级。

    其他方法

    PRINCE2

      PRINCE2 代表受控环境中的项目。 这是一种用于管理英国政府使用的项目的方法,其特点是基于产品的计划方法。 在 PRINCE2 中,结构化的项目委员会负责高层活动,例如确定业务理由和资源分配。 项目经理负责日程安排等较低级别的日常活动。 这种方法使团队可以更好地控制资源并有效降低风险。

    PRiSM

      PRiSM 代表“集成可持续方法的项目”,旨在在将环境可持续性纳入其流程的同时管理变更。 PRiSM的目标是完成任务,同时减少公司对环境和社会的负面影响。 从字面上看,它是绿色项目管理。

    项目管理的角色

    项目经理

      项目经理密切监视开发过程,准备并执行各种计划,安排必要和充足的资源,保持所有团队成员之间的沟通,以解决成本,预算,资源,时间,质量和客户满意度方面的问题。

      正式的项目经理通常通过美国 PMI 或英国 PRINCE2 之类的机构进行认证。认证后,他们需要通过接受额外的培训来收集目标数量的 PDU(Professional Development Units)来维持其认证。

    1. PDU 代表专业发展单元,是 一种衡量正在进行的专业发展的方法。 为了保持作为项目管理专业人员(PMP)的认证,您将需要维护特定数量的 PDU,这些 PDU 可以通过参加活动或完成课程来获得。
    2. 美国项目管理协会(PMI)举办的项目管理专业人员(PMP)认证考试在全球180多个国家和地区推广,是目前项目管理领域含金量最高的认证。被全球项目管理界人士所认可!

      在实际的工作中,认证并不总是一个要求,它可以是在以后的职业生涯中获得的东西。大多数项目经理通常从工商管理学位开始,但实际中并非总是这样。经验往往比学位更响亮。

      通常,项目经理需要熟练使用 PERT 来对项目进行管理。

    Rrogram (or Project) Evaluation and Review Technique (PERT) 程序(或项目)评估和审查技术是用于项目管理的统计工具,旨在分析和表示完成给定项目所涉及的任务。它最初由美国海军于1958年开发,通常与1957年推出的临界路径方法(CPM)一起使用。

    软件项目经理

      软件项目经理是负责执行软件项目的人员,通常是 PMI 认证的项目管理专业人员 (PMP)。 软件项目经理完全了解软件将经历的 SDLC 的所有阶段。项目经理可能永远不会直接参与最终产品的生产,但他会控制和管理生产中涉及的活动。

    项目成员

    他们是负责完成项目一的人员。 团队成员是熟练的专业人员,他们致力于为项目目标做出贡献。

    客户

    项目产品的交付者。可能来自内部,也可能来自外部。

    利益相关者

    这是在项目中有既得利益的人或团体。它可能是一个组织的内部团体或机构,也可能是公共工程项目的公众。

    风险管理

      风险管理是对风险(在 ISO 31000 中定义为不确定性对目标的影响)的识别,评估和优先级划分,然后协调,经济地使用资源以最小化,监视和控制不幸事件的可能性或影响或最大化机会的实现。风险管理包括与识别、分析和为项目中的可预测和不可预测风险做准备相关的所有活动。

    风险评估

      软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题,以及由这些问题而对项目所产生的影响。

      项目的风险与其可行性成反比,其可行性越高,风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面。

    成本预算

    自上而下的预算方法(经验估计技术)

      自上而下的预算方法主要是依据上层、中层项目管理人员的管理经验进行判断,对构成项目整体成本的子项目成本进行估计,并把这些判断估计的结果传递给低一层的管理人员,在此基础上由这一层的管理人员对组成项目的子任务和子项目的成本进行估计,然后继续向下一层传递他们的成本估计,直到传递到最低一层。

    该技术使用经验导出的公式进行估算。这些公式基于 LOC 或 FP。

    • Putnam 模型: 该模型由Lawrence H. Putnam制作,该模型基于Norden的频率分布(瑞利曲线)。 Putnam模型映射了软件大小所需的时间和精力。

      关于 Putnam 模型,详见 https://wiki.mbalib.com/zh-cn/Putnam%E6%A8%A1%E5%9E%8B

    • COCOMO: COCOMO 是由 Barry W. Boehm 开发的建设性成本模型(COnstructive COst MOdel)的缩写。它将软件产品分为三类:有机软件、半分离软件和嵌入式软件。

    自下而上的预算方法(分解技术)

      自下而上方法要求运用 WBS(Work Breakdown Structure,工作分解结构)对项目的所有工作任务的时间和预算进行仔细考察。最初,预算是针对资源(团队成员的工作时间、硬件的配置)进行的,项目经理在此之上再加上适当的间接费用(如培训费用、管理费用、不可预见费等)以及项目要达到的利润目标就形成了项目的总预算。

    主要有两种模式:

    • 代码行: 依据软件产品中的代码行数进行估计。
    • 功能点: 依据软件产品中功能点的数量进行估算。

      自下而上的预算方法要求全面考虑所有涉及到的工作任务,更适用于项目的初期与中期,它能准备地评估项目的成本,与真实费用相差在 5% ~ 10% 之间。

    质量管理

      质量管理确保组织、产品或服务是一致的。它包括四个主要组成部分:质量规划、质量保证、质量控制和质量改进。 质量管理不仅注重产品和服务质量,而且注重实现质量的手段。因此,质量管理利用对工艺和产品的质量保证和控制来实现更一致的质量。

    软件质量保证

      软件质量保证(SQA,Software Quality Insurance)是在软件过程中的每一步都进行的“保护性活动”。SQA 主要有基于非执行的测试(也称为评审)、基于执行的测试(即通常所说的测试)和程序正确性证明。

      软件评审是最为重要的 SQA 活动之一。它的作用是,在发现及改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行正式技术评审的两类具体方法。

    配置管理

      配置管理是根据产品的需求,设计,功能和开发来跟踪和控制软件更改的过程。IEEE 将其定义为:the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items。

      配置管理是组织管理的一门学科,它负责处理阶段性基础化后发生的任何变化(流程、要求、技术、战略等)。CM 会不断检查软件中所做的任何更改。

    软件配置管理

      软件配置管理(SCM,Software Configuration Management)是应用于整个软件过程中的保护性活动,它是在软件整个生命周期内管理变化的一组活动。是配置管理这个更大的跨学科领域的一部分。

      软件配置管理包括版本控制和基线的建立。如果出现问题,SCM 可以确定更改了什么以及是谁更改了它。如果配置工作良好,SCM 可以决定如何在许多主机上复现它。

      软件配置由一组相互关联的对象组成,这些对象也称为软件配置项,它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外,用于开发软件的开发环境也可置于配置控制之下。一旦一个配置对象已被开发出来并且通过了评审,它就变成了基线。对基线对象的修改导致建立该对象的版本。版本控制是用于管理这些对象而使用的一组规程和工具。

    软件配置管理系统
      库是软件配置管理系统的根本。库是集中控制的文件库,并提供对库中所存储文件的版本控制。任何库中的文件都被视为在确定的软件配置管理之下。
      在项目实际工作中,可以用 SVN、Git 等工具来建立配置库。

    基线

      在配置管理中,基线是在某个时间点对产品属性达成的一致描述,可作为定义更改的基础。更改是从此基准状态到下一个状态的移动。 识别基线状态的重大变化是基线识别的主要目的。

      如果 SDLC 的一个阶段已经建立了基线,那么就假定它已经完成了,例如,基线是定义一个阶段完整性的度量。当与阶段有关的所有活动都已完成并得到良好的文档记录时,阶段就被确立为基线。如果它不是最后阶段,它的输出将用于下一个直接阶段。

    版本控制

      在软件工程中,版本控制(也称为修订控制,源代码控制或源代码管理)是一类负责管理对计算机程序,文档,大型网站或其他信息集合的更改的系统。 版本控制是软件配置管理的组成部分。

      在软件开发中,版本控制系统的使用是必不可少的。详细见博文 版本控制系统 之一 概念、分类、常见版本控制系统(CVS、SVN、BitKeeper、Git 等)

    变更管理

      变更管理(Change management)是对所有支持和帮助个人或团队进行组织变更的方法的集合术语。变更的驱动因素可能包括技术的不断演变、流程的内部审查、危机应对、客户需求变化、竞争压力、收购和兼并以及组织重组。 它包括重定向或重新定义资源使用、业务流程、预算分配或其他显著改变公司或组织运营模式的方法。

    变更控制

      变更控制(Change Control)是质量管理系统(QMS)和信息技术(IT)系统中的一个过程,用来确保以受控和协调的方式引入产品或系统的变更。它减少了在没有预先考虑的情况下对系统进行不必要的更改、在系统中引入错误或撤销其他软件用户所做的更改的可能性。变更控制过程的目标通常包括最小化对服务的干扰,减少回退活动,以及对实现变更所涉及的资源的低成本利用。

    不要与版本控制相混淆。

    项目管理工具

    见独立博文

    参考

    1. https://wiki.mbalib.com/wiki/%E8%BD%AF%E4%BB%B6%E9%A1%B9%E7%9B%AE%E7%AE%A1%E7%90%86
    2. http://learnfuture.com/PMP/902
    3. https://www.cnblogs.com/leslies2/archive/2012/06/29/2569765.html
    4. https://www.tutorialspoint.com/software_engineering/software_project_management.htm
    5. https://www.wrike.com/project-management-guide/project-lifecycle/
    6. https://www.wrike.com/project-management-guide/methodologies/
    7. https://en.wikipedia.org/wiki/Software_project_management
    8. https://www.projectmanager.com/project-management
    展开全文
  • 有5年软件开发经历,在PLM领域从业20多年,先后帮助上百家家企业进行过信息化规划及咨询,专注于应用软件开发、PLM咨询和项目管理等领域。 母婴新零售行业面临的挑战 全球前50强的消费品公司中,34家的业绩分析...

    ​本文作者刘吉佳,西门子数字化工业软件高级技术顾问。有5年软件开发经历,在PLM领域从业20多年,先后帮助上百家家企业进行过信息化规划及咨询,专注于应用软件开发、PLM咨询和项目管理等领域。

    母婴新零售行业面临的挑战

    全球前50强的消费品公司中,34家的业绩分析显示85%大公司的营业收入和利润都出现了下滑的现象;只有15%的企业幸免。

    母婴行业的4大核心痛点

    01. 线下母婴店经营成本上涨,毛利润下降

    • 房租成本、人力资源成本都在不断地上涨;

    • 母婴行业已经由卖方市场转化为买方市场,业态处于供大于求的局面;

    • 新兴电商的带来的冲击,导致高利润不复存在。

    02. 竞争趋于封闭,行业较为混乱

    目前,母婴行业集中度较低,竞争比较粗放,大多都依靠价格战来抢占市场,服务内容相对简单,服务水平相对滞后。

    另外,还存在服务缺失,缺乏有效的行业行为标准等问题。

    03. 行业缺乏运营标准

    虽然部分大型连锁母婴店有对部分的运营有自己的标准,但相较大卖场的运营标准,还有很大的距离。至于小型区域连锁及街边小店没有对应的标准是很常见的现象。

    04. 供应链采购体系不足

    在未来十年,供应链的发展是制约行业发展的重要因素,同时该行业的采购体系尚未完善。

    在快速变化的市场竞争环境下,新零售行业的高管们面临下面的诸多挑战:

    为实现正确的产品快速面世的业务目标,行业一致认为的关键因素是速度和适应性,而实现上述目标,行业数字化转型—打造数字化新零售平台是必由之路。

    本篇案例的客户是一家集母婴产品研发、设计、销售于一体的实业企业,作为母婴行业领先品牌的在华品牌方及实际运营方,渠道涉及线上大部分主流电商平台,涉及线下连锁、Mall等多通路,连续多年是天猫/京东等平台的行业TOP商家,并真正积极地布局全球销售网络。

    该客户致力于打造全球母婴消费者可信赖的、忠诚度高的国际母婴品牌。

    Teamcenter + Mendix的新电商PLM解决方案

    母婴新零售企业是以母婴产品为主,已形成电商+社区的线上+线下母婴的新零售平台。其主要的研发过程中所面临的主要挑战/痛点如下:

    行业的员工平均年龄不超过30岁,以快速响应,敏捷团队协作为特点。因此传统的PLM软件会让用户感觉“比较重”,不能满足以下的需求:

    • 行业客户一般拥有十多条产品线,品类多涉及到不同的专业应用。如何给不同角色的人员提供一个统一的门户?

    • 非传统的PLM用户部分使用苹果电脑,例如销售、市场人员、管理人员等,不知道或不关心什么是PLM,但却需要访问PLM数据;

    • PLM系统对客户端要求高,使用专业性强;

    • 需要外出办公,能否通过移动设备访问PLM系统。

    针对新电商客户的特点,西门子售前团队提出了Teamcenter的iPLM(集成的项目全生命周期管理)加Mendix的“催化剂”的解决方案,如下图所示:

    母婴产品数字化应用移动智能统一入口

    通过Mendix低代码开发平台提供客户统一的产品数字化平台,为用户提供一致的整合应用入口。该平台整合企业内外部各大IT系统和平台,进行数据的整合、分析、可视化呈现以及统一的门户入口,为用户提供企业级经营管理驾驶舱;通过该平台,用户可以方便的访问产品生命周期管理过程中各类业务应用。产品数字化平台入口提供了多种访问方式,包括:PC、手机和PAD等,满足用户移动访问的需求,能够更加快捷方便的支持业务应用。界面如下图所示:

    通过Mendix的前端能力,通过统一入口可以链接到各个不同的业务系统。例如:

    • 多个电商系统的连通(销售看板)

    • 配方设计工作台

    • 模具台账管理

    • 联通Opcenter向用户展示生产情况

    • 售后服务管理

    多项目看板

    为更好的支持项目群管理模式,能同时显示多个项目的进度、健康度和成本信息。通过Mendix定义了多项目看板,用户可以通过手机等移动设备一目了然的查看多个项目信息(产品经理同时管控多个项目)。此外,还可以点击具体项目进入到Teamcenter的项目界面进行具体的项目操作。

    Mendix在本项目中的独特价值体现

    通过Mendix的前端能力,统一入口最有价值之处在于:客户未来将“充分利用碎片化的时间”(客户的语言)通过随时携带的手机或平板来进行业务处理,给客户带来效率的极大提升。最典型的例子就是审批流程的平均流转周期由仅仅使用工作电脑的1~3天缩短到1分钟~2小时。

    创新的方案需要技术团队的紧密协作

    作为首个新电商的PLM解决方案,技术团队克服了诸多困难,为项目的成功做出了很多贡献,在这里特别感谢主要的团队成员:高岩松作为技术团队领导,是TC+Mendix创意的提出和推动者,设计了总体方案架构;张怡飞作为售前顾问,是技术方案的主要编制者和POC系统UI设计者;技术售前汤锐剑在非常短的时间内使用Mendix快速搭建平台,同时也参与了POC系统的搭建。另外,还要感谢PFD陈王淼对于客户的iPLM推广宣贯工作。


    更多信息,请访问以下链接:

    Mendix官网:https://www.mendix.com/zh/

    Mendix中国论坛:https://forum.mendix.tencent-cloud.com/

    Mendix行业解决方案:https://solutions.mendix.com/

    Mendix平台指南:https://www.mendix.com/evaluation-guide/

    Mendix动画展示:https://www.mendix.com/demos/

    感谢阅读!

    展开全文
  • 包括:产品/软件需求(与产品规格)管理软件开发与结果管理软件配置管理软件变更管理软件风险管理测试与缺陷管理动态可视化的报告与图形分析此外,系统还应具备以下综合能力:过程的关联管理与追踪敏捷型软件开发...

    在同一的系统平台上实现软件项目全过程的管理,包括需求分析、设计、开发、测试、代码编译发布等,并能够按照业界实践对其过程进行管控和各过程间的连接。

    系统核心功能在统一的管理平台中实现,包括:

    产品/软件需求(与产品规格)管理

    软件开发与结果管理

    软件配置管理

    软件变更管理

    软件风险管理

    测试与缺陷管理

    动态可视化的报告与图形分析

    此外,系统还应具备以下综合能力:

    全过程的关联管理与追踪

    敏捷型软件开发模式的支持

    便捷的软件生命周期资产重用

    与主流研发管理系统(如Windchill系统)的集成

    行业合规性的支持

    支持中文界面

    系统特性与集成

    在软件开发的全生命周期管理的全过程,能够与常规应用的工具进行集成,包括Microsoft Word、Microsoft Excel、Eclipse、Visual Studio等。

    系统支持以下特性:

    可追溯:所有工程工件(Artifacts)必须关联

    可控制:所有核心研发流程(机电软)必须要融合协调,变更可控、版本一致

    可见性:发布准备就绪情况要实时可见、准确和可预测

    可协同:跨领域以及跨组织部门的协作

    可集成:具备和现存工具及流程的集成

    可管理:需求覆盖完整,知识可以重用,从构思采纳到产品上市必须要迅速

    应用方面,需满足如下要求:

    支持单一来源的一体化解决方案

    对软件发布准备情况的即时可视性

    学科和供应链的全球协作

    能够快速回应变更

    适应性强的流程,能不断接受检查和改写(来源网络)

    关于宇航

    深圳市宇航软件股份有限公司是国内领先的工业互联网解决方案提供商。旗下全资子公司宇航智能获得国家高新技术企业认证。公司于 2016年新三板挂牌上市(股票代码835973),一直秉承“专业高效,决不让客户失败”的理念,以质量铸就品牌,用服务赢得口碑,助推中国制造2025。

    宇航股份作为西门子战略合作伙伴,在SIEMEMS MOM产品上深度合作,为宇航提供强大的技术保障;同时自主研发MOM平台U-infor,产品涵盖MES系统、WMS系统、报表平台、智能物联管控系统、U-云等系列产品,凭借在离散制造业10余年服务经验,专业提供新能源汽车、机械装配、智能家居、医疗器械、电子行业等智能数字化工厂一体化解决方案,致力于成为工业互联网整体解决方案引领者。

    展开全文
  •   接受软件项目管理培训已经好长时间了,培训结束之后就一直仍在了一边,现在真正要用的时候却发现基本忘的差不多了!这里就回顾一下之前的所学,充实一下自己。   由于本文中的大多数术语都是一些规范或者约定...

      接受项目管理培训至今已经有三年时间了,一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头,从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验,希望可以帮助到从事项目管理的人!

      由于本文中的大多数术语都是一些规范或者约定俗称的概念,因此,本文的大部分内容都是来自于互联网。例如,软件开发过程 的定义引用自维基百科。本文仅仅是整理记录一些学习重点。如果您发现其中内容有侵权,请随时点击博客右侧的小企鹅进行联系或者直接私信我,我将第一时间进行处理!

    概念

      软件开发生命周期(Software Development Life Cycle,SDLC),又称为软件开发过程(Software Development Process),为软件的开发定义了一个框架,将自动化工具、软件开发方法和质量管理紧密结合在了一起,其各个阶段实现了软件的需求定义与分析、设计、实现、测试、交付和维护。软件开发过程是在开发与构建系统时应遵循的步骤,是软件开发的路线图。
    在这里插入图片描述
    上面这幅图是我在网上找到的(MBA智库),乍一看非常的复杂,甚至出现了哲学范畴的方法论。我个人感觉上图还是非常详细的。不过对于里面的细节并没有详细的介绍,后面我会介绍一下我的理解。

    SDLC 在有的资料里面也称为 系统开发生命周期(Systems Development Life Cycle, SDLC),且将它和软件开发生命周期等价。但是这两者其实是不一样的: 系统 = 软件 + 硬件 。不过他俩的内容基本是一致的。

      软件开发生命周期(SDLC)同时也是一种具有创建高质量软件的清晰定义过程的方法论。 这种 按时间分程 的思想方法是软件工程中的一种思想原则,即按部就班、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。具体而言,SDLC 方法侧重于软件开发的以下阶段:

    • 需求分析
    • 规划
    • 软件设计
    • 软件开发
    • 测试
    • 部署

    需要注意的是,我翻阅了大量介绍软件开发生命周期的文档,他们对于上面的阶段定义并不相同。如下是我在学习中找到的比较多的几种情况:
    在这里插入图片描述
      软件开发生命周期(SDLC)可被视作最早的形式化方法。SDLC 的主要想法是,在采用框架时应当“以审慎、结构化和方法化的方式开发信息系统。生命周期中的每个阶段,从概念提出到系统交付,都应当严格、依次地进行”。

      在实际的开发过程中,开发者们不断的总结归纳,最终形成了一些比较统一开发模式。这些开发模式就是一个个被称为软件开发过程模型(Software Development Process Models)。其中最著名的就应该是瀑布模型了。如下是一些常用的模型:
    在这里插入图片描述
    更进一步,一些业内的大佬还为某些过程模型制定了相应的规范。后面我们将介绍一些常见的过程模型。

      随着新的面向对象的设计方法和技术(包括后来的敏捷开发方法)的成熟,软件生命周期设计方法的指导意义正在逐步减少。但是,作为最早的开发方法,其为后续的软件开发影响深远(基本确立了软件开发的基本框架,说后续的方法基本都是对于 SDLC 的改进一点也不为过)。

      软件开发生命周期 ≠ \neq = 项目的开发周期 。企业项目中,软件开发生命周期 仅仅是项目开发周期的一部分。至于一个项目的具体阶段,则不同的公司有不同的规定(一般都有自己的标准指导文档)。

    软件开发方法论

      软件开发方法论(Software Development Methodology, SDM)框架是在 20 世纪 60 年代开始出现的。软件开发方法历史中的重要事件(引用自维基百科)有:

    我个人认为,软件开发生命周期(SDLC)可以分为宏观和微观两个维度。在宏观上,软件开发生命周期(SDLC)是指的软件开发的整个生命周期,其中包含各种方法论,工具等
    在这里插入图片描述
    在微观上,软件开发生命周期(SDLC) 本身就是一种方法论,这是由于历史遗留的原因,当初提出这个概念的时候其就是作为一种软件开发方法。
    在这里插入图片描述
    其中,比较特殊的就是快速应用程序开发和敏捷软件开发。

    快速应用程序开发

      快速应用程序开发(Rapid Application Development,RAD)是 SDLC 的一个替代品,它结合原型模型,将应用程序开发和 CASE工具的实现相结合。RAD 的优点是速度快,降低了开发成本,并且使用户更积极地参与开发过程。

    敏捷软件开发

      敏捷软件开发(Agile software development),又称敏捷开发,是一种从1990 年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。“敏捷”(Agile)一词由 “敏捷软件开发宣言”(Manifesto for agile software development)中开始推广,“敏捷软件开发宣言” 定义了相关的价值和原则。
    在这里插入图片描述
      同样在微观上,敏捷开发也可以被认为是指导软件开发过程的一种方法(称为敏捷开发模型)。但是,由于敏捷开发的优势,其逐渐发展为了一种方法论,有了一些列的规范,组织机构等。宏观上的敏捷开发中,包含各种具体的方法。

      敏捷开发更强调人的主观能动性,其价值观是:个体和互动高于流程和工具,工作的软件高于详尽的文档,客户合作高于合同谈判,响应变化高于遵循计划。其核心主要在于能够充分了解用户的痛点,将用户痛点分级,每次版本都只解决用户当前最大的痛点,然后通过快速开发的版本迭代满足用户需求从而占领市场,这也是 MVP(最小可用产品)的核心思维。

    敏捷式开发不仅仅是项目上的一种开发方式,同时也能指点我们在生活中采用 2/8 法则,抓住重点,用最小的力度来实现价值最大化。

      敏捷式开发的特性是能够持续性的对软件本体进行不断改造以及处理客户对软件开发过程中的不断介入。敏捷开发的主要优点在于其灵活性。 经过一次次例行的开发迭代期(iterations)后,在每一次迭代期的开始时小组便会考虑向软件引入新的特性和改变,也就不会特别跟随原有的开发要求。

      敏捷开发是现代软件开发中被广泛使用的范式。敏捷软件开发的框架不断的发展,两个最广泛被使用的是 ScrumKanban。敏捷软件开发是一个开发软件的管理新模式,用来替代以文档驱动开发的传统开发模式。

      总结一下就是,敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

       每隔一段时间,Digital.ai 就会发布一次关于敏捷开发的调查 STATE OF AGILE 并发布相应的 STATE OF AGILE 报告,并在 https://stateofagile.com/# 上进行公布。我们可以下载到对应的 PDF 文档。下面是最新的第 14 调查报告中的 敏捷开发方法使用情况:
    在这里插入图片描述
    该报告中有详细的记载关于敏捷开发的地域使用情况,行业使用情况等。

    敏捷软件开发宣言

      在 2001 年,十七名软件开发人员在犹他州的瓦萨奇山雪鸟滑雪胜地会面,讨论一些轻量级的开发方法,并由 Jeff Sutherland,Ken Schwaber 和 Alistair Cockburn 发起,一同发布了 “敏捷软件开发宣言”(Manifesto for Agile Software Development)。

      参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶方法、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

      这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站(http://www.agilemanifesto.org/)首页的《敏捷软件开发宣言》,他们称自己为“敏捷联盟”。
    在这里插入图片描述
    官网提供了各种语言版本的敏捷软件开发宣言。有兴趣的可以直接去官网查看。

    敏捷联盟

      敏捷联盟(Agile Alliance)是一个全球性的非盈利性成员组织,致力于支持那些探索和应用敏捷价值、原则和实践的人们,使构建软件解决方案更有效、更人性化、更可持续。官方网址:https://www.agilealliance.org/
    在这里插入图片描述

    结构化方法

      结构化编程(Structured programming),一种编程典范。它采用子程序、块结构、for 循环以及 while 循环等结构,来取代传统的 goto。希望借此来改善计算机程序的明晰性、质量以及开发时间,并且避免写出面条式代码。

    面向对象方法

      面向对象方法(Object-Oriented Method)是一种把面向对象的思想应用于软件开发过程中,指导开发活动的系统方法,简称OO (Object-Oriented)方法,是建立在“对象”概念基础上的方法学。

    过程模型

      过程模型就是指导软件开发过程的方法论。过程模型由五个基本的框架活动组成:沟通、计划、建模、构建和部署。他们之间的线性(linear)、迭代(iterative)、演进(evolutionary)和平行(parallel)关系会产生不同的模型。常见的过程模型包括:瀑布模型、V 模型、原型模型、增量模型、螺旋模型等。常见的软件测试模型包括 V 模型、W 模型、H 模型、X 模型和前置模型。

      过程模型(Process Models) 意图解决软件过程中的混乱,将软件开发过程中的沟通、计划、建模、构建和部署等活动(activities)有效地组织了起来。

    瀑布模型

      瀑布模型(Waterfall Model)是最早出现的软件开发模型,是传统软件开发方法的代表。在软件工程中占有重要的地位,它提供了软件开发的基本框架。1970 年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到 80 年代早期,它一直是唯一被广泛采用的软件开发模型。

      瀑布模型将软件生命周期划分为 制定计划、需求分析、软件设计、程序编写、软件测试和运行维护 等六个基本活动,并且规定了它们 自上而下、相互衔接的固定次序 ,如同瀑布流水,逐级下落。其 严格强调文档,前一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档,而不是开发软件,因为要到开发的后期,才可以看到软件的“模样”。
    在这里插入图片描述

    • 优点:
      1. 让软件开发过程有序可控,为项目提供了按阶段划分的检查点。瀑布模型的每个阶段都有明确的任务,每个阶段都有明确的交付产物,都有相应的里程碑。这些让整个过程更可控,而且能及早发现问题
      2. 当前一阶段完成后,您只需要去关注后续阶段
      3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
      4. 让分工协作变成可能。瀑布模型的六个阶段,也让软件开发产生相应的基础分工:项目经理、产品经理、架构师、软件工程师、测试工程师、运维工程师。
      5. 质量有保障。瀑布模型每个阶段都需要交付相应的文档,而文档的撰写和评审,可以帮助在动手之前把问题沟通清楚,想清楚。瀑布模型在编码结束后,会有严密的测试,只有测试验收通过后,才能上线发布,这些措施都让软件的质量更有保障。
    • 缺点:
      1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
      2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
      3. 没有迭代与反馈。瀑布模型对反馈没有涉及,所以对变化的客户需求非常不容易适应,瀑布就意味着没有回头路。
      4. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
      5. 瀑布模型的突出缺点是不适应用户需求的变化。
      6. 瀑布模型是一种软件文档的开发,把开发者变成流水线上的机器,大量重复性的工作让编程人员提不起兴趣,工作很枯燥,没有激情,编程成了一种没有创意的机械劳动,这让一向以高科技为标志的高级程序人员大为恼火。

      虽然现在瀑布模型已经不是最主流的开发模式。但是不管什么软件项目,不管采用什么开发模式,有四种活动是必不可少的,那就是需求、设计、编码和测试。而这四项活动,都是起源自瀑布模型,也是瀑布模型中核心的部分。 管理人员喜欢瀑布模型的原因是把文档理解为开发的速度,可以方便地界定不同阶段的里程碑。

    V 模型

      1978 年 Kevin Forsberg & Harold Mooz 提出了 V 模型(也被称为验证和验证模型)。V 模型是一个著名的、以测试为驱动的开发模型,该模型强调开发过程中测试贯穿始终,是瀑布模型的一个变体。V 模型反映了开发过程和测试过程的关系,在测试软件的过程中起着非常重要的作用。测试依旧是开发生命周期中的阶段,与瀑布模型不同的是,有多个测试级别与开发阶段对应。
    在这里插入图片描述
      需求分析要分析用户的需要,整理出系统的需求(功能需求),会和用户面谈,建立 用户需求文档(user requirements document);概要设计是系统设计师根据用户需求文档,分析并理解要开发系统的业务流程的阶段,会产生 软件规格文档(software specification document),软件规格文档是开发阶段的蓝图;详细设计也称为低阶设计,会将设计的系统拆解为较小的单元或是模组,说明每一部分的内容,让程式设计者可以直接写程式。

      单元测试主要发现编程和详细设计阶段的错误,测试计划在详细设计阶段制定,在编码阶段完成;集成测试主要发现设计阶段产生的错误,测试计划在概要设计阶段制定,在详细设计阶段完成;系统测试计划在需求分析阶段制定,在概要设计阶段完成;验收测试(User Acceptance Test)计划会在需求分析阶段就订定,测试计划是由企业用户来进行。

    与瀑布模型一样,V 模式是一种传统软件开发模型,在当前互联网软件开发中,局限性还是比较大的!

    • 优点:
      1. 包含了底层测试(单元测试)和高层测试(系统测试)
      2. 清楚的标识了开发和测试的各个阶段
      3. 自上而下逐步求精,每个阶段分工明确,便于整体项目的把控
      4. 像计划、测试设计这样的测试活动会在编码之前很好地进行。这节省了很多时间。因此相比于瀑布模型,成功的几率更高。
    • 缺点:
      1. 测试与开发是串行进行的而不是并行,自上而下的顺序导致了,测试工作在编码之后,就导致错误不能及时的进行修改
      2. 实际工作中,需求经常变化,导致 V 模型步骤,反复执行,返工量很大,灵活度较低
      3. V 模型太过简单,无法准确的反映软件开发的过程,会让管理者有一种错误的安全感。V 模型反映了软件开发中,管理者的观点,适合专案管理者、会计师及律师,但不适合软件开发者及用户
      4. V 模型和瀑布模型一样,过程中产生大量文档,项目反应速度也越来越不能满足当前日新月异的需求和快速的更新换代的节奏。

      V 模型的软件开发不是以直线的方式进行,其过程在源代码阶段之前逐步往下,而在源代码阶段之后逐步往上,形成了 V 字形。V 模型指出了软件开发中的各阶段以及其对应软件测试阶段之间的关系。横轴表示时间或是项目的完成度,而纵轴表示抽象的程度(范围越大,越抽象的在越上方)。

      V 模型的中心思想是研发人员和测试人员需要同时工作,在软件做需求分析的同时就会有测试用例的跟踪。 这样可以尽快找出程序错误和需求偏离,从而更高效的提高程序质量,最大可能的减少成本,同时满足用户的实际软件需求。V 模型的重要意义在于,非常明确的表明了测试过程中存在的不同的级别,并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。

    1. 据说这是 IBM 的测试模型
    2. V 模型在汽车行业的影响深刻

    W 模型

      W 模型是由 Evolutif 公司提出,相对于 V 模型,W 模型增加了软件开发各阶段中同步进行的验证和确认活动。W 模型由两个 V 字型模型组成,一个 V 是开发的生命同期,另一个 V 是测试的生命周期,其明确表示出了测试与开发的并行关系(如下图)。
    在这里插入图片描述
      W 模型与 V 模型有一个很大的不同,就是 W 模型是一个并行的模型,V 模型是一个串行的模型。W 模型测试是从需求分析开始就开始了,而不是等到编码完成后才开始。并且测试阶段的划分更清楚,而不仅仅是单元测试、集成测试、系统测试,还包括前期的测试计划、测试方案等内容,这更符合现在企业测试的流程。W 模型具有以下特征:

    1. 测试阶段划分得更全面,不仅仅是单元测试、集成测试和系统测试。测试的对象不仅是程序,需求、设计等同样要测试
    2. 测试与开发是并行的,从需求测试就应该开始介入
    3. 提出尽早测试的概念,这样可以降低缺陷修复成本
    4. 测试对象不仅仅是程序,还包括需求或其他的相关文档

    W 模型仍然是以文档驱动的传统开发方式的一个变种

    • 优点:
      1. 开发伴随着整个开发周期,需求和设计同样要测试
      2. 更早的介入测试,可以发现初期的缺陷,修复成本低
      3. 分阶段工作,方便项目整体管理。
    • 缺点:
      1. 开发和测试依然是线性的关系,需求的变更和调整,依然不方便,样就无法支持迭代的开发模型
      2. 如果没有文档,根本无法执行 W 模型;对于项目组成员的技术要求更高!

    快速原型模型

      快速原型模型(Rapid Prototype Model)又称原型模型,它是增量模型的另一种形式;它是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。下图显示了快速原型模型开发的基本步骤:
    在这里插入图片描述
      由于种种原因,在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的。快速原型是利用原型辅助软件开发的一种新思想。 经过简单快速分析,快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,适应变化,最终提高软件质量。

    • 优点
      1. 原型系统已经通过与用户交互而得到验证,克服瀑布模型的缺点,据此产生的规格说明可以正确地描述用户的需求。因此,在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
      2. 开发人员通过建立原型系统已经学到了许多东西(至少知道了“系统不应该做什么,以及怎么不去做不该做的事情”),因此,在设计和编码阶段发生错误的可能性也比较小,这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
    • 缺点
      1. 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下,因此不适合大型系统的开发(适合开发小型的、灵活性高的系统)。
      2. 使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新
      3. 所选用的原型(开发技术和工具)不一定符合主流的发展
      4. 快速原型模型是不带反馈环的,软件产品的开发基本上是按线性顺序进行的。

    现在很多互联网企业提供了各式各样的原型设计工具,例如:Mockplus、Balsamiq、Axure 等。

    增量模型

      增量模型(Incremental Model)融合了瀑布模型的基本成分(重复应用)和原型实现的迭代特征,该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。产品被分解为多个组件,每个组件都是单独设计和构建的。各个构件完成后逐渐并入已有的软件体系结构中。

      当使用增量模型时,第 1 个增量往往是核心的产品,即第 1 个增量实现了基本的需求,但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示:
    在这里插入图片描述
      在增量模型中,每个迭代阶段都得到开发,因此每个阶段都将经历软件开发生命周期的要求、设计、编码,最后是测试模块。每个阶段开发的功能都将添加到以前开发的功能上,在软件完全开发之前,该功能将重复。在每个增量阶段,都会进行审查,根据审查,下一阶段的决定将作出。

      增量模型与原型实现模型和其他演化方法一样,本质上是迭代的,但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本,但提供了为用户服务的功能,并且为用户提供了评估的平台。

      增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。

    增量模型的特征:

    1. 系统被分解成许多小型开发项目。
    2. 部分系统是为了生成最终系统而构建的。
    3. 首先满足最高优先级要求。
    4. 一旦开发递增部分,部分的需求将被冻结。

    增量模型的优缺点:

    • 优点
    1. 采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源。如果核心产品很受欢迎,则可增加人力实现下一个增量。因此,增量能够有计划地管理技术风险。
    2. 每次迭代后,应执行回归测试。在此测试期间,可以快速识别软件的故障元素,因为在任何单个迭代中很少进行更改。
    3. 测试和调试比其他类型的软件开发方法更容易,因为每次迭代时所做的更改相对较小。这允许对整个产品中的每个元素进行更有针对性的、更严格的测试。
    4. 客户可以响应功能并查看产品,以了解任何需要或有用的更改。
    5. 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型
    • 缺点
    1. 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构
    2. 在开发过程中,需求的变化是不可避免的。很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
    3. 如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析
    4. 随着产品增加了其他功能,可能会出现与系统体系结构相关的问题,而早期原型中并不明显
    5. 由增量产生的成本可能会超过组织的成本。

    增量理念也用于敏捷流程模型

    螺旋模型

      螺旋模型(Spiral Model)是巴利·玻姆(Barry Boehm)于 1988 年 5 月在他的文章《一种螺旋式的软件开发与强化模型》提出的。它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。螺旋模型最大的特点在于 引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。

      螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它,项目经理在早期就能够为客户实证某些概念。该模型是快速原型法,以进化的开发方式为中心,在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审 4 个阶段,由这 4 个阶段进行迭代。软件开发过程每迭代一次,软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:
    在这里插入图片描述

    • 优点
    1. 通过原型的创建,使软件开发在每个迭代的最初明确方向;
    2. 通过风险分析,最大程度地降低软件彻底失败造成损失的可能性;
    3. 在每个迭代阶段植入软件测试,使每个阶段的质量得到保证;
    4. 整体过程具备很高的灵活性,在开发过程的任何阶段自由应对变化;
    5. 每个迭代阶段累计开发成本,使支出状况容易掌握;
    6. 通过对用户反馈的采集,与用户沟通,以保证用户需求的最大实现;
    • 缺点
    1. 过分依赖风险分析经验与技术,一旦在风险分析过程中出现偏差将造成重大损失;
    2. 过于灵活的开发过程不利于已经签署合同的客户与开发者之间的协调;
    3. 由于只适用大型软件,过大的风险管理支出会影响客户的最终收益;

      螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。在需求不明确的情况下,适合用螺旋模型进行开发,便于风险控制和需求变更。

    敏捷开发方法

    见后续独立博文

    参考

    1. https://wiki.mbalib.com/wiki/%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B
    2. https://zhuanlan.zhihu.com/p/183798988
    3. https://blog.si-yee.com/2019/10/03/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E4%B9%8B%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B/
    4. https://zhuanlan.zhihu.com/p/29783716
    5. https://zhuanlan.zhihu.com/p/24417533
    6. https://zhuanlan.zhihu.com/p/150399191
    7. https://www.zhihu.com/question/20014400
    8. https://blog.csdn.net/qq_43725037/article/details/86213779
    9. https://www.cnblogs.com/zhuifeng-mayi/p/9853123.html
    10. https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/
    11. https://www.cnblogs.com/ITnoteforlsy/p/11938493.html
    12. https://www.guru99.com/v-model-software-testing.html
    13. https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm
    14. http://www.srcmini.com/35680.html
    15. https://zhuanlan.zhihu.com/p/56673435
    16. https://wiki.mbalib.com/wiki/%E5%A2%9E%E9%87%8F%E6%A8%A1%E5%9E%8B
    17. https://www.technotrice.com/incremental-model-in-software-engineering/
    18. https://melsatar.blog/2012/03/21/choosing-the-right-software-development-life-cycle-model/
    19. https://www.visual-paradigm.com/scrum/scrum-in-3-minutes/
    20. https://tech.gsa.gov/guides/popular_approaches/
    21. https://kknews.cc/tech/e8qgp9z.html
    展开全文
  • 软件缺陷生命周期

    2021-07-23 05:16:46
    这个图片看起来很复杂,但是只要考虑到缺陷生命周期中的这些重要步骤,你很快就会明白缺陷生命周期的含义了。记录完了缺陷之后,开发人员或者测试经理就会去检查这些缺陷报告。测试经理可以把缺陷状态设置为“打开”...
  • 项目管理的流程 第一次内测→第二次内测→SIT内测→UAT测试→试运营→上线跟踪。 第一次内测,主要由研发人员自己开发并验证; 第二次内测,主要是研发提交给测试人员进行测试,并将bug打回,让研发人员重新返工; ...
  • 九章云极DataCanvas技术副总裁于建岗博士受邀出席大会,并在 “未来智能——迈向下一代AI:数据·流程·生态” 分论坛发表题为《AI应用时代:用ModelOps打造模型的全生命周期管理》的精彩演讲。 于建岗博士指出,...
  • 题记:要做好软件实施,要增加看问题的高度,拓宽视野,高屋建瓴,知道站在项目的全生命周期中看问题,而不是只看到实施人员的工作内容。切记,狭隘的思想会让你的成功变得异常困难。本文先简要谈谈管理软件项目的...
  • (ALM) 套件软件调研报告,侧重分析在中国市场扮演重要角色的企业,重点呈现这些企业在中国市场的应用程序生命周期管理 (ALM) 套件软件收入、市场份额、市场定位、发展计划、产品及服务等。历史数据为2016至2020年,...
  • 产品生命周期管理在数字经济发展过程中是必不可少的,在零售快消行业可用来指导产品的以销定采和精准投放,在IT行业可辅助软件应用等产品的开发进程管理,同时还也会对环境管理产生影响,对建筑业在节能减排、减轻...
  • 软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。简单的软件缺陷生命周期:1、发现——打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员;2、打开——修复:...
  • 软件生命周期 / 缺陷

    千次阅读 2020-12-27 21:42:22
    一、软件生命周期 软件开发全部过程、活动和任务的结构框架,是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程 软件测试的生命周期软件开发过程中,软件测试所做的全部工作可称为...
  • 随着各种信息通讯技术的快速发展,软件产品开发中的重要度上升已经是跨行业的趋势,各个行业的产品都...Polarion提供软件生命周期管理的一体化解决方案,它支持从软件需求到版本规划,软件开发过程、测试、软件Bui.
  • 软件的概念 许多人对于软件的一个理解软件就是程序,软件开发i就是编写程序。其实软件是计算机系统中与硬件相互依存的一部分,它是包括程序(程序是...软件生命周期,又称为软件的生存周期。它是按开发软件的规模和复
  • 软件测试工作流程软件生命周期软件生命周期模型软件测试流程 软件生命周期 软件生命周期软件开始研制到最终被废弃不用所经历的各个阶段,在不同阶段里,有不同的组织个人和资源进行着明确的任务。 软件生命周期...
  • 本文研究全球及中国市场产品生命周期管理现状及未来发展趋势,侧重分析全球及中国市场的主要企业,同时对比北美、欧洲、日本、中国、东南亚、印度等地区的现状及未来发展趋势。 2020年全球产品生命周期管理市场规模...
  • 软考信息系统项目管理工程师(高级)必背之信息系统典型生命周期模型 目录 1 瀑布模型 2 螺旋模型 3 迭代模型 4 V模型 5 原型化模型 6 敏捷开发模型 7信息系统典型的生命周期模型总结 1 瀑布模型 2 ...
  • PLM:Product Lifecycle Management=产品生命周期管理产品的整个生命周期包括:投入期、成长期、成熟期、衰退期、结束期。PLM系统使企业可以把...其二,对产品成本的全生命周期管理。从财务角度,将财务从规划、设
  • 文章目录软件工程概述软件的定义软件的分类软件工程要素、目标和原则软件工程知识体系知识域软件生命周期模型工程过程传统模型种类瀑布模型演化模型增量模型喷泉模型V模型和W模型螺旋模型构件组装模型快速应用开发...
  • 大数据在锂电池全生命周期管理中的应用 摘要:在数字经济时代,大数据已被视为一种重要的生产要素。通过数据采集、清洗、分析和建模,将隐藏在数据背后的客观规律充分挖掘利用,成为促进企业智能化管理和产业升级的...
  • 什么是软件过程 ...软件的生命周期概念的提出更加有利于们更加科学,有效的组织和管理软件生产。 软件生命周期这个概念从时间的角度将软件的开发和维护的复杂过程分为若干个阶段,每个阶段完成相对独立的任务
  • 使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于 检验是否满足规定的需求或者弄清预期结果与实际结果的区别。 描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。 换句话说...
  • 软件生命周期与流程

    2021-07-23 12:38:22
    (一)传统软件工程: 分析→设计编码→测试→维护 (二)现代软件工程 1、OOA面向对象 OOD、设计方法等 2、CMMI 软件成熟度模型 CMMI 5:优化级 特征:关注...(三)软件生命周期 可行性分析 →需求分析→设计→ ...
  • 软件生命周期的基本任务 3 1.1. 软件定义时期 3 1.1.1. 问题定义 3 1.1.2. 可行性研究 3 1.1.3. 需求分析 3 1.2. 软件开发时期 3 1.2.1. 系统设计 3 1.2.2. 系统实现 3 1.3. 软件维护时期 3 1.3.1. 软件维护 3 各种...
  • 遗憾的是,许多产品都是使用"边做边改"模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。 在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过...
  • 生命周期软件产品或系统一系列相关活动的周期。《》ISO/IEC软件生存周期12207-1995》或-2008规定的过程标准。 -1995过程的划分:过程->活动->任务 基本过程:和软件开发有直接关系的过程。包括:获取...
  • ISO/IEC/IEEE 24748-1:2018(E) 系统与软件工程 - 生命周期管理 - 第1部分:生命周期管理指南 ISO/IEC/IEEE 24748-2 系统和软件工程-生命周期管理-第2部分:ISO15288 (系统生命周期流程)应用指南 ISO/IEC/IEEE ...
  • 第一章 软件工程学概述 1.1对软件的认识 **1950:**程序 **1960:**程序+文档 1970: 程序+文档+数据 软件是不会被用坏的 1.2 软件工程方法学 0.**对象:**一切具有意义的事物。...1.3 软件生命周期 三个时
  • 项目管理生命周期有五个阶段:启动、计划、执行、监控和收尾。在启动和计划阶段,项目获得必要的审批,计划已经创建,工作实际上从活动开始。执行阶段和监控阶段同时发生。这意味着你一边完成活动,一边在监控你的...
  • 瀑布模型 基线——不可逆转——逆转...开发人力少,适用于商业软件。 螺旋模型 周期性的方法开发,每个周期都包括需求,风险,实现和评审 周期长,风险高,需求不太明确 喷泉模型 开发人员可同步开发,多用于面向对象 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 173,604
精华内容 69,441
关键字:

产品全生命周期管理软件