软件管理工作总结

软件管理工作总结（精选8篇）

软件管理工作总结 篇1

软件项目管理这门课程是我们软件工程专业学生的一门重要的课程，这门课程的开设必有其重要性。软件项目管理的提出是在20世纪70年代中期的美国。由于开发项目不能按时提交、超出预算、质量达不到用户的要求等原因，70%的项目出现问题。于是，软件开发者开始逐渐重视软件开发中的各项管理。软件项目管理和其他项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。因此，项目管理对软件生产具有决定性的意义。

只有相信团队合作才可能把项目做到最好，从整个项目的过程来看，团队合作中需要沟通、分工、协作和监督。只有做好这四项才算是一个好的合作团队。首先，团队合作最基本的技能就是沟通。沟通的目的就是让别人了解你的想法，因为每个人考虑问题的时候总会有各种各样的偏差，我们只有沟通很好的沟通来综合所有人的好的想法，以减少走弯路，而让事情进行的更顺利。因此我们也开了几次会议来互相了解沟通，当然最重要的是与项目经理的沟通。会议中他很认真负责地跟我沟通，我在沟通中用词不当或犯什么错误时，他都会指出来，并改正我的说法，因此单从与他的沟通中就学到了不少以后工作时将会用到的实在的知识。我们项目每人都是按照他给我们的计划提交相应的文件给他，但质量是参差不齐的，他都会进行审核，然后给出建议，让我们修改优化后，他才会通过。

软件管理工作总结 篇2

关键词：设计模式,MVC,单例模式,页面控制器

0 引言

软件项目开发的一个难点是用户需求的变化导致后期功能代码的扩展和维护, 软件项目管理的一个难点是团队成员间的协作和沟通。设计模式 (Design pattern) 是一套被反复使用、多数人知晓的、经过分类编写的、代码设计经验的总结。遵循设计模式的解决方案, 有助于功能的扩展和代码的维护。设计模式是面向对象程序设计的精华, 让对象和对象的关系清晰了起来, 使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式是按场景进行分类, 便于团队间的沟通。本文以工作任务管理系统为例, 讨论几种常用软件模式在信息管理系统开发中的应用。

1 设计模式分析

1.1 MVC模式

MVC是个将一个应用的实现分成三个组件角色的框架技术:模型, 视图和控制器。 (1) 在基于MVC的应用里, Mode l (模型) 是负责保持状态的应用组件。这个状态通常都持久于数据库之中 (譬如, 我们也许会有一个Product (产品) 类用来代表SQL中的Products数据表中的订单数据) 。 (2) 在基于MVC的应用里, Vie w (视图) 是负责显示用户界面的组件。这个UI通常是使用模型数据来创建的 (譬如, 我们也许会生成一个Product“编辑”视图, 根据当前Product对象的状态, 显示文本框, 下拉框和复选框等) 。 (3) 在基于MVC的应用里, Controller (控制器) 是处理用户交互, 操作模型和最终选择用哪个视图来显示UI的组件。在MVC应用中, 视图只是用来显示信息而已, 是控制器来处理和回应用户的输入和交互的。使用MVC方法的一个好处是, 它有助于促进应用中模型, 视图, 控制器间的关注的清晰分离。保持关注的清晰分离使得对应用的测试极其容易, 因为不同应用组件间的契约的定义和表达是更明确的。

1.2 页面控制器

使用页面控制器模式接受来自页面请求的输入、调用请求对模型执行的操作以及确定应用于结果页面的正确视图。分隔调度逻辑和所有视图相关代码。如果合适, 创建用于所有页面控制器的公用基类, 以避免代码重复并提高一致性和可测试性。页面控制器可接收页面请求、提取所有相关数据、调用对模型的所有更新以及向视图转发请求。而视图又将根据该模型检索要显示的数据。定义独立页面控制器将分隔模型与Web请求细节 (例如会话管理, 或使用查询字符串或隐藏表单域向页面传递参数) 。

1.3 单例模式

单例模式的特点: (1) 单例类只能有一个实例; (2) 单例类必须自己创建自己的唯一实例; (3) 单例类必须给所有其它对象提供这一实例。

Single ton模式包含的角色只有一个, 就是Single ton。Single ton拥有一个私有构造函数, 确保用户无法通过new直接实例它。除此之外, 该模式中包含一个静态私有成员变量instance与静态公有方法Instance () 。Instance方法负责检验并实例化自己, 然后存储在静态成员变量中, 以确保只有一个实例被创建。

2 工作任务管理系统的设计模式应用

2.1 工作任务管理系统体系结构

工作任务管理系统的体系结构如图1所示, 图中的箭头表明了信赖关系。在物理上, DAL是公共的数据访问入口层, BLL用来封闭业务实体对象, BIN是经过编译后的逻辑控制代码, Web文件夹下是按功能划分的视图文件。用户与《View》下的视图文件进行交互, 控制数据的显示和接受用户的输入;《View》中的数据来源于《Controller》, 《Controller》负责维护《View》的状态和数据的呈现, 以及将《View》传递过来的数据对象化, 并调用对象方法实现相应的业务逻辑获得数据;《Model》中包含实体的集合, 对应于业务规则, 是数据库表数据和数据增、删、改、查操作的抽象, 实体以类的形式存在, 业务以类方法的形式进行实现, 《Model》从业务规则的层面处理数据, 它是《Controller》数据的供应商。

工作任务管理系统中使用了MVC结构后, 在开发时, 项目组成员间职责明确, 美工和网页设计师只需要关注《View》的设计和HTML实现;数据库设计人员只需要关心数据库的设计以及数据的转换规则;模型人员只需要从业务的角度关注业务规则的实现和从数据库到实现对象的转换工作;而程序只需要关注利用模型的业务规则控制处理《View》的数据显示和输入就可以了。这样做, 非常有利于项目的管理和分工协作。

另外, 到了开发的后期, 需求分析的变化, 导致业务规则的重整, 只需要在现在代码基础上增加一些实体类就可以了, 便于系统的扩展。

2.2 页面控制器

在工作任务管理系统中, 《Vie w》分为两种, 一种是无需授权任何人都可以访问的页面, 称之为通用页;一种是需要用户登录, 特定用户才有权访问的页面, 称之授权页。《View》只是简单的以HTML的方式显示, 由浏览器解析, 否能访问由页面控制器来控制的, 即《View》对应的后台代码。在默认情况下, 所有的布面控制器都继承于System.Web.UI.Page类, 要实现权限控制必须在所有的页面控制添加控制代码, 这用做非常的麻烦, 而且不利于代码的后期修改和扩展。针对于这种需求, 页面控制器设计模式提供了一种非常好的解决方案, 如图2所示。

