软件开发过程一般有几个阶段

软件开发的生命周期一般分为6个阶段：计划、需求分析、逻辑设计、程序编制、调试、运行和维护

软件生命周期分为软件定义、软件开发及软件运行维护三个阶段：

软件定义阶段

制定计划：确定总目标；可行性研究；探讨解决方案；制定开发计划。

需求分析：对待开发软件提出的需求进行分析并给出详细的定义。

软件开发阶段

软件设计：分为概要设计和详细设计两个部分 

软件实现：把软件设计转换成计算机可以接受的程序代码

软件测试：在设计测试用例的基础上检验软件的各个组成部分

软件运行维护阶段

软件投入运行，并在使用中不断地维护，进行必要的扩充和删改。

构成企业管理信息系统的5个基本要素 构成企业信息系统主要包括5个基本要素：企业的组织结构、流程、数据、商务规则与功能（性能）。其中从用户的角度主要关注流程，是以流程为核心的，通过流程将其他几个要素贯穿起来，需求分析人员也应该从这个角度来和用户沟通；从开发者的角度主要关注企业的数据、商务规则与功能，以便于系统的实现；从实施者的角度主要关注企业的组织结构与功能，以便于系统的发布与实施。 1） 企业的组织模型 即企业的组织结构关系，包括部门设置、岗位设置、岗位职责等。树型组织结构图是描述企业的组织模型的一种常用方法，它可用来搞清各部门之间的领导关系,每个部门内部的人员配备情况, 职责分工等情况,它是划分系统范围,进行系统网络规划的基础。在组织结构图中应将用户的组织结构逐层详细描述，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织结构图，是需求获取步骤中的基础工作之一。 用户环境中的企业岗位或角色，和组织机构一样，也是分析人员理解企业业务的基础，也是分析人员提取对象的基础。 对用户角色的识别常常遗漏的是计算机系统的系统管理人员，角色识别不全，对以后的功能识别会造成盲区。 （2） 企业的流程模型 即企业的业务流程，包含哪些流程、流程之间的关系、每个流程中包括哪些活动、每个活动涉及到的岗位。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图形式。对企业而言需要定义关于业务流程图的描述标准，大家采用相同的图例来描述，便于管理。 业务流程图的优点 : ■绘图的过程,实际上是作业流程条理化的过程 ■表达形象直观,易于和用户交流,易于项目组内部交流 调研的结果,需要得到用户的认同,这就需要和用户交流调研的结果,交流的文 档要通俗、易懂, 不能采用专业术语。 ■可以作为培训实施人员与技术服务人员的文档 业务流程图的缺点 : ■对高层管理人员的实际需求调查的不清楚 这一方面是由于用户没有接触过计算机, 对采用计算机后的管理会是什么样子计算机能够完成当前手工 *** 作的哪些内容能够作哪些现在手工无法完成的工作等等没有清楚的概念,因此用户无法将这些问题反应出来 另一方面说明分析人员没有经验,对原始材料挖掘不深,不能从用户 提供的材料中提炼处来用户的真正需求,不能找到当前管理中的问题。 ■对各种业务之间的总体关系没有表达出来 采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表达出来, 但是各业务之间的联系却没有表示出来,单看一种业务的流程图很清楚,但是却不能综合在一起,没有整体的概念,作为需求分析的文档,在这方面表达的不够完整。 ■在不利用工具的情况下,画法烦琐。 图形可以将流程描述的很清楚，但是还要附加以一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述出的内容，需要用文字进行详细描述。 （3） 企业的数据模型 即企业中的信息载体有哪些？以及对这些信息载体的详细刻画，包括企业的各种单据、帐本、报表的描述。在需求报告中，应该将单据的描述格式化，需要描述的内容包括： 单据的用途，即单据用在什么地方？ 单据的格式：需要明确的画出来，并有实际的有数据的样例，能够具体直观地说明问题； 单据中的数据项的具体描述：长度、类型、计算生成方法、约束条件等； 单据的数据项是由哪些不同类型的角色来填写地，包括用计算机可以填那些数据项。 单据中哪些数据是必填的，哪些是可以不用填的。 单据流量：平均每天产生多少条记录，高峰期的数量； 单据的分类：可以从多个角度上进行分类，如：按业务类型来分类（采购/销售/生产），按生成的方式来分类（手工录入型/自动生成型），按格式变化的频繁程度来分类（易变型/稳定型），按表现形式来分类（列表型/卡片型）等等。 单据之间的关系：引用关系等等。 同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。 （4） 企业的商务规则模型 即企业中的商务规则有哪些这些规则用在哪些地方 商务规则可以从影响的范围划分为2类：一类是局部的规则，如不允许出现负库存，一类是整体的规则，如对所有的物料

