软件项目售后服务流程

软件项目售后服务流程（12篇）

1.软件项目售后服务流程 篇一

研发中心项目开发管理流程

1，新项目开发管理流程

按照项目管理规范，项目管理分为：项目启动—》项目计划—》项目执行—》项目控制—》项目结尾。5个阶段。根据该管理流程和我公司实际情况，将新项目开发的管理流程制定如下图：

1.1 项目立项

项目立项阶段，首先由的项目经理编写《项目立项报告》。

研发项目立项报告模板.doc

1.2 立项评审

《项目立项报告》编写完成后，交由项目管理委员会进行立项评审，评审通过后由副总经理签字确认立项。确定需求分析和项目设计阶段的时间和人员安排。

1.3 需求分析

需求分析阶段，需要与用户交流，双方对软件需求取得共同理解基础上达成的协议。编写并完成软件需求说明书：也称软件规格说明书。

软件需求说明书模板.doc

1.4 系统设计阶段

常规的系统设计需要依次完成《概要设计说明书》，《详细设计说明书》。以下是文档的简要说明：

概要设计说明书：该说 明书是概要设计阶段的工作 成果，它应说明功能分配、模 块划分、程序的总体结构、输 入输出以及接口设计、运行设 计、数据结构设计和出错处理 设计等，为详细设计奠定基础。

概要设计说明书.doc

详细设计说明书：着重 描述每一模块是怎样实现的，包括实现算法、逻辑流程等。详细设计说明书.doc

详细设计说明书编写完成后，项目经理应该依次编写安排项目开发工作计划。工作计划安排可以根据项目经理的习惯进行工作计划编写。建议采用project。附件为综合考务平台的工作计划安排，可以供参考：

考试考务综合管理平台工作计划.mpp。并且确定里程碑，以便在后期项目执行过程中，对其进行确认。对于大项目，建议按照项目设计流程，先进行概要设计，再到详细设计。但是对于特殊项目（项目周期较短，小项目），可以讲概要设计和详细设计阶段合二为一，编写功能，接口方案。但是值得注意的是，该方案中，仍然需要涵盖项目模块功能，用户权限和各模块实现逻辑，接口等。

项目设计开发方案.docx。

1.5 项目设计评审

设计阶段完成后，项目经理填写《项目设计评审表》，将相关文档交由项目管理委员会进行项目设计评审。通过评审后，方可进行编码工作。

项目设计评审表.docx

1.6 编码和测试用例编写阶段

项目编码阶段，项目经理需要对项目执行情况进行控制和监督，其中包括（项目输入，项目输出，里程碑）。如果由于特殊情况，如：需求变化，人员临时调配，或者其他原因导致的项目范围和时间，计划等变更，项目经理应该及时填写变更申请。并提交给项目管理委员会。作为之后项目输出验证的重要依据项目变更申请书.doc。

在此阶段，测试人员应该根据《需求说明书》，《概要设计》和《详细设计说明书》的内容，编写相应的《测试用例》。1.7 测试阶段

编码完成后，应该移交测试组进行相关测试工作。按照测试流程，需要提交《测试申请表》。测试人员在接收到《测试申请》后，应该与研发人员讨论《测试用例》的相关内容，确定测试时间，开始程序测试。并在测试工作完成后，编写对应的《测试报告》。

1.8 结项评审与验证

项目负责人和测试负责人分别填写《项目结项评审表》，交由项目管理委员会进行评审。评审通过后，由研发中心副总经理进行发布确认。

项目结项评审验证表.doc

1.9 新产品发布

编写《用户手册》。方可进行新产品发布。

2，旧项目升级开发管理流程

旧项目的升级，依照如下流程：

2.1项目升级需求分析

项目需求分析，需要收集用户在产品使用过程中，已经技术人员在调试过程中的反馈作为需求分析的输入。并填写对应的项目升级需求报告表。项目升级需求报告表.doc

2.2 升级评审

将《升级需求报告》交由项目管理委员会，评审通过后，进行升级设计。2.2项目升级设计

项目负责人，根据需求报告和升级具体情况，编写升级开发方案。项目升级开发方案.docx。并安排整改工作计划。

2.3 项目升级设计评审

升级开发方案完成后，填写《项目设计评审表》，交由项目管理委员会评审。

2.4 编码

按照项目升级开发方案进行编码设计，如果编码工作中，发生特殊情况需要变更计划，或者项目范围等，同样需要提交《变更申请》，作为项目验证的基础。同样，此阶段，测试人员应该编写或者修改相关测试用例。

2.5 测试

编码完成后，应该移交测试组进行相关测试工作。按照测试流程，需要提交《测试申请表》。测试人员在接收到测试申请后，应该与研发人员讨论《测试用例》的相关内容，确定测试时间，开始程序测试。并在测试工作完成后，编写对应的《测试报告》。

2.6 升级输出评审

项目负责人和测试负责人分别填写《项目结项评审表》，交由项目管理委员会进行评审。评审通过后，由副总经理进行发布确认后。

2.软件项目售后服务流程 篇二

1 常用的需求变更控制流程

“需求管理”是C M M 2级的一个K P A (Key Process Area, 关键过程域) 。CMM2级中对”需求管理”的目的定义为:分配给软件的系统需求是受控的, 建立供软件工程和管理使用的需求基线;软件的计划, 产品和活动和系统需求是一致的

CMM对需求管理的建议可以归纳为三点:首先, 应该让有经验和有能力的人来做需求分析活动和需求管理活动;相关的人员应该接受培训。其次, 要对需求分析活动进行评审, 保证他们是可控制和管理的, 并且是软件需求是合适的。最后, 如果需求更改了, 必须对由此造成的其它软件计划, 工作产品等的更改必须加以规划, 识别, 评价;对这些更改要做风险评估;所以这些都需要文档化;并且传达给相关的人员并且一直跟踪这些变化。其中最后一点对需求变更控制提出了明确的要求。

鉴于以上要求, 很多公司和培训、咨询机构都设计了非常严密变更控制流程。

以本文作者所服务的通信行业软件公司 (以下简称“公司”) 为例, 为实施CMM管理体系, 将变更控制流程分为:变更请求、变更评审和分析、变更实施三大子过程。

在进行变更请求时, 需要提供 (预评估) 如下内容: (1) 需求变更内容的描述:变更类型 (增加/删除/修改) 、要求、对应的当前需求等; (2) 由此带来的对已有成果的影响 (设计、编码、测试等) ; (3) 对项目的影响 (项目进度的变化、资源需求的变化等) 。

为了表示对需求变更控制的重视, 公司特别强调了“需求变更评审”的重要性, 要求评审应该由项目经理组织, 高级经理 (项目经理的管理者) 、产品经理、市场 (代表客户) 、质量代表 (代表质量部和流程改进组) 、研发人员、需求管理员等各种角色应该参与到评审过程中, 并对变更负责。

分析公司制定的需求变更控制流程, 以及咨询公司的改进建议等, 给人形成了一种很不好的感觉, 那就是“变更是不好的, 所以应该严格控制变更”。而事实上, 在软件定义阶段, 由于客户对产品往往还不能形成一个完整的印象, 需求不明几乎是所有项目的共同起点。在需求变更时, 客户也不会很好的对变更带来的影响做详细评估, 而是简单的提出要求, 并且要求实时响应。而对于小型软件公司来说, 如果僵化的坚持“需求及其变更必须明确后再开始项目”, 就无法体现小公司灵活, 快速的特点, 在业界根本就无存活的可能。

公司制定的整个流程看起来完美无缺, 非常符合C M M审核的要求, 但是在执行中, 却遇到了以下问题:对于变更申请时必须填报的变更申请表, 客户及其接口都觉得内容过于繁复, 不愿意配合填报。客户更希望提出需求, 并得到响应。由于要求需求变更必须得到高级经理, 项目经理, 公司产品部, 客户, 需求管理人员等各方人员的认可, 并且在进行了深入评估后才能实施变更。因此, 任何变更都不可能实时实施, 实际执行结果是客户不能接受此过程, 认为公司效率低下, 给公司管理层和开发人员造成了很大压力。由于流程未遵循闭环管理原则, 因此, 一些需求公司已经实施, 但是未能及时反馈到需求提出者, 客户感觉需求未得到响应, 降低了客户感受。总之, 从根本上来说, 每个公司实施质量管理体系的目的都是为了更好的满足用户, 因此, 一个不能让客户满意的流程肯定不能说是一个好的管理流程。

2 简化的需求变更控制流程

2.1 流程设计原则

我们回头来看C M M的要求, 其关键是识别变更、评估变更、文档化变更、跟踪变更。要求这些并非一定要由客户来完成, 或者说公司级别来完成。CMM对评审的要求准则是应评审需求的变更, 而对评审的目的, 则可以遵循对需求管理的目的:在顾客和软件项目之间建立对顾客需求的共同理解。而对评审的方式, 参与人员并无机械的要求。

遵照以上要求, 本文提出了一种简化的需求变更控制流程。在小型软件企业中, 可以在如下几个方面来简化变更控制: (1) 简化变更请求。客户只要提出变更的要求, 变更的分析交由公司内部完成。 (2) 变更的权利交由项目级别决定。 (3) 改变变更评审为变更上报和跟踪。项目经理可以根据客户需求, 首先在项目层面实施变更, 但是, 项目经理必须对变更可能的影响等及时通知给高级经理、产品经理、公司级需求管理人员和客户。 (4) 在变更申请人、需求跟踪人员和项目经理发生变更冲突或者以上人员认为必要时, 再启动公司级别的变更控制评审。

