软件开发管理流程图（软件开发管理过程）

本篇文章给大家谈谈软件开发管理流程图，以及软件开发管理过程对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、软件工程各种图的区别
• 2、软件开发有哪些需求分析管理工具？或者说一个软件需求分析师会用到什么工具
• 3、bpmn流程图要运行起来，并且能接收用户输入，跟实际数据库联系，请问用什么软件，在什么环境下开发啊？
• 4、互联网软件开发过程包括哪几个阶段？
• 5、软件开发过程中的常见问题有哪些？

软件工程各种图的区别

1.完成患者监护系统功能级的数据流图、实体联系图、软件结构图。2.网上书店系统,其外部用户主要有游客、会员和管理员。其中,游客进行注册后,可以成为系统的会员,会员享有订购图书及订单和书籍等信息查询的功能,管理员可对系统的各种信息进行管理和维护。根据上述描述,请画出网上书店系统的:①基本系统模型(第0层);②功能级的数据流图(第1层);③底层的订购图书数据流图。1.把如下统计空格程序的Jackson图改画为等价的程序流程图和盒图。2、用Jackson图描述下述的一列火车的构成:一列火车最多有两个火车头。只有一个火车头时则位于列车最前面

软件开发有哪些需求分析管理工具？或者说一个软件需求分析师会用到什么工具

需求分析是不可能考一个软件就搞定的。需求分析指的是开发软件前，对所有需求进行分析整合，最后形成一个文档的过程。最问的文档一般来说就是word，word中的内容就是你自己写的，通常会包含流程图，画流程图的工具有太多太多了，比如，visio，rose等。如果包含数据库模型，还可能用到PD等工具。。。。。等等等等。所以没办法确切的说会用到哪些工具，不过word类应该是99.99%都会用到。

bpmn流程图要运行起来，并且能接收用户输入，跟实际数据库联系，请问用什么软件，在什么环境下开发啊？

业务流程建模标注（Business Process Modeling Notation，BPMN)　描述基本的BPMN符号，包括这些图元如何组合成一个业务流程图（Business Process Diagram）；讨论BPMN的各种的用途，包括以何种精度来影响一个流程图中的模型；（Also discussed will be the different uses of BPMN, including how levels of precision affect what a modeler will include in a diagram.）；BPMN作为一个标准的价值，以及BPMN未来发展的远景。

由BPMI(The Business Process Management Initiative)开发了一套标准叫业务流程建模符号(BPMN)。在 BPMI Notation Working Group超过2年的努力，于2004年5月对外发布了BPMN 1.0 规范。BPMN的主要目标是提供一些被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控。BPMN也支持提供一个内部的模型可以生成可执行的BPEL4WS。因此BPMN的出现，弥补了从业务流程设计到流程开发的间隙。

BPMN定义了一个业务流程图（Business Process Diagram），该业务流程图基于一个流程图（flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型（Business Process Model），指一个由的图形对象（graphical objects）组成的网状图，图形对象包括活动（acticities)和用于定义这些活动执行顺序的流程控制器（flow controls）。

编辑本段BPMN规范简介BPMN是BPM以及workflow的建模语言标准之一,有必要学习。

在我的前篇文章浅谈众多工作流规范中谈到了一个重要的工作流建模语言的规范--BPMN。先是直接查看BPMN V1.01的规范内容，200多页内容繁多，细节不少。作为初学者看得晕头转向，现献上 帮助初学者理清思路,总体把握清楚BPMN规范。

1、什么是BPMN

首先BPMN规范是由标准组织BPMI发布的.BPMN 1.0规范发布于2004年5月。此规范展示了BPMI组织两年多的努力成果。BPMN的主要目标就是要提供被所有业务用户理解的一套标记语言，包括业务分析者、软件开发者以及业务管理者与监察者。BPMN还将支持生成可执行的BPEL4WS语言。所以，BPMN在业务流程设计与流程实现之间搭建了一条标准化的桥梁。

BPMN定义了业务流程图，其基于流程图技术，同时为创建业务流程操作的图形化模型进行了裁减。业务流程的模型就是图形化对象的网图，包括活动（也可以说工作）和定义操作顺序的流控制。

