软件开发项目项目管理8篇(全文)

软件开发项目项目管理（精选8篇）

软件开发项目项目管理 第1篇

1.负责项目管理软件的全部开发管理工作。

2.负责开发工作计划的制订、任务安排、工作检查和考核。

3.负责项目管理软件相关的开发代码、配套文档的管理工作。

4.负责开发队伍的建设和培养。

软件开发项目项目管理 第2篇

1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。

2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。

3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。

执行概述

1、建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。

2、明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。

3、跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。

4、解决项目过程中出现的问题和冲突，一般集中在需求不明/工作量或时长/开发难度/跨部门协调等几个方面。

5、调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。

6、风险识别、风险控制以及风险的预案。

项目管理

1、需求阶段

对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求讨论，明确项目的目标、价值。确定项目范围、功能及优先级。

组建项目团队，特别要搞清楚项目的关键人。项目启动会议，相关的关系人都必须参加。

2、设计阶段

根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。

设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。

该阶段交付成果需要进行评审。

3、执行阶段(开发和测试)准备开发环境、测试环境。跟踪，推动项目按计划进行。

项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。按里程碑对阶段成果进行评估，以确保该阶段完成的质量。代码审核，包括CS审核、SQL审核、WEB审核等。对需求变更进行控制管理。

测试阶段BUG响应及改进、收集反馈意见。对项目风险进行管理。

4、发布阶段

包括制定项目发布计划，用户培训，发布上线。

5、试运行阶段

数据监控(日志、服务器状态)，根据监控出现的问题，及时进行处理，改进性能问题，特定情况执行补丁升级。

6、收尾阶段

产品交付，项目总结会。

常见问题

1、开发时间的估算

制定项目计划时，需要估算每个任务所需的时间，其中主要是开发任务中模块的分配和时间估算，在公司现有的技术框架下，开发人员主要的工作是投入在具体的业务逻辑实现上。通常单个模块开发时间取决于以下因素：

1、负责模块的业务逻辑的复杂程度。

2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度)。

3、模块技术实现上是否存在难点，所谓的技术难点定义是：在现有系统中还未实现的、开发人员自身未没接触过的技术。对于这样的难点，开发者没有相关的代码可以参考，自己也没有经验，所以需要投入学习时间用于研究解决。

模块分配和开发时间估算的步骤：

1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。

2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下：

A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。

B、技术难度较大的模块由技术水平比较高的人负责。C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。

3、模块分配完成后，开发人员评估自己负责开发的模块所需要的时间。在此过程中应

4、对开发人员估算的时间进行确认。在确认过程中作为，项目管理者将预估时间和开与开发者讨论每个模块的技术实现细节，使时间的估算更加准确。发人员估算时间进行比较。那些差异较大的，与人员探讨其中的缘由。对于时间周期比较长的任务，将任务拆分为更小的子任务，每个任务的完成时间为8-24工时，消除时间周期较长的任务，避免不确定性影响项目的进度。

2、CodeReview CodeReview是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是测试后出现大量bug的主因，有时甚至导致返工；关于CodeReview执行，首先应有编码规范和代码审查规范。通过这两个文档来规范开发人员的代码实现，代码编写者必须要严格按照规范来进行；代码审核者根据这些标准来CodeReview代码，同时在CodeReview过程中需要不断完善该文档。

CodeReview一般可按以下步骤实施：

1、检查开发者的代码实现是否遵循了编码规范。

2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。

3、代码编写者和代码审核者坐在一起，由代码编写者按照UseCase依次讲解自己负责的代码和相关逻辑，代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug，对这些bug记录在案。

4、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要检查Bug。同时全面兼顾，确保代码整体上结构优良；审核完毕后，代码审核者编写“代码审核报告”记录发现的问题及修改建议，提交给相关人员。

5、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。

6、代码编写者bugfixed完毕之后给出反馈。

7、代码审核者把CodeReview中发现的有价值的问题更新到“代码审核规范”的文档中，对于特别值得提醒的问题可群发email给所有技术人员。

3、需求变更管理

需求变更管理也是项目管理中最重要的一个环节，对需求变更管理的有效性将直接影响对待需求变更的正确态度：

1、需求变更是不可避免的。

2、需求变更要必须被管理。

3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。需求变更管理的目标：

1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。需求变更流程：

1、确定需求的基准线。将以UserCase作为需求基准线，在UserCase确认之后的任项目的成功与否。何需求改变，都需要走需求变更流程。

2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。

3、项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。项目管理者对项目的成功与否负有主要的责任。需求变更的决策应由项目管理者做出。

4、需求变更确认后，由专人将生成需求变更单记录下来，通知给项目中所有关系人。

5、确定变更的负责人。承担需求变更的具体工作，比如基线控制，对需求变更的记录，并通知相关人员。

6、相关人员接收到确认的需求变更后，需求分析人员修改需求说明书和UserCase的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。

7、按照变更后的计划实施项目，并进行检查，跟踪，对变更后的实施反馈和可能出现的问题及时沟通和处理。

8、需求冻结。项目越到后期，需求变更对项目的影响就越大，所以在一定时候要进入需求冻结阶段，不再接收新需求或需求的变更。

4、风险管理

影响项目成败的因素涉及方方面面，并且风险伴随着项目的始终，是客观存在的，风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，常见风险如下：

1、目标以及需求不明确

为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或口头的传达上，没有正式的业务需求文档，在没有明确的需求范围的情况下，有时为了迎合业务部门的口味匆匆开工，过程中用户不断地提出新的想法，技术人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。

在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。

2、项目目标扩大以及需求变更

在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求。

前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户)，所有的需求要经过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、UserCase确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。

3、代码质量风险

质量风险主要指开发代码的质量。在制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响很大。开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发质量问题。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发非常重要。