定义一个基类Bas e Page, 继承于Syste m.We b.UI.Page, 是系统中所有页面控制器的基础;从Base Page下派生出GenPage和AuthPage两个类, 分别用作于通用页和授权页的父类。在授权页的构造函数中, 实现OnLoad事件的订阅, 在OnLoad的事件处理程序中添加权限控制代码, 所有的授权页都从AuthPage派生出来, 这样在派生页控制器中, 就无需写权限控制代码了。在后期代码的扩展过程中, 只需有修改父类的代码就可以, 而不是每个页控制器的代码。

2.3 单例的数据连接对象

数据连接是系统中非常宝贵的资源, 如果一个数据库系统中存在着多个连接对象, 并且这些对象没有及时释放, 系统的性能将会急剧下降。一个好的设计是, 在一个系统中数据连接应该是唯一的, 单例的, 如图3所示。Cnn是DBAcce s s的一个静态成员, 并在静态构造函数实例化。这样, 不论DBAcce s s有多少个对象, 数据连接对象便只有一个了。

3 结论

设计模式是设计经验的总结, 在系统设计过程中合理地使用一些经典的设计模式, 是十分有利于系统功能的扩展和代码复用的。在工作任务管理系统中, MVC模式使得系统的结构清晰, 有利团队的分工合作;页面控制器模式降低了代码的冗余度, 提高了代码的重用性, 方便了功能的扩展;单例模式实现了数据连接的唯一性, 提高了系统的性能。

参考文献

[1]钟金琴, 辜丽川.一种面向对象的软件设计模式库的设计.计算机技术与发展[J], 2008[.9]:22.

刍议计算机软件维护管理工作 篇3

摘要：计算机在生活中的应用越来越广泛，人们对计算机的要求也越来越高。为此，许多计算机生产研发商家相继提出了计算机软件管理与维护的技术和体系，从而提高计算机的性能和工作效率。本文通过分析计算机软件管理中存在的问题，归纳出了软件工程维护和管理的措施，希望能对日后计算机软件管理升级起到一定的促进作用。

关键词：计算机软件；维护管理

1计算机软件项目管理的主要内容

1.1员工管理。计算机软件工程的设计和管理都需要专业技术人员的参与。作为一项高科技工程项目，软件工程管理对于相关管理人员的技术要求很高，工程人员必须熟练掌握计算机操作使用的技术，同时具备数据整合分析的能力。为使计算机软件管理工作顺利完成，软件工程人员应首先提高自己的思想觉悟，增强工作责任感，在工作中与其他部门人员积极配合，努力保证每一个管理环节的质量。与此同时，软件工程人员还应不断提高自身专业素质，积极学习新兴计算机工程技术，为管理工作的开展打下基础。

1.2用户管理。软件开发的最终收益者是广大用户，因此在软件开发过程中也应充分考虑用户需求。为完善后期管理工作，相关管理人员应在前期就与用户保持积极联系，充分了解和调查用户对计算机软件的要求。在软件投入使用的过程中，工作人员也应做好用户信息的反馈工作，并对问题较大的部分进行及时整改，充分保证软件的实用性，满足用户的使用要求。

1.3组织管理。计算机工程也属于信息工程，其主要工作内容是处理并传递大量的数据信息。为了保证信息传递的准确性，必须对信息进行高效、完善的组织。相关技术人员首先应对数据有一个整体的把握，并形成数据组织的一套系统，在进行数据整合时遵循整体按照系统进行，局部根据实际调整的原则进行。软件在应用时具有一定的风险性，针对软件工程的潜在风险，实行风险管理，避免其在应用中，表现出低度的安全性能[1]。规划软件工程中的风险管理，最主要的是建设风险管理制度，强调风险意识。首先建立风险管理制度，清晰识别软件工程研发过程中的风险因素，规避软件风险，实时保护软件工程的应用；然后加强风险控制，对运行周期比较长的软件，实行风险控制，将风险机制引入到工程内部，降低工程运行过程中的损失，控制风险于安全范围内；最后推进软件的开发管理，结合软件工程的实际应用，记录软件工程开发与应用的详细内容，合理监督工程运行，保障工程处于零风险的运行状态。例如：通过管理制度，清晰识别软件由开发到使用的风险因素，深入研究开发阶段，重点在编程、试验方面进行风险分析，控制开发风险，设定软件空间，提高软件读取、运用的能力，同时跟踪软件应用，在软件应用中，设置风险跟踪系统和反馈系统，风险跟踪主要是监督软件应用中遇到的风险，进行远程处理；风险反馈则是根据用户在线使用，针对出现问题实行及时反馈，软件开发者根据反馈风险，规避处理。

2计算机软件项目的管理问题

2.1用户需求与实际管理中存在较大差距。基于计算机工程的复杂性，用户对计算机软件的使用需求有很大一部分在实际操作过程中无法达成。造成这一原因的因素除了技术限制等方面的客观原因，还有管理人员操作不规范、数据统计不够完整等因素。其次，由于我国计算机软件管理领域尚未形成一个完善的体系，导致技术人员在操作时有很大的随意性，使得用户需求与实际软件功能有较大出入。

2.2对工作量估算的误差。计算机系统要处理的信息数据相当庞大，数据间关系又十分复杂。为高效的完成计算机软件管理工作，技术人员必须首先对信息数量量进行较为准确的估算，从而对数据管理工作投入适宜的人力和物力。对工作量估算的误差将会极大地影响到计算机工作的效率。人为的因素是导致误差产生的主要因素。技术人员对数据的处理方式、后期的校对整改工作都将极大地影响数据量的准确度。因此，有许多估算误差都可以通过后期的核查避免。软件工程人员必须首先端正工作态度，其次应制定一套完整的数据量估算体系，从而提高数据估算的效率和准确性。

3计算机软件管理的方法和措施

3.1提高软件工作效率。信息化时代，各产业的相关理论技术都在进行革新，对于高科技信息产业的计算机工程更是如此。原有的前台软件控制方法在不断发展的计算机系统下已经不再适用，网络开发商逐渐使用工作效率更高的数据库管理来代替传统的软件控制系统。在这种管理系统的控制下，软件运行的速度和效率都有了明显的提升，在未来这种管理系统应获得更广泛的应用。

3.2建立健全的计算机软件管理制度。对计算机软件系统的管理可以分为几个方面。首先是相关技术人员的管理。高科技人才是21世纪最重要的资源。在软件管理领域，具备专业知识和技术的工程人员应受到更多的关注和重视。同时，相关部门应加强对技术人员的培养，并制定相关的措施调动工作人员的工作积极性。其次是对高层监管人员的管理。对于监管人员也应要求具备一定的专业知识，在软件管理问题发生时能及时地做出应对和调整。同时建立完善的监管体制，为监管人员的工作提供依据和参考。

