听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。

需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。

听棠所说到的几点，感受特别深：

“其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析”

还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。

项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。

客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。

需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。

谨记一点，需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。

软件开发的一般流程是什么?_?

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

1.问题的定义及规划

此阶段是软件开发与需求放共同讨论，主要确定软件的开发目标及其可行性。

2.需求分析

在确定软件开发可行性的情况下，对软件需要实现的各个功能进行详细需求分析。需求分析阶段是一个很重要的阶段，这一阶段做的好，将为整个软件项目的开发打下良好的基础。“唯一不变的是变化本身”，同样软件需求也是在软件爱你开发过程中不断变化和深入的，因此，我们必须定制需求变更计划来应付这种变化，以保护整个项目的正常进行。

3.软件设计

此阶段中偶要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计、数据库设计等。软件设计一般分为总体设计和详细设计。还的软件设计将为软件程序编写打下良好的基础。

4.程序编码

此阶段是将软件设计的结果转化为计算机可运行的程序代码。在程序编码中必定要制定统一、符合标准的编写规范。以保证程序的可读性、易维护性。提高程序的运行效率。

5.软件测试

在软件设计完成之后要进行严密的测试，一发现软件在整个软件设计过程中存在的问题并加以纠正。整个测试阶段分为单元测试、组装测试、系统测试三个阶段进行。测试方法主要有白盒测试和黑盒测试。

以上就是软件开发过程的五个阶段，但是有的时候在软件爱你开发过程中并不是必须按照这个过程进行的。

*^_^* 求采纳