往往有这样一种情况，每个团队成员按照项目计划报告进度都是100%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题。这需要在项目实施过程中采取有效的措施来规避风险，通常的做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以发现架构设计问题；管理评审，通过组织级的质量审计看产品以及实施过程是否满足质量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要求的代码，走查通常能够发现50%-70%的错误；每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。

4、人员技能和资源的不足

项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见，一个熟练的技术人员完成同样一个任务需要3天，但一个新手可能就需要7-10天。项目管理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的角色，及时采取相应的技能培训，以保证项目的顺利实施。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风险在后期或中期出现。

5、缺乏良好的团队协作

软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。

6、项目会议

组织会议是项目执行过程中一项非常重要的工作任务，项目过程中很多重要的决定都是在会议中做出的，不成功的会议会对项目本身造成了不好的影响。

不成功的会议通常表现为如下形式：

1、会议氛围不好，参与者发言不踊跃；

2、会议讨论常常偏离主题；

3、会议没有取得预期的结果；

4、会议时间常常一拖再拖。

这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的，很多人都对这样的会议都有抵触情绪，对此也是深恶痛绝。以下是组织会议时应该注意的问题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：

1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有可能取得成功，这是会议成功的充分条件。

2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只是一个发表想法的人，他不用对会议的成功承担责任。

3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。组织会议的十一条最佳实践：

1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。

2、提前发出会议议程，以便会议参与者知道他们来做什么。

3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确保必要人物都在的情况下一次会议参与者越少效果越好。

4、提前预约参与者的时间，以确保他们能按时到场。

5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在开场时说： A、再一次强调会议的目标，我们来做什么。

B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。

C、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人的讲话，等别人说完你再说等等。

6、会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。

7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。

8、会议要有结论。我们常在会议上听到有人说：“大家讨论了这么半天，结论呢？”。没有结论的会议是没有意义的。

9、会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。

10、会议后的action执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。很多会议往往都不注意这一点。

软件开发项目简易管理法 第3篇

关键词：软件开发,项目管理,简易管理法,软件工程

1 软件项目组织

一个中小型软件开发项目的项目组, 一般包括以下角色:项目负责人、项目经理、质量保证人员、配置管理人员、需求调研人员、需求分析人员、系统设计人员、程序员、测试人员等。

在目前国内的很多软件公司中, 这些角色往往都是有重合的。一般, 需求调研人员、需求分析人员、系统设计人员, 都是由公司的核心技术人员或项目经理担任。质量保证、配置管理、测试人员等, 都是由公司统一人员担任, 对于实际的项目过程, 并没有过于介入, 对实际的项目开发过程, 不会产生多大的实际影响。因此, 项目的成败, 很大程序上取决于公司的核心技术人员和项目经理。

2 软件开发阶段划分

软件开发项目, 在软件工程的阶段划分基础上, 可以将其分成以下几个阶段: (1) 计划阶段:包括可行性分析、立项等; (2) 开发阶段:包括制定开发计划、需求调研、需求分析、系统设计、编码、单元测试、联合测试等; (3) 安装试运行:客户实施测试、验收等。

下面, 分别对各阶段所要完成的任务及提交的成果进行说明。

2.1 计划阶段

在计划阶段, 首先是由项目的发起人, 即项目负责人, 根据需求, 提出完成此项目的要求。此需求, 可能来源于软件产品的市场需求, 也可能来自客户的定单开发要求等。

在项目提出后, 需要进行可行性分析、论证, 主要是对项目的政策可行性、技术可行性、经济可行性等方面, 进行分析论证。只有在不违反各项法律、法规、国家政策的前提下, 在现有的技术条件下可以解决项目的所有技术问题, 并且对此项目的产出比投入更多时, 此项目才是合理的, 才能正式立项。一般, 可行性分析需要提交一份《可行性分析报告》, 但对于大部分的小项目来说, 可行性论证, 一般是由项目负责人, 组织几个核心人员讨论一下, 如果认为可行, 就可以立项, 不是一定要编写《可行性分析报告》的。

在完成可行性分析之后, 需要完成一个正式的立项过程。立项过程不能省略。实际执行时, 可以由总经理或相关副总经理主持, 召集此项目的所有参与人, 以及和此项目有关的资深技术、业务人员参加。主要明确以下内容:项目背景、项目目标和范围、项目开始完成时间、项目设计依据 (指需求来源、主要支撑技术、已有产品基础、外部接口等) 、系统主要技术方案 (比较粗的方案) 、项目组织 (明确指定项目经理, 并确定各参与人员的职责) 、项目奖励 (根据情况可有可无) 等。这些内容, 一般是在立项会议之前讨论, 在立项会议上, 一般是宣布结果, 并将以上内容, 形成正式的立项文档。如果有些内容, 在立项会议上不能明确的, 则在制定开发计划时, 一定要明确。

2.2 开发阶段

在立项完成之后, 就进入了正式的开发阶段。此时, 项目控制权, 就交到了项目经理手上。一般的中小软件开发项目, 具有以下特点: (1) 开发周期短, 一般在2周～6个月, 时间安排比较紧凑; (2) 参与人员少, 一般在4～10人, 而主要的工作, 大都集中在一、两个人身上。

因此, 在实际的开发过程中, 并不是严格按照开发阶段的6个过程执行, 而是有交错的。即不是在开发计划、需求调研、需求分析完成后, 再进行系统设计和编码, 而是根据情况, 需求、设计和编码同步进行。