项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。做且只做范围内的工作，避免画蛇添足。

项目范围管理过程包括：规划范围管理，收集需求，定义范围，创建WBS，确认范围，控制范围六个过程，下面将对每个过程做重点阐述。

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。这一过程解决的是整个项目期间对如何管理范围提供指导性文件。

在项目环境中，“范围”有两种含义：

（1）产品范围：某项产品、服务或成果所具有的特征和功能。

（2）项目范围：为交付产品、服务或成果所必须完成的工作。

1-2-1 输入

（1）项目章程

记录项目目的、项目概述、假设条件、制约因素，以及项目意图实现的高层级需求。

（2）项目管理计划

  质量管理计划 ：在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。

项目生命周期描述： 项目生命周期定义了项目从开始到完成所经历的一系列阶段。

开发方法： 开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。

（3）事业环境因素

组织文化；基础设施；人事管理制度；市场条件。

（4）组织过程资产

政策和程序；历史信息和经验教训知识库。

1-2-2 工具与技术

（1）专家判断

需给出判断意见的主题：以往类似项目；特定行业、学科和应用领域的信息。

（2）数据分析

用于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。比如常用的数据分析技术备选方案分析。

（3）会议

参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、范围管理各过程的负责人，以及其他必要人员。

1-2-3 输出

（1）范围管理计划

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。

范围管理计划的内容包括：制定项目范围说明书；根据详细项目范围说明书创建 WBS；确定如何审批和维护范围基准；正式验收已完成的项目可交付成果。

（2）需求管理计划

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。

需求管理计划的主要内容包括：如何跟踪，规划和报告各种需求活动；配置管理如何启动变更，如何分析影响，如何追溯，跟踪报告，如何变更审批权限等活动；需求优先级排序；测量指标及应用这些指标的理由；反映哪些需求属性将被列入跟踪矩阵的跟踪结构等。

收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。

解决的是需要什么的问题。

2-2-1 输入

（1）项目章程

重点关注的是项目章程里面记录的项目概述以及将用于制定详细需求的高层级需求。

（2）项目管理计划

范围管理计划 ：范围管理计划包含如何定义和制定项目范围的信息。

需求管理计划 ：需求管理计划包含如何收集、分析和记录项目需求的信息。

相关方参与计划 ：从相关方参与计划中了解相关方的沟通需求和参与程度，以便评估并适应相关方对需求活动的参与程度。

（3）项目文件

假设日志： 有关产品、项目、环境、相关方以及会影响需求的其他因素的假设条件。

经验教训登记册 ：有效的需求收集技术，尤其针对使用迭代型或适应型产品开发方法的项目。

相关方登记册： 用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。

（4）商业文件

会影响收集需求过程的商业文件是商业论证，它描述了为满足业务需要而应该达到的必要、期望及可选标准。

（5）协议

协议包含的项目和产品需求部分。

（6）事业环境因素

能够影响收集需求过程的事业环境因素包括：组织文化，基础设施，人事管理制度，市场条件。

（7）组织过程资产

能够影响收集需求过程的组织过程资产包括：政策和程序；包含以往项目信息的历史信息和经验教训知识库。

2-2-2 工具与技术

（1）专家判断

针对以下方面给出专家意见：商业分析，需求获取，需求分析，需求文件，以往类似项目的项目需求，图解技术，引导，冲突管理。

（2）数据收集

头脑风暴： 用于产生和收集对项目需求和产品需求的创意技术。

访谈： 与相关方直接交谈，目的是识别和定义所需产品可交付成果的特征和功能，甚至可能获取到机密信息。

焦点小组： 召集预定的相关方和主题专家，一起研讨，目的是了解他们对所讨论产品，服务或成果的期望和态度。

问卷调查： 问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。

标杆对照： 将实际或计划的产品，过程和实践，与其他组织的进行比较，可比组织可以是内部也可以是外部。

（3）数据分析

用于本过程的数据分析主要是文件分析，文件分析包括审核和评估任何相关的文件信息，以识别和获取需求。

（4）决策

适用于手机需求过程的决策技术包括：

投票： 本技术用于生成，归类和排序产品需求，结果包括一致同意（每个人），大多数同意（超过50%）和相对多数同意

独裁型决策制定： 由一个人负责为整个集体制定决策。

多标准决策分析： 借助决策矩阵，用系统分析方法建立诸如风险水平，不确定性和价值收益等多种标准，以对众多创意进行评估和排序。

