软件开发项目进度表(软件开发项目进度表模板)

软件开发 2096
本篇文章给大家谈谈软件开发项目进度表,以及软件开发项目进度表模板对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 本文目录一览: 1、软件项目进度表包含什么内容

本篇文章给大家谈谈软件开发项目进度表,以及软件开发项目进度表模板对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。

本文目录一览:

软件项目进度表包含什么内容

一是参考其它项目.

另一个现在的可参考项目是安装 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 工作日

获得开展后续工作的批准 4 工时

设计工作完成 0 工作日

开发 21.75 工作日

审阅功能规范 1 工作日

确定模块化/分层设计参数 1 工作日

分派任务给开发人员 1 工作日

编写代码 15 工作日

开发人员测试(初步调试) 15 工作日

开发工作完毕 0 工作日

测试 48.75 工作日

根据产品规范制定单元测试计划 4 工作日

根据产品规范制定整体测试计划 4 工作日

单元测试 15 工作日

审阅模块化代码 5 工作日

测试组件模块是否符合产品规范 2 工作日

找出不符合产品规范的异常情况 3 工作日

修改代码 3 工作日

重新测试经过修改的代码 2 工作日

单元测试完成 0 工作日

整体测试 12 工作日

测试模块集成情况 5 工作日

找出不符合规范的异常情况 2 工作日

修改代码 3 工作日

重新测试经过修改的代码 2 工作日

整体测试完成 0 工作日

培训 45.75 工作日

制定针对最终用户的培训规范 3 工作日

制定针对产品技术支持人员的培训规范 3 工作日

确定培训方法(基于计算机的培训、教室授课等) 2 工作日

编写培训材料 3 周工时

研究培训材料的可用性 4 工作日

对培训材料进行最后处理 3 工作日

制定培训机制 2 工作日

培训材料完成 0 工作日

文档 30.5 工作日

制定“帮助”规范 1 工作日

开发“帮助”系统 3 周工时

审阅“帮助”文档 3 工作日

根据反馈修改“帮助”文档 2 工作日

制定用户手册规范 2 工作日

编写用户手册 3 周工时

审阅所有的用户文档 2 工作日

根据反馈修改用户文档 2 工作日

文档完成 0 工作日

试生产 70.25 工作日

确定测试群体 1 工作日

确定软件分发机制 1 工作日

安装/部署软件 1 工作日

获得用户反馈 1 周工时

评估测试信息 1 工作日

试生产工作完成 0 工作日

部署 5 工作日

确定最终部署策略 1 工作日

确定部署方法 1 工作日

获得部署所需资源 1 工作日

培训技术支持人员 1 工作日

部署软件 1 工作日

部署工作完成 0 工作日

实施工作结束后的回顾 3 工作日

将经验教训记录存档 1 工作日

分发给工作组成员 1 工作日

建立软件维护小组 1 工作日

回顾完成 0 工作日

软件开发模板结束 0 工作日

怎么控制软件开发进度?具体方法。

要根据不同技术的开发团队和不同的项目难度制定。调研和数据建模是最基本的。然后在根据调研报告和数据结构制定开发模块,分析开发周期,然后在分析出来的开发周期上在缩短时间分配给下属。期间注意项目进度的跟进和测试

在项目执行的过程中如何进行项目的控制,确保项目进度

转载,供参考。

软件开发项目进度控制

一、影响软件开发项目进度的因素

要有效地进行进度控制,必须对影响进度的因素进行分析,事先或及时采取必要的措施,尽量缩小计划进度与实际进度的偏差,实现对项目的主动控制。软件开发项目中影响进度的因素很多,如人为因素、技术因素、资金因素、环境因素等等。在软件开项目的实施中,人的因素是最重要的因素,技术的因素归根到底也是人的因素。软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。常见的问题有以下几种情况:

1、80-20原则与过于乐观的进度控制

80-20原则在软件开发项目进度控制方面体现在:80%的项目工作可以在20%的时间内完成,而剩余的20%的项目工作需要80%的时间。这个80%的项目工作不一定是在项目的前期,而可能是分布在项目的各个阶段,但是剩余的20%左右的项目工作大部分是在后期。所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉,使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。有些领导看到软件交付给用户了,就一块石头落地“总算交差了”,同时又可能撤出一些被认为不必要的人力资源。但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。这样的结果是拖延了后期的工作,同时如果软件还不成熟的话,会给用户造成不好的影响。

2、范围、质量因素对进度的影响

软件开发项目比其他任何建设项目都会有更经常的变更,大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧,用户是想改就改,造成需求的蔓延,项目经理有时还不知如何拒绝,加上要说“我能”的心理因素,一般都会答应修改。这样集少成多,逐渐影响了项目进度。

如果某项工作在进度上表面上达到目标了,但经检验其质量没有达到要求,则必然要通过返工等手段,增加人力资源的投入,增加时间的投入,实际上是拖延了进度。不管是从横向或纵向来看,部分任务的质量会影响总体项目的进度,前面的一些任务质量中会影响到后面的一些任务质量。

3、资源、预算变更对进度的影响