这里, 假定核心人员只有一人, 即项目经理, 因此, 开发计划制定、需求调研、需求分析、系统设计等工作, 都是由项目经理来完成的。而程序员不可能等到项目经理的这些工作全部完成之后, 才开始编码。一般情况下, 由项目经理先安排一些相对独立的编码任务, 如某些专用的设备操作、通讯等。同时, 项目经理根据情况, 完成以下工作: (1) 完成一个初步的系统设计, 可以只包括系统主体框架设计、模块划分等, 以便程序员能进行下一步工作; (2) 制定项目开发计划; (3) 开展需求调研、需求分析工作, 并完成需求说明书。

以上工作的先后顺序, 根据实际情况而定, 总的原则是让程序员必须有事情做, 不能造成时间的浪费。如果核心人员不止一人, 则以上工作, 可以由其他的核心人员一起参与完成。其他有关程序员的工作不变。这里, 需要项目经理具备比较高的水平, 不会因为这些工作没有完成, 造成前期安排给程序员的编码工作失误。

项目经理在完成以上工作后, 再完善系统设计。而此时, 程序员的各项工作, 都可以正常开展了。项目经理下一步的工作, 就要开始制定测试计划、编写测试案例。同时, 在程序员完成单元测试后, 根据测试计划和测试案例, 组织测试。

这一阶段, 需要提交的成果主要有:《项目开发计划》、《需求说明书》、《测试计划》、《测试案例》、程序等。

2.3 安装试运行

在通过内部的联合测试之后, 需要将软件安装到客户的正式运行环境中, 并用正式的数据进行测试, 然后通过客户的验收测试。

此安装试运行的工作, 并不需要全体程序员的参与。在此期间, 各程序员应首先解决试运行过程中发现的问题, 在多余的时间里, 则要补齐《详细设计文档》, 并在源程序中, 加上相应的注释说明, 同时, 项目经理要安排人员编写《安装维护手册》、《用户使用说明书》等。

如果此软件项目暂时还没有客户, 则此项目就没有安装试运行这一过程, 但是, 《详细设计文档》、《安装维护手册》、《用户使用说明书》等文档还是要写的。

在全部的文档补齐, 并通过客户验收之后, 则需要将与此项目有关的所有资料、文档、程序, 分类归档, 入配置库, 到此项目正式结束。

3 有关注意事项

在软件开发过程中, 为保证项目开发的顺序进行, 要特别注意以下几个地方:

3.1 项目开发计划

在制定项目开发计划书时, 要明确指出:项目背景、项目目标和范围、项目设计依据、系统主要技术方案、项目组织、具体时间安排等。这里, 有些内容, 可以从项目立项书中获得。

3.2 需求调研

需求调研可以根据情况进行。一般的项目管理方法中, 都要求提交需求调研报告, 但在这里, 我们对此不强求, 因为, 需求调研的人和需求分析的人, 一般为同一个人, 因此, 只需要提交需求调研的记录即可。

3.3 需求分析

需求分析是一个很重要的过程, 提交的《需求说明书》, 也是一份必须的、非常重要的文档。此需求说明书, 必须要尽量详细、全面、用词准确, 在完成后, 一般要组织讨论, 并得到客户或项目负责人的签字认可。

3.4 系统设计

一般认为, 系统设计是技术上的事情, 但这里, 要特别说明一下, 项目管理上, 对系统设计, 也是有一定影响的。

项目管理上, 要求开发的总的工期最短, 因此, 要求程序员编码的工作、测试的工作能并发进行。因此, 在系统设计时, 就要考虑到这个因素, 在系统结构设计、模块划分时, 要尽量降低模块之间的关联度, 使编码、不同模块的测试能同步进行, 而不会造成一个模块在测试时, 发现问题, 而另一个模块在此问题修改之前, 就无法测试的情况。

3.5 测试案例

测试案例的编写, 是根据需求说明书来写的。在实际编写测试案例时, 要先根据需求说明书, 写出测试条目, 然后根据测试条目, 逐个写出测试案例。另外, 在测试案例中, 要有需求编号和需求说明书相对应, 以便测试时参考。

当然, 对于一些很小的软件开发项目, 可能有很多人不会去写测试计划和测试案例, 但是, 这里还是要建议, 至少写出测试时间安排, 列出测试条目, 以防止测试的无计划性, 部分功能没有测试到。

3.6 项目过程监控

项目过程监控, 是一项很重要的内容, 是确保项目得以顺序完成的保障。同时, 项目监控, 又是一项很困难的事情, 因为程序员总是不知道, 什么时候可以完成他们的程序。

在这里, 提供以下过程监控方法: (1) 首先要求程序员按照开发计划, 完成各项指定的工作; (2) 根据开发周期, 要求程序员每天或每周, 汇报工作内容和工作进展情况; (3) 对于指定工作, 程序员无法按计划完成的, 要及时汇报; (4) 程序员遇到的技术难题, 或要花时间比较多的问题, 要及时汇报; (5) 因各种原因, 导致指定工作无法继续执行的, 也要及时汇报; (6) 因原定工作任务延期或因事先没考虑周全需要增加新的开发任务时, 项目经理要及时更新修改项目开发计划, 并上报项目负责人, 通报项目组所有成员; (7) 项目组定期或不定期开展交流活动, 交流各程序员的工作情况和遇到的问题, 并协调相互之间的工作; (8) 项目经理要定期汇总项目进展情况, 上报项目负责人, 并通报项目组所有成员。

4 结束语

本文所论述的软件开发项目简易管理法, 去除了CMM和软件工程中一些比较麻烦、实际操作过程中难以执行的部分, 并调整了部分开发过程的执行顺序, 如系统设计分两步执行, 编码和系统设计同步执行等。此简易管理法, 特别适用于一些中小型的软件开发项目, 具有可操作性, 同时又能有效地管理项目开发过程, 保证项目的顺利完成。

参考文献

软件开发项目质量管理措施探讨 第4篇

关键词：软件开发;质量管理;措施

