软件质量管理体系说明

软件质量管理体系说明（通用6篇）

篇1：软件质量管理体系说明

**公司软件工程质量管理体系说明

我公司已软件工程要求建立了质量管理体系，严格控制产品的设计和开发的策划和过程，确保新产品满足市场要求。一：职责分工 研发总监

 主管公司技术、产品发展方向的调查研究,确定新产品的开发项目和新技术的研究方向；

 主管新产品的确定、设计、开发、评审、验证、确认等过程；  主管新产品市场推广的技术支持和新产品的试运行。研发部     组织实施新产品开发之前的可行性调研； 参与对立项报告的评审；

实施新产品的形态设计，编制新产品研发计划；

负责根据公司技术发展战略开展技术研究和新产品开发及老产品的改造、升级工作；

 负责针对每个开发的软件产品进行全方位的测试，保障产品质量；  参与对产品开发过程的阶段性评审和开发结束时的验收。

 负责软件技术的积累和成长，产品的软件开发、测试，产品软件的技术支持等，对软件的质量和稳定性负责，部门成员参加具体的产品的软件开发过程。

二、开发要求

1、确立设计开发项目

 根据市场调查、技术发展或市场需要提出新产品立项或重大改进需求的由指定专人进行可行性调研，编写《立项报告》，申请立项；

 根据立项申请，由研发总监组织相关人员（必要时聘请专家）进行评审并对结果进行记录。

2、设计开发的策划

 由研发部成立专门的项目小组对已立项的新产品编制《设计开发需求》，然后开始系统设计，以此作为项目组成员进行设计开发活动的依据。应阐明设计项目的输入和输出要求、设计的进度要求、人工预计、任务描述、设计验收的时机等活动的安排，并规定实施这些活动的职责；

 研发部在系统设计完成时形成设计文档，由项目小组进行内部评审，形成记录。然后开始进行程序代码开发；  项目负责人的选定要求其具有相当的能力和经验，项目组成员的选定也要求遵循资源优化的原则，有利于提高效率，避开矛盾，使资源得到合理的配置；  项目开发计划可随设计的进展作必要的修改；

 项目组长对开发组织各技术接口所交流的信息进行管理，以确保设计开发过程有效。

3、设计开发输入

 设计开发输入包括：《立项报告》、《设计开发需求》相关客户需求资料及竞争对手资料还有国内国际法律法规以及行业标准，包括公司内部的设计规范；

 设计开发输入是设计开发验收的重要依据；

 在设计完成之时和进行之中，应对设计输入进行适当的评审，尤其对设计输入中不完善、含糊、矛盾的要求，应提出并会同提出者一同解决，并对其进行记录。

4、设计开发输出

 项目正式开始进行，设计人员开始系统设计，输出系统功能模块的形态设计文档；

 设计输出文件必须经设计验证评审通过后，由技术总监或总工签署后才能提交到技术管理中心备案，开发部则按照设计文档进行下一步的代码开发；  研发人员在每个开发、测试阶段完成之后将产生功能模块的源代码、软件各功能模块的说明书、测试报告，评审小组评审后写出评审报告，通过的话表示这个阶段的完成。

5、设计和开发的评审

 按照《立项报告》、《设计开发需求》由技术管理中心在适宜时机对产品在设计开发进行时组织人员进行阶段性的评审，评审方式以会议讨论方式进行，评审主要由技术副总和开发部人员和公司技术骨干参加，主要评价开发满足设计的要求和开发满足《质量保证计划》的能力，识别开发过程中出现的问题，评审中应提出解决办法，并作好记录保存；

6、设计开发的验收

 在设计完成时，需由评审小组对设计进行验收，主要评审功能形态设计及其设计过程产生的文档，通过后将提交到技术管理中心；  产品开发完成后，提交所有的开发文档，由项目验收小组进行产品验收评审，以保证输出满足输入要求的软件产品。

7、设计开发的确认

 质检部应根据所策划的安排对已完成的样品进行验证。以验证样品的要求符合设计输入的要求。并将验证的结果给以记录。 当客户有要求或需要时就按照相应的产品标准对样品进行测试，作为验证方式的一种。记录并保存好有关的测试结果。 验证的结果及任何必要措施的记录将给以保存。

8、设计更改

 在设计开发过程的各个阶段，如需要较大的更改设计，相关的提出部门或设计人员应确定修改的内容，提出设计更改建议。

 针对不同类型的设计开发项目，设计更改建议需在经过不同的相关负责人和/或技术委员会以及其他相关人员的确认，保持相关记录，转交回设计人员手中，同时作为项目文档保存。 在更改实施前必须对其进行验证、确认，以保证不会因更改而造成新的问题；  对设计更改的内容应予以记录，并及时传递到有关部门和场所。

篇2：软件质量管理体系说明

你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。

现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求15；需求9 的说明正好与需求21相反，你因该相信哪一个？需求24非常含糊，你根本不明白它的意思；你不得不花上一个小时与2位开发人员讨论需求30，只因为你们对 其各有各的理解；并且，唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义，并且你能预料到，如果你错了，你要做大量的重复工作。

许多软件需求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其 他原因是公司不愿意将其产品说明书放在公共区域。

这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好 的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。

不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。但是，如果你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。

高质量需求叙述的特性

我们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求叙述应体现的6个特性，下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试 例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。

正确：每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。

只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。

可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其他的权衡。

必要性：每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑 必需的另外情形（译注，此句翻译不顺，请参照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。

优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优 先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时，项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。

我是用3种级别的优先权：高优先权表明需求必须体现在下一个产品版本中，中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中，低优先权表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。

明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS 作者很清楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部 分预期的特性。

可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。如果需求是不可验证的，决定需求是不 是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。

高质量需求说明的特征

一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。

在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。

一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。

可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。

可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。

需求质量的评审

这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个 从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢 迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。

例1．“产品应在不少于每60秒的正常周期内提供状态信息”

这个需求是不完整的：状态信息是什么，如何显示给用户。这个需 求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超 过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。

弥补缺陷，重写需求的一种方法：

1、状态信息

1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息

1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比

1．3任务完成时，应显示相关的信息

1．4后台任务出错应该显示错误信息

为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性 表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。

象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可 打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没

有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不 会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全 体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/

将 要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主 官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档 不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，编写质量需求的方针

编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们

要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你 是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。

需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。

密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。

避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

篇3：软件工程与软件质量管理分析

上世纪60年代,随着计算机应用领域的迅速扩大和计算机软件系统的日益庞大和复杂,出现了“软件危机”。为了解决由于“软件危机”带来的诸如软件质量下降、成本难于控制、软件进度无法完成、软件的可维护性差等问题,产生了软件工程这一学科。人们最初认为软件工程的发展主要由软件工程技术决定,而长期忽视了软件工程与软件质量管理对软件工程管理和软件质量保证的重视,从而导致了对软件工程管理的研究长期滞后。软件质量的管理主要来自于对软件开发过程的管理。

2 软件工程分析

2.1 系统开发的基本过程

系统开发可以分为3个基本的过程,包括分析、开发、测试和维护过程[1]。开发过程还包括设计和实现两个子过程。这种划分将一个复杂的开发过程分解为几个相对独立的子过程,便于系统的并行开发和逐步深化。在分析阶段,需要根据用户的功能说明构造一个分析模型。在这个阶段,用户的需求会经常更改。分析模型的目标是提供一个强壮的体系结构,它要能经得起需求的变化。这一阶段还应该将系统分解为几个子系统,以便于对系统的理解。分析模型应该是在理想的情况下考虑系统功能的实现,不考虑具体的编程语言、数据库系统或性能等的要求,在开发阶段,应该考虑具体的实施环境。开发阶段又分为两个过程———设计和实现。设计阶段将分析模型转化为更加详细的、根据具体环境的设计模型,并将分析模型中的功能模块转化成适当的软件模块并最终在实现过程中编码实现。测试过程用于验证是否所有在分析模型中提出的功能需求都被开发模型实现以及是否正确的实现。测试过程实质上是对整个系统从部分到整体的验证,对测试模型的组织实际上也是对系统的一种抽象理解的应用。在这样一个模型中,维护工作可以从任何一个模型开始。