3.3建立统一软件开发平台。建立统一的软件开发平台有利于资源的共享和数据管理。目前，在我国还尚未有一个完善统一的管理平台，相关部门和技术人员可以借鉴国外发展经验，积极推进平台的建立，为计算机软件的开发管理提供一个更好的技术支持。

3.4加强软件工程的风险管理。软件的开发也存在着一定的风险，要有效地规避风险可从以下几个方面着手。首先应进行有效的需求分析。需求分析阶段的风险主要产生与用户要求与软件实际功能的误差。当用户要求达不到满足时，软件开发商必须在原有的软件功能基础上进行整改，从而造成了人力物力资源的浪费。为避免这种现象，软件开发商应在前期做好与用户的沟通工作。其次，技术工作人员必须保证软件开发的进程。计算机行业产品技术的更新速度快，软件开发一旦更不上市场需求就会很快被市场淘汰，为此技术人员必须保证软件开发的速度。

结语：

学习软件项目管理总结 篇4

这学期通过宋老师讲授软件项目管理这门课程，自己学到了很多东西。最初在单位做设计是一个盲目的过程，无计划、无框架设计，拿来需求大家把模块分摊，就开始埋头写代码，总认为设计代码是最重要的事情，但是经过几次尝试，每次做出的东西不是很理想，自己也不知道原因为什么会不理想呢，自己做的东西是按领导拿来的需求书上的要求做的，可为什么用户不满意呢。

通过学习软件项目管理这门课程后，我知道我们做开发失败的问题了。我自己总结了几点：

一、项目接到手，没有根据软件项目开发的流程进行分析、设计。

二、项目需求说明书、概要设计说明书、可行性报告、详细说明书、数据库设计说明书、软件详细设计说明书，测试报告这些文档东西应该是在设计过程中产生的，但我们工作中都是软件做完了，为了项目的验收急急忙忙赶制出来的。这些说明书已经失去了他们的意义。

三、人员的配合、管理也是很重要的。我们单位中领导就是项目经理，但是这个项目经理没有达标，有项目了他带领大家开会讨论，在会议上就把此项目的可行性和工作分工就安排好了。会下大家就埋头写代码，大家之间的交流也很少，直到模块要合并时，出现问题了大家才把自己的设计理念讲一下，再修改再合并。后期的修改合并工作是一个最费时的事情，把设计中的大多时间花在了这里，如果大家在最初按照流程走，定期交流，项目经理监控、督促就不会出现这样的事情。

四、做项目每个人员的态度认真也是很重要的。自己习惯了大企业中的慢生

活，我们开发软件都是快到项目验收了，才加班加点的工作，这样怎么能做出好软件呢。

宋老师还给我们布置了项目开发作业。我们小组设计了“时光网上商城系统” 我这次所经历的项目更让我明确了这点。在这个小项目里，虽然我们一个月完成了这个软件设计，但存在很多问题。“时光网上商城系统”包括9个模块，我在这个项目里，我参与了概要设计、详细设计、软件测试文档的编辑和会员管理模块、商品展示模块的设计。这两个模块的设计对于自己来说没有什么问题，因为在单位就是做这个的，但是在前期的概要设计说明和详细设计说明对自己有点困难，因为以前没有这样做过，没有什么设计框架，这时自己拿出宋老师讲的笔记和图书进行学习，再和队友交流，终于有了自己的框架。所以、在这个过程中我明确了技术的实在意义，明确了项目管理对我的指导，同时也明确了自己的今后项目开发应该怎样做。

整个项目进行的过程中，我一直在边学习边制作，每周与其他同学定时交流，整个过程我收获很多。

一、项目小组人员都职责明确，每周定时交流沟通工作进度，随时更新方便开发人员、测试人员之间的交流。

二、细致的计划可以让项目进行避免弯路。

三、项目经理时光的组织、督促和监督，小组人员的齐心，这个项目才顺利能完成。

四、这个项目制作把绕老师和陈老师讲的内容也都应用在初期系统构建和中期、后期的软件测试中。

五、通过学习认真分清了软件管理与软件工程的关系和项目管理知识体系。

软件项目质量管理实战总结 篇5

第一章 引言

许多IT项目开发的系统应用在生死攸关的场合。例如，1981年，由计算机程序改变而导致的1/67的时间偏差，使航天飞机上的5台计算机不能同步运行，这个错误导致了航天飞机发射失败。1986年，1台Therac25机器泄露致命剂量的辐射，致使两名医院病人死亡。造成惨剧的原因是一个软件出现了问题，导致这台机器忽略了数据校验。这些惨痛的教训说明，在软件开发项目中认真抓好质量管理，并加强有关软件项目质量管理的研究是摆在我们面前的重要课题。

软件项目质量管理包括：质量计划编制、质量保证和质量控制三个过程域。质量计划是质量管理的第一过程域，它主要结合各个公司的质量方针，产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略，其内容全面反应用户的要求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动，经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。质量控制是对阶段性的成果进行检测、验证，为质量保证提供参考依据，它是一个PDCA循环过程。

第二章 对软件项目质量管理理论的认识

软件项目的质量管理指的是保证项目满足其目标要求所需要的过程，它包括编制质量计划、质量控制、质量保证等过程。

2.1 质量计划编制

现代质量管理的基本宗旨是：“质量出自计划，而非出自检查”。只有做出精准的质量计划，才能指导项目的实施、做好质量控制。

编制项目的质量计划，首先必须确定项目的范围、中间产品和最终产品，然后明确关于中间产品和最终产品的有关规定、标准，确定可能影响产品质量的技术要点，并找出能够确保高效满足相关规定、标准的过程方法。编制质量计划通常采用流程图、因果分析图等方法对项目进行分析，确定需要监控的关键元素，设置合理的见证点(W点)、停工待检点(H点)，并制定质量标准：

1)流程图：

显示系统的各种成分是如何相互关系的，帮助我们预测在何处可能发生何种质量问题，并由此帮助开发处理他们的办法。

2)因果分析图(也称鱼刺图)：

对于复杂的项目，编制质量计划时可以采用因果分析图，描述相关的各种原因和子原因如何产生潜在问题或影响，将影响质量问题的“人员、设备、参考资料、方法、环境”等各方面的原因进行细致的分解，方便地在质量计划中制定相应的预防措施。其次，质量计划中还必须确定有效的质量管理体系，明确质量监理人员对项目质量负责和各级质量管理人员的权限。戴明环(又名PDCA循环法)作为有效的管理工具在质量管理中得到广泛的应用，它采用计划——执行——检查——措施的质量环，质量计划中必须将质量环上各环节明确落实到各责任单位，才能保证质量计划的有效实施。

2.2 按照质量计划实施有效的质量控制