一、软件开发项目质量管理的原则及必要性

（一）软件开发项目质量管理的原则。在我国企业发展的过程中，对软件的依赖程度越来越高，由此也促使企业对软件质量的要求逐渐提升。软件企业在开发软件的过程中，已经充分的认识到了软件质量的重要性，因此，在进行软件开发时，会严格的按照相关的原则来进行，进而有效的保证质量要求。一般来说，软件开发时应该遵循的原则主要包含三点：第一，尊重客户需求原则，软件开发的目的就是为了满足客户的需求，因此，这是最基本的原则，同时，在与客户合作的过程中，要以互利为基础，将质量管理贯彻到软件开发过程的始终;第二，建立完善的质量管理体系原则，质量管理并不单单针对某一个软件开发项目，而是包含所有，因此，通过质量管理体系的构建，保证软件开发项目均具备较高的质量，实现良性循环;第三，重视软件开发团队精神原则，软件开发团队是软件开发项目顺利实施的保障，当团队精神比较好时，软件开发项目的质量就会比较高，因此，在进行质量管理时，必须要重视团队精神。

（二）软件开发项目质量管理的必要性。现如今，我国的软件开发行业已经发展的比较繁荣，软件开发技术也已经发展的比较成熟，软件开发行业属于知识密集型的行业，软件开发人员所具备的智力水平、知识水平都比较高，在进行软件开发的过程中，影响因素比较多，这都会在不同程度上影响软件的质量，由此，质量的保证就是一个比较困难的问题。如果前期开发的软件质量比较差，那么在投入使用之后，后期的维护、运营等成本都会增加，同时，还存在着安全隐患，甚至会带来不可预估的影响，基于此，软件开发项目的质量管理工作十分的重要。

二、软件开发项目质量管理措施

（一）对项目的过程进行合适的定义。软件开发项目的过程并不单单指软件产品的开发，还包含软件产品的维护。随着企业现代化的发展，企业管理中特别重视过程管理工作，通过过程管理，有效的提升了管理的效果和水平。企业在实行过程管理时，会受到外部环境或者组织模式变化的影响。基于此，软件开发项目过程的顺利实施，就需要利用过程管理的思想来保证，根据项目的实际情况，结合企业的发展，优化软件开发流程，同时保证软件开发的功能能够满足客户的需求。对于每一个设计阶段，都需要对其计入和退出条件进行明确的定义，进而有效的开展质量管理，提升软件开发的质量。

（二） 明确项目需求。所谓项目需求，就是指客户的需求，当客户需求非常明确时，软件开发项目所具备的成功率就会比较高，相反，成功难度就比较大。在实际的软件开发过程中，经常会发生用户需求改变的情况，从而对软件项目开发产生比较严重的影响。鉴于此项问题的存在，项目需求的明确是在软件开发之前所必须要进行的管理工作，首先，在与客户进行沟通时，应将客户的需求明确、详尽的填写在说明书中，避免开发人员误解行为的出现;其次，当客户的需求发生变化时，开发人员要与客户及时的进行沟通，并保证沟通的有效性，从而保证软件开发的顺利进行;最后，当用户的需求存在不明确的地方时，采取暂缓开发的政策，同时尽早的对这部分的需求进行明确。

（三）代码走查。软件开发周期比较长，在开发的过程中，会由多个开发人员同时进行，对于自身所负责的开发部分，开发人员要在每周固定的时间讲解代码，这样一来，开发人员可以对自己代码的质量有所了解，并根据他人的意见和建议优化自己的代码，提升软件开发的质量。

（四）对软件产品进行检测。在对软件产品进行检测时，主要包含两种检测，一种是集成检测，一种是系统检测，检测的主要内容有功能、安全性、用户界面、安装等，一般来说，在进行测试时，需要软件产品在模拟环境中运行，通过检测，保证软件产品无任何的缺陷。

结论：对于软件产品来说，质量是非常重要的，因此，在进行软件开发时，就需要进行质量管理。在对软件开发项目进行质量管理时，应该保证整个过程的管理，同时，质量管理工作还需要在充分满足客户需求的基础上来进行，通过检测、代码走查等手段，保证软件开发项目的质量，从而有效地开发出高质量的软件产品。

参考文献：

[1] 张成功.基于CMMI的软件开发质量管理问题研究[J].信息通信，2015，10（03）：154.

软件项目策划书_软件项目策划书 第5篇

1引言.1 编写目的本开发计划的目的是：

a． 把在开发过程中对各项工作的人员、分工、经费、系统资源条件等问题的安排用文档形式记载下来，以便根据本计划开展和检查本项目工作，保证项目开发成功；

b． 制订项目组开发过程中的评审和审查计划，明确相应的质量管理负责人员；

规定软件配置管理的活动内容和要求，明确配置管理工作的人员。

特别要求：需求分析必须详细，并且有相关专家合作进行，.2 背景

本项目软件名称为《电能质量数据分析软件》。

任务来源于（略）公司；

交办单位：（略）公司；

承办单位：北京长峰新康科技有限责任公司。.3 参考资料

无；.4 术语和缩写词

暂无；

特别说明：有关公司内部秘密的内容用（略）代替。

2任务概要.1 工作内容

本项目开发过程中需要进行的各项主要工作为：

编制附和软件需求要求的软件功能的软件。

文档计划建立：

软件开发计划；

软件目录

软件需求规格说明

项目开发计划

可行性报告

软件标准规范

软件测试计划

软件测试办法

概要设计说明

软件可靠性和安全性设计指南

硬件总体设计报告

详细设计说明

软件详细设计报告

软件代码（略）

测试分析报告

软件可靠性和安全性设计检查单

软件评审检查单

软件使用说明.2 产品.2.1 程序

见需求。.2.2 文档