2.2 简化需求变更控制流程

图1给出了简化后的需求管理流程。

[活动1-1]的负责人为需求提出者。

任何人都可以提出需求。即新的需求或者需求变更可以来源于和客户直接交流的市场人员, 产品人员, 客服服务人员, 也可以来源于研发者。客户交流的邮件、会议纪要等文件可以作为需求变更申请的附件。

[活动2-1]需求变更确认

活动2的负责人为项目经理, 活动2的实施者则包括含项目经理在内的所有项目组成员。

项目经理根据需求变更申请中的中描述的内容, 考虑其影响程度, 自行、召集项目成员, 或者将需求提交RRM进行需求变更的评审, 针对需求变更申请中的相关描述, 以及参考产品, 市场, 以及对相关组的影响等各方面的综合因素, 确认是否需进行修改, 修改人, 验证变更人, 修改方案等内容, 并及时跟踪将此信息。

项目经理是负责督促实施需求的人, 因此, 其有责任去了解需求, 分析需求, 以确保需求的清晰明确。

[活动2-2]需求设计和实现

[活动2-3]需求测试

以上可统称为需求实施活动。活动2中的需求实施活动和普通研发活动并无特别之处, 这里不做详述。

在活动2的描述中, 还提到了一个非常设的机构RRM (RequirementReview Meeting) 来处理异常流程和争端。作为流程的规定, 以下条件可促发RRM。

1) 未处理的新需求或者需求变更超过门限值。

2) 两次RRM的时间间隔超过门限值;

3) 需求提出者和项目经理对“不合理”“不合格”存在异议时, 或者其他项目经理、需求管理、项目负责部门、产品市场部等需求干系人觉得存在重大需求, 在项目级别不能达成解决, 或者一致意见而需要公司级别集体讨论时。

以上任何一个条件符合, 项目经理将组织RRM, 就项目遗留的需求进行讨论, 并给出结论。

管理好需求变更, 才能管理好项目。需求变更是不可避免的, 只要项目存在一日, 变更便会随时产生, 逃避变更、排斥变更都不能改变需求变更的事实。本文遵循CMM要求, 提出了一种需求变更控制方法。本文设计的方法主要应用于小型软件项目, 当然管理一个小型软件项目, 除了流程和工具的支持, 更重要的是项目管理者, 参与者, 支持者都应该在需求管理过程中多沟通, 勤实践, 并能积极借鉴业界管理体系的有益指导意见, 唯有如此, 才能更好的完成客户需求, 提高客户满意度。

参考文献

[1]SEI, Key Practices of the Capability Maturity ModelSM, Version1.1, 1993.

[2]中国标准研究中心.ISO9001:2000标准, 2000.

3.软件项目售后服务流程 篇三

关键词：软件实施项目；项目管理

中图分类号：TP3文献标识码：A文章编号：1007-9599 (2011) 08-0000-02

Multiple Service Providers,Software Implementation Project Management Experience of More Partners

Wu Xiaolan

(COSCO Network (Beijing) Co.,Ltd.,Beijing100031,China)

Abstract:On a multi-vendor,multi-partners in the implementation of large-scale software project management experience and understanding to explain the process of cooperation in the project,control,and other aspects of the interface elements defined for the implementation of other project management software to provide reference Comments and suggestions.

Keywords:Software implementation project;Project management

大型软件实施项目，比如一些深化应用项目，是在之前操作型软件项目的基础上，利用系统多年推广的

成果以及原始数据积累，进行企业业务应用更深层次的需求，比如现在较为流行的商务智能（BI）项目，旨在进行数据仓库（BW）建设、实现企业业务整合、财务合并、预算管理、数据分析、接口整合、门户建设以及系统监控，为领导决策提供数据依据。因项目范围大、包含内容复杂；实施项目的单位大多业务范围广泛，源头数据除了来自于早前建设的操作型软件项目，还有来自于专业财务或业务软件、专业报表系统等，数据源种类众多；而从BW数据仓库加工的数据也会导出到展示系统，如BO、久其等数据展示或系统，因此为即将实施的深化应用项目提供服务的IT服务供应商和咨询合作伙伴会有很多家，项目中与合作伙伴以及各合作伙伴之间的协调工作也就尤为重要，合作质量直接对项目成败造成影响。

合作伙伴多种多样，有的是权威原厂，有的是名不见经传的小公司；有的是民族产业，有的是国际知名世界500强。不同的企业背景和文化，在一个项目里能达到融合，确实需要一个磨合过程。项目经理可能会面临许多问题，比如客户、项目经理本身、每个合作伙伴或供应商对项目的视角和理解存在偏差；比如项目沟通渠道和路径复杂导致的沟通信息的不对称；比如项目计划制定的太理想而无法按期完工；比如项目按期完工了但质量无法保证；再比如合作伙伴比预想的实力弱而无法保证项目质量或合作伙伴太强势而无法控制。诸如此类种种，为项目管理带来不少困扰。那么究竟如何和合作伙伴合作呢？

一、项目合作，但求双赢

既然是合作，项目经理就要自始至终贯彻合作的理念，从选择合作伙伴开始就要有双赢的想法，即与合作伙伴双赢。为了实现双赢，作为甲方的项目经理应该明确项目目标和明确的工作范围，要有清晰的工作说明书（SOW）；同时从项目本身出发，了解侯选合作伙伴都有什么优缺点，合作伙伴参与项目的最大动因是什么，不同的侯选公司参与项目的核心动因往往不同，这就需要在项目目标与公司参与项目的两个目标之间要进行平衡。在考虑自己项目目标的实现的前提下，不是一味的追求自己目标的实现而不考虑合作伙伴的利益或目标。作为项目经理应始终关注两方利益与目标的平衡，才能选择最合适的合作伙伴，才能发展健康、高效的合作关系。合作伙伴带来先进的产品和解决方案，经由与我们的合作培养双方的专精人才，双方的技术和人才储备都有所提升，我们的项目成功了，合作伙伴的产品和解决方案也充实了，双赢是项目成功的前提。

二、仔细观审，知自知彼

有了双赢的思想，我们还要从多方面审核和观察，做到多方面的知己知彼。只有多方面的知已知彼，才能更加保证双赢的局面，平衡多方面的利益与目标。

在对合作伙伴的选择过程中，要了解每一个候选合作伙伴提出的各种方案的可行性，专家的参与度和承诺的可靠性，专家的水平以及以前实施过类似项目的经验等，同时统筹考虑自己方参与项目的人员经验，项目预算，相关的干系人对项目的期望等因素。我们要对候选合作伙伴提出的假设和前提逐个进行风险分析，对参与项目的主要专家一定要当面面试，明确专家参与项目的方式，并在合同中做出相应的约束。确定了SOW与公司的参与专家后，在商务谈判过程中，可能出现销售和售前夸大其词的情况，这时候要分析合作伙伴做出的承诺，一般来说对销售与售前顾问的承诺都应在合同中或工作说明书进行约束，同时还要注意不同的合作伙伴对承诺的态度不同，对一般的小公司，有可能做出不切实际的承诺，反之大公司做出的承诺可信度就高得多。另外，项目情况千差万别，合作伙伴就是再有经验，也可能遇到从没有遇见的问题，对之前的承诺大打折扣，这点需要在项目之初就和合作伙伴谈清楚，做好解决方案的制定，在项目过程中取得主动。

三、推己及人，严于律己才能严于律人

项目的实施过程中，不合理的需求或不切实际的方案都不是大家想要的。因此，作为项目经理的你也不应该将或代表将一些不切实际的承诺强加给合作伙伴，正所谓己所不欲，勿施于人，不切实际的承诺带来的结果最终是对项目的伤害。为了避免不切实际的承诺，在选择与确定合作伙伴之前一定要清晰的了解项目实施中各种方案的可行性，前提、假设等，并结合了解到的公司方参与项目的核心动因进行分析，尽可能对项目方向性风险进行评估，避免项目后期出现大的风险。只有这样，才能实现真正的双赢，同时能选到最合适的合作伙伴。不合理的需求与不切实际的方案一样，在实际的项目实施过程中有时是不可避免的，处理这类问题时也应做好甲方内部的沟通和协调工作。有时一个看似简单的需求需要项目花费大量的气力才能完成，而用户并不知情，那么就要想好折中对策后和用户进行沟通，在某种程度上说服用户采纳折中的办法。在做这样说服工作也要事先考虑周到，以理服人，否则可能既得罪用户也得罪乙方，对项目推进同样会造成极大影响。

在选定了合作伙伴、还不止一家合作伙伴后，多家合作伙伴完成同一个项目中不同的项目环节的时候，如何使不同背景、不同产品厂家、不同实施商整齐划一的完成同一个项目的任务目标，那合作伙伴之间的协调工作就非常重要。经过笔者多年的项目实施经验，总结出以下几点：

（一）项目规模控制是项目能如期上线的保证