质量计划确定后，按照其建立的质量管理体系，各责任单位就必须按照PDCA质量环的要求，实施有效的质量控制。质量控制应贯穿于项目的整个过程，它可分为监测和控制两个阶段：监测的目的就是收集、记录和汇报有关项目质量的数据信息;控制就是使用质量监测提供的数据，进行控制，确保项目质量与计划保持一致。

在质量监测过程中，对于质量计划中设置的见证点、停工待检点，质量监测人员要按照作业程序及时进行测量检查(其中对于停工待检点必须由监理人员签字认可后才能进入下一道工序)，以确定项目成果(或阶段成果)是否符合相关的质量标准。对于见证点或停工待检点要防止跳过检查，因为避免错误的成本总是大大低于补救错误的成本。对质量监测的结果应采用相应的统计方法进行分析，如帕累托图法(按发生频率排序的直方图，它显示了可识别原因的种类和所造成的结果的数量)等。通过统计分析对人员、设备、参考资料、方法、环境等影响项目质量的因素进行监控，确定项目实施过程是否在控制之中，同时进行趋势分析，对一些偏向于不合格的趋势及早进行控制。质量控制阶段应根据验收数据做出验收决定，确定是否进入下一步工序。对于质量监测中发现的不合格，应及时利用“因果分析图”等方法分析原因，并进行适宜的处置，保证不合格得到识别和有效的控制。不合格处置包括返工、返修、降级、让步放行、报废等形式。

质量监测分析时，对于已发现的不合格或潜在不合格，应制定相应的纠正措施或预防措施，以消除不合格或潜在不合格的原因，防止不合格的发生。纠正措施或预防措施制定后，应对质量计划进行相应的调整，保证项目的顺利实施。

项目收尾包括项目评估和项目终止两个阶段。项目收尾阶段的质量控制是一个非常重要而又容易忽视的内容。

项目质量评估不仅仅是在项目完成后进行，还包括对项目实施过程中的各个关键点的质量评估。项目质量评估看起来属于事后控制，但它的目的不是为了改变那些已经发生的事情，而是试图抓住项目质量合格或不合格的精髓，以使将来的项目质量管理能从中获益。

项目终止阶段，是在决策项目终止后，检查项目文件资料完备，包括项目施工质量验评表、竣工报告等，同时进行项目总结。项目总结是一个把实际运行情况与项目计划不断比较以提炼经验教训的过程。通过项目质量计划和总结，项目过程中的经验和教训将得到完整的记录和升华，成为“组织财富”。

四、项目质量管理的难点

每个项目的实施总是拥有同样的总体目标：质量、时间和成本。三者是一个相互制约、相互影响的统一体，其中任一项目标变化，都会引起另两个目标变化，并受其制约。如何合理的保证项目质量，正确处理质量与时间、成本之间的矛盾是项目质量管理的一个难点，这需要整合项目所有方面的内容，保证按时、低成本地实现预定的质量目标。

根据侧重点不同，项目可分为质量倾斜型、工期倾斜型及成本倾斜型体系。我们在编制项目计划时，一般而言是时间、成本、质量标准均已确定，在项目实施过程中就需在从客观因素、具体情况出发，根据将要采取的行动和可能导致的后果进行综合分析研究;按切合实际的原则，使项目进展平衡有节奏地进行，以求达到预期目标。避免出现工期紧张或成本减少，导致质量降低的现象，而质量下降又往往造成返工等后果而导致延长工期和增加成本。

2.3 对软件质量保证的认识

2.3.1 有关SQA的理论

我们都知道一个项目的主要内容是：成本、进度、质量;良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们知道 IBM的软件是以质量为最重要目标的，而微软的“足够好的软件”策略更是耳熟能详，这些质量目标其实立足于企业的战略目标。所以用于进行质量保证的SQA 工作也应当立足于企业的战略目标，从这个角度思考SQA，形成对SQA的理论认识。

软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。首先要明确的是这三个因素中，人是第一位的。

现在许多实施 CMM的人员沉溺于CMM的理论过于强调“过程”，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。“XP”中的一个思想“人比过程更重要” 是值得我们思考的。我个人的意见在进行过程改进中坚持“以人为本”，强调过程和人的和谐。

根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了 “要保证项目不失败，我们应当更加关注管理”，注意这个事实没有说明另外一个问题“良好的管理可以保证项目的成功”。现在很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。

如果我们考证一下历史的沿革，应当更加容易理解 CMM的本质。CMM首先是作为一个“评估标准”出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点：

(1)质量重要

(2)规模较大

这是 CMM产生的原因。它引入了“全面质量管理”的思想，尤其侧重了“全面质量管理”中的“过程方法”，并且引入了“统计过程控制”的方法。可以说这两个思想是CMM背后的基础。

上面这些内容形成了我们对软件过程地位、价值的基本理解;在这个基础上我们可以引申讨论 SQA。

2.3.2 生产线的隐喻

如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。

抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含 “决策、执行、反馈”三个重要方面。

QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动;它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

2.3.3 SQA和其他工作的组合

在很多企业中，将 SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。

国内现在基本有三种QA(按照工作重点不同来分)：一是过程改进型，一是配置管理型，一是测试型。个人认为是因为SQA工作和其他不同工作组合在一起形成的。

下面根据经验对它们之间的关系进行一个说明。

QA和QC ,两者基本职责;

QC：检验产品的质量，保证产品符合客户的需求;是产品质量检查者;

QA：审计过程的质量，保证过程被正确执行;是过程质量审计者;

注意区别检查和审计的不同，检查：就是我们常说的找茬，是挑毛病的;

审计：来确认项目按照要求进行的证据;仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的;对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。

对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息;QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。

在这样的分工原则下，QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有;而QC来检查产品是否符合质量要求。

如果企业原来具有 QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。

QA 和SEPG，两者基本职责。SEPG：制定过程，实施过程改进;QA：确保过程被正确执行。SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划;从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。QA本也要进行过程规范，那么所有QA中最有经验、最有能力的QA可以参加SEPG，但是要注意这两者的区别。

如果企业的 SEPG人员具有较为深厚的开发背景，可以兼任SQA工作，这样利于过程的不断改进;但是由于立法、执法集于一身也容易造成SQA过于强势，影响项目的独立性。

管理过程比较成熟的企业，因为企业的文化和管理机制已经健全，SQA职责范围的工作较少，往往只是针对具体项目制定明确重点的SQA计划，这样SQA的审计工作会大大减少，从而可以同时审计较多项目。