文档内容见2.1中文档建立。

文档格式要求按照软件模式化要求进行，模式按照如下名称模板要求规定：

项目开发计划；?软件开发计划

软件目录；?文档目录

软件需求规格说明；? 需求分析报告

概要设计说明；? 概要设计文档

详细设计说明；?详细设计文档

软件标准规范；?源代码

软件使用说明；?软件使用说明书

测试分析报告；?软件测试报告

软件评审检查单。?软件审查报告.2.3 服务

培训：

时间：1天；

内容：软件使用及安装；

软件支持：略。.2.4 验收标准和验收计划

验收测试：

时间：1天。

内容：软件使用。

软件确认：

时间：1天；

内容：确定软件的可使用性，软件的功能完整性。

3实施总计划.1 阶段划分

需求分析：2周；

概要设计：6天；

详细设计：1.5周；

编码：3周；

测试：2周；

验收：2天。

项目启动时间：2000-11-14.2 人员组成姓名职责参加时间

廖燕宁负责软件的总体设计时段：全部，开发时段：部分

耿江涛软件设计，开发全部

高小光设计，开发全部

张欣说明书，部分文档 部分

赵健颖需求部分.3 任务的分解和人员分工

软件开发任务按软件种类采取逐层分解的办法把任务落实到实处。

管理、协调人员：廖燕宁，赵健颖；

确定质量保证人员：廖燕宁

配置管理人员：耿江涛

形式化检查人员：赵健颖

使用者：赵健颖。

软件任务：系统需求

负责人：（略）的市场部经理赵健颖

职责：提供需求。

软件任务：需求分析

负责人：廖燕宁

职责：进行需求分析，提供需求分析报告。

软件任务：概要设计

负责人：廖燕宁，耿江涛，高小光

职责：进行概要设计，概要设计框图，相应文档。

软件任务：详细设计

负责人：廖燕宁，耿江涛，高小光

职责：进行详细设计，出详细设计流图及报告。

软件任务：编码

负责人：耿江涛，高小光

职责：编码，调试及报告。

软件任务：测试

负责人：廖燕宁，耿江涛，高小光

职责：路径测试。

软件任务：更新

负责人：廖燕宁，耿江涛，高小光，赵健颖

职责：由赵健颖根据测试后的软件提出问题，变更需要更改的地方。

软件任务：文档编制

负责人：张欣

职责：软件使用说明书，部分其他文档。.4 进度和完成的最后期限

进度包括：

需求分析；

软件概要设计；

软件详细设计；

编码；

测试；的时间。

完成的最后期限（不包括测试及验收）为：2000/12/15日(中间有一周软件培训，延误一周)。3.5 经费预算

略.6 关键问题

（略）。.7 独立确认测试工作计划和安排

测试由长峰新康进行；

测试数据由长峰华辉提供；

时间：编码结束后一周内；

设备：

普通PC 机

Windows 98

（略）电能分析仪。

4支持需求

Windows 98 操作系统；

Delohi 5.0开发工具（软件开发）；

C++（VC或C-Builder 5）开发工具；

Paradex 数据库软件。.1 计算机系统支持

本软件的开发需要工作平台：PC 主机；.2 需要交办单位承担的工作

需要（略）公司提供：

需求，在本周提供；

PF 1文件格式，或读写代码；.3 需要其它单位提供的条件

测试数据项目列表。

5质量保证

质量审核：赵健颖，廖燕宁.1 评审和审查计划

见评审表；.2 标准、条例和约定

代码每日发送到小组共享区，由廖燕宁提取。.3 人员

赵健颖，廖燕宁.4 对任务间接承办单位的管理

略

6软件配置管理.1 基线

开发编码结束后一周内，交齐文档、代码。.2 配置标识规则

软件开发计划：2000-10-1-1；

文档目录：2000-10-1-0；

需求分析报告：2000-10-1-2；

概要设计文档：2000-10-1-3；

详细设计文档：2000-10-1-4；

源代码：2000-10-1-5；

软件使用说明书：2000-10-1-6；

软件测试报告：2000-10-1-7；

软件审查报告：2000-10-1-8。

其他（略）。.3 配置控制.3.1 更改控制

软件设计的更改权限为：廖燕宁；

软件需求的更改权限为：赵健颖；

需求分析的更改权限为：廖燕宁；

编码的更改权限为：耿江涛，高小光；

文档的更改权限为：廖燕宁, 张欣；.3.2 更改规程

软件开发项目管理应用(4天) 第6篇

一、课程目的为了加强企业信息科技部门建设，提升信息科技部门人员管理技能，充分掌握并应用项目管理的流程、工具和方法，从而提高IT项目实施的效率和效益。拟开展企业信息化项目管理应用培训，经培训使参训人员能用项目管理方法论指导企业信息规划和IT项目建设。

二、课程收益

熟悉项目管理概念和工具技术的应用

了解项目实施和监控过程方法

理解企业信息科技部门IT项目管理体系，掌握企业信息中心项目化管理应用。

三、授课方式

课程讲解、实战训练、案例研讨、模板演示、讨论引导

四、课程对象

分管领导，部门经理、项目经理、项目成员、信息中心人员及对项目管理有兴趣的员工。

六、课程大纲

破冰

（一）项目管理过程活动梳理

1.1项目与项目管理

1.1.1信息化项目管理应用

1.1.2项目管理过程活动流程介绍

1.1.3美国项目管理学会(PMI)项目管理专业人员(PMP)考试制度 □ 问题解答

1.2.软件开发项目管理过程

1.2.1软件开发项目生命周期选择

1.2.2.1新版项目管理思想生命周期的化繁为简

1.2.2.2 HP项目生命周期模型介绍与研讨

实战训练1：确定企业项目生命周期方法与模型