(#Д)

开发一个app的成本到底是多少

首先，一个App开发的基本要求，至少需要ios和android两个平台，来满足现在主要的手机平台使用用户，ios和android平台其中任意一个的开发价格大致为5-10万不等。

其次，app开发，必须要选择一个好的开发团队，从人员配备来看，好的app开发团队需要项目经理一名、ui设计师一名、ios开发工程师和android开发工程师各一名，后台开发工程师、测试工程师各一名。这些人员的人力成本每月至少是5万，对于一些简单的app开发、从设计到开发到测试，大致是需要1-2个月，对于复杂一些的app开发，一般是需要3个月左右的。

如此，一个简单的APP开发需要8-10万，比较复杂的app开发需要10-15万。当然也不一定就是这个价格，最主要的价格还是要根据你app产品的难易程度来决定，越简单越便宜，越复杂价格肯定就是越高的了。

app推广平台接单渠道

如何加强软件需求管理，提高软件质量

一、什么是质量？ 作为软件产品的销售人员，市场人员或维护人员经常会受到客户这样那样的指责或抱怨，客户说：你们产品的质量太差，不稳定等等。那么什么是质量呢？我们该如何来衡量质量呢？ 质量具有三个维度： ?? 符合目标。目标是客户所定义的，符合目标即判断我们是不是在做需要做的事情。 ?? 符合需求。即产品是不是在做让它做的事情。 ?? 符合实际需求。实际的需求包括用户明确说明的和隐含的需求。 ISO 关于质量的定义表示如下： “ 一个实体（产品或服务）的所有特性，基于这些特性可以满足明显的或隐含的需要。 ” 注意，在这个定义中包含明显的需求和隐含的需求。而往往我们会忽略隐含的需求。因此在控制一个产品的质量的过程中必须关注这些隐含的需求，并给予应有的验证。 另一方面因为我们的产品是为客户提供服务的，因此凡是不满足客户需求的，我们都认为是一个失效（ failure ）。所以我们的产品必须始终围绕着客户的需求进行开发和验证。 这里我们谈到客户，其实在一个软件的需求收集过程中需要关注客户和用户。而我们经常会忽略客户与用户之间的区别。那么谁是客户？谁是用户呢？简单的来说，客户是真正能够决定是否购买你软件的人，而用户是实际使用软件的人。了解了这个区别，对于你在分析需求的重要性的时候就可以进行参考。同时在产品质量验证的时候也可以做出不同的权衡。另一方面我们在考虑我们用户需求的时候，往往只考虑了实际使用软件的人员，而忽略了其它一些人员对软件的要求或对软件造成的潜在竞争，这包括维护人员的要求、系统管理人员的要求、软件上下游人员的要求、先前版本的情况、市场上竞争对手的软件情况等。 每个人提到质量的时候，经常会遇到下列矛盾，在这些矛盾中隐含着对质量的承诺【 5 】： ?? 质量需要一个承诺，尤其是高层管理者的承诺。但为了得到质量，高层管理者必须和其雇用的员工进行紧密合作； ?? 许多人相信没有缺陷的产品和服务是不可能的。但是控制在一定级别的缺陷数是正常并可接受的； ?? 质量经常是和成本紧密联系在一起，一个高质量的产品同时也意味着高投入。这是设计的质量和一致性质量的一个矛盾； ?? 一个高的质量要求需求规格说明书足够详细，以便产品可以根据这些规格说明书进行定量的分析。然而许多组织没有能力或者不愿意产生如此详细程度的规格说明书； ?? 技术人员经常相信规范和标准会束缚他们的创造力，因此就不遵照标准做事。然而如果要得到高质量的产品，就必须遵循良好定义的标准和过程。 二、流程对质量的贡献 好了，既然已经了解了什么是质量，那么怎么才能改进软件产品的质量呢？从一个企业的长远发展来看，首先应当从流程抓起，规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化、规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。 软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。在工业界，流水线生产方式被证明是一种高效且能够比较稳定地保证产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提高工作效率。并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围要求。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。 无论做什么事情，都有一个循序渐进的过程，从计划到策略再到实现。软件流程就是按照这种思维来定义开发过程，它根据不同的产品特点和以往的成功经验，定义了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。由于流程来源于成功的经验，因此，按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。 目前流行的流程方法有很多种，不同的过程模型适合于不同类型的项目。瀑布模型是应用的最为广泛的一种模型，也是最容易理解和掌握的模型，然而它的缺陷也是显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从。然而，对于那些容易理解但很复杂的项目，采用瀑布模型会是比较适合的，因为你可以按部就班的去处理复杂的问题。在质量要求高于成本和进度要求的时候，该模型表现的尤其突出。 螺旋模型是也是一个经典模型，它关注于发现和降低项目的风险【 8 】。螺旋型项目从小的规模开始，然后探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一个螺旋的反复。该模型的最大优点就是随着成本的增加，风险程度随之降低。然而螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注以及有管理方面经验。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程【 9 】。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。 RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。 RUP 具有两个轴，一个是时间轴，这是动态的。另一个是工作流轴，这是静态的。在时间轴上， RUP 划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上， RUP 设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。具体可以参考图 1 。 RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。 图1 RUP 工作流程示意图 IPD （ Integrated Product Development ）流程是由 IBM 提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。 IPD 从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。在 IPD 流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点，具体可以参考图 2 。 IPD 流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目，也不是非常适合使用该流程。 图2 IPD 流程示意图 三、流程与技术 流程和成功不是等价的。没有流程就成功是不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近 30 多年的需求分析专家说过：即使是一个已经达到 CMM4 级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件。就好比现在你要从上海到北京去，流程给你指出了最短的路径，技术提供给你最快的交通工具。两者结合就是完美。 对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象，就是大家觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心，但这的确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。 需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工 —— 重做一些你认为已做好的事情。返工会耗费开发总费用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的错误所导致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。在《软件需求》一书中关于如何进行需求分析给出了比较详细的介绍【 7 】， RUP 中关于需求的指导也是很实用的。 设计是最能体现一个工程师能力和水平的环节。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。在 RUP 中关于系统构架师和设计师的定位是相当高的。关于设计方面的技能涉及面是很广的，包括传统的结构化设计到面向对象设计。设计人员需要掌握一定的建模技术。 UML 是国际上比较流行的一种建模语言【 11 】。在嵌入式方面， SDL 也是一种非常好的选择。《设计模式》是在设计思想方面总结的非常出色的一本书【 6 】，作为一名设计人员（尤其是面向对象设计人员）必须要好好研究一下。但是对这些模式的应用应当讲究一种自然的应用，千万不要因为模式而去设计模式，否则会适得其反。 现在的程序员热中于掌握多种编程语言，或者讲究语言的过分技巧化，而往往忽略了编程语言的规范化。不规范的语言应用给程序的可理解性、可维护性以及可测试性带来了大的伤害，进而损害了产品的质量。某公司曾对中国程序员和印度程序员做过一个测验，这个测验要求参加者对一组数进行排序。测试结果发现，印度程序员设计的程序使用的算法并不是最优，但却是最不容易出错的，并且几个程序员写出来的代码如出一辙。而几个中国程序员写出的代码，有的非常漂亮，很精练，效率很高；有的却很冗杂，还有错误。如果大家是在做研究性的项目或纯粹兴趣性的项目，那么充分发挥自己的编程天才也无可厚非。然而，对于一个软件公司，产品最终是要交给用户的，需要遵循的是一个软件产品的开发工程。因此这类软件的开发需要遵循一定的编程规范，毕竟开发的软件不是自己用，还需要和别人的集成，还需要给以后版本重用和维护。 测试的技术将在第五节进行阐述。总之流程很关键，技术也很重要，我的观点是：鱼和熊掌，两者都不能放。 四、全面质量管理 自从 Deming 的全面质量管理（ TQM ）原则在日本工业界获得了巨大成功之后，这个原则迅速被传播到了世界各个地方，同样，全面质量管理原则也被应用到了软件开发当中。如前面提到的，软件开发也是一个工程性的工作，因此必须提高整个工程的质量。产业界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明设计活动引入的错误占软件过程中出现所有错误（和最终的缺陷）数量的 50 ％到 65 ％。根据 IBM 的研究表明，假定在分析阶段发现的错误其改正成本为 1 个单位的话，那么在测试之前（设计编码阶段）发现一个错误的修改成本约为 6.5 个货币单位，在测试时（集成测试，系统测试和验收测试）发现一个错误的修改成本约为 15 个货币单位，而在发布之后（已经交到用户手上）发现一个错误的修改成本约为 60 到 100 个货币单位。同样该比例也适用用于发现一个错误需要的时间。我们可以看下面两条曲线图： 图3 缺陷代价曲线 为了提高产品质量，缩短产品开发进度，节约产品开发成本，必须尽早的进行产品质量控制。全面质量控制要求在过程的每个阶段每个步骤上都要进行严格的验证和确认活动。 什么是验证？ 验证 就是要用数据证明我们是不是在正确的制造产品。注意这里强调的是过程的正确行【 12 】。 什么是确认？ 确认 就是要用数据证明我们是不是制造了正确的产品。注意这里强调的是结果的正确性。 IEEE 给出的验证和确认过程可以用下图来表示。验证和确认是一个广泛的概念，感兴趣的读者可以参考 IEEE Std 1012-1998 。

图4 验证和确认模型 五、关注测试 软件测试是软件质量控制中的关键活动。业界的统计数据表明，测试的成本大约占软件开发总成本的 50 ％左右。 软件测试的目的是要发现软件中的错误。一个好的测试是发现至今没有被发现的错误。传统的软件测试专注于动态测试范畴，如：单元测试，集成测试和系统测试。而测试工程的发展已经进入到了全流程的测试，包括开发过程前期的静态测试。 一般我们可以把测试分为白盒测试和黑盒测试。 白盒测试 ：顾名思义，白盒测试应当是透明的。的确，该类测试是根据程序代码的内部逻辑结构来设计测试用例进行测试。那么什么是测试用例？ 一个 测试用例 就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。 黑盒测试 ：看了白盒测试的解释，我想你很快就能猜出黑盒测试是不考虑程序内部结构情况的。事实上也是这样。黑盒测试是根据规格说明书进行的测试。 规格说明书 记录了用户的需求。比如用户希望在编辑器中增加查找功能，那么我们把该需求写入规格说明书，根据该项要求，直接调用应用程序的该项功能进行测试，而不管其内部是用什么算法实现的。 白盒和黑盒这两类测试是从完全不同的出发点，并且是两个完全对立点，反映了事物的两个极端，两种方法各有侧重，不能替代。但是在现代测试理念中，这两种测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。 常见的白盒测试是单元测试。 单元测试 是测试中最小单位的测试。简而言之，就是拿一个函数出来，加上驱动模块，桩模块，让它能够运行起来，然后设计一些用例测试其内部的控制点（如：条件判断点，循环点，选择分支点等）。 驱动模块 是模拟调用被测函数的函数。 桩函数 是模拟当前测试函数所调用的函数。 常见的黑盒测试包括：集成测试，系统测试。 集成测试 是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。 系统测试 的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来运行。系统测试的内容极其广泛，包括功能测试、协议测试、性能测试、压力测试、容量测试等等。有关测试方面的概念可以参考本人已出版的《软件测试技术概论》。 软件测试是产品最终交付到用户之前的最后一道防线，有着举足轻重的地位。然而，做好软件测试却是不容易的，一方面你需要同时掌握软件开发的技能和软件测试方面的技能；另一方面产品必须给予测试充分的独立性和资源保证。 六、成功的铁三角 在一个软件企业中，如果能够良性的发展，必须关注组织，流程和人三者之间的关系。组织是流程成功实施的保障，好的组织结构能够有效的促进流程的实施；流程对于产品的成功有着关键的作用，一个适合于组织特点和产品特点的流程能够极大的提高产品开发的效率和产品质量，反之则会拖延产品开发进度，并且质量也无法得到保证；对企业来说，人是最宝贵的财富，它们是技术的载体。对于一个软件公司来说，无论是开发人员还是测试人员，都非常关心其今后的发展通道，如果有一条清晰的技术发展线为其指明今后的职业发展方向的话，这可以大大激励员工的士气和工作积极性。另外技术发展的方向应该与现在的开发流程和规范相结合，这样有利于专业技能的提高。 总之，组织，流程和人这三者是一个企业成功的铁三角，理想的情况下它们彼此促进，糟糕的情况下它们彼此制约。 七、国际上流行的质量标准 最早进入国内的质量标准是 ISO 系列。在软件方面主要使用 ISO9000 系列标准。 ISO9000 是一个非常完整的标准，并且定义了供应商设计和交付一个有质量产品的能力所需要的所有元素。 ISO9002 涵盖了对供应商控制设计和开发活动所认为重要的质量标准。 ISO9003 用于证明供应商在检视和测试期间检测和控制产品不一致性的能力。 ISO9004 描述和 ISO9001 、 ISO9002 和 ISO9003 相关的质量标准，并提供了一个完整的质量查检表。 软件能力成熟度模型是目前国内软件企业中非常受欢迎的一个质量标准。并且该标准已经成为业界一个事实上的标准。 CMM 为软件组织提供了一个指导性的管理框架。在这个框架的指导下： ?? 软件组织可以对其软件开发、维护过程获得控制。 ?? 软件组织可以推进其软件工程更为科学、推进软件过程管理更为卓越。 ?? CMM 通过确定当前软件过程管理的成熟度，通过标识软件的质量和过程改进中关键的、要害的问题，可以指导软件组织选择正确的软件过程改进策略。 ?? CMM 将其焦点，聚焦在一系列具体的软件过程活动上，并以侵略方式（ Aggressively ）达到这些活动。一个软件组织就可以稳定地、持续地改进其整个软件组织过程，使得其软件过程管理能力取得持续地、持久地不断争长提高。 在 CMM 中，把软件工厂分为五个等级：初始级、可重复级、已定义级、管理级和优化级。其中： 初始级 ：软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。 可重复级 ：人们根据多年的经验和教训，总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。 已定义级： 要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。 管理级 ：所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。 优化级： 的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。 美国国防部规定，重要性级别高的软件应该由质量级别高的企业承担。不同等级的软件公司提交的软件，其软件质量也相差很大，国外的一份统计资料如下： 表 1 、 CMM 级别与软件质量关系表格 每千行软件的缺陷数目

软件过程成熟度等级

软件准时提交的百分比

每人每月生产的程序行数

软件需要返工的百分比

平均软件失效时间（近似）

大于 10

初始级

<=50

Z

>=45

2 到 60 分钟

小于 10

可重复级

90

1.5Z

20

1-160 小时

小于 1

已定义级

99

2.5Z

10

不确定

小于 0.1

管理级

降低开发时间到 1/2

5 Z

5

不确定

小于 0.01

优化级

降低开发时间到 1/4

10Z

<=2

近似完全可靠

对于很多已经推行或者准备推行 CMM 的公司来说， CMM 的起步是很难的，因此 Humphrey 又提出了 PSP （ Person Software Process ）和 TSP （ Team Software Process ）【 2 】【 3 】。 CMM 是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式【 1 】。企业只有开始 CMM 改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训，合理分配项目人员，并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。 PSP 能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过 PSP 学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用 PSP ，从而有助于 CMM 目标的实现。 TSP 结合了 CMM 的管理方法和 PSP 的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项目的管理，向组织展示如何应用 CMM 的原则和 PSP 的技能去生产高质量的产品。 软件的生产过程及其它的许多子过程、软件的开发者和用户、以及系统的使用中存在着巨大的变化和不同，要使一个软件过程对软件生产的改善真正有所帮助，其框架应是由 CMM 、 TSP 和 PSP 组成的一个完整体系，即从组织、群组和个人三个层次进行良好的软件工程和管理实践的指导和支持。总而言之，单纯实施 CMM ，永远不能真正做到能力成熟度的升级，只有将实施 CMM 与实施 PSP 和 TSP 有机地结合起来，才能发挥最大的效力。 八、如何起步？ 质量改进需要花费成本，因此改进的途径需要视不同公司的规模、业务、财务状况、人员技术水平等多方面综合进行考虑。一般建议中型以上的较大的软件公司实施 CMM 体系。而对于一些小型的软件公司可以采取比较实际的，相对成本较少，且容易操作的方面进行，这些方面大致如下： ?? 实施简洁的开发过程体系，根据不同业务特点可以选择瀑布模型，迭代模型等，并在这些模型上进行适当的变化以适应于短平快的产品开发特点。 ?? 提高需求分析和设计方面的技术，例如：原型法技术，分析模式，设计模式，面向对象设计， UML 等； ?? 加强文档化工作。文档是经验的保留，对于一个企业要想获得长期的发展，必须加强文档化工作； ?? 加强编程规范工作； ?? 进行适当的测试工作，建议进行单元测试和系统测试； ?? 实施配置管理工作，加强版本控制； ?? 开展走读、评审和检视活动，尤其要加强代码走读，建议进行每日交叉走读活动； ?? 进行简单的度量分析获得；建议实施 PSP 活动；

软件工程 图书管理系统需求分析

引言

一直以来人们使用传统的人工方式管理图书馆的日常工作，对于图书馆的借书和还书过程，想必大家都已很熟悉。在计算机尚未在图书馆广泛使用之前，借书和还书过程主要依靠手工。一个最典型的手工处理还书过程就是：读者将要借的书和借阅证交给工作人员，工作人员将每本书上附带的描述书的信息的卡片和读者的借阅证放在一个小格栏里，并在借阅证和每本书贴的借阅条上填写借阅信息。这样借书过程就完成了。还书时，读者将要还的书交给工作人员，工作人员根据图书信息找到相应的书卡和借阅证，并填好相应的还书信息，这样还书过程就完成了。

以上所描述的手工过程的不足之处显而易见，首先处理借书、还书业务流程的效率很低，其次处理能力比较低，一段时间内，所能服务的读者人数是有限的。利用计算机来处理这些流程无疑会极大程度地提高效率和处理能力。我们将会看到排队等候借书、还书的队伍不再那么长，工作人员出错的概率也小了，读者可以花更多的时间在选择书和看书上。

为方便对图书馆书籍、读者资料、借还书等进行高效的管理，特编写该程序以提高图书馆的管理效率。使用该程序之后，工作人员可以查询某位读者、某种图书的借阅情况，还可以对当前图书借阅情况进行一些统计，给出统计表格，以便全面掌握图书的流通情况。

本次作业设计题目：“图书管理系统”主要目的是利用数据库软件编制一个管理软件，用以实现图书、读者以及日常工作等多项管理。同时对整个系统的分析、设计过程给出一个完整论证。

图书管理系统是一种基于集中统一规划的数据库数据管理新模式。在对图书、读者的管理，其实是对图书、读者数据的管理。本系统的建成无疑会为管理者对图书管理系统提供极大的帮助。

2 系统设计

2.1 系统指导思想和建设目标

2.1.1 系统指导思想

立足于校园实际，着眼于未来发展，建成符合标准化协议、通用性较强、实用的系统，以提高图书信息的现代化管理水平，实现信息资源的共享。

2.1.1 系统建设目标

（1）要解决的问题：（以某学校为参照） 随着办公自动化水平的不断提高，现在学校管理学生信息也逐步从手工转到计算机自动化信息处理阶段。设计一个功能完整、操作简便、界面友好的学生信息管理系统已经是势在必行的了。

（2）系统开发的目的：提高图书管理工作的效率，减少相关人员的工作量，使学校的图书管理工作真正做到科学、合理的规划，系统、高效的实施。

（3）系统名称：图书管理系统

2.2 总体功能设计

系统要能实现如下功能：

l 登录系统：注销用户、系统退出。

l 管理：用户管理、图书管理、读者管理、借阅管理。

l 查询：图书查询、读者查询、借阅查询。

l 报表打印：所有图书、借出图书、库存图书、所有读者。

l 帮助：使用说明、关于。

3 数据库设计

3.1 数据库系统的选择

本系统是一个中小型管理系统，运行环境是Windows2000 server，因此使用Windows环境下最容易使用且功能还可以的Microsoft Access 2000 作为后台的数据库系统。

3.2 需求分析

图3 图书流通数据流图

1．2

判断能

否借书

索书

信息

读 者

1．2

办理借

书手续

读者信息

查询结果

借书申请

被借图书

借书结果

借书信息

被借图书复本量

(b) 借书

借阅

3

读者

1

图书

5

1．1

图书

查询

借书信息

查询

4

判断

2

判断结果

索书

信息

图书信息

读 者

1

借书

2

还书

读 者

申请借书

还书申请

借书结果

还书结果

(a) 顶层数据流图

3

办借

书证

读者信息

办证信息

需求分析是数据库设计首先要做的工作，通过需求分析，我们作出了图书管理系统的各层数据流图，图3是图书流通数据流图（图中省略了“还书”和“办理借书证”的数据流图）。

在数据流图的基础上，定义数据字典。数据字典是关于数据库中数据的描述，它的作用是在软件分析和设计过程中为有关人员提供关于数据描述信息的查询，以保证数据的一致性。下面在图3的基础上举例说明数据字典的定义。

图3中涉及很多数据项，其中数据项“读者编号”可以描述如下：

数据项名：读者编号

别名：读者条码

含义：唯一标识每个读者

类型：字符型

取值范围：00000000至99999999

取值含义：顺序编号

“读者”一个数据结构，它可以描述如下：

数据结构名：读者

含义说明：是图书管理系统的数据结构之一，定义了一个读者的有关信息

组成：读者编号，姓名，性别，单位

数据流“借阅记录”可描述如下：

数据流名：借阅记录

说明：读者的借书记录

数据来源：办理借阅手续

数据去向：借阅

数据结构：读者编号、图书馆藏号、借阅日期

数据存储“借阅”可以描述如下：

数据存储名：借阅

说明：记录读者的借书情况

流出数据流：借阅记录

流入数据流：借阅记录

数据描述：读者编号、图书馆藏号、借阅日期

数据量：每年5000条以上

存取方式：随机存取

处理过程“判断能否借书”可描述如下：

处理过程“判断能否借书”

说明：根据读者的已借书情况可被借图书的馆藏情况判断读者能否借书

输入：借阅记录、读者信息、被借图书信息

输出：能否借书的标志

处理：读者提出借书请求后，先判断该读者以前的借书量是否达到了10本，如果达到了10本，则不能再借书，如果没有达到10本，则再判断读者要借的图书的可借量是否为0，如果不为0，则该书可以借出。

3.3 数据库设计

在图书管理系统中，数据库设计占重要位置，数据库设计质量的优劣，可直接影响到数据库数据的冗余度、数据的一致性、数据丢失等问题。下面就系统数据库规范化设计进行说明。

3.3.1 数据库设计的理论指导

数据库设计的理论指导是范式理论，其主要内容如下：

1）如果关系模式R，其所有的域为单纯域则称R是规范化的关系，或称第一范式 (1NF)

2）如果关系模式R为第一范式，且每个非主属性完全函数依赖于码，则模式R为第二范式（2NF）。

3) 如果关系模式R为第二范式，且每个非主属性非传递依赖于码，则称关系模式R为第三范式(3NF)。