另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的 SEPG人员，这些人员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，这时了解全局的SQA人员就是专职SEPG的主要人选;这些SQA人员将逐渐的转化为SEPG人员，并且更加了解管理知识，而SQA工作渐渐成为他们的兼职工作。这种情况在许多 CMM5企业比较多见，往往有时看不见SQA人员在项目组出现或者很少出现，这种SEPG和SQA的融合特别有利于组织的过程改进工作。SEPG确定过程改进内容，SQA计划重点反映这些改进内容，从保证有效的改进，特别有利于达到CMM5的要求。从这个角度，国外的SQA人员为什么高薪就不难理解了，也决定了当前中国SQA人员比较被轻视的原因;因为管理过程还不完善，我国的SQA人员还没有产生这么大的价值。

2.3.4 QA和组织级的监督管理

有的企业为了更好的监督管理项目，建立了一个角色，我取名为 “组织级的监督管理者”，他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目的可视性、可管理性。为了有效管理项目，“组织级的监督管理者”必须分析项目的数据。他们的职责对照上图的模型，就是执行 “反馈”职能。

QA本身不进行反馈工作，最多对过程执行情况的信息进行反馈。SQA职责最好不要和“组织级的项目管理者”的职责混合在一起，否则容易出现SQA困境：一方面SQA不能准确定位自己的工作，另一方面过程执行者对SQA人员抱有较大戒心。

如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较好管理;而 QA来确保这个管理过程的运行。

2.3.5 SQA的工作内容和工作方法

2.3.5.1 计划

针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：

有重点：依据企业目标以及项目情况确定审计的重点。

明确审计内容：明确审计哪些活动，那些产品。

明确审计方式：确定怎样进行审计。

明确审计结果报告的规则：审计的结果报告给谁。

2.3.5.2 审计/证实

依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

2.3.5.3 问题跟踪

对审计中发现的问题，要求项目组改进，并跟进直到解决。

2.3.5.4 SQA的素质

过程为中心：应当站在过程的角度来考虑问题，保证了过程，QA就尽到了责任。

服务精神：为项目组服务，帮助项目组确保正确执行过程。

了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识。

了解开发：对开发工作的基本情况了解，能够理解项目的活动。

沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。第三章 软件项目质量管理在实际中的具体做法

3.1 质量管理责任分配

笔者曾在美国TAJ Technologies公司任软件工程师工作。TAJ Technologies公司(位于美国明尼苏达州，有约200名员工)在开发项目上按照规范化软件的生产方式进行生产，在生产流程上采用ISO9000 的标准进行。每个项目除配备了项目开发所需角色外，还专门配备了配置管理小组、测试小组和质量保证小组确保质量管理的实施，下面针对这三种角色进行说明：

3.1.1 配置管理小组职责

配置管理小组是保证项目开发完毕的同时，内部文档和外部文档都同时完成。内部文档的及时产生和规范，是保证项目开发各小组能够更好的接口和沟通的重要前提，从另一个方面讲，也是保证工程不被某个关键路径所阻塞而延滞的前提。如上所述，配置管理小组还是保证质量保证小组得以发挥作用的基础。配置管理小组的主要职责包括： 完善各个部门发送需要存档和进行版本控制的代码、文档(包括外来文件)和阶段性成果;对代码、文档等进行单向出入的控制;对所有存档的文档进行版本控制;提供文档规范，并传达到开发组中。

3.1.2 测试小组职责

测试小组作为质量控制的主要手段，负责软件的测试设计和执行工作。如同软件开发一样，测试在执行之前，同样需要进行测试计划和测试策略的设计，通常情况下测试可以分为如下几种类型，如：正确性测试、功能性测试、性能测试、安全测试和系统测试等。而这些测试均需要在测试计划和测试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。程序员在交给测试人员之前是进行过一定的单元测试，确保程序编译、运行正确。

测试人员根据详细设计的文档对软件要实现的功能进行一一测试，保证软件的执行正确的实现设计要求，在此也只证明了软件正确的反映了设计思想，但是否真正反映了用户的需求仍需要进一步的功能性测试。

测试人员只有根据软件需求规格说明书所提及的功能进行检测，才能确保项目组开发的软件产品满足用户需求。在正确性测试完成之后，需要测试的是软件的性能，软件的性能在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。如果有必要的话，测试小组还需要做安全测试，以确保系统使用安全可靠。

3.1.3 质量保证小组职责

质量保证小组作为质量保证的实施小组，主要职责是保证软件透明开发的主要环节。在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告，提出差异原因和改进方法。

在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时，提请项目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量保证是建立在文档的复审基础之上，因而文档版本的控制，特别是软件配置管理，直接影响软件质量保证的影响力和力度。质量保证小组的检测范围包括：系统分析人员是否正确的反映了用户的需求;软件执行体是否正确的实现了分析人员的设计思想;测试人员是否进行了较为彻底的和全面的测试;配置管理员是否对文档的规范化进行的比较彻底，版本控制是否有效。

3.2 质量管理实施

有了良好的资源配备，又如何在项目全生命周期内实施质量保证，让我们从以下几个方面来看质量保证的实施过程：

3.2.1 项目进度的质量保证

项目进度是项目进行是否顺利的最直观表现。显然在项目开始之前，项目开发计划是必须的。如果项目开发计划的制定的是完全合理的，那项目进度也就真正表达了项目与最终的交付使用之间的距离，然而要制定完全合理的项目开发计划几乎不太可能。可见要保证项目进度，首先要保证项目开发计划尽可能合理。

项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系，通过经验往往能够预见潜在的阻碍，这样要求项目计划制定者需要集众人之力来完善计划。

当项目计划制定初期，由质量保证小组组织召开的项目计划评审会，邀请公司技术专家、用户以及项目组小组成员一起讨论项目计划的可行性，会议通常采用头脑风暴法，各抒己见，会后由指定的记录员形成质量记录，发送给相关人员，对其计划中不合理的地方进行修改完善，并由质量保证人员对其结果跟踪，以确保项目计划完整性、可行性，完善后的计划交由配置管理人员进行版本控制。

然而在计划实施过程中，计划不是“固定化”。常有人道，“计划赶不上变化”，但“要跟上变化”。项目计划以里程碑为界限，将整个开发周期划分为若干阶段。根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，这种方式非常有利于整个项目计划的动态调整。也利于项目质量保证的实施。

实际运作中，当质保小组发现计划实施的差异后，报告项目经理，由项目经理组织负责对计划进行周期性维护，对于已经变动的计划由质保小组协助配置管理小组完成版本控制。

项目开发各阶段的质量保证

a、需求分析

需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。

解决系统分析错误的方法。TAJ Technologies公司通常采用邀请用户参与进行需求评定，然后对其用户的意见由质保成员跟踪检测是否纳入需求规格说明书，同时与用户签字确认形成需求基线，交由配置管理员放入配置管理库。