1.3.软件开发项目实施组织环境和项目管理因素

1.3.1软件开发项目组织环境：环境—方法—人—工具

1.3.1.1项目组织环境对项目的影响

1.3.2项目接口与支撑体系

模板演示1：IT项目多功能团队接口/界面和工作关系管理

1.3.3软件开发项目管理状况分析

1.3.3.1项目目标和过程成功要素

1.3.3.2导致项目失败的12大因素

（二）软件项目管理方法技术实操演练

2.1项目启动

2.1.1成功的软件开发项目启动

2.1.1.1项目分类（IT工程类项目、软件开发类项目、系统维护类项目……）

4.1.1.2软件开发项目组织类型与项目利害关系者分析管理

4.1.1.3项目角色管理与职责矩阵

2.1.2项目经理选择与项目经理的责权利

2.1.2.1项目经理应该具备哪些能力标准和素质要求

2.1.2.2没有合格项目经理怎么办?

演示：技术型项目经理如何转到技术管理型项目经理

2.1.3软件开发项目经理的两个权利来源

2.2项目规划

2.2.1约定开发过程规则,是项目管理流程,制度,模板和控制的基础保障

2.2.2如何定义软件开发项目的多目标性

2.2.3从软件开发项目需求管理到完成概要设计

2.2.3.1业务需求如何转换为技术需求,技术需求如何转换为产品需求

2.2.3.2需求的接口界面

2.2.3.3如何杜绝需求评审走过场

2.2.3.4项目不断提出需求变更应该如何应对？

2.2.3.5项目需求变更的应对措施：时段法、版本法、有无法……

2.2.3.6如何与业务部门达成需求变更流程规则？

案例研讨：中兴通讯如何管理定性需求

2.2.4 IT项目规划进度规划

2.2.4.1软件开发活动的逐渐明晰与PERT估算方法应用

2.2.4.2中国移动软件开发项目活动工期估算方法介绍

2.2.4.3如何使计划适应变化？

2.2.4.4可操作性和可控计划是如何做出来的？

2.2.4.5三级计划制定的时间点

2.2.4.6开发计划制定的步骤和注意事项

2.2.5、IT项目资源规划

项目多、时间紧、人员少，项目如何确保满足业务要求，过程中又如何实施进度监督与控制，资源或需求发生变化后的进度基准如何确定，对项目进度应如何评价？

2.2.5.1如何调节资源使用的高峰低谷

2.2.5.2进度压缩在软件开发中的应用

2.2.5.3如何通过绩效杠杆调节软件架构师、开发人员和测试人员的协同工作

2.2.5.3.1软件开发项目的考核KPI和考核方法

2.2.5.3.2如何设置开发项目激励奖金？

2.2.5.3.3软件开发项目经理如何评价项目成员绩效？

2.2.6 IT项目费用规划

2.2.6.1费用估算

2.2.6.1.1费用估算依据

2.2.6.1.2费用估算方法

2.2.6.1.3准备金分析

2.2.6.1.4实现价值分析

2.2.7 软件项目质量规划

2.2.7.1 IT项目管理与ISO

2.2.7.2 IT项目与CMM

2.2.7.3 IT质量规划

2.2.7.4SPPP、SQA、QC和SCM

2.2.7.5质量管理工具(益本比分析、基准对照、实验设计、因果图、控制图、流程图、直方图、帕累托图、趋势图、散点图、统计抽样、检查)

2.2.8 制订项目管理计划

2.2.8.1项目管理计划的作用

2.2.8.2项目管理计划的适应范围与应用裁剪

2.2.8.3项目管理信息系统、配置管理系统、变更控制系统之关系与作用 模板介绍：项目管理计划模板介绍

2.3.软件开发项目指导、执行与控制

2.3.1如何实现软件开发项目的过程可控、可视、可度量

2.3.2项目绩效状态报告

模板演示:IBM软件开发项目绩效状态报告模板

2.3.3软件开发项目经理如何指导项目成员执行项目任务

案例研讨:某集团信息中心如何通过建立项目化运作机制,解决项目资源冲突问题

2.3.4如何保证各配合部分提交的工作包是符合质量的?

2.3.5风险应对与监控

2.3.5.1风险规划,让项目防患以未然

2.3.5.2谁来识别项目风险?如何识别项目风险?

2.3.5.3如何评估风险给项目带来的机遇或影响?

2.3.5.4风险评审、风险审计、风险责任

2.3.5.5为什么需要对风险进行集中管理

模板演示:风险管理列表

2.3.6如何规避同样的问题重复发生

模板演示:问题管理流程模板示例介绍

2.4.软件开发项目收尾

2.4.1项目验收

2.4.2项目总结

2.4.3项目后评估

2.4.4如何做好项目移交

2.4.5项目成员解散

模板演示:软件开发项目总结报告

2.5.软件开发多项目管理

2.5.1多项目管理工作方式

2.5.1.1项目群管理

2.5.1.2项目组管理

2.5.1.3项目总监与项目池、资源池

2.5.1.4多项目的多级控制

(三)软件开发项目的激励方法

3.1软件开发项目团队建设与激励

3.1.1软件开发项目经理权利类型

3.1.1.1职位权利,强制权利,奖赏权,专家权,个人魅力,权威权利

3.1.2项目经理领导与管理方式

3.1.2.1专制型,民主型,协商专制型,协调型,引导者

3.1.3软件项目团队建设活动

3.1.3.1例行活动、项目阶段重大成果……

3.1.3.2软件开发团队激励:项目管理之星、项目攻关荣誉奖、月度之星、季度明星、BUG克星……

模板演示:软件开发团队建设指导模板

3.1.4软件开发项目激励方法

3.1.4.1需求法,双因素法,XY方法,期望法,光环法