资源,最主要的还是人力资源,有时某方面的人员不够到位,或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。还有一个很重要的资源,就是信息资源,如某些国家标准、行业标准,用户可能提供不了,而是需要去收集或购买,如果不能按时得到,就会影响需求分析、设计或编码的工作。其他资源,如开发设备或软件没有到货,也会对进度造成影响。

预算其实就是一种资源,它的变更会影响某些资源的变更,从而对进度造成影响。

4、低估了软件开发项目实现的条件

低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。

首先是低估技术难度。软件开发项目团队成员,有时甚至是企业的高级项目主管也经常低估项目技术上的困难。低估技术难度实际上也就是高估人的能力,认为或希望项目会按照已经制定的乐观项目计划顺利地实施,而实际则不然。软件开发项目的高技术特点本身说明其实施中会有很多技术的难度,除了需要高水平的技术人员来实施外,还要考虑为解决某些性能问题而进行科研攻关和项目实验;

其次,低估了协调复杂度,也低估了多个项目团队参加项目时工作协调上的困难。软件开发项目团队成员比较强调个人的智慧、强调个性,这给项目工作协调带来更多的复杂度。当一个大项目由很多子项目组成时,不仅会增加相互之间充分沟通交流的困难,更会增加项目协调和进度控制上的困难。

另外,企业高级项目主管和项目经理也经常低估环境因素,这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。低估这些条件,既有主观的原因,也会有客观的原因。对项目环境的了解程度不够,造成没有做好充分的准备。

5、项目状态信息收集的情况

由于项目经理的经验或素质原因,对项目状态信息收集的的掌握不足,及时性准确性完整性比较差。另外其它一些原因也会造成这种现象。某些项目团队成员报喜不报忧,不希望别人知道自己工作的不好的情况,例如软件程序的编制,可能会先编制一些表面的东西,现有界面,看起来好像完成任务了,实际上只是一个“原型系统”或演示系统。给领导造成比较乐观的感觉。

如果项目经理或者管理团队没有及时地检查发现这种情况,将对项目的进度造成严重的影响。当然,如果出现这种需要时时刻刻都互相提防的氛围,管理人员就应该从管理的角度,从制度的角度检讨一下,进行改进,让大家实事求是地进行沟通。温伯格说:“无论你多么聪明,离开了信息,对项目进行成功的控制就是无源之水、无本之木。”

6、执行计划的严格程度

没有把计划作为项目过程行动的基础,而是把计划放在一边,比较随意去做。例如对于项目团队内部沟通或外部沟通,在计划中要说明清楚人员、周期、方式、方法,不能遗漏,但在实际项目过程中,可能出现沟通没有按时或没有完整地达到所有项目干系人的情况。若项目计划本身有错误,执行错误的计划肯定会产生错误。如,计划制订者在计划系统框架设计考虑上的错误、进度安排上的失误等。实际的项目实施中,除了这种错误之外,还可能因为项目执行上的错误,造成项目的麻烦。例如,项目的客户及其他项目干系人没有及时为项目中出现的情况采取必要的措施或者所采取的措施的不适合具体的情况、没有效果或者有副作用等。另外,如果在项目中的某项工作(如某个子系统或模块、组件)被转包给第三方开发后,不能进行有效的管理,也会造成进度上的延误。

7、计划变更调整的及时性

渐近明细是项目的特点,特别是对于软件开发项目,并不是一个一成不变的过程。开始时的项目计划可以先制定得比较粗一些,随着项目的进展,特别是需求明确以后,项目的计划就可以进一步的明确,这时候应该对项目计划进行调整修订,通过变更手续取得项目干系人的共识。计划应该随着项目的进展而逐渐细化、调整、修正。没有及时调整的计划或者是随意的不负责任的计划的项目是难以控制的。在高技术行业,日新月异是主要特点,因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式,随着项目的进展进行不断细化、调整、修正、完善。对于较为大型的软件开发项目的工作分解结构可采用二次甚至多次 WBS 方法。即根据总体阶段划分的总体 WBS ,需求调研阶段结束、概要设计完成后专门针对详细设计或编码阶段的二次 WBS 。由于需求的功能点和设计的模块或组件之间并不是一一对应的关系,所以只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次 WBS ,根据代码模块或组件的合理划分而得出的二次 WBS 才能在详细设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。有些项目的需求或设计做得不够详细,无法对工作任务的分解、均衡分配和进度管理起参考作用,因此要随着需求的细化和设计的明确,对项目的分工和进度进行及时的调整,使项目的计划符合项目的变化,使项目的进度符合项目的计划。

8、未考虑不可预见事件发生造成的影响