虽然尽早的邀请用户参与，仍然避免不了项目进行中用户的需求变更请求。对于开发过程存在的需求变动，我们要求用户填写变更申请单发送给项目配置管理员，在通过配置配置员转交质保小组，负责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影响，小的变更则直接记录入变更记录原因分析项和风险项栏，大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同步变更(包括需求规格说明书、详细设计文、安装手册、操作手册等)。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这时，我们将变更报告提交给用户或邀请用户进行协调会议，讨论变更取舍问题或是项目进度变更问题。

决定变更之后，由项目经理组织实施变更，测试人员检测变更结果，而质保小组成员监督变更实施过程并协助配置管理员对变更后的成果物进行版本控制。变更实施完后，上线前还需要指定人员协助用户一同测试并由用户签字后同意方可上线。

b、系统设计

优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，自然设计选型成为了系统设计首要的工作，究竟是采用哪种设计方法好呢?

对于设计选型不能一概而论，需要针对项目的结构、项目的特征和用户的需求来分析，同样也要考虑到参与项目小组成员的素质，如果其中大部分都没有从事过面向对象的设计且项目进对紧迫，这样没有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所周知面向对象设计方法的优势，我们还是不如采用面向过程的方式(除用户指定开发设计方式外)可以减少项目承担的技术风险。

TAJ Technologies公司有过一个项目，用户指定需要采用面向对象分析、设计和开发，且开发周期短，在无赖的情况下，项目小组只能选用面向对象的软件开发过程，由于项目小组很少从事过面向对象的开发，经验缺乏，导致项目上马后项目进度延误，项目没有达到预期的效果。

针对此次开发，我们分析其原因，发现小组成员在开发过程中对于新技术互相交流少，各自有各自的理解和想法，造成理解上的不一致性，导致工作重复性高，滞后项目进度。建议解决方法是项目组成员采用集中办公，分块学习，学习的成果马上向项目相关人员发布，再由配置管理员对其发布的文档进行整理、规类放入配置库以供大家共享。这样方便大家的互相学习，减少重复的工作。在这次开发中我们公司从管理人员、设计人员到开发人员都汲取了很多教训，同时经过此次项目的开发，小组成员也积累了丰富的面向对象的开发经验。

除设计选型，还有一个容易被忽视的问题，就是公共类开发。公共类开发可以减少工作中的重复工作，降低开发成本。这要求我们再设计阶段通过对用户需求的仔细研究，尽可能的识别出公共类，并进行定义指定专人负责设计通知其它设计人员，以减少重复工作。对于项目组提供的设计文档，由质保小组组织技术专家、项目组设计人员、开发人员和测试人员对其设计文档的评审，检测设计文档对其下一阶段工作的可行性，及时发现设计中可能存在的错误，降低项目开发风险，同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发，提供项目组或整个公司重用。最后交由配置管理员进行设计文档的版本控制。

c、实现

实现也就是代码的生产过程。这里不仅包括代码的产生，同时也包括测试用例的产生。针对上一阶段提供详细设计，程序员开始编码并且调试程序，测试人员则根据设计进行测试用例的设计，设计出来的用例需要得到项目组成员认可由项目经理审核通过才能进入配置库。同时程序员调试完程序提交测试人员进行程序正确性检测。

d、文档管理

文档维护主要是配置管理小组的工作。文档从用途上分主要分为内部文档和外部文档。

内部文档包括： 项目开发计划;需求分析;体系结构设计说明;详细设计说明;构件索引;构件成分说明;构件接口及调用说明;组件索引;组件接口及调用说明;类索引;类属性及方法说明;测试报告;测试统计报告;质量监督报告;源代码;文档分类版本索引;软件安装打包文件。

外部文档主要包括： 软件安装手册;软件操作手册;在线帮助;系统性能指标报告;系统操作索引。

如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个“ 度”的问题。

在本项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下“填空”的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。

配置管理小组真正核心的工作是对文档的组织管理。根据文档的不同，文档的来源也不同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。

从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。

3.2.2 系统维护质量保证

在TAJ Technologies公司，维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。

维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。

智信客户管理软件个人使用总结 篇6

智信客户管理软件采用以客户信息管理为中心的场景管理模式。帮助用户轻松管理日益增多的客户资源；给用户提供科学的发展潜在客户的步骤，按步就班，渐入佳境；客户的资料和联络记录永远在用户的手中，不怕销售人员流动；销售机会的进展和跟踪，一切进展尽在用户掌握之中；使用户的日程安排井井有条，时间分配更科学；可以通过报表，时时了解销售人员的时间精力都花费在什么客户身上；清楚了解每个客户的购买记录，销售业绩尽在把握；统计分析功能帮助您分析客户的分布、行业、类型、来源，为决策提供关键信息；邮寄信封标签打印功能，摆脱繁重的手工劳动；任意条件快速批量提取email地址，支持邮件群发，节省时间发展更多客户。

软件特色功能：

1、整个操作界面完全类似于 Office，支持不同界面之间的切换。

2、智信客户管理软件导入功能支持自定义选择列，在一个界面上就可以完成列的选择，功能强大但操作简单。

3、支持导出的格式有PDF图片格式，网页格式（htm，html），Excel。CSV等格式。

4、保留用户的常用操作习惯，例如窗体的界面位置等。智信客户管理系统提供了最为方便的自定义查询条件设置功能，查询条件完全由用户自定义设置。

5、软件全面详尽的客户资料及联系人信息管理，支持多联系人。

6、详细记录客户的销售记录和联系活动情况，销售数据一目了然。

7、完备的商品管理，商品分类支持无限分层，满足您的多种需要。

8、查询功能强大、方便、自然，而且如联系人姓名、单位名、商品名等，可以精确查询，也可以实现模糊查询。

9、智信客户管理系统，提供了目前市面上最为强大自定义报表设计。多种报表输出打印，您可以轻松打印客户资料，商品资料，销售单和客户信封标签。

10、各个业务、活动，均可指定管理员，由其负责，并可以按各管理员分别进行查询统计。

11、客户资料、商品资料支持直接从Excel数据导入；所有业务的列表均能方便的导出到Excel。

12、增强的权限管理，数据权限设定，可以设置为业务员互相之间不能查看联系人、客户信息，而经理可以看到下属的所有信息。

软件管理工作总结 篇7

随着我国的作战技术水平的不断提高以及装备跨越式软件的快速发展, 软件的规模越来越大, 数量也越来越多, 因此对软件的研制单位在开发软件的过程中所应用到的技术和工程也都提出了更高的要求.现阶段在软件的开发、研制和管理的过程中, 在软件研究以及对软件的质量管理与控制中也存在着诸多的问题, 主要有以下几点:

1.1 软件开发时的管理力度不够