4)关系模式R为第一范式，满足函数依赖集合F，X和A均为R的属性集合，且X不包含A，如果R满足X－>A且X必包含R的码，称关系模式R为BCNF范式。

3.3.2 数据库设计

图书管理系统数据库常常要设计含有如下数据项：借书证号、姓名、单位、馆藏号(馆藏号为每本书上的条形码号)、书名、分类号、作者、价格等。如何进行模式的设计呢？下面以图书流通模块所涉及的数据库为例来说明。

图 书

读 者

借阅

m

n

借阅时间

馆藏号

书名

分类号

作者

价格

借书证号

姓名

性别

图4 图书流通的E-R图

属于

单 位

1

n

单位名称

单位编号

先设计图书流通的实体－关系图(E-R图)。E-R图由3个相关联的部分构成，即实体、实体与实体之间的关系以及实体和关系的属性。图书流通过程中实体“图书”与“读者”之间的关系是借阅和被借阅的关系，实体“读者”与“单位”之间的关系是属于和被属于的关系，“图书”的属性有“馆藏号”、“书名”、“分类号”、“作者”、“价格”，“读者”的属性有“借书证号”、“姓名”、“性别”，“单位”的属性有“单位编号”和“单位名称”，“借阅”属性“借书日期”，由此得出E-R图如图4。

