软件开发流程-论文

毕业设计（论文）题目：软件开发流程管理

班级：11工升

学号：1000303071

姓名：

指导教师：

2014年11月

从软件开发最初至今，不断地有新的软件开发技术产生，但是在软件开发能力和质量方面却始终存在达不到预计目标这一问题。每一个软件开发的最大目标，就是最大限度提高质量与生产率。而影响质量与生产率的三个关键因素：过程、人和技术，因此，我们除了提高技术能力，培养更多优质人才之外，还需要制定一套软件开发过程管理标准，并在软件开发过程中对这一标准不断地完善，以达到提高软件质量与生产率的目标。

本文结合CMM（软件过程成熟度模型），对软件开发、维护全过程进行标准化、规范化管理，制定出软件开发管理标准。

关键词：软件开发过程，管理标准

第一章软件开发的概念及目的 (4)

第二章软件开发流程划分及开发环境 (4)

2.1.软件开发阶段划分 (4)

2.2.软件开发环境需求........................... 错误！未定义书签。第三章软件开发过程中存在的问题 .................... 错误！未定义书签。

3.1.对用户方需求的掌握不全面................... 错误！未定义书签。

3.2.对软件的价值认识不清晰..................... 错误！未定义书签。

3.3.跟用户方的合作不顺利....................... 错误！未定义书签。

3.4.开发队伍的结构不合理....................... 错误！未定义书签。

3.5.软件开发管理制度不健全..................... 错误！未定义书签。

3.6.开发团队人员不稳定......................... 错误！未定义书签。第四章软件开发流程管理规范 . (10)

4.1.什么是CMM (10)

4.2.结合CMM制定开发流程管理方案 (11)

4.2.1软件项目生命周期模型................... 错误！未定义书签。

4.2.2需求分析流程图及描述................... 错误！未定义书签。

4.2.3设计流程图及描述....................... 错误！未定义书签。

4.2.4编码流程图及描述....................... 错误！未定义书签。

4.2.5测试流程图及描述....................... 错误！未定义书签。

4.2.6验收流程图及描述 (22)

第四章软件开发行业前景 (23)

参考文献........................................... 错误！未定义书签。

第一章软件开发的概念及目的

软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。软件一般是用某种程序设计语言来实现的。通常采用软件开发工具可以进行开发。软件分为系统软件和应用软件，并不只是包括可以在计算机上运行的程序，与这些程序相关的文件一般也被认为是软件的一部分。软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。

为什么我们会使用软件开发？这样做的目的是为了什么，其中的一个主要原因是向客户提供价值不断增长的软件需求。基本的根本在于用户需求或市场营销目标必须创建或转换成好的软件应用。所以从本质上讲,软件开发是它允许最终用户执行他想做的任务。

一个繁荣必然导致其他环节的上升。因此，许多公司都在提供软件开发项目。随着新开发过程中对世界的探索,软件开发将会无限增长。这是当今世界多少软件开发手段。企业网站建设的应用程序必须提供包括一系列非常复杂的机器不同的目的包括很多行业类型和几乎任何你能想到的。

第二章软件开发流程划分及开发环境

2.1软件开发阶段划分

软件开发一般分为六个阶段：

1.问题的定义及规划

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

2.需求分析

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

3.软件设计

软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据，也可以是可组合、可分解和可更换的功能单元。模块，然后进行模块设计。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构，次要任务就是设计数据库，常用方法还是结构化程序设计方法。

4.程序编码

软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的“源程序清单”。充分了解软件开发语言、工具的特性和编程风格，有助于开发工具的选择以及保证软件产品的开发质量。

当前软件开发中除在专用场合，已经很少使用二十世纪80年代的高级语言了，取而代之的是面向对象的开发语言。而且面向对象的开发语言和开发环境大都合为一体，大大提高了开发的速度。

5.软件测试

软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例（测试数据与功能和预期的输出结果组成了测试用例）。如何才能

设计出一套出色的测试用例，关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序，依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述，发现软件的接口、功能和结构错误。

其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。

6.软件维护

维护是指在已完成对软件的研制（分析、设计、编码和测试）工作并交付使用以后，对软件产品所进行的一些软件工程的活动。即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现的错误。编写软件问题报告、软件修改报告。