软件开发部门的项目主管无法了解项目的具体进展情况如何, 项目中各个开发人员具体都是负责什么工作的, 项目负责人也不是十分的了解, 因此这就导致了项目进展的随意性很大, 开发的过程中没有团结协作的能力, 各个开发人员各自为政, 每个人编写的代码风格都是有很大的差异性的。而在软件的开发过程中, 本来就是会经常出现错误的, 如果相关的开发人员工作时不能够很好的进行沟通, 就会留下很多已经重复了的难以维护的代码, 同时开发出来的产品根本就不可能满足实际的使用需求, 很多软件的开发人员对于部队的需求根本就没有细致的进行了解, 这样开发出来的产品就也不可能满足部队的实际需要。

1.2 没有完善的软件质量管理的体系

目前, 我国的软件质量管理的制度和要求才刚刚进行到试行的阶段, 一些研制软件的单位还没有建立起较为完善的质量管理体系, 有关软件质量管理工作的相的体系文件也不是很健全, 所以软件的质量没有得到充分的保证也就是正常的了。

1.3 软件不具备良好的可移植性和可维护性

在现阶段的软件管理工作中, 由于相关的文档都是缺乏的, 不全面的, 这就导致了即使软件程序中存在问题, 也是很难被发现的, 即使是发现了也是很难被修改的。另外由于一些文档的缺乏, 想要在现有的软件的程序中增加一些新的功能, 也基本上是不可能的。目前的软件的开发人员也还处于重复开发软件以及类似软件开发的阶段, 一些如“可重用软件”和“软件标准化”等较为创新性的软件概念也还处在推广的阶段。

1.4 软件产品中本就存在质量隐患

在软件的开发和研制的过程中, 一些软件的质量保证技术也没有真正的被引入进去, 而软件测试的工作也还不能全方位的展开, 这就导致了很多软件是存在着质量隐患的。以往的软件的开发过程, 软件的测试人员只是一种配合性的工作, 他们也根本无法提出具体的测试要求, 因此测试的结果无法量化, 也根本无法考核, 所以实际上测试的结果对于软件的质量好坏可能根本就无法产生重要的影响。

2 软件质量管理的解决对策

2.1 通过加强配置管理的力度, 从而做好软件的质量管理工作

目前我国的计算机技术已经应用到各行各业中, 传统的几个人就可以完成一个项目的现象现在基本上是不可能的了, 即使一个人的能力再好, 他也不可能独立完成一个项目。在质量管理体系的众多活动中, 支持各项活动顺利进行的基础性工作就是配置管理, 在一个项目软件的全生存周期内, 配置管理工作不但能够使软件项目产品更加的完整, 它还能够使其他各项支持活动有机的结合到一起, 这样才能真正的成为一个整体, 从而更好的保证了质量管理体系的顺利实施。变化控制、状态报告、状态记录以及识别配置都是配置管理工作的内容, 同时配置管理工作也是以推行软件质量管理工作的工作规程和政策方针为理念的, 在管理工作执行的全过程, 它都能起到监督和跟踪的作用, 它对软件产品的质量是有着重要的影响的。

2.2 为防止软件开发和使用的随意性, 应建立软件的“三库”管理系统

所谓建立软件产品的“三库”系统就是指建立软件产品的受控库、开发库以及产品库, 这“三库”不但是保证软件产品具备过硬的质量重要手段, 也是软件产品形成过程中的技术状态管理工作的核心的任务。软件产品的受控库必须设在三库的专用的机房内, 同时也必须由专业的管理人员对其进行维护和管理, 其保存的形式可以是光盘或者是硬盘, 可查看受控库相关内容的必须是项目指定的负责人, 对于受控库中的内容, 任何人都是不能够随意改写的。而软件产品的开发库是指软件生存周期内的某一个阶段, 存放作为阶段产品发行的, 可查看开发库的内容的必须是与产品开发相关的技术人员, 对于开发库应是由专业的计算机对其进行局域网连接, 同样的也必须设置读写的权限, 这样软件产品的开发成果和开发进程就能够被有效的监控了。产品库同受控库一样, 也要设在三库专用的机房内, 由相关的部门和军代表对其进行管理, 专人对其进行维护和看管。凡是已经设计成型的软件产品都应转入到产品库中, 产品在产品库中转入或是转出时, 都必须建立备忘录并且办理相关手续, 这样出厂产品的重要资料才能够保存完整。

2.3 另外一些提高软件质量管理的方法

2.3.1 采用快速原型法

必须及时的获取使用用户的反馈信心, 同时也应及时的向用户反馈信息, 这样在软件生成的过程中, 通过不断的修改软件才能使软件产品出现的错误更少。在管理的过程中, 还应将软件划分成若干个较好管理的子单元, 之后再对这些子单元逐个的开发研制, 这样软件就是以多次发布的形式交付的, 当对其进行回归测试时, 软件的各项能力才不会被损害或是减弱。

2.3.2 软件缺陷的预防

对于软件产品以往遇到过的各类缺陷, 都必须加以分析并制定避免再次出现缺陷的解决办法。由于这些缺陷可能是被其他的项目确定的, 也可能是在项目的早期阶段中出现的, 所以做好的缺陷预防的工作, 也就是做好了项目之间的吸取教训的工作, 这个项目确定的缺陷, 下个项目就可以避免了。缺陷预防活动的具体操作步骤是:首先规划缺陷预防的活动, 之后应查明出现缺陷的原因, 最后根据原因将所有缺陷顺利的消除。

3 结束语

通过以上的论述, 我们对软件质量管理中存在的问题以及软件质量管理的解决对策两个个方面的内容进行了详细的分析和探讨。软件的质量管理工作是一项十分复杂的系统性工程, 要想做好软件质量管理的工作, 前期必须对其进行科学的企划, 中期必须对所制定的体系和制度认真的实施, 后期发现问题后必须严肃的对待并且积极的改进问题。软件应同硬件一样, 将其纳入到型号技术配套管理以及型号研制计划中去, 对其实行工程化的管理模式, 同时在对软件质量管理的过程中, 相关人员应善于转换管理的思维和管理的理念, 这样才能对软件做到全面的质量管理工作, 软件管理工作才能越来越正规。

参考文献

[1]王莹.军用软件质量管理工作浅析[J].商品与质量, 2011.[1]王莹.军用软件质量管理工作浅析[J].商品与质量, 2011.

[2]房洁.浅谈软件质量管理[J].现代企业教育, 2009.[2]房洁.浅谈软件质量管理[J].现代企业教育, 2009.

[3]徐伟.软件质量管理存在的问题及对策[J].电脑知识与技术, 2008.[3]徐伟.软件质量管理存在的问题及对策[J].电脑知识与技术, 2008.