从图中可以知道：

①“借书证号”是唯一的，所以“借书证号”决定“姓名”，每位读者应只属于一个性别，所以“借书证号”也决定“性别”；

②“馆藏号”是唯一的，所以“馆藏号”决定“书名”、“分类号”、“作者”、“价格”；

③ “单位编号”是唯一的，所以“单位编号”决定“单位名称”；

④ 每位读者在一个时间只能借一本书，所以“借书证号” +“馆藏号”决定“借阅时间”。

如果将这些数据项置于一个关系模式中，根据范式理论，该关系模式属于1NF（第一范式），它存在删除异常和冗余等问题，不是理想的模式，因此要把它分解成满足3NF或BCNF的关系模式。根据范式理论和E-R图转换成关系模型的规则，上面的E-R图可转换为4个关系模式：①图书（馆藏号、书名、分类号、作者、价格）；②读者（借书证号、姓名、性别、单位编号）；③借阅（借书证号、馆藏号、借阅时间），④单位(单位编码、单位名称)，其中打下划线的为码，这样就解决了插入、删除和数据冗余等问题。

我们对数据的结构进行详细的分析，按照上述的设计思想，共设计了读者表，书目表，馆藏表，流通表等百余张数据表，然后创建视图和存储过程。下面举例说明：

读者表：借书证号、姓名、单位、读者类别、职称等字段；