假设、约束、风险等考虑“不周”造成项目进度计划中未考虑一些不可预见的事件发生。例如软件开发项目还会因为项目资源特别是人力资源缺乏、人员生病、人员离职、项目团队成员临时有其他更紧急的任务造成人员流动等不可预见的事件对项目的进度控制造成影响(即项目按时完成是基于如下假设:人力资源不会缺乏、人员不会生病、人员不会流动)。企业环境、社会环境、天灾人祸等事件对项目的进度控制造成影响。对项目的假设条件、约束条件、风险及其对策等对于进度的影响在项目计划要进行充分的考虑,在项目进展过程中也要不断地重新考虑有没有新的情况,新的假设条件、约束条件、潜在风险会影响项目的进度。假设是通过努力可以直接解决的问题,而这些问题是一定要解决才能保证项目按计划完成;约束一般是难以解决的问题,但可以通过其他途径回避或弥补、取舍,如牺牲进度、质量等等;假设与约束是针对比较明确会出现的情况,如果问题的出现具有不确定性,则应该在风险分析中列出,分析其出现的可能性、造成的影响、采取的措施。实际上像没有考虑人的疾病、人员流动这些情况本身也不是什么问题,因为任何人都不可能把所有以外的情况都考虑完整,实际上也没有必要。但有些诸如下班或节假日的加班时间都被安排用于项目工作的情况就会造成更多的项目不确定性。在可能的情况下当然要对所有可能情况都做到有备无患,但是有的时候也要冒一定的风险,同时对于风险的防范也需要考虑如果防范的成本大于风险本身造成的损失和影响,则这种防范是没有必要的。

9、程序员方面的因素对进度的影响

程序员方面有两种常见的心态影响了进度的控制:一是技术完美主义、二是自尊心。

技术完美主义的常见现象是,有些程序员由于进度压力、经验等方面的原因,会匆忙先做编码等具体的事情,等做到一定程度后会想到一些更好的构思,或者看到一些更好的技术的介绍,或者是觉得外部构架可以更加美化,或者是觉得内部构架可以更加优化,这样他们会私下或公开对软件进行调整,去尝试一下新的技术。而是否使用这些新的技术对完成项目本身的目标并没有影响,相反可能带来不确定的隐患。这种做法不是以用户的需求为本、或以项目团队的总体目标为本,可能对软件开发进度造成较大的影响。

自尊心的常见想象是,有些程序员在遇到一些自己无法解决的问题时,倾向于靠自己摸索,而不愿去问周围那些经验更为丰富的人。有些人也许会通过聊天室等方式匿名地向别人求教。如果运气好会很快地解决,否则要花很多实践摸索。而如果向周围的人求教,可能摸索几天的问题别人早就解决了。

10、未考虑软件开发过程的循环、迭代特性

对软件开发的各个过程分类过于精细,制定进度计划时各项工作过于紧凑、没有弹性,造成的后果是,定期提交项目进度阶段报告的制度只有在表面上起到效果,按照计划的时间表提交阶段成果也只是在表面上起到效果。因为“上有政策、下有对策”,强行的规定会使人产生一些错误的认识:如在项目计划中“规定”某个时间只能做某某类别的事情,那么严格执行的后果就是编码阶段就不能修改文档;另外错误的“里程碑”概念可能会使大家轻易地相信上一个阶段的工作成果都是“通过评审”最终定稿了,而实际上可能只是因为时间到了该提交的人提交、该评审的人评审了。如果上下阶段是不同的人就根本不会去检查其中是否还有错误;如果上下阶段是同一个人,就可能非正式地修改上一阶段的错误,但占用的时间和精力却是下一阶段的,并且这样的修改时没有记录的。这样关于阶段进度控制的措施实际上只是在表面上有效。最为普遍的情况是,用户在合同中限定了提交软件系统的时间,实际上这个时间对完成项目任务来说是远远不够的,但计划只能按照合同来进行,所以要不用户让步,要不只能按照时间的约定提交实际上还未完成的软件系统,完成系统的安装,但这时候的“完成阶段任务”只是一个表面现象,系统虽然安装了,但可能是没有经过严格彻底测试的,也可能是只完成了部分的功能,省略了某些功能,有些是整块功能省略,有的是省略了某些功能的某个过程,如数据录入里面隐含的数据录入前缺省值设置、数据录入检验等功能,而是实现了比较粗糙的功能。这样,系统交付并不意味着项目的完成,而在项目交付之后还要花更多的时间。

11、其他因素

以上这些因素是影响项目进度的几个主要方面,除此之外还有很多其他的影响因素。其实最主要的因素还是人的因素,这里的人包括所有与项目相关的人。项目经理的素质、管理者的水平、用户的因素、项目成员的因素等等,都会对项目进度造成影响,这是因为由于软件开发的特性。因为篇幅有限无法一一列举,只能在此分析一些常见的因素。

不可否认,软件开发项目进度可控性还是带有一定运气成分的。特别是需要用户配合的那些软件开发项目,其可控性与用户的成熟度、软件应用领域的成熟程度和行业标准规范的完备程度有很大关系。关于可控性方面会涉及到一些与客户打交道经验,虽然我们说,顾客是上帝、以顾客为中心,但并不是说我们要把主导权交给他们,而关键是我们如何去主导、引导、把握。因此,项目控制的好坏与相关人员人际关系方面的经验也有关系。

尽管存在很多不可控的因素,我们的任务是首先分清哪些是可以控制的,哪些是我们不能控制的。项目经理一是要尽量扩大可控的领域,减少不可控的领域,二是不要在“不可控”上花太多时间,而是多花一些时间把可控的工作控制好,做好防范措施,减轻不可控因素对项目进度的影响。