[4]丁琼.浅谈如何做好软件项目的质量管理工作[J].电脑知识与技术, 2009.[4]丁琼.浅谈如何做好软件项目的质量管理工作[J].电脑知识与技术, 2009.

软件管理工作总结 篇8

摘要:设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。文中对MVC模式、单例模式和页面控制器的概念进行了探讨，并在工作任务管理系统进行了实现。

关键词:设计模式 MVC 单例模式 页面控制器

0 引言

软件项目开发的一个难点是用户需求的变化导致后期功能代码的扩展和维护，软件项目管理的一个难点是团队成员间的协作和沟通。设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编写的、代码设计经验的总结。遵循设计模式的解决方案，有助于功能的扩展和代码的维护。设计模式是面向对象程序设计的精华，让对象和对象的关系清晰了起来，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式是按场景进行分类，便于团队间的沟通。本文以工作任务管理系统为例，讨论几种常用软件模式在信息管理系统开发中的应用。

1 设计模式分析

1.1 MVC模式 MVC是个将一个应用的实现分成三个组件角色的框架技术：模型，视图和控制器。①在基于MVC的应用里，Model(模型)是负责保持状态的应用组件。这个状态通常都持久于数据库之中（譬如，我们也许会有一个Product（产品）类用来代表SQL中的Products数据表中的订单数据)。②在基于MVC的应用里，View(视图)是负责显示用户界面的组件。这个UI通常是使用模型数据来创建的（譬如，我们也许会生成一个Product“编辑”视图，根据当前Product对象的状态，显示文本框，下拉框和复选框等)。③在基于MVC的应用里，Controller(控制器)是处理用户交互，操作模型和最终选择用哪个视图来显示UI的组件。在MVC应用中，视图只是用来显示信息而已，是控制器来处理和回应用户的输入和交互的。使用MVC方法的一个好处是，它有助于促进应用中模型，视图，控制器间的关注的清晰分离。保持关注的清晰分离使得对应用的测试极其容易，因为不同应用组件间的契约的定义和表达是更明确的。

1.2 页面控制器 使用页面控制器模式接受来自页面请求的输入、调用请求对模型执行的操作以及确定应用于结果页面的正确视图。分隔调度逻辑和所有视图相关代码。如果合适，创建用于所有页面控制器的公用基类，以避免代码重复并提高一致性和可测试性。页面控制器可接收页面请求、提取所有相关数据、调用对模型的所有更新以及向视图转发请求。而视图又将根据该模型检索要显示的数据。定义独立页面控制器将分隔模型与Web请求细节（例如会话管理，或使用查询字符串或隐藏表单域向页面传递参数）。

1.3 单例模式 单例模式的特点：①单例类只能有一个实例；②单例类必须自己创建自己的唯一实例；③单例类必须给所有其它对象提供这一实例。

Singleton模式包含的角色只有一个，就是Singleton。Singleton拥有一个私有构造函数，确保用户无法通过new直接实例它。除此之外，该模式中包含一个静态私有成员变量instance与静态公有方法Instance()。Instance方法负责检验并实例化自己，然后存储在静态成员变量中，以确保只有一个实例被创建。

2 工作任务管理系统的设计模式应用

2.1 工作任务管理系统体系结构 工作任务管理系统的体系结构如图1所示，图中的箭头表明了信赖关系。在物理上，DAL是公共的数据访问入口层，BLL用来封闭业务实体对象，BIN是经过编译后的逻辑控制代码，Web文件夹下是按功能划分的视图文件。用户与《View》下的视图文件进行交互，控制数据的显示和接受用户的输入；《View》中的数据来源于《Controller》，《Controller》负责维护《View》的状态和数据的呈现，以及将《View》传递过来的数据对象化，并调用对象方法实现相应的业务逻辑获得数据；《Model》中包含实体的集合，对应于业务规则，是数据库表数据和数据增、删、改、查操作的抽象，实体以类的形式存在，业务以类方法的形式进行实现，《Model》从业务规则的层面处理数据，它是《Controller》数据的供应商。

工作任务管理系统中使用了MVC结构后，在开发时，项目组成员间职责明确，美工和网页设计师只需要关注《View》的设计和HTML实现；数据库设计人员只需要关心数据库的设计以及数据的转换规则；模型人员只需要从业务的角度关注业务规则的实现和从数据库到实现对象的转换工作；而程序只需要关注利用模型的业务规则控制处理《View》的数据显示和输入就可以了。这样做，非常有利于项目的管理和分工协作。

另外，到了开发的后期，需求分析的变化，导致业务规则的重整，只需要在现在代码基础上增加一些实体类就可以了，便于系统的扩展。

2.2 页面控制器 在工作任务管理系统中，《View》分为两种，一种是无需授权任何人都可以访问的页面，称之为通用页；一种是需要用户登录，特定用户才有权访问的页面，称之授权页。《View》只是简单的以HTML的方式显示，由浏览器解析，否能访问由页面控制器来控制的，即《View》对应的后台代码。在默认情况下，所有的布面控制器都继承于System.Web.UI.Page类，要实现权限控制必须在所有的页面控制添加控制代码，这用做非常的麻烦，而且不利于代码的后期修改和扩展。针对于这种需求，页面控制器设计模式提供了一种非常好的解决方案，如图2所示。

定义一个基类BasePage，继承于System.Web.UI.Page，是系统中所有页面控制器的基础；从BasePage下派生出GenPage和AuthPage两个类，分别用作于通用页和授权页的父类。在授权页的构造函数中，实现OnLoad事件的订阅，在OnLoad的事件处理程序中添加权限控制代码，所有的授权页都从AuthPage派生出来，这样在派生页控制器中，就无需写权限控制代码了。在后期代码的扩展过程中，只需有修改父类的代码就可以，而不是每个页控制器的代码。

2.3 单例的数据连接对象 数据连接是系统中非常宝贵的资源，如果一个数据库系统中存在着多个连接对象，并且这些对象没有及时释放，系统的性能将会急剧下降。一个好的设计是，在一个系统中数据连接应该是唯一的，单例的，如图3所示。Cnn是DBAccess的一个静态成员，并在静态构造函数实例化。这样，不论DBAccess有多少个对象，数据连接对象便只有一个了。

3 结论

设计模式是设计经验的总结，在系统设计过程中合理地使用一些经典的设计模式，是十分有利于系统功能的扩展和代码复用的。在工作任务管理系统中，MVC模式使得系统的结构清晰，有利团队的分工合作；页面控制器模式降低了代码的冗余度，提高了代码的重用性，方便了功能的扩展；单例模式实现了数据连接的唯一性，提高了系统的性能。

参考文献：

[1]钟金琴，辜丽川.一种面向对象的软件设计模式库的设计.计算机技术与发展[J]，2008.(9):22.