书目表：馆藏号、ISBN、题名、作者、出版社、复本数、语种、文献类型、版次等字段；

馆藏表：馆藏号、索书号、分类号、种次号、馆藏位置、单价、出版日期等字段；

流通表：借书证号、馆藏号、借期、还期、续借、应还期、操作员等字段；

借阅规则表：读者类别编码、图书类别编码、限借册数、每期天数、续借天数、过期日期、罚金等字段。

读者类别表：读者类别编码、读者类别等字段。

图书类别表：图书类别编码、图书类别等字段。

3.4 数据库索引

建立索引是加快查询速度的有效手段，数据库的每一个表建立了主键，主键由一个或几个字段组成，每一个表都按主键建立了索引，部分表为了满足查询和排序的需要，除建立主索引外，还建立了次索引。例如在查询时要用到“馆藏号”、“作者”、“题名”等条件来查找图书，因此，在书目表上除了对主键“馆藏号”建立了主索引外，也对“作者”、“书名”等建立了次索引。

3.5 视图

视图是从一个或几个基本表导出的表，它是定义在基本表之上的，它是一个虚表，数据库中只存放视图的定义，而不存放视图对应的数据，数据仍然存放在原来的基本表中。通过定义视图，可以使用户眼中的数据库结构简单、清晰，并可以简化用户的数据查询操作。由于本系统数据表较多，表中的字段多，为了简化对表的操作，我们创建了图书_按书名查询、期刊_按刊名查询、期刊_按编辑部查询、借阅规则查询、待还书查询、超期记录查询等30余个视图。