2.2 面向对象的开发方法

科学的开发方法需要一套科学的方法学,不同的思想方法决定不同的开发方法及最终产品的结构、特性等。所关心的问题是真正地将软件工程技术纳入工业化大规摸的实施进程中,这种方法的关键要素包括在能支持渐进的变化的开发过程中,使系统的开发过程的各个阶段能够简单易行、彼此平滑过渡,系统模型易于理解,易于维护,能够最大限度地重用已有的成果,面向对象的技术为实现以上目标提供了强有力的支持[2]。

传统的功能/数据(F/D)方法不能很好地解决以上问题。首先,功能/数据方法将系统分解为功能和数据两部分,功能是主动的,并具有一定的行为,数据是被动的信息拥有者,它被功能中的各种行为利用或改变。其次,用功能/数据方法开发的系统与现实系统之间存在很大的差别,它往往不是根据现实生活中的实体形成系统模型,而是将所有实体中不同的功能和数据提取出来。最后,继承是面向对象技术本身的特点,它可以极大程度地重用现有的软件产品。因此,对一个大型系统的开发,应该采用面向对象的技术。

2.3 重用

都希望在所有的开发过程中尽可能地重用己有的结果,因为重用可以极大地提高生产效率。重用是解决软件工程危机的一个关键方法,传统的软件工程开发方法并不能很好地利用己有的软件产品。

比较熟悉对软件代码的重用,这是最常见的重用方式。它可以极大地提高生产效率,但是从软件工程的角度来看,这并不是唯一感兴趣的方式。更希望能从软件开发的更广泛的范围和阶段中发现并使用重用技术。例如,最终的软件包可以由已有软件模块组成,软件模块又可以由软件组件(Compoment)组成,组件可以是完成固定功能的并经过测试的最小软件单元[3]。

另外,对文档也可以重用,因为无论是开发阶段的文档,还是维护阶段的文档,对于不同的软件系统而言,只要开发方法和管理方法不变,文档的格式、使用规程等都有极高的可重用率。在重用技术方面,面向对象的技术提供了强大的帮助,它为寻找、理解和分配可重用事务提供了一个很好的解决办法。

3 软件质量管理

日本的著名软件质量专家KAORUISHIKAWA解释日本质量奇迹时指出了质量工作的6个特征:

(1)全公司范围的质量控制。

(2)高层管理者和结构的质量控制监督。

(3)教育和培训。

(4)质量周期活动。

(5)统计方法的应用。

(6)全国范围的质量提高活动。

从上面可以看出,其中至少4点l、2、3、6是涉及到与人或与机构相关的方面。的确,质量的提高没有人的参与是不可能实现的,没有有效地组织管理也是难于实现的。大部分的企业一般都会有质量管理部门,这些企业知道质量管理的重要性。但是对于质量管理和质量改进的概念仅限于这些质量管理部门,而其他人员也想当然地认为质量的管理和改进是这些管理部门的事,与自己无关。

如图1所示,软件质量框架是一个“质量特征—质量子特征—度量因子”的三层结构模型。在这个框架模型中,上层是面向管理的质量特征,每一个质量特征是用以描述和评价软件质量的一组属性,代表软件质量的一个方面。软件质量不仅从该软件外部表现出来的特征来确定,而且必须从其内部所具有的特征来确定。

第二层的质量子特征是上层质量特征的细化,一个特定的子特征可以对应若干个质量特征。软件质量子特征是管理人员和技术人员关于软件质量问题的通信渠道。

最下面一层是软件质量度量因子(包括各种参数),用来度量质量特征。定量化的度量因子可以直接测量或统计得到,为最终得到软件质量子特征值和特征值提供依据。

事实上,质量提高必须是全企业甚至是全社会的责任。企业和社会中的每个人都对质量提高起着决定作用。质量管理部门只是对质量进行监督、审查,并提出改进方法,进行质量培训。尤其是最高管理者,只有他们真正理解了全面质量管理的意义和方法,才能使质量管理真正能得到贯彻和实施。而且全面质量管理已不是仅仅涉及产品质量的一项工作,当今的先进企业应该把质量作为企业的核心目标,一切活动应该围绕着增进质量来进行。因此,全面质量管理己成为企业的一套现代化的管理模式,包括企业所有的生产、经营、管理、流通等环节的管理,集科学性、效率性、经济性于一体。

质量管理的目的在于最终消除一切可能的缺陷,缺陷产生的原因有两种。一种是由工人造成的,一种是由管理造成的。由工人造成的缺陷比较容易解决,只要让工人知道去做什么,知道自己工作产生的结果,以及懂得控制结果的方法就可以阻止工人生产的产品出现缺陷。通过对各种错误和缺陷进行研究,就可以找到产生缺陷的原因,并最终找到解决的办法。通过对工人进行培训,让工人完全认识到以上3点是完全可能的。

但由管理而产生的缺陷往往不易察觉而被忽视。由于管理上的漏洞,往往会形成管理上的交叠或空缺,使工人因无法满足上述3个条件造成产品缺陷。而且,软件开发是一个渐进的过程,很难一开始就把需求完全描述清楚。对软件产品的测试也不可能面面俱到,必然存在隐藏的缺陷。因此,需要一套强有力的管理机构,实施一套有效的管理程序来不断地消灭缺陷,提高质量。

质量管理机构应该具有独立性,并且具有相当的管理权力。除企业最高管理者外,它不应该受其他部门的约束和干扰,并且所有部门涉及质量的过程都应受到质量管理部门的监督甚至管理。质量管理机构按职能可以分为几个子部门,质量管理部门的作用是制定、实施、改进质量计划;质量认证部门负责企业内部质量认证的工作,质量认证是对企业的质量管理水平进行评估的行为,分内部认证和外部认证。外部认证获得通过后往往可以获得国际上的质量认可,如获得系列国际认证,产品出口可以免检。外部认证往往是被动的,而内部认证是一种主动行为,是对自身质量管理水平的考验,通过周期性的认证,不断提高企业自身的质量水平。培训部门对于一个大企业来说,培训是非常重要的工作,要使全体员工理解和掌握质量的概念和方法,培训必须专人负责,并科学地、系统地进行。对于一些大企业,还可以划分出一个支持部门,处理一些辅助性的工作。

质量部门必须涉及与质量相关的所有部门的工作,以便于及时发现质量问题,分析发生的原因,制定相应的修改和解决办法。有了对质量的全面认识,合理的管理机构,还需要一套完善的质量管理程序。质量管理程序是提高过程质量的一套科学方法,产品质量的提高来自于对生产产品的过程的不断提高,这就是全面质量管理的精髓。对产品的测试和评估不能换回产品的质量。质量不是最后加进产品中的,而是在产品产生的每个阶段中创造出来的。因此只有提高生产产品的整个过程的质量,才能真正地提高产品的质量。

4 结语

在对软件工程的发展现状进行分析后,提出了对软件工程的一些基本认识和看法,并以此为出发点,希望结合最先进的软件工程开发技术和管理的成果,探讨一种面向实用的、保证软件质量和提高软件生产效率的大型系统的开发方法,并给出了一个质量体系框架模型。