3.1.4.2项目激励方式:荣誉奖、积分卡、发表扬信、公告、宣传,奖赏

3.1.5项目团队绩效评估

现场训练:抱团打天下

(四)软件开发项目的有效沟通

4.1项目沟通技巧

4.1.1项目沟通渠道计算

4.1.2项目沟通类型

4.1.3项目沟通模型

4.1.4如何将技术语言转换成业务语言进行有效沟通

4.1.5有效的项目沟通影响因素

游戏:项目沟通模拟游戏

4.1.6沟通宝典：项目利害关系者政治关联分析法

案例研讨:根据案例资料识别和管理项目利害关系者

4.2常见的冲突及解决技巧

4.2.1冲突来源

4.2.2有效的冲突管理思维

4.2.3项目冲突的五种有效解决方法

4.2.3.1规避,缓和,折中,正视问题,妥协 课程总结

培训联系:左老师

电话:021-63233980

手机:***

QQ:2749919646

软件开发与项目管理实习报告 第7篇

本次项目实施中，在第二周就落实了培训需要的电脑及网络环境的建立，但在前期培训过程中讲解及练习环节都是临场才添加的需要使用到的数据，例如为护士讲解如何记账操作时发现没有在院病人;因此培训期间的时间有效利用率受了较大影响。主要原因在于对培训环境的理解不全面导致准备不充分，没有提前考虑周全。

培训环境的建立，远远不止电脑等硬件的购置及网络环境的搭建，更重要的是软环境的建立。培训过程中的讲解及操作练习都需要实际数据才能进行，因此需要提前准备好培训要使用到的数据及参数设置。

应对措施：凡事预则立，不预则废。培训前考虑可能使用到的数据环境，提前在培训使用的数据库中准备好数据。

TIP6：启用前的重要准备及测试

本次项目实施在启用时，由于对产品不熟悉及对需要进行的准备工作没有足够的意识，导致在启用当天门诊收费后没有发票打印出来，启用前仅在测试库中进行了测试而没有在收费室进行打印机关联及设置等，且没有进行实际打印的测试。虽然当时医院旧系统仍然在使用，没有对医院业务运营造成重大损失，但是这个错误在我心中的印象是非常深刻的。

系统启用是项目实施中的关键性事务，关系到项目里程碑进展及医院业务开展，其重要性不言而喻。因此在，系统启用前需要做好充分的.准备工作，例如：A.流程测试，B.票据打

印测试，C.登陆账号、权限分配审核，D.重要基础参数设置的检查(例如药品库存检查、票据严格管理)。

应对措施：启用前，必须在正式库中测试门诊与住院收费单据打印、预交款单据打印，一日清单打印等，检查全局参数设置、收费室药房等本地参数情况。

TIP7：与院方的沟通方式

本次项目实施中，有两次与院方的沟通效果不好。一次是用于不当，与一位院长沟通的时候说了：“这个功能，那些大医院可能用的更多……”该院长当即表态“那如果我就是要用这个功能呢?”我明显感觉到院长的防御姿态瞬间提升，沟通进入尴尬境地;第二次是我非常直接的询问院方财务管理人员(每日收费结存人员)是谁，院长没有回答。

对于院方内部事务，特别是涉及内容较为敏感时，可以通过其他渠道了解;对于一些可能损伤院方自尊心的事务，尽量采用委婉或者隐晦的用词进行沟通。沟通始终要注意在合适的时间找对合适的人、使用恰当的词句及方式;否则不仅达不到沟通效果，还影响与院方的关系及项目实施工作的开展。

应对措施：学习卡耐基《说话的艺术》，在接下来项目中注意沟通方式及时间、频率。

TIP8：抓住关键性事务

本次项目实施中，一开始我认为初始化是项目实施中最重要的工作，因此一直在进行初始化数据的准备及对初始化人员的培训;后来在启用前一周才开始关注医保接口实施的具体方法步骤，然后让初始化人员又对收费项目进行医保对码，引起了初始化人员的强烈不满，认为初始化工作没有一次性结束;如果将收费项目的建立与医保对码放到一起进行，可能不会引起不满，而且条件是允许的，初始化数据的录入与医保接口实施并非逻辑先后关系。医保接口实施及医保刷卡测试的速度都相当慢，在启用前一天才完成所有测试。

经过这个项目，我认为该项目中除药品库存、费用流程至关重要，最重要的是医保刷卡功能的正常使用，因为该医院患者中绝大部分为医保病人，这是医院收入的主要支撑部分，医院安装新系统的主要目的就是为了解决原系统不能正常使用医保刷卡功能这一重大问题。

应对措施：时刻与同事、上级保持沟通，得到经验上的指导;项目实施方案中进行体现。

TIP9：项目外事务与项目的协调

本次项目实施中两次被综合部人员协调到另外一个医院处理“光纤交换机”事宜，两次都没有完成计划的任务，并且减少了自己在建项目的实际工作日，对公司的形象也产生了不好的影响。我方主要原因是：A.未得到关于该事务的足够信息;B.未判断清楚任务是否具备完成条件。

经过此事，我认为在涉及影响自己在建项目进展而被协调处理其他事务前，首先需要考虑的是是否会对在建项目的进度产生不良影响，其次是该任务是否能够正常进行并达成计划的结果;否则浪费时间不说，还不能达成结果。

应对措施：应答前，将被协调事务了解清楚，审核是否具备任务达成的条件。

问题诸多，不一一列出。

签完验收，一直期待的兴奋感并没有像我想象的那样从头顶瞬间灌注到脚底，而是一种难过的感觉隐隐在心中升起。系统使用存在的诸多问题，以及在这个项目过程中，学习到的东西都并非我期待的那样得到实现，对自己学习摸索的方式以及效率，对项目进度的把控能力都让自己感到失望。