项目进入实施阶段后,项目经理的几乎所有的活动都是围绕进度展开的。进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目的进度、质量和成本构成一个相互制约的三角关系,需要项目经理去平衡。

二、项目进度控制的目的

项目进度控制和监督的目的是:增强项目进度的透明度,以便当项目进展与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。

1、根据计划进行监控

项目控制的第一个目的是根据计划对项目的各项活动进行监控,即根据已经制定并取得共识的软件开发项目计划来监控项目的实际表现和进度。为此应该根据项目计划来监控项目计划参数的实际值,这些参数包括进度表、项目成本、工作量、工作产品和任务的属性、使用的资源、项目成员的知识和技能;根据项目计划来监控项目团队所作的承诺是否已经或可能兑现、原来的确定的风险是否可以避免或减少损失,是否有新的风险出现;根据项目计划来收集、管理、使用项目数据;根据计划监督项目干系人的参与情况,监控各项任务承担人的参与活动;定期进行必要的进度评审,确定项目是否存在重大偏差、跟踪变更请求和问题报告直到变更或问题得到解决;在项目的里程碑对项目的成果进行评审。

2、管理纠正和预防措施

项目控制的另外一个目的是管理纠正和预防措施,即当项目进度或者结果已经或即将与计划有严重偏差时,对需要采取的纠正或预防措施进行管理。为此应当收集并且分析项目进行中可能存在的问题,并以此确定解决这些问题的纠正或预防措施;对已经确定的问题采取纠正和预防措施;监控要实施的纠正和预防措施,分析措施采取以后的结果,判断这些措施的有效性,确定和记录纠正与计划结果存在偏差的问题而采取的必要且合适的措施。

项目执行过程中仅仅靠最初建立的一份“完善”的基准计划是不够的,最好的计划也未必会一直有效。根据项目任务渐进明晰的特点,特别是软件开发项目的特点,在项目进行过程中,肯定需要在适当和必要的时候对项目进行变更控制,这种控制过程包括定期搜集有关项目进展情况的信息,把实际进展情况与计划进展情况进行对比;如果实际进展情况比计划进展情况有差距,或可能会有差距,就应当采取纠正或预防措施。变更控制应当在项目期间定期进行,这里所说的变更控制不一定要进行真正的变更,而是说要定期对变更进行控制。

如果在项目生命周期内的某一时间点,把实际进度与计划中约定的进度相比对,显示出项目已经延误或即将延误、超出预算目标或不符合质量要求,就必须采取纠正或预防措施使项目回到正轨上来,重新符合计划的安排要求。在已做出执行纠正或预防措施的决定之前,应评估一下纠正与预防措施的有效性和无副作用性,以确保纠正措施使项目回到项目的工作范围、时间和预算约束内,并对项目的其他目标不会造成太大的影响。

3、在各种项目目标中进行平衡

如果经过评估确定项目确实已无法控制,就应当下定决心以牺牲软件功能范围、工作成果范围(如某些中间文档)、成本预算、进度计划或软件质量中的某一项目标为代价,来保住项目最重要的那些目标,在各种项目目标中进行平衡,最终确定一个最合适的解决方案。有效的项目控制的关键是定期及时测量实际进程,并与计划进程相比较,如有必要就立即采取纠正或预防措施。指望不采取纠正和干预措施,问题就自行消失的想法是不现实的。问题越早发现就越好改正,造成的影响和损失越小。问题越提前发现就越好采取预防措施,可以用最小的代价避免造成损失。基于项目实际进展情况,就有可能准确预测项目进度计划和成本预算的实施情况,以便顺利完成项目。如果这些项目参数超出项目目标的限制范围,就必须马上采取纠正措施;如果发现这些项目参数有超出项目目标的限制范围的趋势,就必须马上采取预防措施。

软件开发项目实施中进度控制是项目管理的关键,若某个分项或阶段实施的进度没有把握好,则会影响整个项目的进度,因此应当尽可能地排除或减少干扰因素对进度的影响,确保项目实施的进度。

三、软件开发项目常用进度控制措施

1、项目进度控制的前提

项目进度控制的前提是有效地项目计划和充分掌握第一手实际信息,在此前提下,通过实际值与计划值进行比较,检查、分析、评价项目进度。通过沟通、肯定、批评、奖励、惩罚、经济等不同手段,对项目进度进行监督、督促、影响、制约。及时发现偏差,及时予以纠正;提前预测偏差,提前予以预防。

在进行项目进度控制时,必须落实项目团队之内或之外进度控制人员的组成,明确具体的控制任务和管理职责。要制定进度控制的方法,要选择适用的进度预测分析和进度统计技术或工具。要明确项目进度信息的报告、沟通、反馈、以及信息管理制度。

项目进度控制应该由部门经理和项目监控人员共同进行,之所以需要部门经理参与,是因为部门经理负责项目一般要负责一定人事行政的责任,如成员的考核、升迁、发展等。他们只有通过软件开发项目才能更好地了解项目成员,项目也只用通过对他们有切身利益的管理者参与管理才会更加有效。

