亖呉?盀
软件开发项目全程计划表？
一是参考其它项目.另一个现在的可参考项目是安装 Microsoft Office Project 2003， 内有好几个相关模板.供参：项目启动 6 工作日 组建工作组 6 工作日 定义工作组角色 2 工作日 确定所需技能 2 工作日 确定资源 2 工作日 将角色赋予资源 2 工作日 工作组成立 0 工作日 构想 44 工作日 定义初步的商业需求（持续性工作） 29 工作日 风险管理 1 工作日 定义项目结构 9 工作日 定义跟踪项目的步骤 5 工作日 定义解决问题的步骤 4 工作日 定义跟踪问题的步骤 3 工作日 定义控制变更的步骤 4 工作日 定义责任和期望 2 工作日 项目结构确定完毕 0 工作日 研究和收集设想 25 工作日 进行初步的用户访问 2 工作日 定义使用场合 10 工作日 制定初步的用户描述 5 工作日 制定初步的构想说明 1 工作日 确立设计目标 8 工作日 制定初步的解决方案概念 5 工作日 制定初步的项目范围 19 工作日 定义关键的成功因素 2 工作日 定义衡量成功的标准 1 工作日 定义主要的可交付结果（初步） 3 工作日 起草构想/范围 3 工作日 审阅构想/范围 2 工作日 更新构想/范围 3 工作日 缓冲时间 4 工作日 进行里程碑检查 1 工作日 构想得到批准 0 工作日 规划 59 工作日 更新风险评估 1 工作日 进行用户访问 10 工作日 创建功能描述 31 工作日 制定功能描述： 第 0 批 5 工作日 制定功能描述： 第 1 批 5 工作日 制定功能描述： 第 2 批 5 工作日 制定功能描述： 第 n 批 5 工作日 功能描述基准 0 工作日 开发计划 28.25 工作日 创建开发计划 28 工作日 进行概念性设计 10 工作日 进行逻辑设计 15 工作日 进行物理设计 19 工作日 制定开发日程 5 工作日 测试计划 35 工作日 制定测试计划 30 工作日 制定测试日程 5 工作日 用户培训计划 36 工作日 制定用户培训计划 30 工作日 制定用户培训日程 6 工作日 后勤计划 48 工作日 制定后勤计划 43 工作日 进行基础设施分析 15 工作日 制定安全计划 2 工作日 制定部署计划 27 工作日 定购组件 15 工作日 后勤计划完成 0 工作日 创建后勤日程 7 工作日 产品管理计划 18 工作日 制定产品管理计划 14 工作日 制定产品管理日程 5 工作日 程序管理计划 41 工作日 创建程序管理计划 21 工作日 创建程序管理日程 20 工作日 建立项目计划基准 0 工作日 合并项目计划 11 工作日 审阅合并计划 4 工作日 创建合并日程 2 工作日 缓冲时间 4 工作日 确定交货日期 0 工作日 构想/范围冻结 0 工作日 进行里程碑检查 1 工作日 项目计划得到批准 0 工作日 开发 81 工作日 更新风险评估 1 工作日 提供开发所需的设备/检验概念是否达到 0 工作日 建立开发环境/实验室 5 工作日 内部发布 #1 24 工作日 开发目标组件 9 工作日 测试单个组件 5 工作日 测试组装为整体的应用程序 6 工作日 开发增强性能的材料 4 工作日 测试和审查材料 3 工作日 制定分发步骤 9 工作日 创建分发产品 2 工作日 分发给合适的对象 1 工作日 缓冲时间 8 工作日 内部发布 #1 结束 0 工作日 审阅来自内部发布的结果 2 工作日 进行发布后的审阅 1 工作日 内部发布 #n 24 工作日 开发目标组件 10 工作日 测试单个组件 4 工作日 测试组装为整体的应用程序 5 工作日 开发增强性能的材料 4 工作日 测试和审查材料 3 工作日 制定分发步骤 3 工作日 创建分发产品 4 工作日 缓冲时间 6 工作日 分发给合适的对象 1 工作日 内部发布 #n 结束 1 工作日 审阅来自内部发布的结果 2 工作日 功能说明冻结 1 工作日 最后的特性开发 10 工作日 最后的后勤开发 9 工作日 最后的性能支持开发 5 工作日 特性开发结束 0 工作日 更新计划和日程 13 工作日 更新开发计划 4 工作日 更新测试计划 3 工作日 更新后勤计划 13 工作日 更新程序管理计划 3 工作日 更新产品管理计划 3 工作日 更新用户培训计划 6 工作日 缓冲时间 3 工作日 进行里程碑检查 2 工作日 项目范围规划完成 1 工作日 稳定 73 工作日 更新风险评估 1 工作日 发布测试版 1 32 工作日 制定测试版计划 3 工作日 征寻和选择用户 2 工作日 准备测试版产品包 8 工作日 开始测试 0 工作日 提供测试支持 8 工作日 收集用户反馈 7 工作日 结束测试支持 0 工作日 修补缺陷 10 工作日 结束测试 0 工作日 发布测试版 n 1 工作日 修补缺陷 10 工作日 收集错误 1 工作日 改正高优先级的错误 10 工作日 发布无错误版 0 工作日 进行最后的错误分类 5 工作日 发布版候选 1 7 工作日 进行工作组评估 2 工作日 客户/用户评估 2 工作日 支持评估 3 工作日 发布版候选 n 6 工作日 黄金发布版 0 工作日 发布 1 工作日 项目后检查 2 工作日 软件开发：------------------------- 项目范围规划 3.5 工作日 确定项目范围 4 工时 获得项目所需资金 1 工作日 定义预备资源 1 工作日 获得核心资源 1 工作日 项目范围规划完成 0 工作日 分析/软件需求 14 工作日 行为需求分析 5 工作日 起草初步的软件规范 3 工作日 制定初步预算 2 工作日 工作组共同审阅软件规范/预算 4 工时 根据反馈修改软件规范 1 工作日 确定交付期限 1 工作日 获得开展后续工作的批准（概念、期限和预算） 4 工时 获得所需资源 1 工作日 分析工作完成 0 工作日 设计 14.5 工作日 审阅初步的软件规范 2 工作日 制定功能规范 5 工作日 根据功能规范开发原型 4 工作日 审阅功能规范 2 工作日 根据反馈修改功能规范 1 工作日 获得开展...
软件项目管理的基本信息
书 名： 软件项目管理 作 者：覃征 出版社： 清华大学出版社 出版时间： 2009-10-1 ISBN: 9787302209485 开本： 16开 定价： 39.00元 软件项目管理是软件工程和项目管理的交叉学科，是项目管理的原理和方法在软件工程领域的应用。
本书分为基础篇、管理篇和实践篇。
基础篇介绍了软件产业和软件项目管理导论，使读者从整体上了解软件项目管理的产生背景和概貌。
管理篇以项目管理知识体系（PMBOK）为核心，围绕着软件项目的开发全过程，从软件项目需求管理、软件项目成本管理、软件项目进度管理、软件项目风险管理、软件项目配置管理、软件项目资源管理、软件项目质量管理等方面对软件项目中的管理问题进行探讨。
实践篇将需求管理、成本管理、进度管理、风险管理、配置管理、资源管理和质量管理等相对独立的领域融合在软件过程框架中，介绍了在软件项目实践中如何集中使用相关理论和技术。
其中包括Rational统一过程、敏捷软件开发和6σ软件开发。
本书可作为高等学校信息、软件、计算机科学与技术等专业的学生的教材，也可供从事软件项目管理工作的人员参考。
信息之二 书 名： 软件项目管理 开本： 16开 定价： 32.00元 《软件项目管理》系统介绍了软件项目管理的理论、方法与案例，全书共分15章，内容包括软件项目管理、组织平台、软件项目立项、软件开发过程、软件估算、软件项目计划、软件配置管理、软件质量管理、软件度量、风险管理、软件外包管理、人力资源管理与团队建设、软件知识产权管理、项目经理面临的政治、项目管理技巧。
《软件项目管理》适合软件工程及计算机相关专业的研究生使用，也可作为软件领域开发人员的参考书。
第1章 软件项目管理导论1.1 软件项目管理概述1.1.1 项目管理的发展1.1.2 什么是项目1.1.3 什么是项目管理1.1.4 项目管理环境1.1.5 软件工程与项目管理1.2 软件项目分类1.3 企业愿景1.4 项目成功需要的关键投入1.5 软件项目开发过程1.6 软件项目管理的重要性1.6.1 失控项目定义1.6.2 失控项目特征1.6.3 技术问题1.7 CMM模型1.7.1 CMM概述1.7.2 CMM的内部结构1.7.3 CMM的5个等级1.7.4 CMM中5级的发展关系 第2章 组织平台2.1 组织机构与决策机制2.1.1 组织的定义2.1.2 组织平台与项目决策2.2 常见软件组织形式2.2.1 简单的软件开发组织2.2.2 普通的软件开发组织2.2.3 较成熟的软件开发组织2.2.4 开发组织的选择与设定2.3 CMM中的组织2.3.1 CMM中的关键工作组2.3.2 物理组与逻辑组2.3.3 组织的完善与独立性2.3.4 关键角色 第3章 软件项目立项3.1 识别潜在项目3.2 产品立项3.2.1 商业目标3.2.2 产品战略3.2.3 产品的5个层次3.2.4 产品定位战略3.2.5 产品开发立项3.2.6 产品立项报告3.3 定制项目立项3.3.1 项目选择3.3.2 合同签定要注意的问题3.3.3 定制项目立项报告3.4 立项评审3.5 技术人员在立项中的责任 第4章 软件开发过程4.1 需求确定4.1.1 把握系统需求4.1.2 需求管理的实施过程4.1.3 需求变更管理4.1.4 需求分析提交的结果4.1.5 角色划分4.2 软件设计4.2.1 概要设计4.2.2 详细设计4.3 编码4.3.1 编码标准4.3.2 编码风格4.3.3 命名规则4.4 测试4.4.1 测试目标4.4.2 测试原则4.4.3 软件测试过程管理4.5 发布、部署和维护4.5.1 发布4.5.2 部署4.5.3 维护 第5章 软件估算5.1 软件估算概述5.2 估算步骤5.2.1 确定软件范围5.2.2 确定工作所需资源5.2.3 确定估算内容5.2.4 估算改进5.3 估算方法5.3.1 FP功能点估算法5.3.2 LOC估算法5.3.3 COCOMO估算法5.3.4 软件方程式估算法5.3.5 类比估算法5.3.6 wBS估算法5.3.7 Delphi估算法5.3.8 PERT方法5.3.9 估算方法的综合应用5.4 估算的表达5.5 估算的原则与技巧 第6章 软件项目计划6.1 软件项目计划的层次6.2 软件项目计划编制的方针6.3 软件项目计划的内容6.3.1 项目介绍6.3.2 技术方案概述6.3.3 过程计划6.3.4 测试计划6.3.5 组织计划6.3.6 资源计划6.3.7 软件估算与预算6.3.8 进度表6.3.9 质量计划6.3.10 风险计划6.3.11 变更管理计划6.3.12 文档计划6.3.13 培训计划6.3.14 发布与实施计划6.4 软件项目计划成功的关键要素6.5 软件项目计划模板 第7章 软件配置管理7.1 软件配置管理概述7.1.1 术语与概念7.1.2 软件配置管理定义7.1.3 软件配置管理的基础7.2 软件配置管理的活动7.2.1 制定SCM计划7.2.2 软件配置标识与维护7.2.3 软件配置控制与变更管理7.2.4 版本管理7.2.5 软件配置状态发布7.2.6 软件配置审计7.2.7 软件发布管理7.3 配置管理工具7.3.1 几种配置管理工具介绍7.3.2 配置管理工具选择7.3.3 配置管理工具实施7.4 成功的关键7.5 职责分配与角色 第8章 软件质量管理8.1 软件质量管理基础8.1 一软件质量8.1.2 软件质量需求与质量特征8.1.3 软件质量管理8.2 软件质量保证 …… 第9章 软件度量 第10章 风险管理 第11章 软件外包管理 第12章 人力资源管理与团队建设 第13章 软件知识产权管理 第14章 项目经理面临的政治 第15章 项目管理技巧 参考文献
软件项目进度管理怎样计划项目发挥真正的作用,而不成为挂在墙上的...
1、任务分配、人力资源分配、时间分配要与工程进度相协调在小型软件开发项目中，一个程序员能够完成从需求分析、设计、编码，到测试的全部工作。
随着软件项目规模的扩大，人们无法容忍一个人花十年时间去完成一个需要十几个人年才能完成的软件项目。
大型软件的开发方式必然是程序员们的集体劳动。
由于软件开发是一项复杂的智力劳动，在软件开发过程中加入新的程序员往往会对项目产生不良影响。
因为新手要从了解这个系统和以前的工作做起，当前正在从事这项工作的“专家”不得不停下手中的工作，抽出时间对他们进行培训。
于是，在一段时间内，工作进度便拖后了。
软件开发人数的增加将导致信息交流路径和复杂性的增加，项目进行中盲目增加人员可能造成事倍功半的效果。
适用于大型项目的Rayleigh-Norden曲线[4]表明，完成软件项目的成本与时间的关系不是线性的，使用较少的人员，在可能的情况下，相对延长一些工作时间可以取得较大的经济效益。
然而值得指出的是，程序员小组的正常技术交流能改进软件质量，提高软件的可维护性，减少软件错误，降低软件测试和正确性维护的开销。
任务、人力、时间三者之间存在最佳组合，必须引起项目负责人的足够重视。
2、任务分解与并行化软件工程项目既然需要软件开发人员集体的劳动，就需要采取一定的组织形式，将软件开发人员组织起来。
软件人员的组织与分工是与软件项目的任务分解分不开的。
为了缩短工程进度，充分发挥软件开发人员的潜力，软件项目的任务分解应尽力挖掘并行成分，以便软件施工时采用并行处理方式。
3、工作量分布 用前几节介绍的软件估算技术可以估算出软件开发各个阶段所需要的工作量，通常用人月或人年表示。
软件在需求分析和设计阶段占用的工作量达到总工作量的40%~50%，说明软件开发前期的活动多么重要。
当然这也包括分阶段开发原型的开销。
大家熟悉的编码工作只占全部工作量的10%~20%，而软件测试和调试的工作量占到总工作量的30%~40%。
这对于保证软件产品质量是十分必要的，实时嵌入式系统软件的测试和调试工作量所占的比例还要大些。
4、工程进度安排 软件项目的工作安排与其他工程项目的进度安排十分相似，通常的项目进度安排方法和工具稍加改造就可以用于软件项目的进度安排。
目前，程序评估与审查技术（PERT）和关键路径方法（CPM）是两种比较常用的项目进度安排方法。
两种方法都生成描述项目进展状态的任务网络图。
网络图中按一定的次序列出所有的子任务和任务进展的里程碑，它表示各子任务之间的依赖关系。
网络图也是作业分解结构（WBS）的发展。
20世纪70年代，作业分解结构就已广泛应用于航天、航空、航海、雷达、通信、火控系统等领域的基于计算机项目的分解，并用以命名各项子任务，这些子任务不仅可以用网络图的形式表示，还可以用树型或层次结构图表示。
PERT和CPM方法为软件规划人员提供了定量描述工具，包括：①关键路径。
完成关键路径上所有任务时间的总和，就是项目开发所需要的最短时间。
②用统计模型估算开发每个子任务需要的工作量和时间。
③计算各子任务的最早启动时间和最迟启动时间，即确定启动子任务的时间窗口边界。
某个子任务的最早启动时间被定义为该子任务的所有前导任务完成的最早时间。
反之，某个子任务的最迟启动时间被定义为在保证项目按时完成的前提下，最迟启动该子任务的时间。
与最早启动时间和最迟启动时间对应的概念是最早结束时间和最迟结束时间。
它们分别是最早启动时间和最迟启动时间与完成该子任务所需要时间的和：在任务进度安排过程中，应先寻求关键路径并在关键路径上安排一定的机动时间和节假日，以便应付意想不到的困难和问题。
采用这些工具可以大大减轻软件项目管理人员在制定软件项目进度表方面的工作量，并可提高工作质量。
怎么写项目开发的文档？
1.1.1 项目名称项目名称（项目类型）1.1.2 项目开发者成员一：**成员二：***成员三：***1.1.3 项目开发环境MyEclipse + Tomcat5.5和MyEclipse（自带）+ SQLServer 20051.1.4 系统功能设定品红商业网分为2大模块：1.前台系统## 设定新闻，商品以及购物相关功能：NEWS：对新闻的增加、删除和查询操作，并且增加上下条功能进行查询，以及最新新闻的显示与增加。
PRODUCT：对商品的增加、删除、修改和查询操作，并且增加分页技术进行查询，以及最新商品的展示与增加；增设对商品的选购，打印清单、结算功能。
TALKING：用户之间的在线聊天，进行互动交流，洽谈业务，对信息发表自己的看法等，并设有广告介绍，让用户了解最新信息。
MESSAGE：客户留言薄，针对各种商情，业务交流进行离线留言，站外，站内用户可以通过此信息及时了解最新资讯，了解用户反馈信息等。
ABOUT：介绍了公司对客户的信心，诚意做出了诚恳的表态。
AFTER：介绍了公司关于商品的售后服务条例等，给客户提供更满意的服务。
COPYRIGHT：介绍了公司的版权信息，以及法律授权及其相关。
2.后台管理系统## 设定对管理员，用户以及管理员对新闻和商品信息的相关操作。
ADMIN：对用户的查询和删除，对新闻的增加，删除和查询，对商品的增加、删除、修改和查询，都增设了分页技术更有规范的查询。
并附有时间，让操作人员在任何时候都能得到精准时间，以提高管理员的时间观念。
1.1.5 项目开发技术JSP + JavaScript + HTML1.1.6 设计思路通过相关技术，一一实现对管理员，站外，站内用户，公司新闻信息，商品信息进行实用的操作。
1.1.7 项目背景本着为客户提供最优质的服务，项目从多角度考虑需求，以求达到客户所需要的功能，实现零距离的操作。
1.1.8 主要模块讲解1.1.8.1 模块一1. 名称：管理员模块2. 简介：管理员的登录，对相应信息操作实现了管理员对用户，管理员的操作：1. 对用户的查询，删除（必要的删除），使用分页技术给管理员更好的视觉效果。
2. 添加管理员使用了MD5加密技术，登录及相关操作时的各种精密验证，达到更高的保密性，安全性。
1.1.8.2 模块二1. 名称：新闻模块2. 简介：新闻展示，更新，增加和删除1.对新闻的查询和删除，使用分页技术给管理员提供更好的操作性能1.1.8.3 模块三1. 名称：商品模块2. 简介：商品展示，更新，增加和删除1. 对商品的查询、删除、增加和更新，分别使用分页技术给管理员提供更好的操作1.1.8.4 模块四1. 名称：用户模块2. 简介：可以进行授权的操作，登录在线聊天进行交流，登录购物台进行选，购。
1.1.8.5 模块五1. 名称：论坛模块2. 简介：可以查看所有的论坛信息，并进行筛选，删除不健康、不文明留言
IT项目质量管理的计划工具
在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时，提请项目经理、项目负责人等必要的相关人员举行质量会议。
解决当前存在的和潜在的问题。
质量保证是建立在文档的复审基础之上，因而文档版本的控制，特别是软件配置管理，直接影响软件质量保证的影响力和力度。
质量保证小组的检测范围包括：系统分析人员是否正确的反映了用户的需求；软件执行体是否正确的实现了分析人员的设计思想；测试人员是否进行了较为彻底的和全面的测试；配置管理员是否对文档的规范化进行的比较彻底，版本控制是否有效。
3.2 质量管理实施有了良好的资源配备，又如何在项目全生命周期内实施质量保证，让我们从以下几个方面来看质量保证的实施过程：3.2.1 项目进度的质量保证项目进度是项目进行是否顺利的最直观表现。
显然在项目开始之前，项目开发计划是必须的。
如果项目开发计划的制定的是完全合理的，那项目进度也就真正表达了项目与最终的交付使用之间的距离，然而要制定完全合理的项目开发计划几乎不太可能。
可见要保证项目进度，首先要保证项目开发计划尽可能合理。
项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系，通过经验往往能够预见潜在的阻碍，这样要求项目计划制定者需要集众人之力来完善计划。
当项目计划制定初期，由质量保证小组组织召开的项目计划评审会，邀请公司技术专家、用户以及项目组小组成员一起讨论项目计划的可行性，会议通常采用头脑风暴法，各抒己见，会后由指定的记录员形成质量记录，发送给相关人员，对其计划中不合理的地方进行修改完善，并由质量保证人员对其结果跟踪，以确保项目计划完整性、可行性，完善后的计划交由配置管理人员进行版本控制。
然而在计划实施过程中，计划不是“固定化”。
常有人道，“计划赶不上变化”，但“要跟上变化”。
项目计划以里程碑为界限，将整个开发周期划分为若干阶段。
根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，这种方式非常有利于整个项目计划的动态调整。
也利于项目质量保证的实施。
实际运作中，当质保小组发现计划实施的差异后，报告项目经理，由项目经理组织负责对计划进行周期性维护，对于已经变动的计划由质保小组协助配置管理小组完成版本控制。
项目开发各阶段的质量保证a、需求分析需求分析是开发人员对系统需要做什么和如何做的定义过程。
从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。
只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。
从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。
解决系统分析错误的方法。
TAJ Technologies公司通常采用邀请用户参与进行需求评定，然后对其用户的意见由质保成员跟踪检测是否纳入需求规格说明书，同时与用户签字确认形成需求基线，交由配置管理员放入配置管理库。
虽然尽早的邀请用户参与，仍然避免不了项目进行中用户的需求变更请求。
对于开发过程存在的需求变动，我们要求用户填写变更申请单发送给项目配置管理员，在通过配置配置员转交质保小组，负责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影响，小的变更则直接记录入变更记录原因分析项和风险项栏，大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同步变更（包括需求规格说明书、详细设计文、安装手册、操作手册等）。
但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这时，我们将变更报告提交给用户或邀请用户进行协调会议，讨论变更取舍问题或是项目进度变更问题。
作者：麦秸杆儿2006-5-29 16:51 回复此发言6 软件项目质量管理经验谈决定变更之后，由项目经理组织实施变更，测试人员检测变更结果，而质保小组成员监督变更实施过程并协助配置管理员对变更后的成果物进行版本控制。
变更实施完后，上线前还需要指定人员协助用户一同测试并由用户签字后同意方可上线。
b、系统设计优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，自然设计选型成为了系统设计首要的工作，究竟是采用哪种设计方法好呢？对于设计选型不能一概而论，需要针对项目的结构、项目的特征和用户的需求来分析，同样也要考虑到参与项目小组成员的素质，如果其中大部分都没有从事过面向对象的设计且项目进对紧迫，这样没有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所周知面向对象设计方法的优势，我们还是不如采用面向过程的方式（除用户指定开发设计方式外）可以减少项目承担的技术风险。
TAJ Technologies公司有过一个项目，用户指定需要采用面向对象分析、设计和开发，且开发周期短，在无赖的情况下，项目小组只能选用面向对象的软件开发过程，由于项目小组很少从事过面向对象的开发，经验缺乏...
转载请注明出处51数据库 » 软件项目开发计划模板