前文提到每个参与项目的服务供应商或者合作伙伴都有参与项目的动因。在动因的驱使下，有些合作伙伴或者多个合作伙伴之中的某一个可能存在求好心切的心理从而一味迁就用户，承诺SOW之外的用户需求或者自行扩大项目范围而未考虑到用户方的相关沟通耗时，包括审批汇报、原型开发等成本对项目周期可能带来的影响。这种情况下，应该协调用户和合作伙伴，在有限的时间里先保证项目既定内容的如期上线，其他内容在维护甲方利益的前提下，签署“Change Request”（变更需求书），考虑在上线之后再进行实施。否则可能遇到的情况就是项目无法如期上线、项目质量无法保证、项目其他供应商会有怨言等问题，项目实施推进就会变得非常被动。

（二）贯彻项目全貌的同时制定清晰的工作界面

正所谓先小人而后君子，事先定好规矩强过事后互相扯皮。为各参与项目的合作伙伴定义清晰的工作界面，包括各自工作目标、内容的制定，包括两两接口的人员和规范等。如遇定义不清的地方，就多方坐下来进行商谈，直到定义清楚为止。清晰的工作界面使得每个合作伙伴都能专注于本职工作，避免在沟通协调上浪费成本。分工明确，职责清晰可大大提高项目实施的效率。项目全貌的宣传和灌输旨在让各合作伙伴了解自身在项目中所处的关键位置，服务于各自工作目标以及总体工作目标的实现。

（三）根据不同的项目实施内容在不同的项目阶段，定义主导合作伙伴

作为甲方项目经理，在项目实施过程中更多的依靠主导的合作伙伴可取的事半功倍的效果。多家合作伙伴中谁是主导的一方呢？我做过的一个深化应用项目中企业管理驾驶舱子项目，为其提供的服务的合作伙伴有三家，一家数据源（A伙伴），一家负责BW数据仓库建设，也就是数据源数据模型加工（B伙伴），一家负责BO数据展示，即加工数据的图表展现（C伙伴）。数据流向：A->B->C，需求流向：C->B->A。表面上看来主导合作伙伴非A即C，它们是流程的两端，实则不然。B作为数据的加工方才是主导的合作伙伴。对于数据，按照接收方原则，B要向A提出数据传输的规格；对于前台的报表展现，B要向C提供加工好的数据。B中数据加载、加工的效率，直接影响系统的性能。在这个项目的蓝图设计阶段，B就是主导合作伙伴。B需要提出系统最核心的系统架构和分析模型搭建架构，需要对项目的总体计划进行制定和监控。到了系统集成测试阶段，C就成为了主导合作伙伴。C要根据展示出来的结果和数据源头系统进行核对，检验数据的准确性，对于不准确的数据，C要根据和B的接口文件向B提出核对需求，B经核对无误后根据和A的接口文件向A提出核对需求，从而找出问题所在。在项目不同阶段定义主导合作伙伴后，甲方项目经理只专注主导合作伙伴的计划执行情况，而主导合作伙伴则在本阶段是工作的发起和监控权威，其他合作伙伴在主导合作伙伴的要求下完成各自相应的工作。

（四）目标统一，不分彼此

无论合作伙伴来自于什么样的企业，一旦参加项目就和甲方的派出代表形成一个项目整体，大家目标一致，就事论事，任何分歧都在桌面解决，形成良好的项目合作风气，促成项目成功。真知来自于争议和讨论，而争议越是尖锐越是到了问题快要解决的关键阶段，因此在目标一致的前提下，欢迎争议。面临同一个问题的不同解决方案，多方对比和评估，在项目组范围内无法决策的一定要快速提交到高一级别的组织进行决策，以保证项目进度不受影响。对于项目组内部可以处理解决的问题则不是高一级别组织关注的焦点。项目的结果不好，不是某一个合作伙伴的问题，项目的结果好，亦不是某一个合作伙伴的功劳。因此大家的目标是一致的，在项目工作中是不分彼此的。

（五）有始有终，项目收尾漂亮，项目才算漂亮

项目收尾除了必要的项目总结外，项目的回顾过程也很重要；回顾的重点是项目过程中问题的处理解决情况、项目文档的各个版本是否齐备、项目重大里程碑相关的文件及过程、此次项目取得的经验教训和成果。项目最终的汇报则是项目达到尾声的仪式，在这个仪式上每个参与项目的合作伙伴都要“浮出水面”，在汇报之后听取用户方代表的意见，开阔视野之后再去回顾项目的整个过程，回顾之后就会有更高的起点迈向未来。

4.投融资项目的流程服务 篇四

投融资项目指需要从外部以股权形式或者负债形式获得资金的项目。投融资项目可以是创业项目或者已有企业再融资。

脑库投资管理公司作为投资银行顾问，在投融资项目中主要承担投融资专业咨询和中介的角色，在需要时，我们也会以自有资金参与项目投资，但脑库投资管理公司仍以收取项目咨询费和中介成功佣金为主要业务。我们首先是一家专业咨询机构，不是纯粹的投资机构。

所有投融资项目在被我们正式接受处理之前，一般要求项目方已完成相关的项目可行性研究，并制作好一个结构规范、内容完整的商业计划书。经常遇到项目方只能提供粗略的想法或几张纸的不规范的项目说明、有关政府批文执照的情况，这样的项目准备未达到进入受理的标准，需要项目方先请专业机构按行内要求制订项目文件后再提交给我们。当然，我们也可以接受项目方的委托，为项目方提供有偿的项目可行性研究和商业计划书制作服务（收费标准附后）。以下是我们的投融资项目的步骤： 1项目文件审读

此处项目文件特指符合投融资行业要求的项目可行性研究报告和商业计划书。

审读的目的是通过相应行业专家对项目资料的把关，筛选出适合的供脑库投资管理公司进一步推进的投融资候选项目。此项工作主要由脑库公司外聘并签订了保密协议的专家进行审读。审读后由专家给出3-5条修改完善建议以及对项目是否值得进行下一步工作的初步判断。审读的收费标准: 审读专家按照其工作量收费,一般标准是审读每份项目可行性研究报告或商业计划书收费500-1000元人民币。注意：

每天我们都收到各类项目信息，这些免费提供的信息多数来自项目方或者同行、朋友，投融资经理每天都要处理10-20个这样的信息，无法对每个项目进行深入研究，我们的投融资经理此时只能做出“受理”或“不受理”的判断，而无法向信息提供方提出针对项目的具体的意见。如果我们认为不能受理，多数情况是因为收到的项目资料不符合规范，内容不完整，无法进一步审读。而同意受理的项目文件，在项目提供方支付了专家审读费后，我们会交予相关行业专家审读。2．签订委托书、尽职调查

专家审读后推荐进一步调研的项目，由投融资经理与项目提供方（通常要求项目最原始拥有方）签定委托书，因为我们收取的是项目成功投融资后的成功佣金，因此，前期的从尽职调查开始，到最后完成投融资的时间和费用成本先由我们自己垫付，这就必须确保我们投入的时间精力和费用不会浪费，此时，我们通常要求项目方在三个月内独家委托我们来进行这项工作，我们将争取在三个月内完成项目投融资。如果超过三个月，则委托自动转变为非独家委托，即项目方此时可以同时委托其他机构进行项目融资，而任何被委托的机构都有同等权力为项目方提供服务，与最先完成的一方交易。委托书还应承诺支付成功佣金的比例和支付条件等条款。

尽职调查为投融资项目的标准程序，通常我们会进行尽职调查，以确认和锁定项目风险，此项调查为内部风险控制的一个步骤，不能代替资金投入方做的尽职调查，如果需要，资金投入方会独立进行另一次尽职调查，以锁定其投融资风险。3． 路演

路演是指为了寻找适合条件的投融资对象，由我们协助项目方对项目进行商业包装，并向潜在投融资方推介项目的过程。路演资料由我们指导项目方准备，双方共同商定路演计划和细节，项目方在需要时，要参与路演活动，项目方承担路演组织费用。4． 组织与潜在投资方进行投融资谈判

在路演阶段，我们将组织与潜在投融资方进行细节谈判，协助项目方选择合适的资金方，获得最佳谈判条件。我们将作为项目方的专家团队，提供商务和法律咨询服务。5． 签订投资意向书/合同

此投资意向书/合同是指项目方与资金方签订的初步投/融资意向性协议，此文件具有法律约束性，我们将协助项目方与资金方确定协议细节，规避法律陷阱，为项目方争取最大利益。6． 监督资金/资产到位

签订投资意向书后，我们将协助项目方和资金方安排资金到位，监督各方履行协议责任，同时协调过程中出现的问题。7． 项目结题

5.软件项目售后服务流程 篇五

陵川县职业介绍服务中心是政府劳动保障行政部门所属的，承担公共就业服务职能的公益性服务机构，为劳动者免费提供下列服务：

（一）就业政策法规咨询；