2、项目进度控制主要手段

项目计划书:作为项目进度控制的基准和依据,项目负责人负责制作项目计划书。项目进度监控人员根据项目计划书对项目的阶段成果完成情况进行监控,如果由于某些原因阶段成果提前或延后完成,项目负责人应提前申请并做好开发计划的变更。对于项目进度延后的,应当分析产生进度延后的原因、确定纠正偏差的对策、采取纠正偏差的措施,在确定的期限内消除项目进度与项目计划之间的偏差。项目计划书应当根据项目的进展情况进行调整,以保证基准和依据的新鲜性、有效性。

项目阶段情况汇报与计划:项目负责人按照预定的每个阶段点(根据项目的实际情况可以是每周、每双周、每月、每双月、每季、每旬等等)定期在与项目成员和其他相关人员充分沟通后,向相关管理人员和管理部门提交一份书面项目阶段工作汇报与计划,内容包括:

a、对上一阶段计划执行情况的描述

b、下一阶段的工作计划安排

c、已经解决的问题和遗留的问题

d、资源申请、需要协调的事情及其人员

e、其他需要处理的问题

这些汇报将存档,作为对项目进行考核的重要材料。

在计划制定时就要确定项目总进度目标与分进度目标;在项目进展的全过程中,进行计划进度与实际进度的比较,及时发现偏离,及时采取措施纠正或者预防;协调项目参与人员之间的进度关系。

在项目计划执行中,做好这样几个方面的工作:

检查并掌握项目实际进度信息。对反映实际进度的各种数据进行记载并作为检查和调整项目计划的依据,积累资料,总结分析,不断提高计划编制、项目管理、进度控制水平。

做好项目计划执行中的检查与分析。通过检查,分析计划提前或拖后的主要原因。项目计划的定期检查是监督计划执行的最有效的方法。

及时制定实施调整与补救措施。调整的目的是根据实际进度情况,对项目计划作必要的修正,使之符合变化的实际情况,以保证项目目标其顺利实现。由于初期编制项目计划时考虑不周,或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑,计算调整后的各时间参数、关键线路和工期。

3、进度控制内容

从内容上看,软件开发项目进度控制主要表现在组织管理、技术管理和信息管理等这几个方面。组织管理包括这样几个内容:

(1)项目经理监督并控制项目进展情况;

(2)进行项目分解,如按项目结构分,按项目进展阶段分,按合同结构分,并建立编码体系;

(3)制订进度协调制度,确定协调会议时间,参加人员等;

(4)对影响进度的干扰因素和潜在风险进行分析。

技术管理与人员管理有非常密切的关系。软件开发项目的技术难度需要引起重视,有些技术问题可能需要特殊的人员,可能需要花时间攻克一些技术问题,技术措施就是预测技术问题并制订相应的应对措施。控制的好坏直接影响项目实施进度。

在软件开发项目中,合同措施通常不由项目团队负责,企业有专门的合同管理部门负责项目的转包、合同期与进度计划的协调等。项目经理应该及时掌握这些工作转包的情况,按计划通过计划进度与实际进度的动态比较,定期向客户提供比较可靠的报告等。

软件开发项目进度控制的信息管理主要体现在编制、调整项目进度控制计划时对项目信息的掌握上。这些信息主要是:预测信息,即对分项和分阶段工作的技术难度、风险、工作量、逻辑关系等进行预测;决策信息,即对实施中出现的计划之外的新情况进行应对并做出决策。参与软件开发项目决策的有项目经理、企业项目主管及客户的相关负责人;统计信息,软件开发项目中统计工作主要由参与项目实施的人员自己做,再由项目经理或指定人员检查核实。通过收集、整理和分析,写出项目进展分析报告。根据实际情况,可以按日、周、月等时间要求对进度进行统计和审核,这是进度控制所必须的。

4、不同阶段的项目进度控制

从项目进度控制的阶段上看,软件开发项目进度控制主要有:项目准备阶段进度控制,需求分析和设计阶段进度控制,实施阶段进度控制等这几个部分。

准备阶段进度控制任务是:向业主提供有关项目信息,协助业主确定工期总目标;编制阶段计划和项目总进度计划;控制该计划的执行;

需求分析和设计阶段控制的任务是:编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划,控制相关计划的执行等。

实施阶段进度控制的任务是:编制实施总进度计划并控制其执行;编制实施计划并控制其执行等。由甲乙双方协调进度计划的编制、调整并采取措施确保进度目标的实施。

为了及时地发现和处理计划执行中发生的各种问题,就必须加强项目的项目的协同工作。协同工作是组织项目计划实现的重要环节。它要为项目计划顺利执行创造各种必要的条件,以适应项目实施情况的变化。

5、关于进度落后时的“赶工”措施