3.6 存储过程

存储过程是一段经过编译的程序代码，存放在数据库服务器端。通过调用适当的存储过程，可在服务器端处理大量数据，再将处理结果送到客户端。这样可减少数据在网络上的传送，消除网络阻塞现象；例如：要查询某条记录，若该记录在表中的顺序号是10000，不采用存储过程，服务器将从1至于10000条记录数据逐条送至客户端，采用存储过程后，由于过程是经过编译的并且是在本地，不需要通过网络，因此能很快查出所需记录并将结果送到客户端，大大减少了网上数据传输量。存储过程另一好处是可供不同的开发工具调用，如PB、VB、ASP、Delphi等开发工具均可调用。在流通模块和WEB查询模块上均有图书检索功能，实际上调用同一存储过程完成的。本系统建立了60多个存储过程，实现诸如借还书处理、新书入库统计、编目入馆藏、读者统计、生成索书号等功能。

3.7 数据库调用

采用ODBC接口实现数据库的调用，采用ADO接口调用。

4 条形码的使用

条形码具有唯一性和一次输入后就可反复使用的优点，利用条形码技术作为信息快速输入的手段可迅速且不易发生错误地处理图书管理业务。本系统使用条形码作为图书和读者的标识，实现标识的唯一性。

使用条码后，能够使图书管理工作更加简单、快捷、不易出错。例如，当一本书具有唯一条形码标识，每位读者也具有唯一条形码标识时，图书的借阅、查询就十分便捷了。应用条形码取代了以往填写书袋卡、借书证，核对借阅时间等繁琐的手工劳动。读者在借书时只要将借书证给工作人员，工作人员只需登录借书系统，用条形码阅读器扫描读者借书证上的条形码，屏幕就会显示出该读者的信息，包括读者姓名、单位、可借几本书、已借几本书、是否过期、有无罚款等。如可以借书，工作人员只需用条形码阅读器扫描该读者所需借的书上的条形码符号后，该书的书名和条形码等信息都从数据库中调出显示在屏幕上，自动记录在该读者的借阅档案中，借书工作即告完成。一般借一本书仅需 1至 2秒钟。操作完后，计算机自动地将该借阅者和借阅的图书号码输入对应数据库中，并自动提示借阅期限