（5）数据表现

亲和图： 对大量技术进行分组，以便进一步审查和分析。

思维导图： 头脑风暴结果的呈现，用于反映创意间的共性和差异，激发新创意。

（6）人际关系与团队技能

名义小组技术 ：一种结构化的头脑风暴形式，有四个步骤：向集体提出问题，每个人写出想法；主持人记录所有人想法；集体讨论想法达成明确的共识；私下投票决出各种想法的优先排序，得分高者胜出。

观察和交谈 ：直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。

引导 ：把主要相关方召集在一起定义产品需求，有效引导参与者积极参与给出意见。适合引导的场景包括联合应用设计或开发 (JAD)、质量功能展开 (QFD)、用户故事

（7）系统交互图

对产品范围的可视化绘制，显示业务系统（过程，设备，计算机系统等）及其与人和其他系统（行动者）之间的交互方式。展示了业务系统的输入，输入提供者，业务系统的输出和输出接收者。

（8）原型法

原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。

2-2-3 输出

（1)需求文件

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。

需求分类包括：业务需求、相关方需求、解决方案需求（功能需求/非功能需求）、过渡和就绪需求、项目需求、质量需求

（2）需求跟踪矩阵

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。

可应用于整个项目生命周期中跟踪需求。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期等。

3-1 定义

定义范围是制定项目和产品详细描述的过程，本过程的主要作用是，描述产品、服务或成果的边界和验收标准，解决的是需要做什么的问题。

本质是从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。

3-2 重点描述

3-2-1 输入

（1）项目章程

项目章程中包含对项目的高层级描述、产品特征和审批要求。

（2）项目管理计划

项目管理计划中的范围管理计划记录了如何定义、确认和控制项目范围。

（3）项目文件

假设日志： 有关产品、项目、环境、相关方以及会影响项目和产品范围的假设条件和制约因素。

需求文件： 应纳入范围的需求。

风险登记册： 可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险。

（4）事业环境因素

 组织文化；基础设施；人事管理制度；市场条件。

（5）组织过程资产

用于制定项目范围说明书的政策、程序和模板；以往项目的项目档案；以往阶段或项目的经验教训。

3-2-2 工具与技术

（1）专家判断

（2）数据分析

此过程中常用备选方案分析，备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。

（3）决策

常用的是多标准决策分析，多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。

（4）人际关系与团队技能

通过引导使关键相关方就项目可交付成果以及项目和产品边界达成跨职能的共识。

（5）产品分析

产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。

产品分析技术包括产品分解，需求分析，系统分析，系统工程，价值分析，价值工程。

3-2-3 输出

（1）项目范围说明书

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。包括：

  产品范围描述： 逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。

可交付成果 ：为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或

服务能力 ：可交付成果也包括各种辅助成果，如项目管理报告和文件。

  验收标准 ：可交付成果通过验收前必须满足的一系列条件。

项目的除外责任 ：识别排除在项目之外的内容。

（2）项目文件更新

可在本过程更新的文件包括：假设日志，需求文件，需求跟踪矩阵，相关方登记册。

4-1 定义

创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程解决的是怎么做的问题。

4-2 重点描述

4-2-1 输入

（1）项目管理计划

项目管理计划中的范围管理计划定义了如何根据项目范围说明书创建 WBS。

（2）项目文件

项目范围说明书：需要实施的工作及不包含在项目中的工作。

需求文件：各种单一需求如何满足项目的业务需要。

（3）事业环境因素

会影响创建 WBS 过程的事业环境因素包括（但不限于）项目所在行业的 WBS 标准，这些标准可以作为创建 WBS 的外部参考资料。

（4）组织过程资产

能够影响创建 WBS 过程的组织过程资产包括（但不限于）：用于创建 WBS 的政策、程序和模板；以往项目的项目档案；以往项目的经验教训

4-2-2 工具与技术

（1）专家判断

（2）分解

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。

4-2-3 输出

（1）范围基准

范围基准是经过批准的范围说明书、WBS 和相应的 WBS 词典。

项目范围说明书 ：包括对项目范围、主要可交付成果、假设条件和制约因素的描述

WBS： 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。

工作包： WBS 的最低层级是带有独特标识号的工作包。每个工作包都是控制账户的一部分。

规划包： 一个控制账户可以包含一个或多个规划包，其是一种低于控制账户而高于工作包的工

作分解结构组件，工作内容已知，但详细的进度活动未知。

WBS词典： 针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。

（2）项目文件更新

