软件开发项目管理文件doc.docx

1、软件开发项目管理文件doc软件开发项目管理文件1软件开发项目管理文件1.项目的启动（Project Initiation）与客户进行沟通，了解项目的需求，进行需求调研和可行性分析，分别从技术可行性、经济可行性和社会可行性方面进行论证项目的可能性和必要性。阶段性文档：项目启动报告项目可行性分析报告以上阶段性文档必须经过评审通过，才能进入下一个阶段。2.项目的计划（Project Plan）首先，确定软件项目的目标，然后以软件开发的目标为基础，进行功能需求分析和总结，由此确定软件开发的具体工作。明确开发项目的范围，需要的资源，整合的系统，外部因素依赖等，对整个项目进行范围的定义和分解，把一个大项目

2、分成若干个小项目，把一个小项目分成若干个活动，形成项目范围的工作分解结构(WBS),确定每个活动的人员安排，以及所需要的人天，确定人天标准。以及所需要的软硬件的资源，估算每个活动的费用。最后，估算整个项目所需要的人天和人员安排，以及费用。根据用户的实际情况，确定用户需求，划分系统模块，确定系统的开发架构，书写项目的解决方案。在所有需要开发功能中，确定哪些是重要的，是必须要做的，哪些是次要的，是可以放弃的；同样，对软件的性能要求和其他要求，也做这样的审核与总结。阶段性文档：项目的计划项目工作任务分解书项目资源分配报告项目进度计划项目费用控制计划以上阶段性文档必须经过评审通过，才能进入下一个阶段。

3、项目解决方案(必须经过用户确认,才能进入下一个阶段)3.项目执行（Project Execution）。系统需求分析根据用户的实际需求，结合项目的可行性分析报告，分别绘制用例图、类图、时序图、活动图、状态图、组件图、部署图，编写项目的需求分析报告和需求规格说明书、项目验收测试计划。阶段性文档：需求分析报告需求规格说明书(必须经过评审通过和用户确认,才能进入下一个阶段)项目验收测试计划以上阶段性文档必须经过评审通过，才能进入下一个阶段。系统架构设计架构师的职责主要有如下4条：1、确认需求在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人

4、员反复交流，以保证自己完整并准确地理解用户需求。2、系统分解依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。软件架构师的功力基本体现于此，这是一项相对复杂的工作。3、技术选型架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度

5、等实际情况进行权衡，最终进行确认。4、制定技术规格说明架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。阶段性文档：系统架构设计说明书。系统总体设计根据系统需求分析，分别绘制系统的模块结构图、功能模块图，进行系统的模块划分和输入、输出界面的设计，编写项目总体设计报告和系统集成测试计划。阶段性文档：项目总体设计报告系统集成测试计划以上阶段性文档必须经过评审通过，才

6、能进入下一个阶段。系统详细设计根据系统总体设计，进行数据库设计和编码设计，编写系统详细报告和单元测试计划。阶段性文档：系统详细报告数据库设计概念结构设计逻辑结构设计物理结构设计编码设计单元测试计划以上阶段性文档必须经过评审通过，才能进入下一个阶段。系统编程根据系统详细设计和数据库设计，进行系统程序设计，编写系统模块开发卷宗和程序开发说明书。阶段性文档：系统模块开发卷宗以上阶段性文档必须经过评审通过，才能进入下一个阶段。软件测试根据测试计划，进行单元测试、集成测试和验收测试，编写系统测试报告。阶段性文档：系统测试报告以上阶段性文档必须经过评审通过，才能进入下一个阶段。4.项目验收（Project

7、 Check and Accept）进行系统的试运行，编写用户手册、维护手册和运行日志报告，最后编写项目的验收报告。阶段性文档：项目的验收报告5.项目需求变更管理（Project Demand Chang Management）需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。实施需求变更管理需要遵循如下原则：1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新

8、确定新的需求基线。通常把需求分析报告中的用例图作为需求基线，在用例图确认之后的任何需求改变，都需要走需求变更流程，没有走需求变更流程的需求将不被认可。2.制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。3.成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。4.需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。5.需求变更后，受影响的软件计划、产品

9、、活动都要进行相应的变更，以保持和更新的需求一致。6.妥善保存变更产生的相关文档。实施需求变更管理的方法：需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。相互协作在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来过分的要求，也应该仔细分析原因，积极提出可行的替代方案。充分交流需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入

10、设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。安排专职人员负责需求变更管理有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。合同约束在与用户签订合同时，可以增加一些相关条款，如不能随意变更已经进入基线的软件需求，限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。区别对待随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最

11、初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。选用适当的开发模型采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的迭代

12、式开发方法对工期紧迫的项目的需求变更控制很有成效。用户参与需求评审作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。6.项目风险管理（Project Risk Management）软件项目都存在着这样那样的风险，尤其是数据分析项目这就需要我们在进行软件开发项目时更加注重风险管理，注重风险识别、风险分析，做好风险管理计划，积极寻求风险应对方法，从而提高项目成功的机会。针对软件开发过程中经常发生的风险，我们应采取的预防措施为：1.需求不明确需求不明确是软件开发过程

13、中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题：(1) 让用户参与开发提供一个协作开发环境，让用户参与开发过程。如果条件不允许，至少应该在每次迭代的需求分析和系统测试阶段，让客户能够参与开发。在选择参与开发过程的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参与。另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代表性的用户参与。仅仅让

14、用户参与是不够的，应该采取一定的激励措施，提高用户参与的积极性。(2) 开发用户界面原型用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式，帮助用户清楚表述需求。然后，开发一个用户界面原型，以便用户确认需求。用户界面原型的作用仅仅是收集用户需求，不应该再作它用，也不要给用户造成系统快要实现的错觉。(3) 需求讨论会议对于用户分布广、用户量大的项目，要全面收集用户需求，往往很困难，通常采取需求研讨会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见，然后集中各地或各部门的用户代表，举办一次需求研讨会，通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。(4) 强化需求分析与评审首先，需求分析是项目成功的基础，需要引起足够的重视，并分配充足的时间和人力，要让有经验的系统分析员负责，切忌让项目新手或程序员负责。其次，要进行需求评审，尽可能让用户参与需求评审，不要让需求评审流于形式。第三，也是最重要的一点，通过评审的需求规格说明书，要让用户方签字，并作为项目合同的附件，对双方都具有约束力。在公司内部要将通过评审的需求规格说明书，纳入配置管理。3.项目缺少可见性