一个中等规模的软件，如果研制阶段需要一年至二年的时间，在它投入使用以后，其运行或工作时间可能持续五年至十年。那么它的维护阶段也是运行的这五年至十年期间。在这段时间，人们几乎需要着手解决研制阶段所遇到的各种问题，同时还要解决某些维护工作本身特有的问题。做好软件维护工作，不仅能排除障碍，使软件能正常工作，而且还可以使它扩展功能，提高性能，为用户带来明显的经济效益。然而遗憾的是，对软件维护工作的重视往往远不如对软件研制工作的重视。而事实上，和软件研制工作相比，软件维护的工作量和成本都要大得多。

在实际开发过程中，软件开发并不是从第一步进行到最后一步，而是在任何阶段，在进入下一阶段前一般都有一步或几步的回溯。在测试过程中的问题可能要求修改设计，用户可能会提出一些需要来修改需求说明书等。

2.2软件开发环境需求

开发平台

软件开发平台源于繁琐的实践开发过程中。开发人员在实践中将常用的函数、类、抽象、接口等进行总结、封装，成为了可以重复使用的“中间件”，而随着“中间件”的成熟和通用，功能更强大、更能满足企业级客户需求的——软件开发平台应运而生。

平台是一段时间内科研成果的汇聚，也是阶段性平台期的标志，为行业进入新的研发领域提供了基础。由于平台对企业核心竞争力的提升非常明显，目前国内的管理软件市场，软

件开发平台的应用已经成为一种趋势。

由于开发环境、开发人员、功能定位、行业背景等的不同，不同品牌的平台存在较大差别。

开发环境

软件开发环境在欧洲又叫集成式项目支持环境（Integrated Project Support Environment，IPSE）。软件开发环境的主要组成成分是软件工具。人机界面是软件开发环境与用户之间的一个统一的交互式对话系统，它是软件开发环境的重要质量标志。存储各种软件工具加工所产生的软件产品或半成品（如源代码、测试数据和各种文档资料等）的软件环境数据库是软件开发环境的核心。工具间的联系和相互理解都是通过存储在信息库中的共享数据得以实现的。

软件开发环境数据库是面向软件工作者的知识型信息数据库，其数据对象是多元化、带有智能性质的。软件开发数据库用来支撑各种软件工具，尤其是自动设计工具、编译程序等的主动或被动的工作。

较初级的SDE数据库一般包含通用子程序库、可重组的程序加工信息库、模块描述与接口信息库、软件测试与纠错依据信息库等；较完整的SDE数据库还应包括可行性与需求信息档案、阶段设计详细档案、测试驱动数据库、软件维护档案等。更进一步的要求是面向软件规划到实现、维护全过程的自动进行，这要求SDE数据库系统是具有智能的，其中比较基本的智能结果是软件编码的自动实现和优化、软件工程项目的多方面不同角度的自我分析与总结。这种智能结果还应主动地被重新改造、学习，以丰富SDE数据库的知识、信息和软件积累。这时候，软件开发环境在软件工程人员的恰当的外部控制或帮助下逐步向高度智能与自动化迈进。

软件实现的根据是计算机语言。时至今日，计算机语言发展为算法语言、数据库语言、智能模拟语言等多种门类，在几十种重要的算法语言中，C&C++语言日益成为广大计算机软件工作人员的亲密伙伴，这不仅因为它功能强大、构造灵活，更在于它提供了高度结构化的语法、简单而统一的软件构造方式，使得以它为主构造的SDE数据库的基础成分——子程序库的设计与建设显得异常的方便。

事实上，以C#&C++为背景建立的SDE子程序库能为软件工作者提供比较有效、灵活、方便、友好的自动编码基础，尤其是C++的封装等特性，更适合大项目的开发管理和维护。

第三章软件开发过程中存在的问题

当今社会的软件工程理论和数据库设计理论为我们提供了各种各样系统开发的方法，在开发实践过程中也有很多成功的案例，但在实际开发过程中失败的个例也是屡见不鲜的。普遍情况是这样：投入大量人力、物力、财力，开发出来的系统不符合用户的需求，需要大量的返工修改，甚至重新开发。开发工作进度难以控制，周期一拖再拖，用户发怨声载道，认为开发方没有尽心尽力，开发方也是满腹牢骚，认为用户方不配合工作，甚至有些已经验收的项目在投入实际使用的过程中被弃用了，这样就造成了很大的浪费。那么在软件开发过程中，究竟产生哪些方面的问题呢？下面我们就来探讨。

3.1对用户方需求的掌握不全面