2、BPMN基础

业务流程图由一系列的图形化元素组成。这些元素简化了模型的开发，且业务分析者看上去非常熟悉。这些元素每个都有各自的特性，且与大多数的建模器类似。比如，活动是矩形，条件是菱形。应该强调的是：开发BPMN的动力就是为了在创建业务流程模型时提供一个简单的机制，同时又能够处理来自业务流程的复杂性。要处理这两个矛盾的需求的方法就是将标记的图形化方面组织分类为特定的类别。这里提供标记类别中的一小部分，以便业务流程图的读者可以简单地识别出元素的基本类型从而理解图形。以下是四种基本的类型：

1）流对象

2）连接对象

3）泳道

4）人工信息

下面一一解释

流对象：

一个业务流程图有三个流对象的核心元素。这三种流对象是

事件---一个事件用圆圈来描述，表示一个业务流程期间发生的东西。事件影响流程的流动，一般有一个原因（触发器）或一个影响（结果）。基于它们对流程的影响，有三种事件：开始，中间以及终止事件

活动－－－一个活动用圆角矩形表示，是要处理工作的一般术语。一个活动可以是原子性的也可以是非原子性的（可以是由多个活动组合而成的更大粒度的活动）。活动的类型包括：任务和子流程。子流程在图形的下方中间外加一个小加号（+）来区分。

条件－－－条件用熟悉的菱形表示，用于控制序列流的分支与合并。另外，它还可以作为传统的选择，还包括路径的分支与合并。其内部的标记会给出控制流的类型。

连接对象：

连接对象将流对象连接起来形成一个业务流程的基本结构。提供此功能的三个连接对象是：

顺序流---顺序流用一个带实心箭头的实心线表示，用于指定活动执行的顺序。注意“控制流”这个术语一般不用于BPMN

消息流－－－消息流用一条带有开箭头的虚线表示，用于描述两个独立的业务参与者（业务实体或业务角色）之间发送和接受的消息流动。在BPMN中，用两个独立的池代表两个参与者。

关联－－－用一根带有线箭头的点线表示关联，用于将相关的数据、文本和其他人工信息与流对象联系起来。关联用于展示活动的输入和输出。

泳道：

许多建模技术利用泳道这个概念将活动划分到不同的可视化类别中来描述由不同的参与者的责任与职责。BPMN支持2种主要的泳道构件。

池－－－池描述流程中的一个参与者。可以看做是将一系列活动区别于其他池的一个图形容器，一般用于B2B的上下文中。

道－－－道就是在池里面再细分，可以是垂直的也可以是水平的。道也是用于组织和分类活动。

人工信息：

人工信息添加到建模的业务流程上下文中作为信息备注，便于人员理解，当前BPMN规范的版本预定义了3种人工信息：

数据对象－－－数据对象是一个显示活动是如何需要或产生数据的。它们通过关联与活动连接起来。

组－－－组用一个虚线的圆角矩形表示，用于记录或分析的目的，但不影响顺序流。

注释－－－注释是建模者为BPMN图的读者提供附加文本信息的一个机制。

3、BPMN建模的价值

BPMN的开发是减少众多已存在的业务建模工具和标记断层的重要的一步。BPMI标准化组织从许多存在的标记中展示出了专业和经验，且从这些不同的标记中找到了最好的理念形成一套标准的标记语言，众多的标记语言包括UML、Activity Diagram、UML EDOC Business Process、IDEF、ebXML BPSS、RosettaNet以及Event-Process Chains等等。一个好的标准建模标记将会减少业务与IT用户之间的混乱。

另一个驱使BPMN的开发原动力是，历史上由业务人员做出来的业务流程建模从需要系统设计与执行的流程描述中隔离出来，所以有必要将原有的业务流程模型转换为执行模型，而这个转换对于流程拥有者来说容易出错，且很艰难。

为了减少建模技术的断层，开发BPMN的重要目标就是要创建面向业务流程建模标记到面向IT执行语言的一座桥梁。

　ProcessOn在线流程设计器