摘要：我国的软件开发行业拥有众多优秀的软件开发人员,但是企业对项目软件开发的管理始终处于比较低的水平。随着国内众多工业企业掀起的与国际标准接轨,进行国际标准化质量体系认证(ISO9000系列)的热潮,许多软件开发企业的有识之士己经开始关注软件质量的管理,甚至开始准备或已经进行软件质量体系国际标准化认证的工作。本文就软件工程与软件质量管理方面的有关问题进行分析研究。

关键词：软件工程,软件质量,管理

参考文献

[1]Pressman.R.Software Engineering:A Reactionary’s Approa-cb,4th ed.New York:Mcgraw-Hill,1997.

[2]Lin,Jy huong,Lee,Mingchang.An object-oriented analysismet hod for customer relationship management information system.Information and software technology Volume:46,2004,5(8).

篇4：论软件项目质量管理

关键词：软件项目；质量管理；研究

中图分类号：F270.7文献标识码：A文章编号：1007-9599 （2010） 13-0000-01

Talking on Software Project Quality Management

Ba Wenguang

(Dongying Office of Shandong Rural Credit Cooperatives,Dongying257000,China）

Abstract:Software quality management throughout the whole life cycle of the software is very important.This paper describes the main contents of eye quality management,puts forward the measure improving software project mass.

Keywords:Software projects;Quality management;Research

海爾总裁张瑞敏说：“有缺陷的产品等于废品。”的确，产品质量是企业生存的根本。当前，IT企业越来越重视软件项目的质量，而质量管理对软件项目成败又有着直接的影响。因此，研究软件项目质量管理，探索提升软件项目质量的途径成为一个热门课题。

一、软件项目质量管理的内容

软件项目的实施过程也是软件质量形成的过程，涉及软件产品的各个层面。软件项目质量管理主要包括软件项目质量计划编制、软件项目质量保证和软件项目质量控制三个过程。

（一）软件项目质量计划编制

软件项目质量计划是软件质量管理的行动纲领，通常由项目经理和质量人员共同协商制定质量计划。它包括确认与项目有关的质量标准以及如何满足这些标准。如果机构有独立的质量人员，就由质量人员起草《质量管理计划》，递交给项目经理和质量经理审批。如果机构没有独立的质量人员，就由项目经理兼任质量人员和质量经理的角色。质量计划的主要输出结果有：质量管理计划、质量度量指标、质量检查单、过程改进计划等。

（二）软件项目质量保证。

质量保证的实质是检查项目的工作过程和工作成果，是否符合既定的规范。质量保证的要点：找出明显不符合规范的工作过程和工作成果，及时指导开发人员纠正问题，切勿吹毛求疵或者在无关痛痒的地方查来查去。质量人员首先设法与项目成员协商，给出解决措施。在项目内难以解决的质量问题，由上级领导给出解决措施。这个过程的主要输出结果是：过程质量检查结果、产品质量检查结果、问题与对策和经验总结。

（三）软件项目质量控制

质量控制主要是监控特定的项目结果，确保它们遵循了相关质量标准，并确定提高整体质量的方法。这个过程常与质量管理所采用的工具和技术密切相关。例如，帕雷托图、质量控制图和统计抽样。质量控制的主要输出结果包括：质量控制度量、有效和建议的缺陷修复、建议的纠正和预防措施、请求的变更、质量基线更新、组织过程资产更新和项目管理计划更新等。

二、提高软件项目质量的措施

（一）确立有效的质量标准体系

建立必要的质量标准是进行软件项目质量管理的前提和关键。根据在实施软件项目方面的整体战略规划与软件项目实施计划，实施软件项目的主体企业首先要确立衡量项目质量的标准体系。衡量项目质量的标准一般包括项目涉及的范围、项目实施的具体步骤、项目周期估计、项目成本预算、项目工作详细内容安排、质量目标要求以及客户满意度等。值得注意的是，项目质量标准体系一定要具备完整性、科学性与合理性，项目实施各相关主体应该事先进行讨论与沟通，以保证其完整、无漏洞，又具备较强的可实施性。

（二）做好技术评审

技术评审的目的是通过同行专家对工作成果的评审进行讨论，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。质量人员应当参与重要的技术评审会议，这样既监督了技术评审，又加深对工作成果的了解。技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本。技术评审的价值在于“请同行专家评审工作成果，找出缺陷，给出改进建议”，而不在于是否按照规范召开了评审会议（形式是次要的）。技术评审时，项目经理一定要请真正内行的人参与评审，而且要让评审者投入一定的精力，这样才可能取得评审的效果。

（三）提高项目文档质量

按照软件质量管理的要求，在软件生命周期的各阶段应该及时、认真的编制相应的文档。软件项目文档质量不高的主要原因：一是缺乏评价文档的质量标准；二是对文档编写不够重视。质量差的项目文档会削弱对项目的管理，增高项目成本，甚至造成更加有害的后果。我们必须加强对文档质量的检查，提高项目文档的质量。一般在项目文档检查中主要检查“软件需求说明书”、“详细设计说明书”、和“软件测试报告”。另外，我们还要检查上述文档的评审记录，评审结论，重点检查文档中发现的问题是否已经归零。

（四）建立有效的激励机制

通过有效的激励机制，让员工慷慨激昂、充满激情的全力工作，是提高产品质量的重要手段。根据马斯洛理论我们知道：不同的人，有着不同的需要。因此，调动员工的积极性，需要实行多样化激励方式。项目管理者需要对员工进行分类，建立员工分类手册，并且要建立重点员工的个体分析表，以便采取多样化激励措施。斯金纳的操作性条件反射理论告诉我们：当行为结果有利于个人时，行为的得到强化，表现积极主动，愿意重复；当行为结果不利于个人时，行为得到弱化，表现消极被动，不愿意重复。若根据日常考核结果，进行即时化奖惩，该表扬的表扬，该批评的批评；该奖励的奖励，该处罚的处罚。人的行为即时反映出奖罚结果，那么他下一个行为就能即时根据奖罚作出调整。这样就容易发挥奖罚的作用，使项目按照正确的方向顺利进行，从而提高软件产品的质量。

参考文献：

[1]项目管理协会.项目管理知识体系指南[M].北京:电子工业出版社,2009,4

篇5：关于资产管理软件说明

背景：目前学校固定资产管理中存在的普遍问题

管理体制不顺，管理职责不清。

学校固定资产是国有资产的重要组成部分。但长期以来，事业单位国有资产的管理体制一直没有理顺，存在着职责划分不清的问题。有的将职能放在了财政部门，有的将职能放在了国有资产监管部门，资产管理的部分具体工作由学校实施。体制问题导致职能交叉、分工不明，导致制定制度、开展监督等固定资产管理工作“谁都负责，谁都不负责”。可以说，体制不顺是学校固定资产管理弱化的一个根本问题。

管理意识淡薄，管理制度缺失。

由于教育投资体制的单一性，学校的支出都由国家大包大揽，使人们形成了重申请拨款，轻资产管理的观念。管理制度方面，学校固定资产的管理是依靠一系列管理制度以及由其规定的管理办法实现的，但目前，全国或地区统一、有效的管理制度包括固定资产核算制度缺失或不尽完善与合理，许多学校也未针对自身的具体情况制定规范的管理制度及方法。

资产家底不清，账实不符。

固定资产存量不清、账实不符，“有账无物”，“有物无账”的现象是学校固定资产账务管理中存在的又一严重问题。许多固定资产以账外资产的形式存在。另外，购买与登记入账脱节，购置固定资产只列支出，校内不记固定资产总账、明细账，账实不符，或者以表代账等。

管理人员专业素质较低，管理水平低下。

目前许多学校固定资产专职管理人员的数量非常少，一般都是总务后勤部门和教师兼管。而且人员设置不稳定，变动大。管理人员上岗前也很少经过专业学习和定期培训。另外，在调查中还发现，运用固定资产软件对固定资产实行管理的学校更是少之又少。

闲置浪费严重，使用效率低下。

学校对固定资产的购置盲目求全、求新，追求与兄弟学校的齐头并进。结果造成一方面价值不菲的设施设备长期闲置，使用率极低，没有发挥它们的正常使用效能，另一方面却又是教学经费的紧缺。

报废环节失控，清查工作未得以落实。

许多学校固定资产报废随意性很大，科室、部门或个人报废时根本没有履行必要的报批程序。另外，许多学校固定资产的清查工作没有正常开展，对于清查结果，财务部门未按规定程序及时处理与入账。

一、资产管理模块需要的功能：

1、教育局对各校资产的全局监管管理（对报各校或全教育局资产情况进行分类查询或按校、资产资金汇总），拥有该类资产数量、全额，对学校报废申请审批，对学校申请的报废资产可以做同意报废或学校间资产转移（转给需要的学校）。

2、教育局管理中可对系统的项目可以增加，可对项目中的选项内容增加和修改。

3、学校可以利用其进行资产及消耗物品产管理（包括分类查询等）。

4、学校可以通过该软件进行固定资产，报废申请，接收，新增等操作，每个资产都有一个唯一编号。

5、教育局可对本年度资产报废或新增资产进行汇总，形成报告。

6、按两基A3要求和标准化办学要求可以查询（学校、教育局都要）。

7、消耗物品的购入量、领取量、库存量等可查询、分类记录（学校用）

二、资产管理模块功能要求：

1、各学校要有资产录入人员（配权限）；资产审核人（配权限）各一名；配资产查看权限。

2、教育局资产管理人员（配权限）；资产查看权限。

3、学校对自己已审资产没有删除、修改权（物品名、数量、型号、规格、价格、购入年限）；可以增加新的使用人或管理员；增加新的存放地可在校内调整；可以报废申请等操作。

三、资产管理模块项目：

（一）、创建的学校类型有：幼儿园、小学、独立初中、独立高中九年一贯制学校、十二年一贯制、完中

（二）、以校为单位：

1、资产项目内容名称：

1）用地管理。2）建筑物管理。3）班级 4）专业室 5）办公室 6）其它室

7）户外设施、设备 8）其它设备、设备 9）消防设施 10）监控类设备

2、消耗物品项目有：

1）购入管理 2）库存管理 3）物品领用管理

四、对项目详细说明：

资产项目：

（一）用地管理

包括内容：序号、土地名称、编号、类型、面积（平方米）、位置或坐标、土地证号、备注

（二）建筑物管理

包括内容：序号、建筑物名称、编号、类型、建造时间、占地面积、建筑面积、建筑结构、层数、防震等级、防火等级、建造价、位置或坐标、备注。

（三）班级 说明：根据学校的班级数，学校自己可建班级或删除班级。删除班级时，班内物品必须为空。

1、班级资产管理页：班级名称、类型（幼儿、学前、小学、初中、高中、）几班、班主任、班级位置（楼号+层号+房号）

2、基础设施设备：安装后，更换班（室）时不能取下或不用跟随的基础设备。

内容：序号、物品名称、单价、数量、合计、备注，按钮“申请报废”数量为1不能更改。

3、班级资产内容：序号、物品名称、数量、价值、备注，按钮“详单”。（该项为详单的汇总项目）

说明：根据各班内容不同可以增加或删除，删除条件为详单为空。每种类型的资产为一行，每行后都有一个“详单”按钮。

（1）详单内容：物品编号、物品名称、型号或规格、购置时间、数量（自动为1不可改）、单价、来源、备注。按钮“校内转移”、申请报废。说明：来源为选项（配发、自购、捐赠、援建），备注自动记录该资产的转移情况、报废情况（每转移一次记录一次，报废被教育局批为转移到其它校时也记录，直到批准为报废为最后记录，此项不可修改。）校内转移时其它项不变。学校间转移时，物品基本属性不变。学校间转移时，来源为：捐赠，同时备注中记录转移时间和学校。

（四）专业室 说明：所有教学有关的功能室。根据学校的功能室情况，学校自己可建专业室或删除专业室。删除专业室时，专业室物品必须为空。

1、专业室资产管理页：专业室名称、序号、功能、管理员姓名、专业室位置、面积，选项：A3指标功能室（是或否）。

2、基础设施设备：安装后，更换室时不能取下或不用跟随的基础设备。

内容：序号、物品名称、单价、数量、合计、备注，按钮“申请报废”数量为1不能更改。

3、专业室资产信息：序号、物品名称、数量、价值、备注，按钮“详单”。（该项为详单的汇总项目）说明：根据专业室内容不同可以增加或删除，删除条件为详单为空。每种类型的资产为一行，每行后都有一个“详单”按钮。

（1）详单内容：物品编号、物品名称、型号或规格、购置时间、数量（自动为1不可改）、单价、来源、备注。按钮“校内转移”、申请报废。说明：来源为选项（配发、自购、捐赠、援建），备注自动记录该资产的转移情况、报废情况（每转移一次记录一次，报废被教育局批为转移到其它校时也记录，直到批准为报废为最后记录，此项不可修改。）校内转移时其它项不变。学校间转移时，物品基本属性不变。学校间转移时，来源为：捐赠，同时备注中记录转移时间和学校。

（五）办公室 说明：所有教学有关的办公室。根据学校的办公室情况，学校自己可建办公室或删除办公室。删除办公室时，办公室物品必须为空。

1、办公室资产管理页：办公室名称、序号、人数、办公室负责人、办公室位置

2、基础设施设备：安装后，办公室时不能取下或不用跟随的基础设备。

内容：序号、物品名称、单价、数量、合计、备注，按钮“申请报废”数量为1不能更改。

3、办公室资产信息：序号、物品名称、数量、价值、备注，按钮“详单”。（该项为详单的汇总项目）说明：根据办公室内容不同可以增加或删除，删除条件为详单为空。每种类型的资产为一行，每行后都有一个“详单”按钮。

（1）详单内容：物品编号、物品名称、型号或规格、购置时间、数量（自动为1不可改）、单价、来源、备注。按钮“校内转移”、申请报废。说明：来源为选项（配发、自购、捐赠、援建），备注自动记录该资产的转移情况、报废情况（每转移一次记录一次，报废被教育局批为转移到其它校时也记录，直到批准为报废为最后记录，此项不可修改。）校内转移时其它项不变。学校间转移时，物品基本属性不变。学校间转移时，来源为：捐赠，同时备注中记录转移时间和学校。

（六）其它室（与功能室相同）

（七）户外设施、设备

说明：此项用于学校户外的设施设备资产入档，包括：校园文化类，体育设施类，其它的户

外设施设备。所有各学校情况不同，内容根据情况输入，做成统计标准模板。

1、户外设施、设备资产管理页：负责人、设施数、设施总价值、设备数、设备总价值（由下面的信息内容自动计算生成）不可改。

2、户外设施、设备资产信息：序号、物品名称、数量（自动为1）、价值、购入日期、来源、备注；每项一组（单选项：设施、设备；按钮“校内转移”、申请报废）。说明：来源为选项（配发、自购、捐赠、援建），备注自动记录该资产的转移情况、报废情况（每转移一次记录一次，报废被教育局批为转移到其它校时也记录，直到批准为报废为最后记录，此项不可修改。）校内转移时其它项不变。学校间转移时，物品基本属性不变。学校间转移时，来源为：捐赠，同时备注中记录转移时间和学校。

（八）其它设备、设备（同七）

（九）消防设施

说明：此项用于学校有关消防类设备资产入档。所有各学校情况不同，内容根据情况输入，做成统计标准模板。

1、消防设施资产管理页：负责人、设施数、设施总价值、设备数、设备总价值（由下面的信息内容自动计算生成不可改）。

2、消防设施资产信息：序号、物品名称、型号、容量、灭火类型、数量（自动为1）、价值、购入日期、来源、安装位置、备注；每项一组（单选项：设施、设备；按钮“校内转移”、申请报废）。

说明：来源为选项（配发、自购、捐赠、援建），备注自动记录该资产的转移情况、报废情况（每转移一次记录一次，报废被教育局批为转移到其它校时也记录，直到批准为报废为最后记录，此项不可修改。）校内转移时其它项不变。学校间转移时，物品基本属性不变。学校间转移时，来源为：捐赠，同时备注中记录转移时间和学校。

（十）监控设备 说明：此项用于学校有关安全监控设备资产入档。所有各学校情况不同，内容根据情况输入，做成统计标准模板。

1、消防设施资产管理页：负责人、设备数、设备总价值（由下面的信息内容自动计算生成不可改）。

2、消防设施资产信息：序号、物品名称、数量（自动为1）、价值、购入日期、来源、备注；每项一组（按钮“校内转移”、申请报废）。

说明：来源为选项（配发、自购、捐赠、援建），备注自动记录该资产的转移情况、报废情况（每转移一次记录一次，报废被教育局批为转移到其它校时也记录，直到批准为报废为最后记录，此项不可修改。）校内转移时其它项不变。学校间转移时，物品基本属性不变。学校间转移时，来源为：捐赠，同时备注中记录转移时间和学校。消耗物品项目：

说明：主要是学校用，用于日常消耗物品管理，配有录入及查看两种权限。以库存管理为主窗口，配有汇总功能。

（一）主窗口设置：主管人、记录人、物品管理信息

物品管理信息：序号、物品名称、规格及型号、现有数、合计金额；按钮“购入”、“领取”（每项后都有），注：现有数为购入数减去领取数，合计金额为现有数的合计金额。按钮“购入”窗口内容：序号、物品名称（自动显示）、规格及型号（自动显示）、购入数量、金额、购入日期、购入人（可选为主管人或记录人或手动输入）、备注。每输入一条确定后，自动新增一条空的，每次进入是自动到最后一条记录。确定后不可删除、修改。按钮“领取”窗口内容：序号、物品名称（自动显示）、规格及型号（自动显示）、领取数量、金额（自动计算）、领取日期、领取人、备注。每输入一条确定后，自动新增一条空的，每

次进入是自动到最后一条记录。确定后不可删除、修改。汇总功能：

打印本年度消耗物品购入清单（为全部“购入”内容，以购入时间为顺序重新排序，A4纸，有页眉、页脚，打印完成后提示：是否清空记录，是将清空记录，只留下现在有数量为第一条记录，如果该项现有数为零，将删除该项）

打印本年度消耗物品领取清单（为全部“领取”内容，以购入时间为顺序重新排序，A4纸，有页眉、页脚，打印完成后提示：是否清空记录，是将清空记录）报废资产的管理：

当申请报废的资产被示为报废后，该资产从学校资产帐上同原始属性被转移报废资产管理中。通过报废资产查询系统可以查询和打印。该管理窗口可以以时间为排序和学校排序两种方式，学校可对自己学校报废的资产按报废时间进行排序打印（指定时间段或全部信息两种），教育局可以以学校为排序，对指定时间段内的报废资产进行查询，打印形成汇报材料，可以excel导出备份，报废资产信息保存时间为10年，过时信息自动删除以每年12月31号为准线。

五、查询系统

（一）教育局管理

1、可对资产管理的数据进行导出excel（以学校为排序）

2、指定学校查询、指定类型（上面的十个项目）单项或多项条件查询（除清单外、要有汇总项：总数量、总金额，可导出为excel文件）。

3、购入物品查询，时间段、学校、类型等可以单项或多项条件查询（除清单外、要有汇总项：总数量、总金额，可导出为excel文件）。

4、本年度资产购入汇报，从本年1月1日至12月31日，形成汇总、分项汇总和清单。汇总：本年度共购入多少件资产，价值为多少金额（其中配发、自购、捐赠、援建各为多少，如果该项为零则不显示）；分项汇总，其中：以学校为汇总，学校名，购入总数，价值（其中配发、自购、捐赠、援建各为多少，如果该项为零则不显示）；清单：以学校为第一排序，购入时间为第二排序，列出清单。

5、A3功能室达标情况汇总：按学校名称排序，各学校对专业室标注A3功能的进行种类，数量两项的列成表，A4打印（教育局需要）；也可以对指定学校的A3情况进行汇总（学校、教育局都要），可以导出excel。其它说明一：

对资产申请报费的说明：学校在要报废的物品详单后单击申请报废，会进入学校的申请报废管理中，报废管理是对本次要报费的物品进行一个汇总，各物品的基本属性全在清单中，学校在报废管理中，再选中物品（设上全选按钮），立即申请报废或取消报废，在教育局资产管理人员的窗口中就有标，可以将此清单导出excel和直接打印。去实地查看后，对清单中的资产一一批复，各资产后面有同意报废和移动两按钮，不管选按哪一个按钮都可以写原因或说明，移动按钮按下后还多一个学校列表信息，可以选择学校。此原因、说明和转移学校在按确定后写入该物品的备注里（批复人的姓名（可以输入）日期（自动获取）也写入备注中）。批复后清单在学校管理里中有提示，学校可以看到每个资产的批复内容，设有确定按钮。情况一：报废的资产将从资产帐中减除，该资产所有属性内容进入该校的报废物品管理中，最后报废时间和操作人信息也写入到备注中。情况二：资产设为转移，该资产从学校资产中减除，通过平台到指定的学校。由学校的资产管理人员接收该资产，接收后该物品的名称、数量、单价、备注不变，其它为空，由学校进行设置，确定，进入指定的科室中。接收时间和接收人，写入该物品的备注中。

所有资产表中除序号外，还有一个编号（必须输入），这个编号以实物标签贴在实物资产上。

篇6：酒店管理系统软件设计说明书

需求规格说明书

目录

1.引言……………………………………………………….3 1.1目的……………………………………………………..3 1.2 定义…………………………………………………….3 1.3 产品的范围和产品特性……………………………….3 1.4 参考文献……………………………………………….4 2.综合描述………………………………………………….4 2.1 产品的前景…………………………………………...4 2.2 产品的描述…………………………………………...4 2.3 用户类和用户特性…………………………………...4 2.4 运行环境……………………………………………...5 2.5 设计和实现的约束条件……………………………...5 2.6 假设和依赖…………………………………………...5 3.外部接口需求…………………………………………….5 3.1 用户接口……………………………………………...5 3.2 硬件接口……………………………………………...6 3.3 软件借口……………………………………………...6 3.4 通信接口……………………………………………...6 4.系统特性………………………………………………….6 4.1前台管理………………………………………………6

4.2 消费管理……………………………………………...8 4.3 收银管理……………………………………………...9 4.4 客房服务……………………………………………...11 5.其他非功能需求…………………………………………13 5.1 性能需求……………………………………………..13 5.2 安全性需求…………………………………………..13 5.3 软件质量需求………………………………………..13 6.附件………………………………………………………14

附录 分析模型…………………………………………...14

1.引言 1．1目的

随着旅游业的民展，酒店、餐饮娱乐行业日趋发达，引入全方位的电脑服务和电脑管理日益流行。同时，酒店和餐厅娱乐业引入电脑服务和管理也取得了优良的经济效益和社会效益。酒店管理系统将先进的电脑技术和现代酒店服务管理管理完美地结合起来，实现了住宿，餐饮全新概念的服务和管理方式。

酒店管理的电脑化，不仅是体现酒店现代化形象的一个重要标志，而且对于提高员工的工作效率，加速资金周转，降低各项成本及改善服务质量都有十分积极的作用。

1．2定义

1.客房预定系统:可以处理散客预定、团体预定、客房预定、预定未到处理、预售查询等事务。

2.前台接待系统：可以处理散客入住登记，合约入住，团体自动入住和手动入住，补填客单，修改客人信息、转房、调房、设置房态、客人留言，预定客房查询、可售客房查询等事务。

3.前台必银系统：处理记账、埋单、限制客人消费、退房、押金加入、查账、转账、设置跑单、客用保险箱管理、团体埋单及退房业务。

4.账务系统：除具有收银的功能外，还具有纠错、报表输出等功能，能将损失降至最低。5.管家系统；可处理设置净房、脏房、坏房及取消坏房，设置SKIP房、SLEEP房，查询诌房表、脏房表、坏房表，房间状态，新入住查询等业务。

6.电话系统：具有自动计费、夜间稽核，客人信息查询、动态房态查询、房间明细账查询、收银员报表、当日入住客人报表等功能。

7.客历系统：能处理客人手工、自动输入，客人资料查询与修改，黑名单，入住客人自动查询客历、入住客人自动归入客历。

8.合约系统：可将酒店签约的单位或个人的资料输入电脑，并可随时查询和更新。

9.经理系统：可修改客房定价，增加、删除、修改各级密码，个性特别客单，设置系统参数，内部银行系统，数据整理，自我诊断，数据备份。

10.总经理系统：具有客单查询，查询客房状态，查询可售情况，客房占用统计，账务查询，万能查询，报表输出功能

11.密码管理系统：可以管理客户和酒店的各种密码。

12.报表系统：主要是对处理一些非账务表单。主要有客房占用表、转房改租表、预定未到表、客房取消表、房租分析表、经营统计表、可售情况表、房间状态表、坏房状况表、日租统计表、合约销售表。

13.账务报表：主要是处理酒店的日常的账务报表，有收入报表（前台收入明细表、现付收入明细表）、消费报表、顾客账务（住房账务、离店客人账务各跑单账务）、交班报表、信用卡报表、街账报表、应收报表、催账报表、转账报表、借贷报表、联网消费、酒店总表。

1．3产品的范围和产品特性

“酒店管理系统”允许酒店工作人员对酒店的客房、员工以及入住酒店的顾客进行客房入住、酒店服务等一些管理。“酒店管理系统”实施后，能节约人力资源，提高服务质量，方便各项管理。账务处理的时间明显减少，数学计算上的错误也会消失。对客房状态（如是否入住，入住顾客信息等）的查询与统计也显得非常方便，减少了顾客等待与员工分类统计的时间。详细的项目描述请参见酒店管理系统前景和范围文档。文档中这一部分的标题为“初始版本和后续版本的范围”，列出了按照进度计划在这一版本中实现的全部或部分特性。

1.4 参考文献

1）《软件需求》Karl E.Wiegers(美)著 清华大学出版社

2）前期所写的《酒店管理系统的前景和范围文档》

3）《现代软件工程》 孙涌等著 北京希望电子出版社

2.综合描述

2.1 产品的前景

随着计算机技术的飞速发展，信息时代的到来，信息改变了我们这个社会。各类行业在日常经营管理各个方面也在悄悄地走向规范化和网络化。客房管理的信息化程度体现在将计算机及网络与信息技术应用于经营与管理，以现代化工具代替传统手工作业。无疑，使用网络信息化管理使客房管理更先进、更高效、更科学，信息交流更迅速。

酒店客房管理系统是酒店经营管理中不可缺少的部分，它的内容对于经营的决策者和管理者来说都至关重要,所以客房管理系统、信息管理系统应该能够为用户提供充足的信息和快捷的查询手段。但一直以来人们使用传统人工的方式管理文件档案，这种管理方式存在着许多弊端，如:效率低、保密性差，容易出现差错等，且对于查询空房间及已定房间等极为不方便。在当今时代，这些完全可以改用计算机来代替人的手工操作。

作为计算机及网络应用的一部分，使用计算机对客房信息进行管理，具有手工管理所无法比拟的优点。例如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高客房经营管理的效率，也是企业的科学化、正规化管理，与世界接轨的重要条件。且办事效率也是决定收入的一个关键因素。

“酒店管理系统”代表了酒店管理的信息化，不仅是体现酒店现代化形象的一个重要标志，而且对于提高员工工作效率，加速资金周转、降低各项成本及改善服务质量都有十分积极的作用。

2.2 产品的描述

一个成熟的酒店管理系统不仅仅是记录酒店客人的信息，提供查询，报表打印等一 系列简单的工作，它能让工作人员从烦琐的手工操作中解脱，并且酒店管理系统本身就 代表着一种管理方法。随着它的深入，将带动企业的运作，为管理和决策提供支持。本项目在经过对各酒店软件进行分析和研究后，参考国际上的先进酒店软

件管理思想，结合中国酒店的实际特点，认为可将整个酒店管理系统细分为五个子系统：（1）前台管理系统（2）消费管理系统（3）收银管理系统（4）客房服务系统（5）系统维护

2.3 用户类和用户特性

酒店前台工作人员（优先考虑）：前台服务员的主要职能是负责订房和退房，以及查询入住的客户信息。所有该角色只可以使用部分功能，包括客房经营管理、客户信息查询、个人密码修改以及注销功能。前台工作人员对客房信息进行管理，包括对客房的基本信息(如客房号、客房类型客房位置等)进行检索、录入和修改。工作人员根据酒店规定可 定义客房类型，并对其进行管理，包括对客房类型的基本信息(如类型名称、面积、床位、价格等)进行检索、录入和修改系统。界面会自动显示各种房类的订房情况，以方便前台接待控制房态。按客人姓名系统可自动调出回头客信息 及历次住店统计信息以确定房价优惠、优惠时段和客人具体的消费记录等。

酒店管理人员：酒店管理员享有最高权限，可以使用酒店客房管理系统所提供的所有功能，包括员工信息维护、客房类型维护、客房信息维护、客户信息查询、经营状况统计、个人密码修改以及注销功能。

顾客：顾客可以在酒店提供的网上酒店管理系统进行自助查询酒店的一些相关信息，以及预定客房等。

财务管理部门：根据酒店客房的业务记录，酒店财务管理部门的工作人员可选择客房类别和日期的统计方式对营业额进行统计。他们需要接受培训，学会如何让使用计算机以及一些office应用。

酒店房务服务人员：酒店的房务服务人员利用系统可看到系统根据自家酒店的实际情况按顺序房号列出客房，很直观地显示客房所属的房间类型及用图形及颜色表示不同的房态，有没有顾客入住、退房等，客房需要什么样的服务，是否需要打扫、服务。

2.4 运行环境

为了达到系统要求，必须依靠高起点的硬件环境和软件开发工具来保证系统的稳定和正常运行。酒店电脑系统要求24小时连续运行，数据量大，可靠性要求高，因此整个电脑系统供电采用专线方式，加配lips（不间断供电系统），并合理接地，以便保障整套系统的正常运行。

2.5 设计和约束条件

CO-1:部分子系统将使用酒店本来的业务流程。

CO-2:系统必须操作简单、用户手册通俗易懂。

CO-3：该服务器实现要使用由公司批准的Red Hat Linux版本和Apache HTTP Server.2.6 假设和依赖

AS-1: 酒店拥有一台打印机和传真机，能方便打印报表，以及对预定客房的商务传真进行处理。

AS-2: 酒店有链接外网的服务器或计算机，能提供网上预定功能，方便顾客预定。DE-1: 对于经常光顾或要求打折的顾客以及节假日或者店庆优惠活动，应具备折扣管理功能。

DE-2: 对于使用酒店管理软件前的电话预定等，该管理软件应该有专门的录音功能。

3.外部接口需求

3.1 用户接口（User Interfaces,UI）

UI-1:入住登记界面应包含：部门，可选设施图标区，宾客登记信息区，选定设施列表。

UI-2：消费点单操作界面应包含：部门选择，总账单列表区，子账单列表区，消费记录区，消费品选择区。

UI-3:外卖零单消费界面应包含：消费品选择区，消费记录区，支付方式选择区。UI-4:在退房结账界面应包含：部门选择，总账单列表区，子账单列表区，消费明细表，结账操作面板。

3.2 硬件接口（Hardware Interfaces,HI）

HI-1:采用基于超5类双绞的综合布线系统，同时支持语音和数字的传输。HI-2：对机器的指示是：CPU2400转以上，显示器支持800*600分辨率，基本内存512兆推荐2G，Windows兼容打印机。

3.3 软件借口（Software Interfaces,SI）

“人事管理系统”。“人事管理系统”通过程序界面与“酒店管理系统”进行通信，完成下面这些工作：

1：提取人员业务完成情况，作为进行绩效考核的依据。

2：根据酒店管理系统中各部门的项目消费情况，作为合理分配人员的依据。

3.4 通信接口（Communications Iterfaces,CI）

CI-1：“酒店管理系统”接收熟客的电子邮件预订，由操作员将预订信息输入系统。

CI-2：“酒店管理系统”将向宾客发送电子邮件消息，以确认收到预订或者预订失败信息。

4.系统特性

4.1 前台管理

（1）描述和优先级

为住店客人提供预订信息，并为顾客办理登记入住手续，将登记信息录入电脑。并可以为客人增加房间，更换房间，还能根据操作员的权限不同，对客人登记信息及房间价格加以修改，提高系统的灵活性，满足不同客人的要求。

（2）刺激/响应序列

预定

刺激：选择客人准备预约登记的部门，如客房…等，点击“新增预订”。响应：系统给出预定登记区。

刺激：在预订登记区填入相关信息、选择具体需预订的设施项目及数量。填写无

误后按“保存”按钮。

响应：系统记录预定信息，并返回预定成功。刺激：反之选择“取消”按钮。响应：系统取消预定。

入住登记

刺激：进入“接待画面”后，先选择当前需接待登记的部门，如：客房、餐饮…．．

再选择设施规格，默认状态下是“标准”。

响应：建立客户消费帐，为每位客人安排一个房间、床位、桌号、牌号、及其他相关登记类型索引记录。

刺激：选择和填写完毕，按“确定”按钮。响应：完成接待操作。

刺激：按“取消”按钮。响应：取消所有操作。

顾客换房

刺激：进入“登记调整”界面，响应：系统调出所有已登记宾客和空余设施。

刺激：首先选择需调整宾客当前所登记的“部门”，在界面“原登记”列表框内移动光标选择需调整的宾客。在“设施列表”中选择想调换的设施。按“调换”按钮。

响应：完成调换。

刺激：按“取消”按钮。响应：取消所有操作。

追加登记

刺激：进入“追加登记”界面，在客人列表框内直接移动光标选择需追加登记的客人。

响应：系统调出该客人已登记的项目。

刺激：在“可供追加项目”列表框内双击鼠标添加新的项目到该宾客资料中，点击“确定”。

响应：系统更新该客人的已登记记录，并返回追加成功。刺激：选中追加项目，通过点击“—”取消追加。响应：系统将新追加项目从该宾客资料中移除。刺激：按“取消”按钮。响应：取消所有操作。

4.2 消费管理

（1）描述级和优先级

根据客人需求，为已登记在店客人提供店内能提供的消费服务，并自动建立消费档案。每位顾客发生消费前必须进行登记，需要建立客户帐，然后是顾客在酒店里进行了各种消费，例如：就餐点菜、会议室的租用、沐浴按摩、酒水消费等等，将这些消费信息录入在客户帐上，对这些消费进行管理满足顾客不同的消费。

（2）刺激/响应序列

点单

刺激：进入“总帐单列表区”界面，通过移动上下键或直接用鼠标在此区域选择需

要消费的客人，或者直接在“定位框”中输入需要消费客人的编号或姓名直接进行定位选择客人，选定客人，点击客户姓名。

响应：弹出选定顾客的消费总账单，包含总帐单下的所有子帐单。子账单也会并行

显示在“子帐单列表区”。

刺激：根据客人的需求通过移动上下键或直接用鼠标在此区域选择具体子帐单人，点击进入。

响应：系统进入选定顾客的消费品选择区，系统并行弹出消费品选择区和消费记区界面。

刺激：先选择消费品所在部门，然后根据该部门所提供的消费品列表双击某消费品 或按［添加］按钮。

响应：系统添加该客人的本次消费品记录，并返回添加成功。

刺激：所有消费品点单完成后，按“保存”按钮。

响应：系统将本次操作所产生的消费额记录在该客人的帐单数据表中，并生成消费

品记录单反馈到消费服务部门，提示服务人员提供消费服务。

外卖

刺激：先选择消费品所在部门，然后根据该部门所提供的消费品列表双击某消费或 按“添加”按钮。

响应：系统添加该客人的本次消费品记录，并返回添加成功。

刺激：所有消费品点单完成后，在顾客支付方式选择区，根据客人的支付方式，如：

现金、支票、信用卡…等支付方式，进行选择，按“保存”按钮。

响应：系统即刻将消费记录在消费记录区等待顾客付费并弹出提示框，提示客人进 行付款。

刺激：点击“付款”按钮，输入顾客已付款数额。响应：弹出应找零金额。

刺激：点击“付款完成”按钮。

响应：系统即刻生成客人消费记录单反馈到服务部门，弹出提示框服务人员提供服务。

查单

刺激：进入“消费查询（未结帐）”界面后，选择需要查询的部门，如选择：进店 日期、消费部门这两个项目，点击“确定”按钮。

响应：系统确定所查询的范围，弹出客人列表框。

刺激：在画面左边的客人列表框中移动光标，进一步确定某位客人的具体“消费明 细”和“收银明细”情况。通过鼠标点击“消费明细”和“收银明细”页框。

响应：系统显示“消费明细”或“收银明细”页面。

刺激：可再进一步用鼠标点击“只显示电话费”明细。

响应：系统显示电话费明细信息。

4.3 收银管理

（1）描述和优先级

每一个客人从入住房间起，系统就需要自动产生该客人的帐号，住店的客人享受酒 店的短期贷款，可以在酒店绝大部分签单，这将刺激客人的消费心理，增加酒店收入，酒店管理者还应可根据客人的情况锁住其帐号，以限制其消费。

前台收银的埋单应允许客人一帐多单，分期埋单，分类别埋单，退房时能自动检测：客人的帐务余额为零；客人帐号的帐项为空；否则不能退房。

系统还应具有合并、分拆帐户的功能，既不但可以把几个帐号的消费转入另一帐号，也可把某一帐号特定时期特定几类消费转入另一帐号，便于满足客人的多种结帐要求。

细分为如下四个需求：退房结帐、取消结帐、合并帐户、订金管理。（2）刺激/响应序列

退房结账

刺激：客人提出退房结账申请。响应：系统给出退房结账界面。

刺激：在“总账单列表区”选择登记客人、在“子账单列表区”选择该客人账目下项目。

响应：系统在“消费明细表”区域显示“待结账客人列表框”或“子客列表框”中光标焦点所指客人的记录，在“结账操作面板”中显示结算金额、已收金额，计算出实际收款。

刺激：选择付款方式、付款。

响应：系统更新数据库，提示结账成功。刺激：按“取消”按钮。响应：取消所有操作。

取消结账

刺激：客人登记后随即提出“退单”。

响应：系统给出退房结账界面。

刺激：在“退房处理”处打勾，点击结账按钮。

响应：完成取消结账操作，其所有消费不作营业额统计。刺激：按“取消”按钮。响应：取消所有操作。

合并账户

刺激：选择需要合并帐单的客人所在的部门。响应：系统调出所有已登记宾客的账户信息。刺激：在 “已登记在店客人”列表框内移动光标或直接用鼠标指定客人，也可在“已登记在店客人”文本框内输入宾客姓名或房间编号迅速查找定位相关宾客。“已登记在店客人”列表框内按回车键或双击鼠标。

响应：将当前光标所指的客人记录移动到“合并区”列表框。刺激：重复操作，选择另一位需合并的客人。

响应：将当前光标所指的另一位客人记录移动到“合并区”列表框。

刺激：在“合并区”移动光标，可确定合并后以哪个帐单号作为合并后的帐单 号。点击“合并”按钮。

响应：系统将合并的账单存储到合并后账单号下，另一个账号账单清空，并提示合并成功。

刺激：按“取消”按钮。响应：取消所有操作。定金管理

刺激：在“客人列表框”，通过直接用鼠标在此区域选择欲缴款客人。也可 以在“定位框１”中输入客人的编号或姓名直接进行定位选择欲缴款客人。也可在 “子帐单列表区”直接接用鼠标在此区域选择的欲缴款客人。响应：根据选择的客人，其账户作为缴款账号。

刺激：在“单据编号”文本框中输入收款单据号（“单据编号”文本框为可选项，可通过“需要单据号”是否打勾确定）。

响应：根据单据号调出客人信息，作为缴款账号。刺激：选择“付款方式”，系统默认付款方式为“现金”。响应：等待输入现金金额。

刺激：在“续缴金额’框中输入具体金额。点击“确定”

响应：系统将定金信息存储到该客人的账单号下，并提示缴纳定金成功。刺激：按“取消”按钮。响应：取消所有操作。

4.4 客房服务

（1）描述和优先级

酒店提出需要一个专门的子系统用于客房部检查客房等项目设施状态，根据多家酒店调研得出，通常将客房分为五种状态：清洁、有客、清理中、待修理和有预约，在电脑系统中应以五种图标代表。为增加灵活性，可以对其进行修改或调整。客房部根据电脑中的资料对脏房进行清洁，并能将清洁后的房态更改为清洁房。也可将部分房态改为待修理，使前台不能出售此类房间。可显示各部门的设施利用率，对已离店宾客的详细情况进行查询或打印。

（2）刺激/响应序列

房态管理

刺激：光标在“接待状态表”主画面上，直接用鼠标点击图标来选择设施，如果该设

施状态为：“有客”。

响应：系统在界面右下部会显示使用该设施客人概况。

刺激：在房态标示为“有客”图标上双击鼠标左键。

响应：系统弹出该客人的基本情况表。

刺激：点击右键。

响应：系统弹出一菜单，供选择改变当前指定设施的状态。

刺激：如果改变了当前客房的房房态。

响应：被改变客房的房态图标下面的文字变为红色文字。

刺激：进行的更改完成，按“保存”按钮完成保存操作。

响应：系统自动进行保存。

员工留言

刺激：系统界面设计有员工留言窗口，员工登录留言。

响应：系统提示员工输入登录用户名。

刺激：员工输入用户名点击登录。

响应：系统界面跳转到员工留言窗口输入框。

刺激：员工进行留言输入，点击完成发表。

响应：系统将员工的留言进行记录在员工留言数据表中。

刺激：操作员登录留言窗口进行查看时，如有“未接受”留言一提示，点击查看。

响应：系统将“未接受”留言从数据表抽取出来显示在界面上。

刺激：操作员查看完留言，进行回馈，点击“完成”按钮。

响应：系统将状态为“未接受”留言改为“已接受”留言。将操作员的回复信息显示在员工留言窗口。

设施利用统计

刺激：系统有一个查看酒店各部门的项目设施利用率，出租率情况的界面。酒店员工点击查看。

响应：系统弹出输入员工ID号的输入框。

刺激：员工输入自己的ID号，点击“确定”按钮。响应：系统判断此员工是否有查看的权限。

刺激：如果有，系统弹出选择框，选择需查看的酒店部门，点击“确定”按钮。响应：系统弹出员工确认查询的酒店部门项目设施利用率以及出租情况。

刺激：如果有部门项目设施利用率发生变化，员工要求更改记录，点击“修改”按钮。响应：系统再次要求输入员工身份认证密码，弹出密码输入框。刺激：员工输入密码，点击“确认”按钮。响应：系统进行确认是否有修改权限。

刺激：如果有修改权限，进入设施记录修改界面进行修改，修改完成，点击“保存”按钮。

响应：系统将新的记录保存在酒店各部门的项目设施利用率，出租率报表中，进行更新。

客史资料查询

刺激：系统有一个“登记人信息”界面，移动鼠标选择要查询客人的姓名，点击“确定”。

响应：系统弹出输入酒店工作人员ID号的输入框。刺激：工作人员输入自己的ID号，点击“确定”按钮。响应：系统判断此员工是否有查看的权限。

刺激： 如果有，系统弹出进入指示，提示工作人员选择进一步要查询某位客人的信息

类别。

响应：系统根据员工的选择弹出需查询某位客人具体的登记情况。

刺激：在“其他人信息”区中移动光标，选择进一步确定某位客人的查询。

响应：系统根据员工的选择弹出需进一步查询某位客人的具体情况。

刺激：有一个“登记人信息”界面，点击“查找按钮”。

响应：系统弹出的“查找窗口”。

刺激：输入“姓名”、“住址”和“证件号”，点击查询。

响应：弹出查询客人信息。

5.其他非功能需求

5.1 性能需求

PE-1：当查询空余项目时，系统的响应时间不能超过2秒。

PE-2：用户向系统提交信息后，系统将在1秒钟内向用户显示确认信息。

5.2 安全性需求

SE-1：用户安全性需求：

（1）限制不必要的用户。经常检查系统的用户，删除已经不再使用的用户。

（2）创建两个管理员账号。创建一个一般权限用户用来处理一些日常事物，另一个有管理员权限的用户只在需要的时候使用。

（3）开启用户策略，分别设置复位用户锁定计数器时间为20分钟，用户锁定时间为20分钟，用户锁定阈值为3次。

SE-2：密码安性需求：

（1）使用安全密码，注意密码的复杂性，还要经常改密码。（2）设置屏幕保护密码。

（3）开启密码策略。设置密码长度最小值为6位，设置强制密码历史为5次，时间为3天。

SE-3：系统安全性需求：

（1）安装防毒软件，经常进行系统扫描并升级病毒库。（2）关闭默认共享。

SE-4：服务安全性需求：

（1）关闭不必要的端口。用端口扫描器扫描系统已开放的端口，确定系统开放的哪些服务可能引起黑客入侵。

（2）设置好安全记录的访问权限。安全记录在默认情况下是没有保护的，把它设置成只有管理员和系统账户才有权访问。

（3）要把一些重要的用户数据（文件、数据表、项目文件等）定时备份在另一个安全的服务器中。

5.3 软件质量需求

Available（可用性）-1：“酒店管理系统”将具备每天24小时可用。

Robustness（健壮性）-1：如果在缴纳定金或退房结账时客户机和服务器中断，那么当时的操作全部视为无效，系统不记录到数据库。

6.附件

附录 分析模型

图1是酒店管理系统用例图。用例视图是表示整个系统需求。这个用例视图反映了：参与者为系统管理员（总经理）和各部门经理，用例为各部门子系统，除了系统管理员（总经理）能与所有的用例进行通信外，每位部门经理只能与一个用例进行通信。

图2为酒店管理系统的局部DFD图。