进度落后的情况下,有几种措施来弥补,如加人、加班、加激励等等,这些都是增加资源而又未必会见效的方法。根据Brooks原则,在某些项目进度延迟的情况下增加人手,有可能会使项目的进度更加延后。因为对于新加入本项目的员工来说,对项目相关背景、需求、设计的培训、对项目环境的熟悉和项目团队成员之间的沟通路径的增加,可能会使项目的工作效率急剧下跌。而加班造成的疲劳会再次使工作效率降低。增加激励会造成工作成本却不断的向上攀升。这些措施并不是完全不可取,而是项目经理要考虑适度原则。最好是要全面分析项目进度延迟的原因,如果确实是不合理的项目交付时限要求,就应当通过沟通变更为合理的项目时限要求,以免因为这样一个不合理的时限要求造成对软件质量或团队成员心理上的负面影响,最终导致项目最终的失败。否则应从技术、团队成员心态、环境等方面查找原因,找到提高效率、加快进度的方法。

软件开发项目进度怎么写。要写具体时间吗。

列下你项目中所有功能点 表明 新建 安排 开发 测试 完成等进度 记得更新每个时间

软件开发项目进度表包含那些内容

一是参考其它项目.

另一个现在的可参考项目是安装 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 工作日

获得开展后续工作的批准 4 工时

设计工作完成 0 工作日

开发 21.75 工作日

审阅功能规范 1 工作日

确定模块化/分层设计参数 1 工作日

分派任务给开发人员 1 工作日

编写代码 15 工作日

开发人员测试(初步调试) 15 工作日

开发工作完毕 0 工作日

测试 48.75 工作日

根据产品规范制定单元测试计划 4 工作日

根据产品规范制定整体测试计划 4 工作日

单元测试 15 工作日

审阅模块化代码 5 工作日

测试组件模块是否符合产品规范 2 工作日

找出不符合产品规范的异常情况 3 工作日

修改代码 3 工作日

重新测试经过修改的代码 2 工作日

单元测试完成 0 工作日

整体测试 12 工作日

测试模块集成情况 5 工作日

找出不符合规范的异常情况 2 工作日

修改代码 3 工作日

重新测试经过修改的代码 2 工作日

整体测试完成 0 工作日

培训 45.75 工作日

制定针对最终用户的培训规范 3 工作日

制定针对产品技术支持人员的培训规范 3 工作日

确定培训方法(基于计算机的培训、教室授课等) 2 工作日

编写培训材料 3 周工时

研究培训材料的可用性 4 工作日

对培训材料进行最后处理 3 工作日

制定培训机制 2 工作日

培训材料完成 0 工作日

文档 30.5 工作日

制定“帮助”规范 1 工作日

开发“帮助”系统 3 周工时

审阅“帮助”文档 3 工作日

根据反馈修改“帮助”文档 2 工作日

制定用户手册规范 2 工作日

编写用户手册 3 周工时

审阅所有的用户文档 2 工作日

根据反馈修改用户文档 2 工作日

文档完成 0 工作日

试生产 70.25 工作日

确定测试群体 1 工作日

确定软件分发机制 1 工作日

安装/部署软件 1 工作日

获得用户反馈 1 周工时

评估测试信息 1 工作日

试生产工作完成 0 工作日

部署 5 工作日

确定最终部署策略 1 工作日

确定部署方法 1 工作日

获得部署所需资源 1 工作日

培训技术支持人员 1 工作日

部署软件 1 工作日

部署工作完成 0 工作日

实施工作结束后的回顾 3 工作日

将经验教训记录存档 1 工作日

分发给工作组成员 1 工作日

建立软件维护小组 1 工作日

回顾完成 0 工作日

软件开发模板结束 0 工作日

微软公司软件开发进度月报ppt

1.1 项目实施进度计划

XXX系统工程实施是以用户需求和技术方案为蓝图,进行全面开发建设以至整个工程建成投入运行的全过程。要确保应用系统工程的成功实施,一定要组织安排好实施计划。同时,一个成功的项目实施,还必须科学有效的使用项目管理流程,才能够充分保障项目依据预定的计划和设计按时保质地完成。以下我们从项目管理的各个要素,简要介绍公司针对本项目的项目管理方案。

1.1.1 项目实施总体思路

1.1.1.1 同时并行实施

为了保证进度,XXX公司专门为客户设计了高度并行的实施计划。XXX公司将为本项目设置多个实施小组,投入大量的人力,同步并行实施,从而大大的减少了施工时间。

1.1.1.2 本地化人员实施

为了加快工程进度,提高对本项目的服务质量,XXX公司充分发挥自身服务体系和强大技术储备的优势,全部采用当地办事处技术人员进行实施。详细请见工程实施小组和项目成员介绍。

1.1.1.3 合理分工有效协调

结合大量项目实施经验,XXX公司可以为本项目做出合理的分工,协调相关厂商,保证项目按期高质量的完成。在本项目中,为了保证进度,划分多个实施小组,项目实施小组严格按照施工方案进行施工,对于意外情况,将同时汇报各自的项目经理,由项目管理小组裁决。

1.1.1.4 合理组织确保工期

本项目地域分布广、涉及众多视频音频以及网络设备的特点,决定了本项目实施中会面临种种风险,包括设备到货风险、众多节点施工风险等等。

为了保证系统的准时上线,借助公司强大的备品备件储备,我们制定了周密的应急方案,保证系统准时上线。