ProcessOn流程图设计器支持BPMN2.0的三种标准类型建模 - Process, Collaboration和Choreography. 用户在画BPMN2.0流程图的同时，还可以设置与特定图形相关的业务属性，ProcessOn内置了BPMN2.0展示层所要求的所有标准业务属性。

BPMN 2.0 Modeler for Visio description

BPMN的2.0建模for Visio是微软Visio附件设计绘制和建模业务流程。这是一个全面的用户友好的软件包。2.0建模的BPMN为Visio支持的BPMN 2.0元素提出一套完整的（流对象，连接对象，泳道，文物和数据）。

目前最新版本为支持Visio 2010的2.1版。

互联网软件开发过程包括哪几个阶段？

Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

IEEE：软件工程是开发、运行、维护和修复软件的系统方法。

Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

软件工程学的内容

软件工程学的主要内容是软件开发技术和软件工程管理．

软件开发技术包含软件工程方法学、软件工具和软件开发环境；软件工程管理学包含软件工程经济学和软件管理学。

软件工程基本原理

著名软件工程专家B.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，于1983年在一篇论文中提出了软件工程的七条基本原理。

（1）用分阶段的生存周期计划进行严格的管理。

（2）坚持进行阶段评审。

（3）实行严格的产品控制。

（4）采用现代程序设计技术。

（5）软件工程结果应能清楚地审查。

（6）开发小组的人员应该少而精。

（7）承认不断改进软件工程实践的必要性。

B.Boehm指出，遵循前六条基本原理，能够实现软件的工程化生产；按照第七条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。

软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。