目前国内的软件开发企业的规模都不大，开发团队需要承担的工作量多且繁重，企业在接了项目之后，马上组织团队开发，在尽可能短的时间内完成项目任务，将资金收回。这种短、平、快，急功近利的运作方式，导致我们在对用户的业务需求认识还不够充分之前，就开始编程，加上很多用户对需要提供也不重视不专业，导致软件开发过程中频繁的调整，调试运行和维护期间的工作多是“打补丁”。

3.2对软件的价值认识不清晰

由于目前国内的IT产业还处于起步阶段，软件价值及其在计算机技术应用中的核心作用还未被认识，目前国内保护知识产权的意识不强，相关法律也不很健全，软件业盗版猖獗，使得广大用户不愿意购买价格相对高的正版软件，更不愿意投入较大的财力开发应用软件，导致软件项目投入过低或在计算机相关的工程中软硬件投入比列失调，自然无法保护软件的开发质量。

3.3跟用户方的合作不顺利

用户方在软件开发过程中一般会指定人员来配合开发方的工作。

对一些有计算机专业人员的用户单位，在计算机行业飞速发展的形势下，他们的知识结构与目前的信息技术发展已有了一定的距离，所提出的对软件的要求或者太空泛，或者过于计较某些细节。

还有，一些用户单位在出资购置软件后，软件开发过程中根本不给予开发方有力的配合，

甚至还认为开发工作室开发方一家的事情，他们只管用，不参与开发工作，他们对于购买软件的观念还是“我出钱买你的东西，买来就得好用”。

3.4开发队伍的结构不合理

目前，大多数的软件开发单位，缺少优秀的系统分析员和项目管理人员，缺少由项目管理员、系统分析员、程序员等组成的良好的开发队伍结构，往往有项目了就临时组织一个软件开发小组，小组成员没有工作层次上的分工，更没有管理和具体技术工作的分工。全体人员从事基本相同的工作，每人分工负责一块，然后从用户需求、系统设计、具体编程到测试，文档编写统统一做到底，各干各的，项目小组的负责人也往往是程序员出身，没有受过项目管理的专业培训，更没有项目管理的经验，当然也不能真正较完满地起到项目的管理、协调作用。

大多数的系统分析员也多是程序员出身，虽然有参加过或大或小项目的经验，可实际上他们是一边学习最新的计算机技术的理论，一边结合自己的编程和做项目的经验来做分析做设计。在没有系统的符合实际的理论知识指导的情况下，我们的很多项目都面临着管理上的问题，至少不能取得高效率的投入产出。

3.5软件开发管理制度不健全

主要表现在项目开发计划制定不明确，项目开发小组成员职责不明确。开发方与用户方的分工协作的工作没有很好的界定。开发过程中每个环节的管理不到位，没有制定相应的管理规范和操作程序的工作，基本上还是手工作坊式的个体行为。

现今软件开发，特别是大型软件的开发是高度集中的集体行为，要有团队精神，一个单打独斗的个人英雄时代已经过去，但是，很多开发人员在软件开发中，既不做整体设计规划，也不写文档，只会写程序，没有规范性的整体开发思路，这样开发出的软件程序往往与个人捆绑，既没有通用思路，也很难协同开发整个产品，更不用说是大型软件。有时候一个人的离去，可能影响整个软件产品的开发，甚至导致产品的早期流产。

软件作为成熟的产品，一般要经历前期调研、总体设计、编程开发三个过程，前期调研和设计完成以后，最后的开发也就是写程序，而当调研和设计较为全面和成熟后，写程序则是一个并不是很复杂的问题。

3.6开发团队人员不稳定

由于目前社会对IT技术人才需求缺口较大，各类企业纷纷高薪招聘有一定实践经验的IT技术人才，加之企业与国外公司较大的收入差距，致使很多企业参加过大型计算机应用系统建设的计算机技术人员大量跳槽流失，这种流失造成了很多国内企业成为事实上的人才培训基地，无法形成持续强有力的开发力量。因骨干开发人员流失致使软件项目开发、维护受到影响的事例也时有发生。

第四章软件开发流程管理规范

软件开发团队应具有使软件开发过程实现标准化的能力。如果开发团队不能使得软件开发过程实现标准化，则该团队是不能承担软件开发任务的。美国卡耐基梅隆大学软件工程研究所创立了软件能力成熟度模型（CMM）对软件开发、维护全过程进行标准化、规范化管理。

4.1什么是CMM