1.1.2 项目组织与管理

1.1.2.1 项目管理的目的

1)提高项目运作的规范性

2)提高异地项目运做的可控性

3)使项目按时验收

4)降低项目成本

5)提高客户满意度

6)确保项目质量

1.1.2.2 项目流程规范的组成

项目管理流程分为四种规范

1)流程:给出项目实施的正确程序。

2)规程、指南:是流程的支持文件,规定某一项目要素的工作程序。

3)模板:是流程的支持文件,给出某个文档的格式。

4)表格:是流程的支持文件,给出某个工作表格的样式。

1.1.2.3 项目实施组织与职责

1)领导重视和参与

XXX系统工程的重视与支持是建设成功的关键。领导的重视主要体现在对该项目的规划决策和监督落实上。领导的参与表现在领导对XXX系统建设项目的需求把握,只有当系统能及时、准确地向管理者提供信息,为管理者的日常办公、决策提供辅助服务时,该系统才具有实质性的意义,系统才具有活力。

在项目建设中,当涉及到资源的分配、人员调动、资金落实、甚至涉及到管理方式改变时,各方领导的参与就显得尤为重要。总之,只有各级领导的参与支持,该项目的建设才可能得以顺利进行。

2)项目实施组织与角色职责

为保障“XXX系统工程”高质量、高效、顺利的实施,XXX公司将成立项目组,并由项目经理调配公司前、后端人力资源,为项目管理及实施提供保障。

项目管理与实施过程中的组织情况如下图所示:

项目联合领导小组

为有效进行资源控制、进度控制、质量控制,确保项目项目顺利实施及系统维护的方便进行,根据公司以往在大型项目管理和实施方面的经验,建议由贺兰公安部门、交警部门及中科软公司共同组成项目联合领导小组,以把握和推动整个项目的执行,保证整个项目如期高质量地完成。项目联合领导小组负责监督项目实施情况,协调解决各方之间的工作问题。项目联合领导小组成员可由XXX系统工程参与方负责人组成。

项目联合领导小组成员负责:

 整个项目的项目预算、项目进度、项目质量等的审核批准和监督;  协调各小组的配合作业,负责合理调配公司内人力及物力资源,以确保本项目高质量、高效率、顺利的进行实施。

贺兰公安局交警队参加联合领导小组成员负责:

 担任联合领导小组的组织领导;

 提供必要的人员配合;

 协调内部各方面联系人;

 监督整个项目进度。

项目经理

 项目经理可以调配XXX公司所拥有的前后端人力资源,负责项目实施小组的领导和日常组织。

项目前端人员

 客户经理:负责客户支持、客户业务需求上报、与客户签定合同以及合同管理等。

 业务经理:负责公司内部前后台部门之间的工作协调、项目实施等。 项目后端人员

 各部门的技术工程师:负责资源配置、网络组织、网络测试、网络运行管理等。

 各部门的系统实施工程师:负责系统开发、系统实施、交付测试等。  技术专家:

“盛泽镇电子警察系统和高清卡口系统建设项目”项目的专家主要由大客户技术支持中心、南京办事处、上海办事处的技术专家组成,提供项目整个项目的技术支持。在该项目中,也可根据项目的需要,从公司抽调专家,一起开展项目的技术支持工作。

1.1.2.4 项目进度管理

为保证管理应用系统的成功实施,必须按照系统开发流程对项目实施进行严格管理。项目启动前,各方人员应做好充分准备,确保项目所需人员及其他必要条件及时就绪。项目实施过程由用户相关单位和部门与我方共同完成,各方应通力合作,并保证人员稳定。

我方有专门的项目管理部门,并且有着严格的项目管理流程,对项目进度进行实时的监督与管理,保证项目的成功实施。

1)项目进度管理的原则

通过项目进度管理使全体成员积极主动,在项目进展中,遇到问题主动找相关人员解决,若解决不得力而又确实属此人管的,则应及时向上一级反映,不得以任何借口推脱不按进度计划完成任务,除非确实是技术上不可解决的,即便如此,也应尽早汇报,以免影响整体进度。

2)项目进度管理的方法

在开始实施项目时,项目经理必须根据任务情况做好进度安排计划,按周做计划以书面呈交项目协调委员会,以周为单位做计划以书面形式下达各组,各组分头安排落实到个人,组长或个人在接到计划书时,认为恰当,则签字;若认为

不恰当,必须及时陈述理由,否则责任自负。在计划时间到时,项目经理严格按照进度计划书验收。在验收合格情况下,项目经理在原下达的计划书上签字,并结合完成任务情况给出一定的评价,将来作为奖励晋级的参照依据;若验收不合格,则责成3日内修正,若仍不能完成必须以书面形式说明理由,项目经理依情况处理。

在每次验收都合格或者在责成期限内都合格的情况下,若项目不能及时完成,责任应在项目经理身上,项目经理必须以书面形式向项目协调委员会陈述理由。

3)项目沟通机制

