制定计划的软件.docx
- 文档编号:30127684
- 上传时间:2023-08-05
- 格式:DOCX
- 页数:50
- 大小:33.19KB
制定计划的软件.docx
《制定计划的软件.docx》由会员分享,可在线阅读,更多相关《制定计划的软件.docx(50页珍藏版)》请在冰豆网上搜索。
制定计划的软件
制定计划的软件
篇一:
如何制定和编写软件项目计划
如何制定和编写软件项目计划
软件项目计划(Software Project Planning)是一个
软件项目进入系统实施的启动阶段,主要进行的工作包括:
确定详细的项目实施范围、定义递交的工作成果、评估实
施过程中主要的风险、制定项目实施的时间计划、成本和
预算计划、人力资源计划等。
在软件项目管理过程中一个关键的活动是制定项目计划,
它是软件开发工作的第一步。
项目计划的目标是为项目负
责人提供一个框架,使之能合理地估算软件项目开发所需
的资源、经费和开发进度,并控制软件项目开发过程按此
计划进行。
在做计划时,必须就需要的人力、项目持续时
间及成本作出估算。
这种估算大多是参考以前的花费作出
的。
软件项目计划包括二个任务:
研究和估算。
即通过研
究确定该软件 项目的主要功能、性能和系统界面。
一、软件项目计划内容
软件项目计划内容如下:
1.范围。
对该软件项目的综合描述,定义起所要做的工
作以及性能限制,它包括:
(1)项目目标。
(2)主要功能。
(3)性能限制。
(4)系统接口。
(5)特殊要求。
(6)开发概述。
2.资源。
(1)人员资源。
(2)硬件资源。
(3)软件资源。
(4)其他。
3.进度安排。
进度安排的好坏往往会影响整个项目的按期完成,因此
这一环节是十分重要的。
制定软件进度与其他工程没有很
大的区别 ,其方法主要有:
(1)工程网络图。
(2)Gantt 图。
(3)任务资源表。
(4)成本估算。
(5)培训计划。
二、制定软件工程规范
对软件工程管理来说,软件工程规范的制定和实施是不
可少的,它与软件项目计划一样重要。
软件工程规范可选
用现成的各种规范,也可自己制定。
目前软件工程规范可
分为三级:
(1)国家标准与国际标准。
(2)行业标准与工业部门标准。
(3)企业级标准与开发小组级标准。
三、软件开发成本估算
为了使开发项目能在规定的时间内完成,而且不超过预
算,成本预算和管理控制是关键。
1.成本估算方法
(1)自顶向下估算方法。
估算人员参照以前完成的项目所耗费的总成本,来推算
将要开发的软件的总成本,然后把它们按阶段、步骤和工
作单元进行 分配,这种方法称为自顶向下估算方法。
它的优点是对系统级工作的重视,所以估算中不会遗
漏系统级的诸如集成、用户手册和配置管理之类的事务的
成本估算,且估算工作量小、速度快。
它的缺点是往往不
清楚低级别上的技术性困难问题,而往往这些困难将会使
成本上升。
(2)自底向上估算方法。
自底向上估算方法是将待开发的软件细分,分别估算每
一个子任务所需要的开发工作量,然后将它们加起来,得
到软件的总开发量。
这种方法的优点是对每个部分的估算
工作交给负责该部分工作的人来做,所以估算较为准确。
其缺点是其估算往往缺少与软件开发有关的系统工作级工
作量,所以估算往往偏低。
(3)差别估算方法。
差别估算是将开发项目与一个或多个已完成的类似项目
进行比较,找到与某个相类似项目的若干不同之处,并估
算每个不同之处对成本的影响,导出开发项目的总成本。
该方法的优点是可以提高估算的准确度,缺点是不容易明
确“差别”的界限。
除上三种还有:
(1)专家估算法。
(2)类推估算法。
(3)算式估算法。
2.成本估算模型
(1)COCOMO 估算模型。
机构性成本模型 COCOMO(Constructive Cost Mode)是
最精确、最易于使用的成本估算方法之一。
该模型分为:
基本 COCOMO 模型,是一个静态单变量模
型,它是对整个软件系统进行估算;中级 COCOMO 模型,是
一个静态多变量模型;详细 COCOMO 模型,将软件系统模型
分为系统、子系统和模块三个层次。
①基本 COCOMO 模型估算公式:
E=ab(KLOC)exp(bb)
D=cb(E)exp(db)
式中 E 为开发所需的人力(人/月)。
D 为所需的开发时
间(月)。
KLOC 为估计提交的代码行。
ab、bb、cb 和 db 是
指不同软件开发方式的值。
②中级 COCOMO 模型。
其估算公式为:
E=ai(KLOC)exp(bi)×乘法因子,ai,bi
(2)Putnam 成本估算经验模型。
Putnam 估算模型是一种动态多变模型,它是假设在软件
开发的整个生存期中工作量的分布。
如下图:
根据曲线导出关于提交的代码行数 L,人力 K(人/年)
和时间 td(年)之间估算公式:
式中 Ck 是技术状况有关
的常数,它的典型值如下:
对于差的开发环境 Ck=2500
对于好的开发环境 Ck=10000
对于有的开发环境 Ck=12500
由上述公式可以得到所需开发工作量的公式:
四、风险分析
风险分析对于软件项目管理是决定性的,然而现在还是
有很多姓名不考虑风险就着手进行。
五、软件项目进度安排
软件项目的进度安排与任何一个工程的进度安排没有实
质上的不同。
首先识别一组项目任务,建立任务间的相互
关联,然后估计各个任 务的工作量,分配人力和其他资源,
指定进度时序。
1.软件开发任务的并行性
若软件项目有多人参加时,多个开发者的活动将并行进
行。
2.Gantt 图
Gantt 图常用水平线段来描述把任务分解成子任务,以
及每个子任务的进度按排,该图表示方法简单易懂,一目
了然,动态反映软件开发进度情况。
如下表:
进程计划时间表
3.工程网络图
工程网络图是一种有向图,该图中用圆表示事件,有向
弧或箭头表示子任务的进行,箭头上的数字称为权,该权
表示此子任务的持续时间,箭头下面括号中的数字表示该
任务的机动时间,图中的圆表示与某个子任务开始或结束
事件的时间点。
如下图:
六、软件质量保证
软件质量保证是软件工程管理的重要内容,软件质量保
证应作好以下几个方面的工作:
(1)采用技术手段和工具。
(2)组织正式技术评审。
(3)加强软件测试。
(4)推行软件工程规范(标准)。
(5)对软件的变更进行控制。
(6)对软件质量进行度量。
七、如何制定软件项目计划
项目计划详细说明了所需软件工作及如何实现。
它定义
了每一个主要任务,并估算其所需时间和资源,同时为管
理层的评估和控制提供了一个框架。
项目计划也提供了一
种很有效的学习途径。
如果能合理建档,它便是一个与实
际运行效能比较的基准。
这种比较可以使计划者看到他们
的估算误差,从而提高其估算精确度。
我们着重强调对项目规模和资源的估算,是因为低质量
的项目资源估算将不可避免地造成资源短缺,进度延迟和
预算超支。
又由于项目资源估算是从软件规模估算中直接
衍生出来的,所以低质量的规模估算是造成许多软件项目
问题的根本原因。
项目计划应在项目开始初期制定出,并随着工程的进展
不断地加以精化。
起初,由于软件需求通常是模糊而又不
完整的,我们的工作重点应在于明确该项目需要哪些领域
的知识,并且如何获取这些知识。
如果不遵循这一指导原
则,程序员们通常会积极地投入到那部分已知的工作中去,
而把未知部分留滞到以后。
这种工作方式通常会产生很多
问题,因为未知部分具有最高的风险系数。
软件项目计划
的逻辑如下所述 :
由于软件需求在初始阶段是模糊而又不完整的,质量计
划只能建立在对客户需求的大致而不确切的理解之上。
因
此,项目计划应该从找出含糊不确切与准确恰当的软件需
求间的映射关系入手。
接着建立一种概念设计。
项目初始架构的建立要十分谨
慎,因为它通常标定了产品模块的分割线,同时描述了这
些模块所实现的功能及所有模块间的关系。
这就为项目计
划和项目实施提供了组织框架,因此一个低质量的概念设
计是不能满足要求的。
在每一次后续的需求精化时,也应同时精化资源映射,
项目规模估算和工程进度。
八、制订软件项目计划的方法与策略
制订软件项目计划的目的在于建立并维护软件项目各
项活动的计划,软件项目计划其实就是一个用来协调软件
项目中其它所有计划,指导项目组对项目进行执行和监控
的文件。
一个好的软件项目计划可为项目的成功实施打下
坚实的基础。
篇二:
制订软件项目计划的方法与策略
制订软件项目计划的方法与策略
制订软件项目计划的目的在于建立并维护软件项目各项
活动的计划,软件项目计划其实就是一个用来协调软件项
目中其它所有计划,指导项目组对项目进行执行和监控的
文件。
一个好的软件项目计划可为项目的成功实施打下坚
实的基础。
软件项目有其特殊性,不确定因素多,工作量估计困难,
项目初期难于制定一个科学、合理的项目计划。
我曾主持
和参与过大大小小的软件项目十余项,下面我将把我制订
软件项目计划的经验分享给大家。
1.注重项目计划的层次性
软件项目计划的层次及其关系如下图所示。
高级计划,是项目的早期计划。
高级计划应当是粗粒度
的,主要是进行项目的阶段划分,确定重大的里程碑,所
需相关的资源,包括人力资源、设备资源、资金资源,即
所谓的人、财、物三个要素。
大的阶段交替之前,应做好下一阶段的详细计划,我们
称之为二级计划。
详细计划要确定各项任务的负责人,开
始时间,结束时间,任务之间的依赖关系,设备资源,小
的事件点(即里程碑)。
如果项目规模相对较大,可以有多级的计划,比如说,
一个项目组可能分为几个开发组,二级计划是各开发组制
订的适合的自己小组的计划。
如果开发组还分了小组,可
以有小组的三级计划。
开发人员的个人计划是低级计划,由开发人员根据自己
的任务自行制定,要把任务细化到人·日。
一般的,软件项目计划至多有四级就够了,过多的等级
将会引发效率的瓶颈。
大的项目不见得要有庞大的组织和
人员数量来支撑,合理的划分小组,减少组织的层次,有
利于项目计划的制
订和实施。
较小的软件项目由于工期不长,人员较少,
有二级计划(高级计划与低级计划)也是可行的。
2.重视与客户的沟通
与客户的沟通是很重要的。
不必害怕客户知道我们的开
发计划,特别是项目进度情况,应当和客户共享这些信息。
首先,客户会提出一些对项目时间、进度、效果上的要
求,这个指标往往经不起推敲,有的还带有较强的政策性。
如:
在我主持的一个某单位人事 MIS 系统的开发中就发现,
客户方对时间上的约束是有成形的文件的,是他们单位领
导们开会的决定。
客户给出的从项目启动到验收的时间只
有三个月,但是,经过我们认真的需求调研,做出项目进
度的粗计划和部分的二级计划后,发现三个月的时间是难
于实现的。
我们把做出的调研文档和项目计划摆出来和和
客户讨论,最终使项目的开发时间延长为六个月。
站在为
了科学地分析和解决问题的立场上来看,项目组和客户的
目的是一致的,所以对于合理的项目进度客户是会理解与
支持的。
其次,我们有义务要让客户知道项目的计划。
这样才能
让客户和用户主动、积极参与项目,达到项目的最终目标。
项目计划取得双方签字认可是一种好的习惯。
客户可能不
愿意签正式的文件,那么在文档的封面上签上双方负责人
的姓名、联系方式也行,虽然是非正式的,但留下了项目
工作的痕迹。
有必要想办法让客户清楚签字意味着什么。
这就意味说双方有了一个约定,既让用户感觉心里踏实,
也让自己的项目组有了责任感,有一种督促和促进的作用。
3.该详细的详细,该简略的就简略
软件项目计划就如同软件项目本身一样有它特殊性,一
个三五个人花两三个月就可以完工的小项目,可能项目计
划就四五页纸,包括一个 WBS(工作分解结构)和一个
Gantee 图(甘特图)。
一个需要五六十个人甚至上百人,要
花上半年或更长时间的大型软件项目则会有更多的项目计
划内容。
我们得按照项目的的特定情况量体裁衣。
如下表表 1 所示,这是我主持的一个某高校教务办公信
息系统项目的风险管理计划表。
项目较小,我们只用了两
个月的时间就开发完工,通过验收。
正因如此,我们在项
目计划中大量的采用了这种表格来制订人员计划、培训计
划、风险计划、成本估计、文档大小估计、进度计划,一
目了然,责任到人,其效果和效益是很明显的。
项目的工作安排一定要责任到人,这点是要详细的。
如
果是多个人共同完成的任务也要指定一位主要负责人,否
则开发人员会操作不便,甚至互相推卸责任。
4.制订的项目计划要现实
软件项目中的项目经理和系统分析员大都是从程序员成
长起来的,我亦是如此,担任项目经理之前我写了五年的
VB、Java 和数据库 SQL 代码。
项目经理和系统分析员做出
来的项目计划最终要能够被项目组成员所实现。
制订项目计划仅靠“个人经验”是不够的,不可能面面
俱到,不要期希望于“个人经验”。
解决的办法有两个方面。
一是充分鼓励、积极接纳项目干系人(包括客户、公司
高层领导、项目组成员)来参与项目计划的制定。
可以邀请客户和公司高层领导来共同讨论高级计划的制
订。
客户会乐意参与的,因为追求项目的成功是大家的共
同目标。
公司高层领导的支持是项目组的坚强后盾,项目
组需要获取必要的资源,需要及时获取对项目特殊要的审
批,需要在领导事务上得到适当的指导和帮助,有些事项
有时是需要公司高层领导加入才能解决的,如合同款项的
按期支付。
制订二级、三级项目计划要与项目组成员互动。
当规划
由一个人做出而由另一个人实施时,如果项目没有按时完
成,会使得他们怀疑项目计划的可行性,也会影响开发人
员的士气。
与项目组内部人员的沟通亦很重要。
软件程序
员平时通常表现得内向、清高,作为项目经理应当学会调
节工作中的气氛,在轻松的氛围中去融合开发人员的意见。
可以让开发人员对自己职责范围内的事提出建议的时间
和资源,再作讨论约定。
这样开发人员在主观上会更加投
入工作。
客观上,开发人员的能力很难用时间及工作量来
衡量,一名熟练的 Java 程序员比一名初学 Java 的程序员
开发效率可能快上四五倍,因而安排的时间周期、任务量
当然要不一样。
我比较倾向于召开一次专题讨论会,事先
写出一个初稿,再各抒已见,最后作出结论。
二是要充分利用一些历史数据。
历史数据是宝贵的财富,
是可复用的资源。
不仅要注意积累这些数据,也要学会从
中提炼出可以为我所用的数据。
如,项目计划的模板,计
划的资源数据等。
5.运用过程化的思想指导开发
软件项目计划是 CMM2 级的一个 KPA。
可用软件过程化的
思想指导计划的编制与实施。
CMM2 共有 6 个 KPA,它们是:
需求管理、软件项目计划、
项目跟踪和监控、软件转包合同管理、软件质量保证、软
件配置管理。
一个软件组织如果达到了 CMM2 的各个过程方
面的全部目标,就表明这个组织的软件能力达到了第 2 级
成熟度等级。
这也可以是针对一个项目而言。
通常需要根据项目的进
展情况对项目计划进行修改,以便应付需求和承诺的变更、
不够准确的估计、纠正措施和过程更改等。
在策划和重新
策划中涉及的活动,都包含在这个过程方面里。
6.利用成熟的项目管理工具
Microsoft Project 2000(或更高的版本)是一款公认
的功能强大、操作方便的项目管理工具软件。
它自带了一
个叫做“软件开发”的模板,可以用它来生成大体的框架,
再作细节方面的改动,也可以自己制作一个符合自己公司
软件项目运作流程的模板。
Microsoft Project 2000 的操作面版中可以安排任务,
并设置开始时间、结束时间、前置任务、资源名称等参数,
它能自动生成 Gantt 图、Pert 图,找出项目中的关键路径。
7.结束语
软件项目计划分为高级计划、二次计划、三级计划和低
级计划,制订软件项目计划应注意及时与客户沟通,该详
细的详细,该简略的就简略,制出来的计划要是现实的,
可以运用 CMM2 的思想指导计划的制订,Microsoft
Project 是倍受推荐的项目计划软件工具。
愿我们多做出高
质量的软件计划,从而打造软件精品。
篇三:
工作计划制定软件(共 2 篇)
篇一:
附录 6:
软件开发项目计划编制过程
软件开发项目计划编制过程
1 项目计划的要素
根据 pmbok2000,项目计划可以包含如下要素:
1.1 项目范围说明 1.1.1 项目意义
为了使用户和开发小组能明确对所建网站要达到的功能。
双方通过不断地讨论和交互,最终形成具有建设性目标的
书面条款。
经过研究确认后,将作为开发小组设计开发的
基本依据和需求方的软件验收标准。
同时,通过该需求分
析报告,开发小组可以更加进一步了解客户的需求,从而
严格按照流程及时、准确的完成系统的开发,以满足客户
的需求。
同时,该文档也是概要设计及后续设计的基础.
1.1.2 项目框架
1.2 项目进度计划 进度
对于需求分析、设计、编码实现、测试、移交、培训和
安装等工作,给出每项工作任务的预定开始日期、完成日
期及所需资源,规定各项工作任务完成的先后顺序以及表
征每项工作任务完成的标志性事件(即所谓“里程碑)。
系统规划阶段:
项目标志性事件开始到完成 开发阶段:
项目开发计划书的完成3.09-3.12 需求分析阶段:
系统需
求说明书完成 3.12-3.20 系统概要设计:
系统概要设计
说明书完成 3.20-4.05 系统详细设计阶段:
系统详细设计
说明书 4.05-4.25 编码实现:
项目的形成 4.25-5.05
测试阶段:
测试计划和 bug 跟踪列表 5.05-5.12 移交阶
段:
项目的递交 5.27工作任务的分解与人员分工
组长:
苏威任务:
(1)系统总的开发计划书。
(2)每个阶段组织小组讨论一次,记录讨论内容,列
出本阶
段开发计划。
(3)项目开发进度的管理。
(4)团队的组织和协调。
设计:
李 燕魏红芳
(1)参与小组讨论。
(2)进行系统的需求分析和系统设计。
(3)完成系统需求说明书和系统设计说明书。
(4)编写测试计划,参与系统测试,记录 bug 跟踪列
表。
(5)协助文档人员完成用户相关文档。
开发:
苏 威李 燕 魏红芳
(2)根据设计完成编码,并注释。
(3)进行单元测试。
1.3 项目质量计划
基于企业的质量方针和质量目标,结合本项目的特点,
制定项目的质量目标:
1).基于需求测试的覆盖率为 100%;
2)软件功能测试用例通过率大于 95%;
3)每个阶段评审中发现的我难题都已经解决或得到处
理; 4)产品发布时不存在严重及其以上的缺陷。
1.4 项目资源计划
在编制图书管理系统项目计划中考虑到,4个开发人员
是全职在这个项目中,二项目经理,质量保证和配置管理
人员不是全职在这个项目中,他们还同时在管理其他的项
目,进行成本估算的时候,应该根据项目人员付出的时间
以及各项任务的具体情况进行成本预算,最后得到比较详
细的成本分配情况,即成本基准。
滋养费用比例如下表所
示:
1.5 项目沟通计划
1.6 风险对策计划 1.6.1 风险管理规划
风险管理规划是规划和设计如何进行项目风险管理的过
程。
该过程包括定义项目组织及成员风险管理的行动方案
及方式,选择适合的风险管理方法,确定风险判断的依据
等。
风险管理规划的流程如图所示:
1.6.2 风险降低活动可列出减少风险发生的可能性或减
少风险发生时所造成损失的程度,对
那些应特别关注的风险,几种降低风险的活动可以同时
开始。
降低风险的活动示例如下:
(1)建立一个可测试此活动的模型。
以验证这种风险降
低策略可以减少风险发生的可能性;
(2)为有风险的活动
建立备选方案。
一旦风险发生,采用备选方案可使该风险
对项目整体进度的影响降低。
1.7 项目采购计划
(1)五台 pc 机
(2)一台交换机
1.8 变更控制、配置管理计划
由于软件开发的手工性、个体性特征,软件开发项目计
划不可能是一个静态的计划,一次在项目启动时,可以先
制定一个颗粒度相对比较粗的项目计划,先确定项目高层
活动和预期里程碑。
粗颗粒度的项目计划需要不断地更新
迭代,根据项目的大小和性质以及项目的进展情况进行迭
代和调整。
迭代和调整的周期也是根据项目的情况进行制
订的,一般短到一周,长到 2 个月左右。
经过不断的计划
制订、调整、修订等工作,项目计划从最初的粗粒度,变
得非常详细。
这样的计划将一直延续到项目结束,延续到
项目的成果出现。
2 项目计划编制过程
由于软件开发的手工性、个体性特征,软件开发项目计
划不可能是一个静态的计划,一次在项目启动时,可以先
制定一个颗粒度相对比较粗的项目计划,先确定项目高层
活动和预期里程碑。
粗颗粒度的项目计划需要不断地更新
迭代,根据项目的大小和性质以及项目的进展情况进行迭
代和调整。
迭代和调整的周期也是根据项目的情况进行制
订的,一般短到一周,长到 2 个月左右。
经过不断的计划
制订、调整、修订等工作,项目计划从最初的粗粒度,变
得非常详细。
这样的计划将一直延续到项目结束,延续到
项目的成果出现。
制定计划的过程就是一个对项目逐渐了解掌握的过程,
通过认真地制定计划,项目经理可以知道哪些要素是明确
的,哪些要素是要逐渐明确的,通过渐近明细不断完善项
目计划。
阶段计划中包含的工作汇报和下一阶段工作安排
是掌握项目进度的依据,从阶段计划对照总体计划,才能
一目了然地看出工作的进展情况。
制定计划的过程,也是
在进度、资源、范围之间寻求一种平衡的过程。
制定计划
的精髓不在于写出一份好看的文档,而在于运用您的智慧
去应对各种问题和面临风险并尽可能做出前瞻性的思考。
一旦计划被负责任地完成,他就可以给自己一个和管理层
或客户交流与协商的基础,帮助你在项目过程中防范各种
问题的出现,帮助你保证项目按时完成。
企业确定要开始某个项目时一般会下达一个立项的文件,
暂且叫“项目立项文件”,主要内容是遵照的合同或相关协
议,项目的大致范围、项目结束的截止时间和一些关键时
间,指定项目经理和部分项目成员等等。
接下来的项目计划编写一般要按照以下过程:
2.1 成立项目团队:
2.2 项目开发准备:
2.2.1 工具准备
(1)五台 pc 机
(2)源代码管理工具
2.2.2 开发环境
配置环境、数据库环境等
2.3 项目信息收集:
项目经理组织项目团队成员通过分析接收的项目相关文
档、进一步与用户沟通等途径,在规定的时间内尽可能全
面收集项目信息。
项目信息收集要讲究充分的、有效率的
沟通,并要达成共识
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 制定 计划 软件