可在本过程更新的项目文件包括假设日志和需求文件。

确认范围是正式验收已完成的项目可交付成果的过程。解决的是验收问题。

5-2-1 输入

（1）项目管理计划

范围管理计划、需求管理计划、范围基准

（2）项目文件

经验教训登记册、质量报告、需求文件、需求跟踪矩阵

（3）核实的可交付成果

核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。

（4）工作绩效数据

包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。

5-2-2 工具与技术

（1）检查

检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。

（2）决策

可用于本过程的决策技术包括（但不限于）投票。

5-2-3 输出

（1）验收的可交付成果

符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。

（2）工作绩效信息

包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给相关方。

（3）变更请求

对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。

（4）项目文件更新

本过程可更新的项目文件包括：经验教训登记册，需求文件，需求跟踪矩阵

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。

6-2-1 输入

（1）项目管理计划

包括范围管理计划、需求管理计划、变更管理计划、配置管理计划、范围基准、绩效测量基准

（2）项目文件

经验教训登记册，需求文件、需求跟踪矩阵

（3）工作绩效数据

包括收到的变更请求的数量、接受的变更请求的数量，或者核实、确认和完成的可交付成果的数量。

（4）组织过程资产

能够影响控制范围过程的组织过程资产包括（但不限于）：现有的、正式和非正式的，与范围控制相关的政策、程序和指南；可用的监督和报告的方法与模板。

6-2-2 工具与技术

（1）数据分析

偏差分析： 偏差分析用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。

趋势分析： 趋势分析旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

6-2-3 输出

（1）工作绩效信息

本过程产生的工作绩效信息是有关项目和产品范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。

（2）变更请求

分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程的审查和处理。

（3）项目管理计划更新

范围管理计划

范围基准：在针对范围、范围说明书、WBS 或 WBS 词典的变更获得批准后，需要对范围基准做出相应的变更。

进度基准：在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。

成本基准：在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。

绩效测量基准：在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。

（4）项目文件更新

本过程可更新的项目文件包括：经验教训登记册，需求文件，需求跟踪矩阵

软件开发的定义：软件开发（Software development）是根据用户要求建造出软件系统或者系统中的软件部分的过程。它是一项包括需求获取、开发规划、需求分析和设计、编程实现、软件测试、版本控制的系统工程。 软件开发包括研究、修改、复用、重新设计（再工程）、维护等活动，通常采用软件开发工具进行开发。对所要解决的问题进行总体定义，包括了解用户的要求及现实环境，从技术、经济和社会因素等3个方面研究并论证本软件项目的可行性，编写可行性研究报告，探讨解决问题的方案，并对可供使用的资源（如计算机硬件、系统软件、人力等）成本，可取得的效益和开发进度作出估计，制订完成开发任务的实施计划。搜狗百科



软件开发

根据用户需求编写指定软件的行为

软件开发（Software development）是根据用户要求建造出软件系统或者系统中的软件部分的过程。它是一项包括需求获取、开发规划、需求分析和设计、编程实现、软件测试、版本控制的系统工程。 软件开发包括研究、修改、复用、重新设计（再工程）、维护等活动，通常采用软件开发工具进行开发。

中文名

软件开发

外文名

Software development

领域

计算机

作用

根据用户需求建造软件产品

阶段划分

计划



软件开发

对所要解决的问题进行总体定义，包括了解用户的要求及现实环境，从技术、经济和社会因素等3个方面研究并论证本软件项目的可行性，编写可行性研究报告，探讨解决问题的方案，并对可供使用的资源（如计算机硬件、系统软件、人力等）成本，可取得的效益和开发进度作出估计，制订完成开发任务的实施计划。

分析

软件需求分析就是对开发什么样的软件的一个系统的分析与设想。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计定义，编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计划。在任何软件或系统开发的初始阶段必须先完全掌握用户需求，以期能将紧随的系统开发过程中哪些功能应该落实、采取何种规格以及设定哪些限制优先加以定位。系统工程师最终将据此完成设计方案，在此基础上对随后的程序开发、系统功能和性能的描述及限制作出定义。

需求分析。生命周期法是信息系统最早使用的一种开发方法，至今仍是大中型系统项目的最好开发方法，在这个生命周期设计软件过程中的用例图是需求分析的工作，该工作概括为四个方面需求获取、需求分析、编写需求规格说明书和需求评审。例图是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。

以上就是关于软件开发过程一般有几个阶段全部的内容，包括:软件开发过程一般有几个阶段、构成管理信息系统的基本要素是什么、PMP|十大知识体系（二）项目范围管理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！