（二）职业供求信息，市场工资指导`价位信息和职业培训信息发布；

（三）职业指导和职业介绍；

（四）对就业困难人员实施就业援助；

（五）办理就业登记、失业登记、录用和终止解除劳动关系、备案等项事务；

（六）为用人单位和求职者提供服务，协助用人单位进行劳动力余缺调剂；

（七）组织劳务输出和输入，并组织相应的培训；

（八）接受委托保存人事档案；

（九）接受劳动者和用人单位的委托，从事劳动保障事务代理业务；

（十）劳动保障行政部门指定的公共就业服务。

业 务 范 围

1、对劳动者求职和用人单位招聘用人进行登记。求职登记的主要项目包括：求职者本人的基本情况，职业经历，技能水平，求职愿望等等。用人单位招聘登记的主要项目包括：用人单位的基本情况，用人条件，工资待遇等等。

2、为求职的失业人员、需要转换职业的在职职工、农村剩余劳动力转移和其他人员提供需求信息，推荐用人单位。

3、为用人单位提供劳动力资源信息，为其推荐求职者。

4、对劳动者求职和用人单位招聘提供职业指导和职业咨询。开展对求职者素质的测试和能力评估工作，帮助其了解职业状况，掌握求职方法；指导用人单位正确招聘用人和按规定招聘用人。

5、向职业培训机构提供职业需求信息。推荐需要培训的人员。

6、为特殊群体人员和长期失业者提供专门的职业介绍服务。

7、通过组织劳务输出、举办洽谈会，以及提供劳务承包、劳务协作等活动，根据需要开展推荐临时用工、家庭服务员等服务，为求职者提供直接的就业服务。

8、建立劳动力市场信息资源库，开展劳动力供求情况预测、预报，进行劳动力供求信息咨询服务，收集、整理和发布劳动力市场信息。

公开办事项目及工作流程

1、（1）用工登记

（2）用工单位进入中心招工（聘）或委托中心代理招工（聘），须持《营业执照》（副本）和招工简章，家庭用工须持雇主《居民身份证》，外地用人单位须持县级或县以上劳动部门批准的外出招工证明，《营业执照》（副本）和招工简章（3）填《用人单位用工申请表》、输入微机、刊登大屏幕（4）即时

2、用工备案

（1）①经劳动部门审核的《招工招聘简章》；

②招聘人员登记表

③《就业登记表》

④《劳动合同》

⑤《就业失业登记证》、《职业资格证》等

（2）签订劳动合同、填《备案人员花名册》、《备案登记表》《劳动合同制职工备案（录用）登记表》

（3）十个工作日

3、失业登记

（1）失业人员进行失业登记应持户口簿（身份证）和证明原身份的有关证件，（有就业经历的失业人员，除身份证件及街道证明外还须持原单位出具的终止或者解除劳动关系的证明）（2）领《求职登记表》、《就业失业登记证申领登记表》、填表及相关证明材料，办证。

4、求职登记

6.软件项目售后服务流程 篇六

2009年省级现代服务业（软件产业）发展专项引导资金

项目申报指南

一、指导思想

认真贯彻落实国家和省“保增长、促发展”的决策部署，加快推进我省产业结构调整，围绕国家和我省“电子信息产业调整和振兴规划”，重点支持拥有自主知识产权、技术特色明显、产业化成熟度高、具备市场竞争能力的软件和集成电路企业做大做强，支持具有全局性、基础性、先导性、示范性、带动性的重大软件产业项目建设，提高我省软件和集成电路企业的核心竞争力，促进和带动全省电子信息产业的加快发展。

二、项目范围及申报条件

（一）重点软件产品项目（01）

1、操作系统（实时控制类嵌入式操作系统、网络业务类嵌入式操作系统等）；

2、数据库（实时数据库系统软件、分布式数据存储软件等）；

3、中间件（移动通信中间件、网格中间件、无线传感器网络中间件等）；

4、普适计算基础软件、三维CAD软件、三维GIS软件；

5、环保监测、监查、污染控制管理与系统集成软件；

6、电力、通信、智能交通、电子政务等面向行业和社会领域的应用软件；

7、面向行业用户的SaaS软件；

8、数字内容处理及服务支撑软件；

9、基于中国优秀文化的网络游戏软件、绿色网络控制软件、多媒体教育/教学软件等；

10、行业、企业级数据信息集成与应用平台开发；大型物流管理信息系统；

11、重点行业大型电子商务和特色电子商务系统；

12、现代生产服务业和其它信息技术融入到研发设计、生产、流通、管理、人力资源开发各环节的大型集成和协同系统。

申报条件：项目对软件产业发展有较大带动作用；项目成果具有创新性，拥有自主知识产权，权属明确；具备实现产业化的技术基础和广阔的市场前景，项目实施能产生显著的经济效益；产业化目标任务明确，实施方案合理可行；项目实施单位具有较强的技术创新能力、良好的产业化基础以及较好的管理能力和人才队伍；项目实施单位的资产及经营状况良好，产权清晰；项目申报单位为在本省注册且独立核算的软件企业，成立时间不得低于3年（以下企业在江苏注册成立的最低年限可放宽至1年：从我省成立3年以上的制造企业中剥离成立的软件企业；从其他省市引入的成立3年以上的软件企业；在其他省市成立3年以上的软件企业在我省设立的子公司）。

（二）信息化与工业化融合试点项目（02）

1、植入嵌入式软件、应用软件、关键芯片和核心芯片的工业产品的生产与产业化；

2、机械、电子电器、冶金、造船、纺织、风力发电等重点设备、重大装备或设备群等数控集成产品的研发与产业化；

3、能源（煤矿生产和清洁能源生产等）企业管控一体化系统及其它信息技术应用系统；

4、流程工业企业采用信息技术的节能降耗管控系统（重点在冶金、化工、轻工、建材、环保等）、生产过程管控系统。

申报条件：关于第1、2类项目，申报项目为工业企业自主研发产品，产品具备数字化、网络化、智能化等核心技术，产品产业化前景好，产品生产、销售对企业销售业绩有较大提升。申报单位为省内规模以上先进制造业。

关于第3、4类项目，申报项目实施的内容明确、技术路线可行，在核心技术或关键技术方面创新点明显，能形成具有自主知识产权的软件产品及系统，具有较好的经济和社会效益；2008年至本项目申报截止日前，应用方和信息技术依托方已签订规范、正式的合作合同，项目合同总金额不低于200万元人民币，项目申报截止日前，投资方付款已达到50%，项目实施已进入中后期。信息技术应用单位为我省境内的重点支柱行业中的大型骨干企业，项目实施对其产业提升具有显著效果，信息技术依托方具有雄厚的技术实力和良好的财务状况。项目申报单位为在本省注册且独立核算的软件企业，成立时间不得低于3年（关于成立年限的其他规定，比照“重点软件产。品项目”）

（三）重点集成电路产品项目（03）

1、具有自主知识产权的集成电路IP核；高端通用芯片的研发与应用；集成电路制造关键工艺、先进封装测试技术及关键配套材料、设备等；

2、新一代数字移动通信系统设备、终端及配套产品；光通信关键设备；无线传感器网络及关键设备；

3、基于国标的数字电视系统及关键设备、数字视频监控系统、数字媒体终端设备；

4、平板显示关键元器件、敏感元器件及传感器、半导体电力电子器件、光电子器件、高性能电子信息材料；

5、医疗电子、汽车电子、船舶电子、智能交通、绿色照明产品等。

申报条件：比照“重点软件产品项目”。

（四）信息安全类项目（04）

1、安全操作系统、安全数据库、安全中间件、容灾备份、安全办公等基础类软件产品的研发与产业化；

2、网络攻击防护、网络监控、恶意代码防治、网络内容安全管理等网络安全类软件产品，基于国产可信计算芯片、高性能专用安全芯片、自主密码技术的集成应用产品，适用新一代网络环境的高性能、多安全功能集成化软件产品的研发与产业化；

3、移动存储介质保密管理、电子文档安全管理、网络数字版权保护、电子证据取证、安全评估与保密检查、终端安全防护等专用安全软件产品的研发与产业化；

4、重点领域、重点行业采用自主安全产品建设的安全监控、安全支付与信用保护、安全综合防范等软件管理系统，为软件园区和其他软件企业集聚区提供重要数据保护的软件管理系统。

申报条件：项目对信息安全有重要意义，其他比照“重点软件产品项目”申报条件。

（五）资质认证奖励（05）

1、CMMI认证奖励。

申报对象为通过CMMI认证（含升级），符合《江苏省财政厅江苏省信息产业厅<关于对通过CMM/CMMI评估的软件企业实行奖励的办法>的通知》（苏财建[2005]126号）有关规定的软件企业。

2、信息安全管理（ISO27001）认证。

申报对象为在我省境内注册，具有独立法人资格，通过信息安全管理认证的软件和集成电路企业。

（六）其他类（06）

1、社会信息化推广项目。

申报对象为自主研发、销售为农村、社区信息化示范点服务的软件产品的软件企业。必须为省级以上信息化试点或示范项目。

2、实用软件人才培训补贴。

申报条件：经省信息产业厅认可的，有培训资质的机构，为江苏软件产业培养实用人才、项目经理等，并取得较好成效。所培养人才必须是面向社会招录的软件人才，不包括在校大学生。

3、国家“核高基”和“新一代宽带无线移动通信网”重大专项配套项目。

三、资金支持方式

（一）补助

1、对重点软件产品、重点集成电路产品、信息安全类、社会信息化推广类项目，根据所报项目技术含量、研发成熟度、产业化前景、产品投资额以及企业近几年来销售及增长情况等因素给予一定的补助。

2、关于信息化与工业化融合项目。对工业企业自主研发的项目，根据项目技术含量、研发成熟度、项目投资额、产品生产销售促进工业企业销售业绩增长情况、产品产业化前景等因素给予工业企业一定的补助；对工业企业联合省内软件企业开发项目，除上述参考因素外，结合合作开发合同，对软件开发企业给予一定补助。

3、对我省相关企业和单位申报并已通过“核高基”、“新一代宽带无线移动通信网”等国家重大专项审核的项目，其地方配套不足部分，给予适当补助。

（二）奖励

对当年通过CMMI认证（含升级），按规定标准予以奖励。具体标准为： CMMI 2级30万元，3级40万元，4级60万元，5级70万元。对于已按原标准获得奖励的企业，提高标准部分在升级时按新标准补足，未升级的不予补足。

对通过信息安全管理（ISO27001）认证的企业，按规定标准予以奖励。

（三）以奖代补

软件专业人才培训项目，主要按照取得培训合格证书的人数、对实训平台建设的投入或与境外机构合作培训的公共性费用等实行“以奖代补”。

四、项目申报要求

（一）项目申报单位应按填表说明认真填写《江苏省级现代服务业（软件产业）发展专项引导资金项目申报书》和《江苏省级现代服务业（软件产业）发展专项引导资金项目申报单位主要经济指标表》（见附件2）。

（二）对本专项引导资金项目实行限额申报。申报数量结合全省信息产业布局规划和各地信息产业发展的现状、特色、质量等统筹安排，原则上南京市本级不超过50个，苏州、无锡市本级不超过40个，常州市、镇江市本级不超过20个，其他市市本级不超过10个，有关县(指省信息产业厅明确的重点县)原则上每县不超过2个。对申请CMMI等资质奖励认证的，申报数量不作限制，但必须符合上文有关限制条件。

（三）项目申报材料

1、对重点软件产品、重点集成电路产品、信息安全类项目、信息化与工业化融合项目、社会信息化推广项目，申报单位需提供下述材料：

①项目申报书；

②申报单位营业执照复印件；

③经具备资质的中介机构出具的最近三年(2006、2007、2008年)的财务审计报告（如为复印件需加盖审计确认章）。

④信息安全类项目需提供省信息化领导小组办公室批准文件。⑤信息化与工业化融合项目，需提供软件开发企业和制造企业合作开发合同。

3、对CMMI、ISO27001认证奖励，申报单位需提供下述材料： ①企业营业执照复印件；

②CMMI证书(或ISO27001)证书；

③2008经具备资质的中介机构出具的财务审计报告（复印件需加盖审计确认章）。

4、对软件专业人才培训，申报单位需提供下述材料： ①项目申报书； ②单位营业执照复印件；

③软件专业人才培训资质认定证书复印件； ④培训人才证书及其他相关证明文件。对于按有关规定，最低成立年限放宽至1年的企业，应对照规定附相关财务审计报告及其他证明材料，如附件不全或附件不符合规定，则作为企业成立年限不足、不符合申报资格处理。

（四）各市、县（市）软件和集成电路专项经费主管部门会同当地财政部门认真做好省专项经费项目申报组织工作。要深入分析审核企业申报项目的质量，并从技术含量、产品附加值、市场前景及企业能力等方面作出客观的评价，出具推荐意见，并填写《江苏省级现代服务业（软件产业）发展专项引导资金项目材料审查表》（附件2）。

7.软件项目售后服务流程 篇七

一、问题的提出

近几年,中国房地产业快速发展,房地产开发投资额与年俱增,基本上都高于同期全社会固定资产总投资的增速,房地产已经成为推动国民经济发展的重要产业。在房地产业迅速发展的过程中,房地产市场的竞争也日趋激烈,房地产开发商的成功不只取决于现在占有和使用资源的多少,更在于他们识别、创造、有效整合与利用资源的能力,从而规避风险。所以,房地产开发商在开发一个项目前应将市场基本状况、国家政策、消费者选择以及项目特点有机结合,以便把风险降到最低,这其中关键的一项就是做好项目定位。

二、房地产项目定位的概念

房地产项目定位的概念可以进行如下表述:房地产开发经营者经过研究市场前提、技术前提和资金投入状况等一系列与房地产产品生产有关的前提条件,利用科学的方法,构思出房地产项目产品方案,从而在产品市场和目标客户中确定与众不同的价值地位。

三、房地产项目定位研究的主要内容

房地产定位一般包括:产品定位、客户定位和形象定位三部分内容。

(一)产品定位。

产品定位就是形成市场差异化产品,主要包括两部分内容:一是研究房地产市场环境,从而确定市场需求的种类、形式、大小和趋势,为产品定位提供市场基础;二是研究产品构成要素和目标客户消费使用过程,以便确定房地产项目形成过程中的外部和内部条件,分析产品构成的主要因素,形成市场差异化产品。

(二)客户定位。

客户定位是确定房地产项目的目标消费群体和他们的特征。客户定位需要研究消费者的消费行为、消费动机以及消费方式,同时研究消费者自身的人格、观念、所处的阶层、环境、文化背景、偏好和生活方式等。

(三)形象定位。

形象定位主要是找到该房地产项目所持有、不同于竞争对手、能进行概念化描述、能通过广告表达并能为目标客户所接受而产生共鸣的特征。形象定位需要研究房地产项目的市场表现形式,确定房地产项目从产品到商品的过程中的最佳表达方式。

四、房地产项目定位方法

房地产项目定位主要研究如何确定目标客户群体和产品内容,是投资决策的重要因素。项目定位贯穿于市场研究、投资分析、产品规划管理和销售执行,是决定产品未来销售好坏的关键因素。具体来说,主要有以下四种方法:

(一)房地产项目市场分析方法。

房地产项目市场分析方法是指运用市场调查方法,对房地产项目市场环境进行数据搜索、归纳和整理,形成项目可能的产品定位方向,然后对数据进行竞争性分析,利用普通逻辑的排除、类比、补缺等方法形成项目的产品定位。可以通过实地调查、问卷访问和座谈会等多种方法进行市场调查。

(二)项目SWOT分析方法。

SWOT是优势、劣势、机会和威胁的合称,主要是对房地产项目内外部条件各方面进行综合和概括,进而分析项目的优势、劣势、机会和威胁。其中,优势和劣势分析主要着眼于项目自身的实力及与竞争对手的比较,机会和威胁分析是关注外部环境的变化及对项目的可能影响。

(三)建筑策划方法。

房地产项目产品的核心集中体现在建筑环节,同时也是产品差异化竞争优势的产生方式。建筑策划方法就是抓住这一点,根据总体规划的目标,从建筑学角度出发,依据相关经验和规范,以实态调查为基础,经过客观分析,最终得出实现既定目标的方法。

(四)目标客户需求定位法。

目标客户需求定位法是指房地产开发商在物业产品定位时,根据所选定目标市场的实际需求,开发建设出能满足他们个性化需求的产品。比如,各种酒店的投资开发。

五、“西安高新区国家级软件服务外包基地”实例分析

(一)项目概况。

西安高新区木塔寨软件外包基地项目所在地的南北主干道为唐延路,南临城市交通干道———丈八东路,东接太白南路,交通网络完善。项目周边分布着众多的医疗机构、教育机构、金融机构和商业配套,木塔寺遗址位于其间,项目周边生活条件优越、人文景观丰富。项目所在地域,近距离有高新区软件园、信息产业基地、长安科技产业园、银河科技园等大型科技产业基地和大唐电信、东盛集团、海星集团等知名科技企业,科技氛围十分浓厚。

(二)市场分析。

据赛迪顾问预测,到2010年中国软件外包市场规模将达到70.28亿美元,占全球软件外包市场的8.4%,年均复合增长率为50.2%。毋庸置疑,软件外包业务已经成为软件行业发展的新增长点。IDC(国际数据资讯)预计,在2009年之前,软件外包业将保持每年50%的高速增长。计世资讯的研究报告也显示,在未来5年中,中国在IT与服务方面的投入将达到2.3万亿元人民币。由此可见,软件外包行业发展潜力巨大,在未来的几年里需要大量的软件外包基地来满足软件外包行业发展的需要。

西安高新区成立于1991年3月,是经国务院批准设立的国家级高新技术产业开发区,现已完成开发配套35km2。自1994年以来,各项综合指标一直位居全国53个国家级高新区前列,多次被评为全国先进高新区。1997年率先加入APEC科技工业园区组织;2001年被列为“十五”期间国家重点建设的五个国家示范高新区之一;2002年12月被联合国工业发展组织考察认定为六个“中国最具活力的城市和地区”之一;2004年通过了ISO14000验收,成为国家环保示范区;2005年成为全国首家高新技术产业标准化示范区和国家知识产权保护示范园区。目前,正与北京、上海、深圳等地高新区一起,共同建设世界一流高科技园区。

西安高新区作为西安软件服务外包产业示范区和引领区,在西安市委、市政府出台了《关于促进软件服务外包产业发展的扶持政策》后,也及时出台了《西安高新区促进软件服务外包产业发展扶持政策》,表明了西安高新区对发展软件服务外包产业的决心。

综上所述,高新区以其重要的地理位置、良好的软件外包市场投资环境和优惠的产业政策,将依然是众多软件外包及相关行业投资商的青睐之地。

(三)定位分析。

结合市场调研,主要从SWOT(优势、劣势、机会和威胁)四个方面对该项目进行分析:

1、优势分析。

(1)高新区经济高速发展;(2)项目区位优势;(3)投资商资源优势;(4)科技氛围浓厚;(5)西安高新区市政基础设施和公建配套不断完善。

2、劣势分析。

(1)相比其他区域,该项目所在位置现有公交线路覆盖不足;(2)涉及大量的拆迁、安置和补偿,工作进展中将会遇到较大的阻力。

3、机会分析。

本项目存在着以下发展机会:(1)高新区不断发展壮大,被列为国家以及陕西重点开发对象,西安要通过自身的比较优势以及积极营造出的产业环境,来确保成为全球软件服务外包产业中的桥头堡;(2)软件行业持续发展,新成立的软件公司不断出现,对基地的需求强烈。

4、威胁分析。

目前,很多城市的高新区以及西安本地的一些经济开发区都在筹划建设软件园,投资者的选择余地变大,如何吸引投资者进行投资将成为项目实施必须解决的一个问题。

(四)定位结论

1、产品定位。

项目进行包含地上建筑物和建筑物的拆迁、安置、补偿,以及上水、下水、电力、道路、燃气、热力、通信、场地平整等在内的“七通一平”基础设施建设。基础设施建设完成后,将来定位于西安高新区软件外包基地、办公、住宅、商业、城市景观为一体的城市高新科技开发综合配套区。

2、客户定位。

(1)有签约意向的知名软件开发公司的总部基地;(2)已经成立的欲设立分公司的知名软件开发公司;(3)新成立的欲寻找开发基地的中小型软件企业。

3、形象定位。

8.软件项目售后服务流程 篇八

工业和信息化部软件服务业司司长陈伟表示，软件产业具有资源消耗低、带动系数大、就业机会多、综合效益好的特征，是有效推动国民经济结构和发展方式战略性调整的重要引擎。

加快软件产业发展要从改造提升传统产业、培育战略性新兴产业、发展生产性服务业三个方面入手，同时促进以综合集成为核心的技术创新模式和以服务为核心的商业模式创新。陈伟表示，目前以云计算为代表的新计算、新模式打破了传统IT应用的成本限制以及降低IT应用的风险，同时在一体化软件平台体系下，硬件与软件、内容与终端、应用与服务加快整合，软件业已经从传统的单一产品竞争发展到基于体系架构的产业链竞争。

陈伟明确提出，2012年软件与信息技术服务工作要重点推进国发4号文件等政策的落实工作，促进产业做大做强，确保软件产业实现25%，力争28%的增长目标；突破核心关键技术，支持智能终端操作系统和云计算等核心技术的研发；强化服务支撑能力，加快安全可靠关键软硬件的应用推广，提高对安全可靠党政军信息系统和事关国计民生的重要信息系统的支撑能力；完善行业管理和公共服务，推动移动互联、云计算等重点领域的标准、法规和制度建设，不断优化产业发展环境。

9.金蝶软件操作流程 篇九

一、新建账套：软件安装后，双击桌面图标，出现账套登录，点击新建账套。

1、输入文件名（文件名不等于账套名称，可以是账套名称的简称）

2、录入账套名称（即公司的名称）

3、根据公司的需求，选择本位币，会计科目、科目级数、启用账套的时间等

二、初始化：启用账套后，系统自动登陆到初始数据的画面。

1、打开账套选项，根据公司的需要在在所需要的地方打上钩

例：凭证新增后自动不断号：凭证保存后立即新增

2、本位币：人民币做为本位币，有外币增设外币

3、核算项目：

1）如新增往来单位、部门、职员以外的项目，在啬类别的地方新增项目

2）往来单位，涉及到应收、应付、预收、预付等往来管理

3）部门：指公司内部部门

4）职员：指公司内部的职员，涉及到内部的报销等

4、会计科目：新增会计科目，例1002银行存款，新增明细100201商行，如有核算项目。

例：应收账款、应付账款要核算到往来单位，双击应收账款修改，在核算项目的地方，选单一核算往来单位一核销往来。

5、期初数据的录入：根据总账，凭证汇总或试算平衡表录入。

例：应收账款80万，是哪几家的应收账款，分别数是多少。录入完后，试算平衡。

6、试算平衡后，即可启用账套

三、日常账务必

1、在系统维护里----新增凭证字“记”-----维护摘要栏----新增用户授权等。设置用户：工

具-----新增用户（安全码不等于密码，安全码录入大于等于五位的数据）-----授权（A授权所有权限，B对所有用户授权）

2、新增凭证-----录入摘要（按F7选择录入好的摘要）-----按F7或上面的获取选择会计科

目----录入数据（在录入数据的地方要计算的话按F11调入计算器，计算完后关闭计算器按F12数据自动上去）----复制上一条摘要按两点（。或）----试算平衡CTRL+F73、凭证审核：自己录入的凭证自己不能审核，必须按一个人审核，双击右下角的名字更换

操作员，点击审核，有单审核和多审核。点击凭证，调入单张凭证点击审核，再点击一下审核是取消审核。直接点击多张审核（连续多张凭证的话，按住SHIFT键后点第张和最后一张凭证，如果是不连续的多张凭证，按住CTRL键，然后点击第一张凭证）所以凭证一次性审核完。

4、过账

5、损益结转：点击结转损益自动结转，自动生成一张凭证，然后再对这张凭证进行审核，过账。

6、查看报表

7、期末结账：结账之前在“D”或“E”中新建文件夹命名为数据，将数据保存在这个文

件夹里。（这主要是做一个备份，以后所有的备份文件都可以放在这里，以便查询）

10.软件著作权流程 篇十

1、办理流程

填写申请表--→提交申请文件--→缴纳申请费--→登记机构受理申请--→补正申请文件（非必须程序）--→取得登记证书

注释：如已登记软件的著作权发生继受（受让、承受或继承），权利继受方办理著作权登记时需先做软件著作权登记概况查询。（查询申请表可以到我中心网中的“软件登记特别提示”中下载）

2、填写申请表

在中心网站上，首先进行用户注册，然后用户登陆，在线按要求填写申请表后，确认、提交并打印。

3、提交申请文件

申请人或代理人按照要求提交登记申请文件。

4、缴纳申请费

申请文件符合受理要求时，软件登记机构发出缴费通知，申请人或代理人按照通知要求缴纳费用。

5、登记机构受理申请

申请文件符合受理要求并缴纳申请费的，登记机构在规定的期限内予以受理，并向申请人或代理人发出受理通知书及缴费票据。

6、补正程序

根据计算机软件登记办法规定，申请文件存在缺陷的，申请人或代理人应自发出补正通知之日起，30个工作日提交补正材料，逾期未补正的，视为撤回申请；经补正仍不符合《计算机软件著作权登记办法》第二十一条有关规定的，登记机构将不予登记并书面通知申请人或代理人。

7、获得登记证书

申请受理之日起30个工作日后，申请人或代理人可登记我中心网站，查阅软件著作权登记公告。北京地区的申请人或代理人在查阅到所申请软件的登记公告后，可持受理通知书原件在该软件登记公告发布3个工作日后，到我中心版权登记大厅领取证书。申请人或代理人的联系地址是外地的，我中心将按照申请表中所填写的地址邮寄证书，请务必在申请表中填写正确的联系地址。

注释：外地的软件登记申请人或代理人如需自取证书，应当在申请表中申请人或代理人信息栏内的联系人后加注括号，写明联系人的北京联系地址，我中心将不做邮寄处理。

软件著作权登记申请所需文件

软件著作权登记申请文件应当包括：软件著作权登记申请表、软件的鉴别材料、申请人身份证明、联系人身份证明和相关的证明文件各一式一份。如在登记大厅现场办理的，还需出示办理人身份证明原件，否则将不予办理。

1、软件著作权登记申请表

应提交在线填写的申请表打印件，请勿复制、下载和擅自更改表格格式，签章应为原件。

2、软件（程序、文档）的鉴别材料

•一般交存：源程序和文档应提交前、后各连续30页，不足60页的，应当全部提交；

•例外交存：请按照《计算机软件著作权登记办法》第十二条规定的方式之一提交软件的鉴别材料。

注：申请人若在源程序和文档页眉上标注了所申请软件的名称和版本号，应当与申请表中相应内容完全一致，右上角应标注页码，源程序每页不少于50行，最后一页应是程序的结束页，文档每页不少于30行，有图除外。

3、有关证明文件

证明文件包括：申请人、代理人及联系人的身份证明文件、权利归属证明文件等。

①代理人身份证明文件

登记申请委托代理的，应当提交代理人的身份证明文件复印件，申请表中应当明确委托事项、委托权限范围、委托期限等内容。

②申请人有效身份证明文件（单位的需盖公章）

•企业法人单位提交有效的企业法人营业执照副本的复印件；

•事业法人单位提交有效的事业单位法人证书副本的复印件；

•社团法人单位提交民政部门出具的有效的社团法人证书的复印件；

•其他组织提交工商管理机关或民政部门出具的证明文件复印件；

•著作权人为自然人的，应提交有效的自然人身份证复印件（正反面复印）；

•著作权人为外国自然人的，应提交护照复印件，及护照复印件的中文译本，并需翻译者签章。同时，需提交非职务开发保证书或非职务开发证明。

•著作权人为香港企业法人的，应提交注册登记证书和有效期内的商业登记证书正本复印件，并需经中国司法部委托的香港律师公证。

•著作权人为台湾企业法人的，需出示经台湾法院或公证机构认证的法人身份证明文件，填写并提交《台湾法人证明》。

•著作权人为外国法人及其他组织的，应提交申请人依法登记并具有法人资格的法律证明文件，该证明文件须经过中国驻当地领事馆的认证或经当地公证机构公证方为有效。申请时需提交公证或认证的证明文件原件。目前国外法人因所在国家或地区不同，其提交的法人身份证明文件内容和格式会有所不同，但文件中的基本信息项应至少包括

1、法人名称；

2、注册日期、3、注册地、4、注册证明编号、5、证明文件的有效期等基本信息。

以上身份证明文件以及与登记有关的其它证明文件（例如：合同或协议等证明）是外文的，须一并提交经有翻译资质的单位翻译并加其公章的中文译本原件。

③ 联系人证明文件

申请人自行办理的，需提交联系人身份证明（身份证、护照、军官证等）复印件；委托代理人办理的，需提交联系人（申请联系人和代理联系人）身份证明复印件

④ 权利归属的证明文件

•委托开发的,应当提交委托开发合同；

•合作开发的, 应当提交合作开发合同；

•下达任务开发的, 应当提交上级部门的下达任务书；

4、其他证明文件

修改他人软件应当授权许可的，应当提交授权书；

受让取得软件著作权的, 应当提交软件著作权转让协议；

享有著作权的法人或其他组织发生变更、终止后，由承受其权利义务的法人或其他组织享有著作权。登记时，需要提交有关企业变更（合并或分立）、终止的股东会或董事会决议、企业合并协议、清算报告、企业注销证明等相关证明文件；

继承人继承的，需要提供的证明文件包括：被继承人的死亡证明、被继承人有效遗嘱、与被继承人的关系证明、继承人身份证明、法院的法律文书等。

如已登记软件的著作权发生继受，权利继受方办理著作权登记时需做著作权登记概况查询，查询结果是办理登记申请的文件之一，并交回原登记证书。注释：申请文件应当使用A4纸张，纵向、单面打印，文字应当从左向右排列。文档和源程序需黑白打印。申请文件各部分应当分别用数字顺序在右上角标注页码。所有登记材料中出现的版本号，应与申请表中保持完全一致。

11.软件开发流程方法探析 篇十一

1 国内外软件工程理论应用现状

国外的软件工程理论的应用相对比较成熟,其中表现最为突出的是印度。印度作为亚洲最大的软件外包大国之一,其软件工程的思想在软件开发流程中的应用是比较好的。整个软件开发过程已经完全成为一个流程化的过程。其软件开发行业30%以上的编程人员的流动性对软件开发工程不会造成什么影响,可见他们的编程规范及流程规划的水平。从以下特点之中可以找到其软件开发行业发展如此成熟的答案[2]。(1)流程重于项目;(2)软件质量管理独立于研发部门,专门检查研发部门的开发流程是不是按照既定流程走,如果软件质量管理人员觉得流程不对,会直接上报高层,项目肯定就此停止;(3)所有的东西(包括草稿)都有文档,详细文档要求达到只有这个文档就可以编码的程度,一般写文档时间占60%,编码时间极少;(4)有各种详细的同行评审,包括项目组内,项目组件以及与客户之间的沟通。而中国相对于印度而言差距很大,这种差距不在于研发技术是否先进,而是在于软件工程的思想重视与运用水平的差距。从开发团队上来看,中国的开发团队人员过少,仅仅是″作坊式″的开发方式,软件的生产速度、产量和品质上都与印度等国家差距日渐变大[3]。因此,从根本上重视软件工程的开发思想,严格执行软件开发的规范流程,将是改变我国当前软件开发现状的有效途径。

2 软件系统开发流程分析

典型的软件过程有Waterfall Model(瀑布模式)、Iterative&Incremental Model(反复渐进模式)和Spiral Model(螺旋模式)[4],无论采用哪种模型方式,软件开发过程最起码要包括支持软件整个生命期的活动。基本的生存周期包括软件计划、需求分析、总体设计、详细设计、编码及单元测试、综合测试、移交及软件维护。

由此可以看出,需求分析阶段是软件开发流程的第一步,是软件开发最首要的工作,直接影响到软件设计和开发的一切流程。如果需求分析工作不到位,将会导致与用户要求存在偏差的严重后果。国内软件企业对需求分析工作的重视程度普遍低于流程中的设计和开发。国内大部分企业特别是小软件企业将70%的时间花在软件设计开发上,需求分析过程只占整个流程中的l5%。相比之下,国外开发企业是40%的时间进行需求分析,比设计开发时间还多10%[5]。需求分析阶段要根据软件开发需求特点确定采用何种软件工程方法进行设计。目前比较典型的方法有结构化的方法、面向对象的方法、基于构件的方法、基于A-gent的方法、基于净室技术[6]以及基于敏捷技术的方法等。由于后三种方法相对是针对某些特殊用途而产生的,适用性上有很大的局限性,有待进一步完善,因此,仅对主要的三种方法在操作单位、方法特性等方面进行了比较,如表1所示。

从表中可以看出,基于组件和面向对象的方法更适合于当前复杂的开发应用,成为当前的主流方法。如图1所示需求分析阶段还包括可行性研究,需求确认和需求复合等工作。对于设计阶段而言,包括总体设计、概要设计、详细设计,同时形成相应的文档。然后进行编码的实现,综合全面的测试,包括单元测试、系统间测试、系统整体测试、性能测试、极限测试以及上线的运行测试等,最后进行文档、培训和维护的工作。中间某些环节会根据实际的用户需求的改变进行反馈,修改和完善。

3 结束语

综上所述,软件工程技术和方法在不断发展。为了设计出大规模、复杂度高的软件,必须有更高水准的结构设计技术。目前越来越受到软件工程研究者关注的是把对象群作为角色、将各种角色进行拼装组合的技术。不管是已经出现的技术,还是行将推出的方法,十全十美的软件开发方法是难以寻觅的,真正实用的技术或方法往往是多种开发方法的结合。

摘要：首先对国内外软件开发理论的应用现状作了比较,然后重点分析软件系统开发流程,综合分析比较软件开发流程的各个阶段。

关键词：软件工程,软件开发,流程

参考文献

[1]Meyer B.Object-oriented Software Construction.北京:清华大学出版社,1998.

[2]姜火文.软件工程方法的演进.北京:科技广场,2005,(5):114-115.

[3]李蕾.企业未来的软件架构—面向服务的体系架构.北京:电脑知识与技术,2005(33):60-62.

[4]李松领,金蓓弘.软件过程的比较框架研究.北京:计算机科学,2004,31(5):72-76.

[5]伍晏.软件开发结构化处理初探.北京:企业技术开发,2005,24(10):55-56.

12.软件配置管理规范流程 篇十二

本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。

1.2 适用范围

本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。

1.3 术语和缩略语

1.3.1 软件配置管理（Software Configuration Management，SCM）软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。

1.3.2 配置项（Configuration Item，CI）

凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。

每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

1.3.3 基线（Baseline）

在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其修改要严格地按照变更控制的过程进行。在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。

基线的主要属性有：名称、标签、版本、日期等。1.4 权限与职责 1.4.1 研发总经理助理 1）审核变更请求。

1.4.2 项目经理（Project Manager，PM）1)审核批准配置管理计划； 2)接收或拒绝小范围的变更申请； 3)召集评估变更；

4)提出配置管理的建议和要求； 5)配合配置管理员的工作。

1.4.3 配置管理员（Configuration Management Officer，CMO）1)编写配置管理计划；

2)执行版本控制和变更控制方案； 3)制定访问控制策略；

4)负责项目的配置管理工作，包括搭建环境、权限分配、配置库的建立、配置项的控制等；

5)配置管理工具的日常管理与维护； 6)配置库的日常操作和维护； 7)负责配置审核并提交报告；

8)根据配置部署表单编译发布版本，并维护版本； 9)对开发人员进行相关的培训；

10)对配置审核中发现的不符合项，拟订纠正措施，要求相关责任人进行纠正。

11)监督项目组成员规范的执行情况。1.4.4 开发人员（Developer）

1)根据确定的配置管理计划和相关规定，提交配置项和基线； 2)负责项目组内部测试； 3)负责软件集成和版本生成；

4)按照软件配置管理工具的使用模型来完成开发任务。2 实施细则 2.1 配置项管理 2.1.1 配置项的范围

软件配置可包括以下几方面：开发文档，代码，第三方控件、插件，参考资料，测试文档，用户文档，项目管理文档，验收文档等。

l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录。

l 代码主要指：源代码等。

l 工具主要指：脚本文件、插件、第三方控件等。2.1.2 配置项基线管理

结合SPP和ISO9000的相关规定，配置管理员根据配置管理规范及配置管理计划，对配置项进行分阶段管理，每一阶段正式评审通过后纳入受控库，作为该项目的一个基线。

l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档，评审或审批通过后建立发布基线。

l 需求阶段：系统调研后开发人员进行需求分析，并整理产品需求规格说明书。产品需求规格说明书经过客户的确认后，建立需求基线。如需升级版本则必须通过评审或审批并得到客户的确认。

l 项目计划：需求分析完成后即可制定项目的开发计划，包括项目计划和主要下属计划。包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划。项目开发计划评审通过后，建立项目计划基线。

l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。针对用户需求规格说明书进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计说明书评审或审批通过后，建立设计基线。l 编码（设计实现）：编码按功能模块分子项目，即每个模块记作一个配置项。代码在提交项目组系统测试时建立Beta版本，系统测试产品正式发布后建立Version版本。

l 测试：单元测试和系统测试。单元测试通过提交《单元测试报告》，项目启动后应提交《系统测试计划》，系统测试完成后应提交《系统测试报告》。配置时应说明测试的版本与编码版本的对应关系。系统测试完成后建立测试基线。

l 版本发布：项目组提交《部署表单》，CMO根据部署表单进行编译，发布测试服务器上，并对版本进行维护。同时将发布的版本上传到文档服务器上备份。

l 交付与验收：在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置项，包括交付文档、代码、工具等。

l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档。

l 相关资料：相关资料也应作为配置项纳入配置管理，此部分包括： 1)相关法律、法规；必须遵照或项目组约定的技术规范；

2)与客户或项目组内部重要的交互信息记录，如会议记录、会谈记录、e-mail和MSN记录等；

2.2 版本控制 2.2.1 文档的版本控制

所有文档的管理纳入配置管理库，用版本控制工具进行统一管理。文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现，主要分为以下几类：

2.2.1.1 版本变化型文档

命名方式：[文档名称]+[子系统名称]（可选）

适用文档：项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等。

示例：项目计划.doc 详细设计_SP门户.doc 标签结构：[大版本] + [子系统简称] + [版本号] + 日期（标签控制说明版本信息）

l [大版本]： 可选，表示同一项目为不同用户定制的版本。l [子系统简称]： 可选，当一个项目有多个子系统时，为区分不同子系统而设置。

l [版本号]：采用[Vs_x_y]的形式。

l 日期：纳入基线管理的日期，用8位表示，如20071031 说明：

a.文档发布名称采用[文档名+ Vs_x_y]的形式，文档的版本号应该和版本控制工具中相应标签上的版本号一致。

b.对文档的修改需要从配置管理库中取到本地进行。

c.对于文档小的修改，如文字错误，格式调整，变更Vs_x_y中的y来区别（如：V1_0_1）。

d.文档内容没有大的增加和删节，意思表述没有发生重大的变化，版本标识通过版本工具中加上x标签来表示（如：V1_1_0），以及在文档内部控制页标注变化来表示。

e.文档有重大增加和删节，意思表述有重大变化的，版本标识通过在相应文档加上s标签来表示（如：V2_0_0）。

f.对于纳入基线库的文档的修改需要提交变更申请，经批准才能进行修改，并且修改的内容要经再次评审才能重新纳入基线库，作为后续阶段的参考文档。

2.2.1.2 时间区别型文档 命名方式：[文档名称＋撰写时间] 适用文档：文档名称有明确的含义，需要用时间标识的日常性文档。如周例会会议纪要，项目月计划，项目月总结,阶段性计划等等。

示 例：周例会会议纪要20030901.doc 2.2.1.3 时间序号型文档

命名方式：[文档名称+人员姓名（拼音）+撰写时间+序列号] 适用文档：测试报告

示例：单元测试报告_lixiaohong_20071112_01.dco 2.2.1.4 其他文档：

对于不能按照前四种类型进行命名的文档 会议纪要：会议纪要YYYYMMDD()示 例：9月9日召开的项目启动会 命名为：会议纪要20030909(项目启动).doc 评审报告：评审报告YYYYMMDD()同”会议纪要”要求一致。

示 例：10月9日召开的项目总体方案评审 命名为：评审报告20030910(总体方案).doc 2.2.2 发行版本表示

发行版本采用标签说明，结构如下：

[大版本] + [版本类型] + [版本号] + [子系统简称(拼音)]+日期 +序号 [大版本]： 可选，表示同一项目为不同用户定制的版本。

[子系统简称]： 可选，当一个项目有多个子系统时，为区分不同子系统而设置。

版本类型：分为3种

Beta表示项目组内部测试，标签：B1_0_0-20071015-01 Release系统测试，标签：Release1_0_0-SPmenhu-20071112-01 Version正式发行版，标签：Version1_0_0-SPmenhu-20071112-01 [版本号] 对于Version正式发行版 是必须要注明的，而其它可选。发行产品基线在版本号前加Version，如

Version_1, Version_2, Version_3….表示分支；

Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的标签； Version_0_0, Version_0_1, Version_0_2… 表示在主线上的标签。2.3 配置库管理 2.3.1 配置库的分类

配置库统一由配置管理员负责管理，服务器端使用cvsnt2.0.4，客户端主要使用乌龟CVS。配置库目录结构如下：

2.3.2 配置库的建立 所有项目应建立配置库，以便管理各配置项，配置管理员组织建立配置库。程序库主要通过设置版本的分支来实现对配置项权限管理：

1)开发库：开发人员相对比较自由的存储空间，开发人员可以在自己的权限范围内任意取出提交。

2)基线库：配置管理员有最高权限，其余相关人员均为读的权限，发生变更时变更人员须提交变更申请后方可修改基线库内的配置项。

Ø 文档评审通过后，文档严格受控。由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除。

Ø 代码一般在移交系统测试时纳入基线库受控，可根据项目的具体情况设置基线。

3)产品库：产品库的产品均出自于基线库，产品库存储的产品用于交付和存档。

配置三库统一由配置管理员管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

2.3.3 分配权限

项目开始后配置管理员编写《配置库目录结构表》明确项目组成员以及相关人员的权限。在wincvs里有三种权限，读（r）、写（w）、添加删除（c）权限。在开发库内，文档部分项目组成员有rcw权限，其他相关人员只r权限；代码部分项目组成员有rcw权限，其他相关人员没有任何权限。在基线库内，项目组成员仅有r权限，其他相关人的权限视情况而定。在产品库内，所有人没有任何权限。配置管理员在三库内均拥有最高权限。

2.4 配置变更控制 2.4.1 变更的分类

软件及其相关文档的变更按照变更的影响范围进行分类：

1)A级：变更会影响系统级的需求、外部接口、产品价格或者交付期；这类变更必须经过配置管理委员会审核并有客户批准和确认。

2)B级：变更会影响配置项间的功能接口、内部功能的设计、组件；这类变更必须由项目经理或配置管理委员会的批准和认可。3)C级：变更只会影响配置项内部或对BUG问题的处理；这类变更可以由配置项的管理人员负责批准。

Ø 系统测试前变更控制流程：

Ø 系统测试完毕发布release版本后变更控制流程

图2 变更控制流程 2.4.2 变更请求的提出

a． 由技术支撑中心汇集顾客意见，影响到需求变更则填写《配置项变更控制报告》，并提交给配置管理员。

b． 配置管理员对申请表是否清晰、明确和完整性进行审查，若发现变更不明确或不完整，应返回申请者。对通过审查的变更申请分配变更ID，以便跟踪和记录变更信息。

2.4.3 评估变更

a． 配置管理员将《配置项变更控制报告》发送给项目经理（或者其他授权人员），由项目经理负责对变更进行评估。

b． 项目经理对变更进行分解，一般的BUG修正不需要审批直接由项目经理决定是否需要变更。新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更。变更评估文档在完成变更评估后发送给配置管理员。

2.4.4 变更实施和确认

a． 变更被批准后，项目经理提交变更实施进度计划，开发人员开始实施变更，并详细记录变更的内容；质量部对变更的实施进行跟踪。

b． 对于代码变更，必须进行回归测试，以确保变更没有引入新的Bug。另外与变更相关的文档必须修订，以反映变更。当变更以及测试完成后，进行提交。

c． 通过测试后，质保人员需对变更进行审核，审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号。

a． 审核后，由配置管理员更新到基线库中。2.5 配置状态报告 2.5.1 目的

记录和报告整个软件生命周期演化状态。2.5.2 记录内容

配置状态报告记录的内容包括： 1)软件和文档的标识； 2)目前状态； 3)基线演化状态； 4)变更状态； 5)版本交付信息等。2.5.3 生成报告

配置管理报告自第一个基线创建时建立，由配置管理系统生成，及时反映当前配置状态。

2.6 配置审核 2.6.1 类别 配置审核分为：

1)功能配置审核（Functional Configuration Audit，FCA）：审核软件功能是否与需求一致，并符合基线文档要求，通常要审查测试文档等。

2)物理配置审核（Physical Configuration Audit，PCA）：审核要交付的组成项是否存在，是否包含所有必需的项目，如正确版本的源代码、资源、文档、安装说明等等。

2.6.2 执行时机

通常选择以下几种情况由质量保证人员负责实施配置审核： 1)软件产品交付或是软件产品正式发行前； 2)软件开发的阶段工作结束后； 3)在产品维护工作中，定期地进行。2.6.3 不符合项处理

对配置审核中发现的不符合现象，配置管理员进行记录，并交由责任部门限期进行纠正，配置管理员负责纠正措施的验证。所有的不符合项报告均关闭后，才能发布新版本。

2.7 发行管理

通过配置审核后，经项目经理批准，由配置管理员负责生产新版本。2.7.1.1 交付管理

这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付出去的配置项必须有据可查，避免发生混乱。流程如下：

1)交付人向质量部申请；

2)质量部如果不同意交付，则拒绝交付配置项。如果同意交付，配置管理员应给出详细的交付清单；