请问：给你个项目你要怎么进行软件测试?

测试流程你先要熟悉需求，公司应该会有一个需求文档，时间够的话，需求文档也要测，这时候要用到静态测试，检查需求说明书写的是否符合清晰无歧义等要求，然后你就要了解系统，通过对系统的了解在加上需求说明书你就可以写下测试计划了，测试计划一般来说好一点的公司的测试组都有一个模板，写就好，测试计划写好了，就要写测试用例了，可以根据性能测试，功能测试，兼容性测试等这些方面来写，还有要把测试方法使用到例如等价类，边界值等那些方法，接着测试用例写好了，下面就要执行测试用例，发现bug，公司应该会有一些bug管理工具，写好后提交，交给开发人员修改，然后开始写缺陷报告，记住要写一些具体的统计性的数据，那样更有说服力，像bug覆盖率等，当然测试用例中最好也要加一些，那样维护起来比较好。下面呢，就是比较麻烦的回归测试，经过回归测试之后，基本上就不会有什么问题，系统就可以上线了，接下来呢就是维护的工作 了。

因为这个测试的流程不同的公司是不同的，具体问题具体分析，要结合实际去测试，你要注意如何能够科学有效的测试，并且要注意维护，这就要做到测试的文档话，什么时候都有据可依，测试的时候不要追求完美，没有必要的测试是会浪费时间的，不同的系统都有它核心的模块，只要保证用户常用的模块不出问题就没事，基本的系统都是单元到集成 这不仅是白盒，黑盒也一样，通常流程测试是最重要的，时间短的话，只要保证系统能够正常运行就是关键，接口测试是这时候的主要测试目标。

委托软件公司开发软件要提供什么资料，最好有范文或模板。急……

一般是自己的需求给人家写一份就是了,很简单的.

求问，软件测试一般简历要怎么写

软件测试一般简历的格式及内容：

姓名：

目前所在： 天河区 年　　龄： 24

户口所在： 江西 国　　籍： 中国

婚姻状况： 未婚 民　　族： 汉族

培训认证： 未参加 身　　高： 175 cm

诚信徽章： 未申请 体　　重： 64 kg

人才测评： 未测评

我的特长：

求职意向

人才类型： 普通求职　

应聘职位： 软件测试工程师：

工作年限： 3 职　　称：

求职类型： 全职 可到职日期： 一个星期

月薪要求： 3500--5000 希望工作地区： 广州,,