ERP软件项目管理开发对策 第8篇

针对基于项目管理的ERP软件项目开发, 初始步骤的主要目标是和用户一起确认项目的目标和范围。在初始步骤, 项目成员需要建立的ERP软件的范围和边界条件, 包含软件操作的远景设想、用户验收条件以及在产品中包含和不包含的内容;区分出ERP系统的关键用例;初步估计整个项目的整体成本和进度安排;识别项目潜在风险;准备项目的支持环境。

要达到初始步骤的目标, 项目人员需要开展下列活动:

阐明ERP软件项目的范围。项目的范围包含两层含义:ERP软件的功能范围和ERP软件开发工作执行的范围。项目成员需要捕获环境、主要需求和约束, 在此基础上定义ERP软件的功能范围, 根据功能范围形成软件开发工作执行的范围。ERP软件的功能范围的确认以ERP软件产品的验收条件为准。

计划和准备项目的商业理由。评估项目风险, 从商业角度充分考虑项目的成本/效益, 从而确定项目是否可以盈利;估计项目需要的资源, 确定在现有条件下是否能完成项目;对各种备选方案进行评估选择。

制定项目方案。拟订项目计划的可选方案, 对人员、时间等进行初步规划。考虑各种项目限定因素, 以便可以估计成本、进度安排和资源。证明解决方案的可行性, 以便在精化和构建期间实现该解决方案。

准备项目环境。当项目被证明可行, 并且有了初步的方案以后, 就可以正式准备开发项目的环境了。制定项目的流程, 确定要改进流程的哪些部分, 选择开发中要使用的各种软件硬件工具。

在初始步骤结束时, 要对步骤成果进行评估。生命周期里程碑评估的依据是项目产生的工件, 对于基于项目管理的ERP软件项目开发来说, 生命周期里程碑应包括ERP开发项目的风险列表、商业理由、软件开发计划、迭代计划、迭代评估、开发流程、开发基础结构、前景、针对ERP用户的商业分析模型、针对ERP软件需求的用例模型等工件。生命周期里程碑衡量的标准主要有:就ERP软件开发项目的范围和用户达成一致;初步估计项目成本和进度, 并取得用户的理解和同意;和用户就ERP软件的功能需求达成一致;识别项目风险, 并制定预防措施。

二、构造ERP软件系统的架构

针对基于项目管理的ERP软件项目开发细化步骤的主要目标是构造ERP软件系统的架构, 为后步骤的大量详细设计和组件实施提供稳固基础。要达到细化步骤的目标, 项目人员需要开展下列活动:

建立足够详细的用例模型, 进一步理解和验证用户对ERP软件的需求, 保证充分用户需求已经足够稳定。

构造ERP软件的体系结构。在需求用例基本被识别的情况下, 设计人员应尽可能快地定义ERP软件的体系结构, 验证可行性, 并为ERP软件体系结构建立基线。

为ERP软件的构建步骤制定详细的迭代计划, 保证ERP软件的实现。根据项目步骤的状况, 改进开发流程并放置到开发环境中, 包括支持团队在构建步骤开发所需的流程、工具和自动化支持。

三、依据体系结构澄清剩余的需求并完成ERP软件系统的开发

针对基于项目管理的ERP软件项目开发, 构建步骤的主要目标依据细化步骤建立的ERP软件体系结构, 澄清剩余的需求并完成ERP软件系统的开发。要达到构建步骤的目标, 项目人员需要开展下列活动:

构建ERP软件系统。项目的开发工作此时己经全面展开, 这是最耗费时间、人力等资源的步骤。项目应做好资源的管理控制、优化开发流程。在构建过程中, 往往要对设计模型进行修改和优化。

测试ERP软件系统。根据用户对ERP软件的需求和系统设计, 安排测试案例, 并组织测试活动。对照用户验收条件来评估ERP产品发行版本。随着构建步骤的进展, 组成ERP软件系统的各个单元被开发出来, 需要依照在项目初始步骤和用户协商好的验收条件检验产品。

在构建步骤结束时, 要对步骤成果进行评估。RUP把本步骤的里程碑称为初始操作能力里程碑。对于基于项目管理的ERP软件项目开发来说, 初始操作能力里程碑依据的工件应包括风险列表、软件开发计划、迭代计划、ERP软件的部署方案、测试案例、测试评估、企业用户的支持材料、ERP软件设计模型、ERP软件数据模型和ERP产品的部署单元。初始操作能力里程碑衡量的标准主要有:开发的ERP产品发行版是否满足用户要求;开发的ERP产品发行版是否己足够稳定和成熟到可以交付ERP实施项目组和用户使用;实际资源耗费与计划相比, 是否仍可接受。

四、确保ERP软件可以满足企业用户的要求

针对基于项目管理的ERP软件项目开发, 移交步骤的主要目标是确保ERP软件可以满足企业用户或者ERP实施项目组的要求。项目人员需要开展下列活动:

到企业环境中, 部署ERP软件;为企业用户提供支持材料, 如用户手册、培训资料等;现场测试可交付的ERP产品;为新的ERP软件创建产品发行版;获得用户反馈, 根据反馈调整产品。

在移交步骤结束时, 要对步骤成果进行评估。产品发行里程碑最主要的工件是产品和用户支持材料。产品发行里程碑衡量的标准主要有:企业用户和ERP实施项目组对ERP软件系统的评价和满意度;开发项目实际资源耗费与计划的耗费相比, 是否可接受。

参考文献

[1]甄进明著:《项目管理是IT服务企业的运营管理》,

[2]侯灵明:《企业项目管理体系标准模型研究》, 2004,

[3]王知群:《组织的项目管理成熟度的发展和应用》, 2004