(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。

(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。

(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

软件工程必须遵循什么原则

围绕工程设计、工程支持以及工程管理已提出了以下四条基本原则：

(1)选取适宜的开发模型

该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其它因素间是相互制约和影响的，经常需要权衡。因此，必需认识需求定义的易变性，采用适当的开发模型，保证软件产品满足用户的要求。

(2)采用合适的设计方法

在软件设计中，通常需要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

(3)提供高质量的工程支撑

工欲善其事，必先利其器。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

(4)重视软件工程的管理

软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品以及提高软件组织的生产能力等问题。因此，仅当软件过程予以有效管理时，才能实现有效的软件工程。

软件工程是指导计算机软件开发和维护的工程学科。

采用工程的概念、原理、 技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够 得到的最好的技术方法结合起来，这就是软件工程。

软件工程强调使用生存周期方法学和各种结构分析及结构设计技术。它们是在七十年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略。软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。采用软件工程方法论开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果检查通不过，则必须进行必要的返工，并且返工后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出“最新式的”（即和所开发的软件完全一致的）高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置交付使用。文档是通信的工具，它们清楚准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生存周期的下一阶段之前，必须补足这些遗漏的细节。在完成生存周期每个阶段的任务时，应该采用适合该阶段任务特点的系统化的技术方法——结构分析或结构设计技术。

把软件生存周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；在软件生存周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性。总之，采用软件工程方法论可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。

目前划分软件生存周期阶段的方法有许多种，软件规模、种类、开发方式、开发环境以及开发时使用的方法论都影响软件生存周期阶段的划分。在划分软件生存周期的阶段时应该遵循的一条基本原则就是使各阶段的任务彼此间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发工程的组织管理。一般说来，软件生存周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进一步划分成若干个阶段。下面的论述主要针对应用软件，对系统软件也基本适用。

软件定义时期的任务是确定软件开发工程必须完成的总目标；确定工程的可行性，导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分成三个阶段，即问题定义、可行性研究和需求分析。

开发时期具体设计和实现在前一个时期定义的软件，它通常由下述四个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。

维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。

下面扼要介绍软件生存周期每个阶段的基本任务和结束标准。

1问题定义

问题定义阶段必须回答的关键问题：“要解决的问题是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。

通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不精的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。

问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的时间。

2可行性研究

这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。

可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。

在问题定义阶段提出的对工程目标和规模的报告通常比较含糊。可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基础上更准确、更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本／效益分析是这个阶段的主要任务之一。

可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入要多的人力物力。及时中止不值得投资的工程项目，可以避免更大的浪费。

3需求分析

这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。

用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。

在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。系统分析员通常都是计算机软件专家，技术专家一般都喜欢很快着手进行具体设计，然而，一旦分析员开始谈论程序设计的细节，就会脱离用户，使他们不能继续提出他们的要求和建议。较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结束标准，需求分析阶段必须提供完整准确的系统逻辑模型，经过用户确认之后才能进入下一个阶段，这就可以有效地防止和克服急于着手进行具体设计的倾向。

4总体设计

这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”

首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是人机交互方式；信息存储使用传统的文件系统还是数据库……。通常至少应该考虑下述几类可能的方案：

低成本的解决方案。系统只能完成最必要的工作，不能多做一点额处的工作。

中等成本的解决方案。这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。

高成本的“十全十美”的系统。这样的系统具有用户可能希望有的所有功能和特点。

系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上,推荐一个较好的系统 (最佳方案),并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。

上面的工作确定了解决问题的策略以及目标系统需要哪些程序，但是，怎样设计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的关系。通常用层次图或结构图描绘软件的结构。

5详细设计

总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢？”

这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。

通常用HIPO图（层次图加输入／处理／输出图）或PDL语言（过程设计语言）描述详细设计的结果。

6编码和单元测试

这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。

程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把说细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

7综合测试

这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。

最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。

必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。

为了使用户能够积极参加验收测试，并且在系统投入生产性运行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。

通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求也可以决定测试和调试过程什么时候可以结束。

应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，做为软件配置的一个组成成分。

8软件维护

维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。

通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。

虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

软件开发过程中的常见问题有哪些？

1.前言应用软件系统是事件驱动的软件系统，系统通过接口接受事件后，交由系统业务层处理，业务层处理完事件后将需要的信息存入数据库，整个应用软件系统分为三个子系统：接口子系统，业务子系统，数据库子系统，业务子系统进一步分为三个子系统：表示层，业务层，数据接入层。其中业务层是整个系统的核心，表示层负责通过接口子系统接收系统事件交给业务层处理，数据接入层供业务层使用完成数据的持久化。每个层对编程人员的技术要求是不同的，表示层需要了解的技术根据接口子系统选择的不同而不同：如windows界面，需要对MFC有比较深入的了解，web界面则要求对asp，asp.net，或jsp有比较深入的了解。数据访问层需要的技术则由数据库子系统的选择决定，另外还需要了解：ODBC，JDBC等。接口子系统的选择：windows界面，java界面，web界面，命令行接口，CTI， API等 数据库子系统的选择：关系数据库，普通文件等基于以上对应用软件系统的理解，软件开发流程的输入是用户的业务需求，输出就是系统的业务层、表示层、数据接入层的代码，以及接口和数据库,以及各种文档。因此得到比较理想化的软件开发流程图，该图使用uml中的活动图描述。2.需求分析阶段需求分析阶段的常见问题是：需求分析不够深入，对问题域没有仔细研究，急于进入设计阶段。造成这种问题一方面是因为项目管目赶进度以及存在于管理人员头脑中的根深蒂固的想法：任何时候不能让任何人员闲着，另外很大的原因是很多人不知道如何进一步深入研究问题域。需求分析阶段不仅要列出系统的use case，更重要的是要列出use case的输入输出和例外情况等，以及问题域中的对象之间的静态关系和动态关系，如对象间的包含关系，继承关系，调用关系等。需求分析阶段另外一个常见的问题是常常将需求分析等同于数据库设计，需求分析阶段定义的是系统作什么，而不是怎么做，需求分析的结果应该与具体的技术实现无关。数据库设计是技术实现的细节，应该尽可能的推迟技术细节的决策，不应该使技术细节束缚了我们对系统需求的理解。需求分析阶段应该从用户的角度对系统建模，不应将大量的技术细节暴露给用户，导致系统易用性差。需求分析阶段可以进一步细分为业务需求分析阶段和系统功能需求分析阶段。在很多研发性质的系统中，不注重业务需求分析，只有系统功能需求分析，导致开发人员知其然不知其所以然。系统功能规范文档与业务需求文档的重要区别有以下几点：内容不同：系统需求分为功能需求和非功能需求，功能需求进一步分为业务功能需求和非业务功能需求。系统需求规范文档除了包括业务需求文档中的业务功能需求，功能规范文档需要增加以下内容：系统的非业务功能需求，由于业务需求由计算机系统实现而产生的功能需求，如系统需要系统管理员管理，系统管理员的角度产生一些非业务功能需求，另外需要描述系统非功能需求：数据量，性能要求，响应速度，可用性要求，可靠性要求，界面语言要求等等。 阅读的对象不同：业务需求文档是用来与业务人员交流，功能规范文档是开发人员开发的依据 使用的语言不同：业务需求文档使用自然语言书写，而功能规范文档使用比较严谨的语言，如：uml书写 对编写人的要求不一样：业务需求编写人员只需要对业务系统熟悉，系统规范由系统架构师完成 体现系统架构师价值的地方是编写系统规范文档和业务层设计, 系统规范文档是下一步界面设计，业务层设计和数据库设计的依据，表示层，业务层，数据访问层之间是相互联系的，它们之间的关系应该在系统规范文档中找到。3.架构设计阶段架构设计阶段的常见问题是将架构设计理解为技术架构设计，实际上架构设计分为技术架构设计和业务架构设计。技术架构一般由系统软件商提供，可以在不同的应用软件系统中使用，例如：微软的MFC， SUN的J2EE等。对于一个应用软件系统，更重要的是业务架构的设计，也就是将需求分析阶段中得到的各种关系，根据系统的非功能需求将需求分析转变为代码。其实没有业务架构的设计也是可以的，很多项目中直接将对象之间的各种关系以数据库的方式实现，这样的系统不是面向对象的，因此面向对象设计的很多好处不能体现。由于在架构设计阶段中没有进一步细分，通常会导致不能准确估计任务量，造成项目计划变成摆设。4.详细设计阶段详细设计阶段一个重要的任务是系统持久化设计。对应用系统而言，持久化设计只是管理存储的机制，有多种技术手段可以选择：可以是面向对象数据库管理系统，简单的文件，或者是关系数据库，也可以是使用ORM工具等。总之应该把它留到最后作为细节处理。我们不应该将我们的系统和任何特定的技术绑定在一起。我们可以根据需求自由选择需要的持久化技术，并且保留在将来需要时更改持久化技术的自由。5.编码阶段编码阶段还处于小农经济，自给自足，没有分工合作。编码阶段以use case为粒度安排工作，这样的安排方式要求每一个开发人员必须对表示层，业务层，数据接入层的所有技术都要有比较深入的了解，由于每个开发人员各自只对自己的use case负责，对别人的use case不了解，但是每一个use case会有功能重复的地方，导致大量的重复工作。编码阶段工作安排的粒度应该是类，编码阶段工作的安排原则是先分层，再分割，按照表示层，业务层，数据访问层分开后，每一层内可以进一步分为不同类，使用测试驱动的编程方法，每个编程人员单独编写代码，并进行单元测试。每个层次的编程人员只需要对某一种技术有比较深入的了解。6.测试阶段很多人分不清什么是单元测试，什么是集成测试，什么是系统测试？测试的顺序是先单元测试，然后是集成测试，最后是系统测试。单元测试是源代码级的测试，一般由编程人员自己使用各种unit工具测试，是白盒测试。集成测试是在单元测试结束后，将一个或若干个单元作为一个子系统的黑盒测试，测试子系统内的所有组件可以正确的交互，集成测试通过对子系统不断增加新的单元最后完成整个系统的测试，集成测试不应由开发人员完成。7.结束软件开发过程中，各种辅助工具以及process很重要，但是使用工具和process的最终目的是为了更高效的在开发人员之间沟通交流，记录存在开发人员脑子里的想法，不要为了process而process。不能以为会使用MS word，就认为可以成为作家。最后引用Robert Martin的《敏捷软件开发：原则、模式与实践》中的一句话作为本文的结束：过渡信赖工具和过程以及低估智力和经验都是软件开发灾难的源泉。 注： 本文摘自网络 台州极速网络有限公司愿以雄厚的技术实力基础

软件开发管理流程图的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件开发管理过程、软件开发管理流程图的信息别忘了在本站进行查找喔。