工作经历

江西易往信息技术有限公司　　 起止年月：2009-06 ～ 2010-05

公司性质： 股份制企业　　所属行业：通信/电信/网络设备

担任职位： 软件测试工程师

工作描述： 主要职责：1. 根据项目需求，制订测试方案，编写测试计划，编写测试用例；2、搭建测试环境，执行测试用例并跟踪测试结果； 3、编写维护软件说明及测试报告等相关文档；4、日常差错问题查询、处理及跟踪提交详细报告；

离职原因： 深造

广东赛特技工学校　　 起止年月：2008-02 ～ 2009-06

公司性质： 私营企业　　所属行业：教育/培训/院校

担任职位： 班主任兼教师

工作描述： 学生管理与家长沟通，课件安排及课程的教学。

离职原因： 目标--资深软测工程师

志愿者经历

教育背景

毕业院校：

最高学历： 本科　　获得学位: 毕业日期： 2008-06

专 业 一： 机械电子 专 业 二：

起始年月 终止年月 学校（机构） 所学专业 获得证书 证书编号

2010-06 2010-12 北大青鸟广州软测培训中心 软件测试 北大青鸟软件测试工程师证书 -

语言能力

外语： 英语　良好 粤语水平： 良好

其它外语能力： 英语 四级

国语水平： 精通

工作能力及其他专长

掌握C语言，熟悉HTML、XML语言、VBScript脚本语言，了解Java语言、C++ ；

能够熟练读写英文技术文档，并具备良好的英语阅读能力；

能熟练的搭建Windows测试环境，能熟练搭建DHCP、DNS、FTP、WEB服务器等。

掌握软件工程，软件测试理论知识，软件测试流程，能根据需求分析编写测试计划，设计测试用例，执行测试用例并提交缺陷报告，提交测试总结报告；

掌握高效设计测试用例的方法，根据不同的情况运用适当的方法设计测试用例，例如：边界值，等价类，因果图，正交表，状态图等；

能熟练使用Linux命令实现基本操作，包括文件管理、用户权限管理、进程管理等，能配置linux与网络应用环境，对shell编程有一定基础；

熟悉掌握SQL与Access数据库，了解视图、存储过程、触发器、表链接、事务的创建及工作原理,主键与外键的关系，对MySQL、Oracle数据库有一定的了解；

熟悉白盒测试，能利用各种覆盖率技术，如：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖，设计测试用例并实施测试，对代码检查工具Logiscope和C++ test有一定的了解；

熟练使用自动化测试工具，例如：功能测试工具QTP，性能测试工具LoadRunner,测试管理工具TestDirector、 Bugzilla等缺陷跟踪及管理工具的运用，并能熟练使用配置文档管理软件VSS；

自我评价

热爱软件测试工作，可以胜任重复性工作，工作细致认真、积极主动、有耐心、严谨。

有较强的沟通技巧及团队合作精神，组织协调能力，较强的责任感及进取精神。

时间观念超强，能根据任务安排及时完成，承受较大的工作压力，能适应加班及出差工作。

积极上进，不耻下问，具有发现问题并分析、解决应用问题的能力，较强逻辑分析及文字表达能力。

能与开发人员以及客户很好地进行沟通和交流，能与客户成为最为友好的朋友，最终与团队共同创造价值。

具备良好的身体素质及心理素质，非常热爱音乐及各球类运动。非常积极参加文体活动。

在今后工作中不断的积累经验，拓展自己各方面的知识，往极具有挑战性的高级测试工程师和管理方向发展，成为资深的测试工程师和系统架构师。

项目经验

项目经验一

项目名称：Mattel Video Girl Camera

项目描述：该项目有硬件与软件两部分。硬件可以随时随地拍照录像并传到软件上，也可以作为网络摄像头使用，通过软件编辑添加一些特效，做成影片。

工作职责：

1)搭建测试平台；

2)对所有的功能进行功能性的覆盖测试；

3)在不同的系统上测试兼容性，并对声卡显卡进行兼容性测试；

4)提交缺陷报告，并对缺陷进行跟踪处理；

5)回归测试。

项目经验 二

项目名称：供电管理系统性能测试

项目描述：1）核心业务场景测试；

2）组合业务场景测试；

3）历史大量数据访问测试；

4）压力测试和负载测试；

5）WEB服务运行平台：Windows 2000 Server JDK1.42 TomCat4.1.18。

工作职责：1）参与项目测试计划的制定；

2）主要进行核心业务模块测试；

3）根据需求文档和测试计划编写测试用例；

4）根据测试目的设计性能测试用例，运用Loadrunner录制脚本并设计测试场景；

5）执行测试并运用VSS配置管理工具管理和提交测试文档和TestDirector进行缺陷跟踪系统填写缺陷跟踪报告并提交；

转载请注明出处51数据库 » 软件需求提交模板 项目需求报告要怎么写