交流有助于解决问题,尤其是在研究开发等项目组之间。针对本项目的特殊性——多方参与,沟通机制更为重要。沟通畅通能融多方智慧,促进项目成功;沟通阻塞,则障碍重重、举步维艰。项目实施组作为沟通畅通的领头羊,制订相关计划,定期举行项目组和用户的交流会,建立和保持与主要利益相关者的关系,做到双向沟通;定期安排项目组内部各小组之间的相互交流;在日常工作中,营造相互学习共同成长的氛围。

1.1.2.5 资料文档的管理

所有设备的安装调试资料和详细的施工日志都有项目经理统一管理,工程验收后统一交由甲方管理。

完善的文档是项目管理的重要手段,是项目可持续发展的基础,也是项目进度控制和品质保证的重要依据。

“项目投标阶段”以调研考察用户需求为核心,由市场、销售、技术顾问和开发经理联合组成项目小组,开始项目的需求调研与考察工作。通过与用户的接触和充分沟通,适时地形成并评审《用户需求规格说明书》、《项目解决方案》、《合同草案》等文档,确定项目的实施。

“项目实施阶段”以项目投标阶段的《用户需求规格说明书》、《项目解决方案》为基础,重新配置实施过程中需要的资源。在实施过程中,着重加强对项目进度的控制和项目质量的管理。进行任务的明确和职责划分,通过《项目实施计划》、《项目联调计划》、《项目验收方案》进行项目的阶段控制,确保项目能够按质按时顺利完成。

在项目过程中,所有文档可划分为“基础文档(必须有的文档)”和“辅助

软件项目实施进度计划(二):软件项目实施进度表

软件项目实施进度表

软件项目实施进度计划(三):2015软件项目实施计划书

第1篇:学生信息管理系统项目计划书

1引言

1.1编写目的

此项目开发策划书的编写主要是为了给开发《学生成绩管理系统》做主要的规划和整合,在开发过程中起到引导作用,以及给使用者提供简要的说明。

1.2背景

随着计算机应用的日益普及和深化,网上办公已近成为一种趋势。本项目要开发的是基于局域网和互联网的学生成绩管理系统,实现一个将学生成绩管理和服务功能结合起来的管理信息系统,既可以节省资源、又可以有效的存储、更新、查询信息、提高工作和服务效率。

开发的系统要求界面友好,方便直观。既要方便校方对学生信息进行添加、删除、修改、查询和统计等管理,又要方便学生等查询。

软件名称:学生成绩管理系统

项目提出者:“学生成绩管理系统”开发小组

开发者:“学生成绩管理系统”开发小组,成员:郭明娟、陈秋男、王如意、高静、王彩霞、关娜仁、孙佳星、赵鹏、王凤舞。

配置要求:SQL Server2015数据库,C#等

该软件需与数据库连接使用才能运行。

1.3定义

文档中采用的专门术语的定义及缩略词简要如下:

Microsoft Visual C#

Microsoft SQL Server2015

MIS:Student Achievement Management System,学生成绩管理系统

Microsoft Visual Studio2015,版本控制工具

2项目概述

2.1 工作内容

《学生成绩管理系统》针对的用户是学校相关部门、学生。相应的内容有:

(1)主要的功能包括:

1)学校管理:管理部门为每个学生建立信息表格,其中包括学生的,姓名、学号、院系、专业、成绩以及老师的相关信息。

学校相应管理员定期或不定期的对学生和老师信息进行入库、修改、删除、等信息管理以及注销。

2)信息查询:可通过局域网或内网并根据权限依据学号、姓名等查询学生成绩。

(2)管理员实现的主要功能:

1) 查看用户登陆情况。

2)对用户信息的管理。

3)能够对需要的统计结果提供打印输出。

4)能够提供一定的安全机制,提供数据信息授权访问,防止随意删改,同时提供信息备份的服务。

2.2主要参加人员

2.3产品

2.3.1程序

学生成绩管理系统,由C#编程语言编写而成。配合SQL Server数据库

2.3.2文件

1系统需求分析报告

2系统功能说明书

3系统数据库报告

4系统内容设计报告

5美工及界面报告

6用户手册

2.4验收标准

外观新颖、漂亮,以及具备完善的功能。

3实施计划

3.1工作任务的分门与人员分工

组长: 郭明娟、陈秋男 任务: (1)系统总的开发计划书

(2)组织小组讨论,记录讨论内容,列出开发计划

(3)项目开发进度的管理

(4)团队的组织和协调

设计:郭明娟 任务: (1)参与小组讨论

(2)完成系统需求说明书和系统设计说明书

开发:王彩霞、高静 任务: (1)参与小组讨论

(2)根据设计完成编码,并注释

美工及界面:关娜仁、王如意 任务:(1)界面的设计和美工

(2)完成美工报告

影音:赵鹏、王凤舞 任务:(1)记录小组成长过程

(2)完成影音文案作品

3.2进度

3.3关键问题

编码的成功以及与各个组员之间的配合,以及老师的指导。

4支持条件

4.1计算机系统支持

操作系统:Windows 7或XP版本

软件开发项目进度表的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于软件开发项目进度表模板、软件开发项目进度表的信息别忘了在本站进行查找喔。

扫码二维码