能力成熟度模型（Capability Maturity Model，英文缩写为CMM）[1] 是一种开发模型。Carnegie Mellon大学的研究人员从美国国防部合同承包方那里收集数据并加以研究，提出了CMM。美国国防部资助了这项研究。Carnegie Mellon以该模型为基础，创办了软件工程研究所（SEI）。CMM的目标是改善现有软件开发过程，也可用于其它过程。

CMM是一种用于评价软件承包能力以改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。其假设是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。

4.2.结合CMM制定开发流程管理方案4.2.1软件项目生命周期模型

4.2.2需求分析流程图及描述

过程描述：

1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规

模确定。

2、PM制定需求阶段日程表，该表须通过研发经理审核。

3、PM指示配置管理员建立配置库。

4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项

目裁剪表。

5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。

6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管

理、问题管理、QA、CM等。

7、项目组人员与客户进行沟通，编写需求清单列表。

8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程

中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。

对技术方案选择（例如，系统结构、开发平台、数据库等的选择），要事先建立评价准则（例如，满足系统需求的能力（例如，功能、性能、可靠性等）、技术的发展前景、供应商资质与实力等）及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。

关于自行开发和采购复用的分析。

如果公司有基本满足系统需要的可复用组建（包括其分析、设计、代码、测试用例等），一般应进行复用；

本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购；

否则，由项目组自行开发。

架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。

9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。

10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认要求规格书为止。

11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。

12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。

13、PM、测试负责人与临时项目组确定项目关键参数。

工作量、工期、日程、人数

成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管

理等同于计划工作量的管理）

质量目标

14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。

15、项目组基于公司环境标准，结合项目实际情况建立合适的工作环境。

16、PM、测试负责人编制项目计划书。

17、PM、测试负责人编制项目日程表。

18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。

19、PM指示配置管理员建立配置基线。

20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。

4.2.3设计流程图及描述

过程描述：

1）项目经理组织项目组人员学习需求规格书；

2）项目经理组织项目组中的开发人员确定设计约束，这些约束可能包括以下几个方面： 需求约束，需求规格书中约定的设计约束；

隐含约束，需求规格书中没有，但对系统设计或者使用带来潜在影响的特殊约束。3）项目经理及开发人员根据需求规格书、架构设计书进行设计，编制《设计说明书》。

基于对业务和现有系统结构的理解，划分/调整系统模块。

描述各系统模块协作实现各业务场景的处理流程（可用序列图）。

必要时，修正系统模块划分和处理流程。

描述各处理流程中的各活动的输入、处理、输出和可能的异常。

系统模块构成及其相互关系。

系统模块内部设计

4）开发人员根据《需求规格书》、《架构设计书》进行设计、《设计说明书》进行用户界面和数据库以及接口等方面的详细设计，纳入《设计说明书》。

用户界面设计

数据库设计

文件设计

接口设计

5）项目经理组织开发人员、测试人员及其他骨干评审《设计说明书》。

6）配置管理员建立设计阶段配置基线

7）项目经理编制阶段报告，组织项目组人员并邀请部门经理召开阶段会议，并形成会议纪要。

4.2.4编码流程图及描述

过程描述：

a)根据准入条件中的设计文档，绘制详细类图，以指导编码。

b)对生成的类图进行审核。

c)项目经理组织开发人员学习编码规范、用户界面规范，以保障程序的可靠性、可读性、

可修改性、可维护性、一致性以及界面的规范性。

d)开发环境的配置

项目经理或其他指定人员在公司的《开发环境指南》的基础上编制开发环境配置说明，项目组成员遵照开发环境配置说明配置统一的开发环境。

e) 编写及调试

f）审评代码

g) 进行自测

h) 编写阶段报告

4.2.5测试流程图及描述

过程描述：

1.测试负责人组织测试人员学习、评审《用户需求列表》、《需求规格书》。在学习、评

审过程中充分理解客户及业务需求，确保文档信息的正确性、充分性、一致性。

2.测试负责人组织测试人员完成编写整个项目的测试方案。

3.测试负责人组织测试人员基于《需求规格书》编写测试用例。《设计说明书》通过评审

后，测试人员基于《设计说明书》对测试用例进行必要的调试。测试用例的组织分类须遵循以下原则：

测试用例的组织分类（例如，文档名、页面名、一级标题、二级标题等）必须与需求规格书中的各需求点明确对应起来。

4.测试负责人组织测试人员、开发人员、PM评审测试方案、测试用例。

5.测试负责人指示配置管理员将测试方案及测试用例文档入库。

6.测试负责人组织PM、开发人员、测试人员召开阶段会议形成阶段报告。