软件项目方案.docx
- 文档编号:28884246
- 上传时间:2023-07-20
- 格式:DOCX
- 页数:34
- 大小:173.05KB
软件项目方案.docx
《软件项目方案.docx》由会员分享,可在线阅读,更多相关《软件项目方案.docx(34页珍藏版)》请在冰豆网上搜索。
软件项目方案
1项目实施管理方案
我公司通过多年的实践经验积累,形成了整套的软件开发项目的实时管理方案,对项目建设的全程提供过程管理、质量管理,同时支持对客户的系统培训和售后服务。
1.1项目管理流程
项目经理是作为项目驱动的主导者,获得公司管理高层的授权和各管理层的认可,在我公司严格的项目管理制度基础上,严格执行工作流程,确保项目的成功实施与交付。
在我公司系统开发与交付控制程序的指导下,本项目的开发实现过程会包括以下几个阶段:
1.1.1项目立项
根据委托要求规定适于项目的生命周期模型以确定开发过程的活动和任务;明确项目开发原则和项目开发委托合同。
1.1.2需求定义
开发部系统分析员向用户讨论详细需求,建立项目功能与性能基准及运行的环境条件、资料定义、数据库要求、用户操作与维护需求等。
1.1.3系统概要设计
开发部对软件系统进行概要设计,包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等,为软件的详细设计提供基础。
1.1.4系统开发与现场安装调试
由本项目的设计工程师主要负责按照需求进行系统设计与开发。
开发过程需要的相关的资源由研发部提供。
设计工程师提供项目详细设计方案,设备采购要求等。
必要时公司提供调测方案给用户方,并在用户的参与督导指导下进行调试。
1.1.5系统测试
首先由项目组确定系统测试方案,方案应包含详细的条款、测试方法、测试目标和系统测试的必需仪器等。
然后由项目质量员主导,开发及施工人员共同参与进行系统测试。
测试完成后形成测试文档(测试项、测试记录、测试结果、问题点列表、改进方法、最终结论等)。
系统测试方案由项目组提交项目总监和质量经理批准,必要时交用户审核。
测试过程邀请用户参加,测试文档完成后需提交给用户方。
如果系统测试不能满足预定目标时,则在系统改进后,重新进行测试。
1.1.6试运行与验收
系统安装、调试达标后,开始试运行。
一般在试运行期间进行用户培训。
系统平稳运行业务达到用户指定时间(本项目为3个月)后,开始系统验收。
验收规范(包括项目、指标、方式和测试工具等)在验收前一个月提交给用户。
经双方确认后形成最终验收文件作为验收依据。
验收后,即认为我方已按合同规定交付了产品。
1.2项目风险控制
本项目的实施过程是一个复杂的过程,在这过程中会牵扯到方方面面的人、物、事、时间等等。
在信息化的实施过程中,必然会出现这样或那样的困难与风险。
因此,在项目开始前、在项目进行中都必须对可能出现的困难与风险进行深刻地认识、教育与准备。
只有这样,企业信息化才能取得预期的效果,取得最终的成功。
1.2.1风险规避总体思路与原则
风险控制是项目管理的重要的控制手段,是保证项目正常进行的有效防范措施,我公司在进行项目风险控制时,用分析量化已知风险,防范于未然,预测警惕未知风险,有备而无患的总体思路来进行风险管理。
风险规避的原则为:
●文档化管理:
跟踪分析潜在风险;
●无极限沟通:
及时发现风险根源;
●度量化指标:
评估风险潜在数据;
●风险管理储备:
从历史项目积累风险管理经验;
●共同目标:
一切以项目成功为根本,保证风险出现后,相互谅解,相互支持;
●明确项目计划:
基线管理方法,双方达成共识,优先解决主要问题,降低风险影响;
●有序变更控制程序:
通过规范化操作有效控制风险规模,有效地化解风险。
1.2.2风险的识别及对策
(1)商业风险识别及对策
风险类型
检查项
风险的原因
发生阶段
风险缓解措施
政治
法律
市场
政府或者其他机构对本项目的开发有限制
法律\法规的变化
立项
立项时加强立项调查,需求分析
可能有不可预测的市场动荡
法律\法规的变化
立项
立项时加强立项调查,需求分析
可能有不利于我方的官司要打
合同等不正规;法律\法规的变化
立项
立项时加强立项调查,需求分析
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故
无客户服务
立项
立项时加强立项调查,需求分析
竞争对手可能会有不正当的竞争行为
竞争对手的素养
立项
立项时加强立项调查,需求分析
在开发很少有人真正需要却自以为很好的产品
公司的发展战略
立项
立项时加强立项调查,需求分析
可能在开发可能亏本的产品
公司的发展战略;公司的开发能力
立项
立项时加强立项调查,需求分析
客户
客户的需求含糊不清
客户的联系人自己不明白;需求调查不清楚
需求开发
安排充分时间的需求调查,需求文档用户要有承诺
客户反反复复地改动需求
客户的联系人自己不明白;需求调查不清楚;客户没有承诺;
需求开发
安排充分时间的需求调查,需求文档用户要有承诺
客户指定的需求和交付期限在客观上不可行
客户不了解开发;公司的开发能力低于产品需求的开发能力
需求开发
安排充分时间的需求调查,需求文档用户要有承诺,重新变更合同
客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求
客户要求高
需求开发
安排高水平的项目组,需求文档用户要有承诺
客户的合作态度不友善
客户与我们的公司关系不好.客户代表与客户公司之间与问题.
需求开发
需求文档用户要有承诺
与客户签订的合同不一定公正.不一定双方互利.
合同不公正,不正规,有法律漏洞
立项
签订合同时应有法律顾问来审查,有必要时应修改合同,需求文档用户要有承诺
按客户的需求开发了产品,但是客户可能不购买。
客户是信誉不好
测试验收
需求文档用户要有承诺,法律解决
供应商
与供应商签订的合同不一定公正.不一定双方互利.
合同不公正,不正规,有法律漏洞
采购
签订合同时应有法律顾问来审查
供应商的信誉不好
供应商信誉不好,没有执行正确的供应商选择过程
采购
重新执行正确的选择供应商的过程
供应商有可能倒闭
供应商产品不好,市场不好.经营差,金融危机,经济危机,没有执行正确的供应商选择过程
采购
重新执行正确的选择供应商的过程
供应商不能及时交付质量合格的产品(或部件)
供应商的生产能力弱,跟踪差
采购
加强跟踪,有可能的话换一个新的供应商
供应商没有能力做好售后服务
供应商的售后服务能力差
采购
在采购初期执行正确的选择供应商的过程
(2)管理风险识别及对策
风险类型
检查项
风险的原因
发生阶段
风险缓解措施
项目计划
对项目的规模、难度估计可能不太正确\准确
项目估算能力差,工作不够,估算方法不对.估算的参考信息少
项目策划
增加估算力度,运用合理的方法
人力资源(开发人员,管理人员)不够用\不合格.
公司人员不足,人员水平低
项目策划
申请人员
项目所需的软件、硬件不能按时到位
采购部门不能按时采购,所需软硬件无法买到.供方出现偏差
项目策划
跟踪采购,执行正确的采购确定方案过程
项目的经费不足
客户预付款没有到帐.公司帐务管理问题.项目浪费
项目策划
增加估算力度,运用合理的方法,加强费用管理
进度安排可能过于紧张,没有合理的缓冲时间
工期短.估算不足
项目策划
增加估算力度,运用合理的方法
进度表中可能遗忘了一些重要的(必要的)任务
估算不足,需求调查不够
项目策划
增加估算力度,运用合理的方法
进度安排没有考虑了关键路径
估算与策划不足
项目策划
增加估算力度,运用合理的方法
可能出现某一项工作延误导致其他一连串的工作也被延误
没有考虑关键路径,估计不足
项目策划
增加估算力度,运用合理的方法
任务分配不合理,任务没有分配给合适的项目成员
估算与策划不足
项目策划
重新估算,重新策划,把任务分配给合适的项目成员充分发挥其才能
为了节省钱,不采用(购买)成熟的软件模块,一切从零做起
项目利润低,工期有富余.
项目策划
加强决策分析的过程
能者多劳,任务分配不平衡
估算与策划不足
项目策划
合理分配工作与任务,建立好的奖励机制
项目团队
项目成员不团结,存在矛盾
员工之间有过节,员工的信仰不同
整个过程
多开展娱乐活动,促进交流
部分的项目成员对工作不认真负责
公司福利不好,客户关系不好,员工素质差,工作环境差
整个过程
多开展娱乐活动,促进交流,建立好的奖励机制,
部分的项目成员工作热情不高
公司福利不好,客户关系不好,员工素质差,工作环境差
整个过程
多开展娱乐活动,促进交流,建立好的奖励机制,
团队之中可能有“害群之马”
员工素质差,技术水平低.员工想离职公司却不放人.
整个过程
多开展娱乐活动,促进交流,建立好的奖励机制与惩罚机制
技术开发队伍中有临时工
公司人员不足,人员水平低,有临时人员需求
整个过程
公司建立临时人员的管理机制,安全措施.对临时人员建立合理的风险控制能力
本项目开发过程中可能会有核心人员辞职、调动
本项目的级别低,核心人员不想加入这个项目,核心人员在加入项目之前就想辞职了.
整个过程
公司人员储备
不能保证"人员流动基本不会影响工作的连续性"
相应职务与级别的员工比较缺少
整个过程
建立合理\有效的工作记录,加强人才储备
项目经理忙于行政事务无暇顾及项目的开发工作
项目的干系人总是影响项目,项目经理身兼多职.项目组内成员复杂,水平素质参差不齐
整个过程
项目经理专职,策划时规范干系人活动并得到承诺.策划时合理安排人员.
上级领导行政部门合作部门
上级领导可能随时会抽调本项目的资源用于其他"高优先级"的项目
项目计划时没有承诺,项目工期不紧张.客户要求不高,资源确定时没有考虑.
整个过程
保证完整的项目承诺,安排项目工期时应有一定的保证.向上级申请项目延期,
上级领导不是很重视本项目
项目利润不高,规模小,成熟项目
整个过程
找领导谈话,汇报工作
上级领导会过多地介入本项目的事务并且瞎指挥
项目计划时没有承诺,领导能力差,项目经理能力差
整个过程
建立承诺
行政部门的办事效率比较低以至于拖项目的后腿
行政部门的配合力度不够,项目计划时没有承诺,高层控制不力
整个过程
协调,必要时向更高级领导反映情况
行政部门可能会干一些无益于生产力的事情,以至于骚扰本项目
行政部门的配合力度不够,项目计划时没有承诺,高层控制不力
整个过程
协调,必要时向更高级领导反映情况
公司不能全面公正地考核员工的工作业绩
考核方法与奖惩办法不力
整个过程
多开展娱乐活动,促进交流,建立好的奖励机制与惩罚机制
机构没有较好的奖励和惩罚措施
考核方法与奖惩办法不力
整个过程
多开展娱乐活动,促进交流,建立好的奖励机制与惩罚机制
本项目的合作部门的态度不积极,应付了事,或者做事与承诺的不一致
各部门的配合力度不够,项目计划时没有承诺,高层控制不力,项目经理能力不足,与人交恶
整个过程
多开展娱乐活动,促进交流,建立好的奖励机制与惩罚机制
(3)技术风险识别及对策
风险类型
检查项
风险的原因
发生阶段
风险缓解措施
需求开发
需求管理
需求开发人员不懂得如何获取用户需求
无真正的需求开发人员
需求开发
立项时申请专业的需求开发人员或系统分析师
需求开发效率不高
客户对需求不清.开发人员能力不足,客串的或临时的需求开发人员
需求开发
立项时申请专业的需求开发人员或系统分析师
需求开发人员不懂项目所涉及的具体业务.不能否理解用户的需求
开发人员能力不足,无真正的需求开发人员,客串的或临时的需求开发人员
需求开发
立项时申请专业的需求开发人员或系统分析师
需求文档不能够正确地、完备地表达用户需求
开发人员能力不足,无真正的需求开发人员,客串的或临时的需求开发人员,需求开发人员文案能力低下,文档模板不好,
需求开发
立项时申请专业的需求开发人员或系统分析师
需求开发人员不能与客户对有争议的需求达成共识
需求开发人员不懂项目所涉及的具体业务,需求开发人员职责权限有限
需求开发
立项时申请专业的需求开发人员或系统分析师,项目经理参与需求开发
需求开发人员不能获得客户对需求文档的承诺,不能保证客户不随便变更需求
客户素质差,客户与项目组关系不好,项目经理或需求开发人员与客户交恶
需求开发
立项时申请专业的需求开发人员或系统分析师,项目经理参与需求开发,项目经理增加与客户的交流
综合技术
开发能力
包括设计测试等
开发人员没有相似产品的开发经验
公司人力不足,使用实习人员,人员搭配不合理
策划-开发
立项或项目策划时申请有能力的人员,加强培训
待开发的产品可能要与未曾证实的软硬件相连接
采购部门更改采购内容,客户提供的资源有变化,集成测试不力,估算与策划不力
开发编码
按正确的过程确定采购方案,集成方案,提前采购,加强对软硬件的培训.
对开发人员而言,本项目的技术难度高
公司人力不足,人员搭配不合理,项目是公司业务拓展试点
策划-开发
培训,申请人员
开发人员没有全部掌握了本项目的关键技术
培训不足.
策划-开发
培训,申请人员
如果某项技术尚未实践过,开发人员不能在预定时间内掌握
技术难度大,开发人员学习能力差,培训差.
策划-开发
增加前期培训,申请人员
开发小组没有采用比较有效的分析、设计、编程、测试工具
估计与策划不力,开发小组水平低
策划-开发
加强估算\策划\设计.增加培训
分析与设计工作过于简单、草率,从而让程序员边做边改
需求开发人员工作热情不高.工期短,分析与设计与开发是同一人完成
策划-开发
划分合理的工作任务安排,确定职责与权限,合理的里程碑
开发小组没有采用统一的编程规范
公司无规范,开发小级无QA,无评审活动,项目经理管理不力
开发
制定编程规范,申请QA,加强评审.
开发人员对测试工作不重视,不能保证测试的客观性
公司不重视测试工作,无专门的测试人员,产品质量与工资无关
测试验收
建立奖惩制定,产品质量与效益挂钩
项目经理对测试工作不重视
公司不重视测试工作,无专门的测试人员,产品质量与工资无关
测试验收
建立奖惩制定,产品质量与效益挂钩
客户对测试工作没有要求
客户认为公司的质量要求能满足他们的要求.客户对开发工作不了解
测试验收
不管有没有,都要有测试过程
项目没有独立的测试人员,不懂得如何进行高效率地测试
公司不重视测试工作,无专门的测试人员,产品质量与工资无关
测试验收
增加测试人员的策划
没有对所有重要的工作成果进行了同行评审(正式评审或快速检查)
工期短.重视不足,人员少
整个过程
增加测试人员的策划
开发人员不懂得版本控制和变更控制,不能够按照配置管理规范执行
无配置管理员
开发
加强策划与培训,安排配置管理人员
开发人员不重视质量,会在进度延误时降低质量要求
公司不重视测试工作,无专门的测试人员,产品质量与工资无关
开发
加强策划与培训
1.2.3风险的组织级日常管理
我公司的软件项目在软件开发的风险控制方面有组织级的策略,以下做简要介绍。
(1)建立组织级风险库
●确定风险的来源与类别、风险的级别
a)过程改进组收集组织日常动作过程中总结的常见风险和行业内的通用的风险管理方法中的常见风险。
b)过程改进组分析这些收集而来的常见风险,确定风险的参数,一般包括风险的来源、类别。
c)过程改进组制定风险的等级划分办法。
可依据风险的来源、类别、可能性、严重性等、制定一个在风险识别时,对风险进行等级划分的依据和方法。
●建立风险库
a)过程改进组将收集来的常见风险归档分类,形成一个组织内部的《风险库》,一般按来源和类别进行分类。
b)过程改进组应将“风险的等级划分办法”作为风险库的一个附件,一同发布。
(2)维护组织级风险库
●建立组织级风险维护计划、维护准则
组织级风险维护准则应该是不违反组织《风险库》维护准则。
●增加新的可能发生的风险
a)按照组织《风险库》维护准则的要求和办法,收集项目组、个人、公司内部、公司外部的风险改进建议、各个可能的风险。
分析改进建议及各种风险,形成一个能正确的风险描述,排除掉相似、相同的只是说法不一样的风险,排除掉《风险库》中已经存在的风险。
b)过程改进组评审或检查这些风险,认为有必要或确切与组织的实际活动相关的风险,确认风险的来源、类别等,并将其补入《风险库》中。
认为没有可能的风险或没有必要的风险,则被抛弃。
●修改风险来源、类别、可能性等
过程改进组依据《风险库》维护准则定期检查现有的《风险库》,修改不合适的风险的来源或类别。
当检查到在某种范围内从来没有发生的风险时,应通过过程改进组的审核,适当的降低此风险的发生的可能性。
●删除不可能发生的风险
过程改进组依据《风险库》维护准则定期检查现有的《风险库》,当发现从来没有发生的风险、或不可能发生的风险时,通过过程改进组的审核,从《风险库》中删除这个风险的描述。
●发布新的《风险库》
过程改进组依据组织财富库的维护及发布准则,定期发布经过修改的《风险库》。
1.2.4项目的风险管理
在组织级之下,在项目中的一些风险管理措施也是非常关键的。
(1)确定风险、制定计划
●分析项目情况
项目经理组织项目成员或项目干系人,依据已经确定的《用户需求说明书》、《项目过程定义书》,掌握项目的现实情况。
●分析风险的情况,确定分析类别、范围
项目经理组织项目成员或项目干系人分析项目的实际情况,结合组织提供的《风险库》,识别出项目中可能存在的风险类别和范围;认定项目有哪些类别的风险要防范。
●确定已识别的风险的参数
项目经理组织项目成员或项目干系人依据组织提供的《风险库》中的《风险等级划分》,确定本项目的《风险等级划分》。
●制定风险管理计划
项目经理组织项目成员或项目干系人分析项目可能存在的风险,依据工作安排,与项目组成员讨论,一起形成《项目风险管理计划》。
《项目风险管理计划》中主要包括对风险管理的时间安排,活动安排,人员安排,资源安排等;制定当前项目的风险管理的准则。
准则中应包括:
Ø风险如何来分类;
Ø如何确定参数系统;
Ø规定参数的阈值;
什么情况下什么范围内的人要参加制定风险缓解方案、执行这个方案等;
风险监督的时间安排和力度(一般可以在里程碑时安排)。
●识别风险
项目经理组织项目成员或项目干系人分析项目的实际情况,结合组织提供的《风险库》,识别出项目中可能存在的风险;
依据组织风险库的一些经验性文档,排除一些几乎从来没有发生的风险(或这部分风险也没有采取过措施的),确定出本项目的风险,并填写在《风险识别跟踪表》中的“风险列表”中。
项目经理组织项目成员或项目干系人通过对已经识别的风险的分析,确定风险的类别、来源、严重性、可能性等参数,依据组织提供的“风险等及划分”,确定本项目的风险的等级划分。
确定风险的排列顺序。
项目经理将结果记录在《风险识别跟踪表》的“风险列表”中的“风险等级”中。
将风险的等级划分办法也作为附属表或说明加入到《风险识别跟踪表》中。
项目经理组织项目成员或项目干系人通过对已经识别的风险的分析,确定风险的类别、来源、严重性、可能性等参数,依据组织提供的“风险等及划分”,确定本项目的风险的等级划分。
确定风险的排列顺序。
项目经理将结果记录在《风险识别跟踪表》的“风险列表”中的“风险等级”中。
将风险的等级划分办法也作为附属表或说明加入到《风险识别跟踪表》中。
●制定缓解风险措施
项目经理组织项目组成员,也可以在必要的情况下组织项目干系人,依据已经识别的风险及等级排序,制定相应的缓解措施方案。
当初次识别的风险的参数系数已经超过了规定的阈值时,项目经理组织项目组成员,依据已经建立的缓解措施方案,执行缓解措施。
没有超过规定的阈值的风险可以不作任何处理。
同时项目经理应组织制定一套完整的风险发生的问题应急预案,用来处理风险转化为问题时的处理。
项目经理将缓解措施方案、应急方案记录在《风险识别跟踪表》中。
(2)风险跟踪
项目经理定期跟踪、监控风险的现状。
●定期跟踪识别风险
只要项目没有结束,项目经理依据《项目风险管理计划》定期或事件驱动地跟踪、监控风险的现状。
定期分析当前风险的可能性,严重性等参数是否发生变化。
是否有新的可能的风险会产生。
当风险发生变化时,及时组织人员对这个风险进行分析、制定缓解措施方案。
1)当风险参数变化超过规定的阈值,但没有转化为异常,或没有造成对项目有明显的影响时,项目经理组织人员依据已经制定的缓解方案,对风险进行缓解。
2)当风险参数变化超过规定的阈值,并已经对项目有明显的影响,产生了不良后果或产生灾难性后果,也就是说风险发生,转化为异常时,项目经理应及时组织项目组成员、项目的干系人(包括客户、高级经理等)分析这个异常,制定一套良好的应急方案。
异常有可能导致项目失败。
项目经理组织人员执行这个应急方案来解决这个异常,直到各相关项目干系人认为措施已经缓解了风险为止。
3)项目经理应将风险跟踪活动中的,分析分析、制定方案、缓解风险等过程、结果,花费的时间、人力、资源等一一记录在《风险识别跟踪表》中。
(3)总结经验
当项目结束时,项目经理总结“风险管理”过程中的一些建议、经验教训、新发现的可能的风险等,形成项目的总的建议、经验教训,可以将这部分写入《项目总结报告》或《过程改进建议》中,一并提交到过程改进组。
2项目进度及技术文件交付计划
我公司根据招标文件中的具体进度要求,初步排定了项目初步的建设进度和各进度阶段的成果交付计划。
2.1项目阶段及时间安排
本项目于项目合同签订后开始,3个月内完成投标系统的详细需求调研与分析;6个月内完成系统的设计、开发、测试和安装部署,开始试运行;9个月内系统正式上线。
详细计划如下:
合同签订后1个月,项目准备阶段:
项目立项,团队组建,细化项目计划,确立项目目标与评价基准。
合同签订后2-3个月,项目调研阶段:
项目组对用户需求进行详细调研,明确设计要求,与用户沟通设计方案。
合同签订后4-5个月,项目开发阶段:
软件设计与开发,硬件配置与采购,单元测试。
合同签订后6个月,模拟环境测试,完成测试报表,以及用户现场软硬件安装,调试,具备运行条件。
合同签订后9个月,完成系统试运行,试运行结束,系统正式上线,项目验收。
项目各个阶段的目标、交付物及双方的责任义务如下表:
阶段目标
交付物
责任义务
完成详细需求调研与分析
详细需求调研及分析报告
由我公司与招标方双方共同完成
完成设计、开发和测试
系统设计、程序代码、测试报告
由我公司负责系统设计开发测试工作
完成系统安装部署,具备试运行条件
系统安装部署计划、试运行方案
由我公司负责系统安装部署,并负责用户培训
完成系统试运行,系统正式上线
试运行报告
由招标方安排用户对系统进行试用,由我公司负责对各类系统问题进行解答处理
完成项目验收
项目验收单
由我公司与招标方双方共同完成
系统质保期
系统运维报告
由我公司负责对系统进行运维,并对各类系统问题进行解答处理
2.2沟通计划
项目沟通计划采用会议和书面形式进行,项目会议将按沟通计划所规定的方式定期或不定期举行。
沟通类型
参与/分发人员
频率
召集/负责人
形式
实施项目例行会议
实施项目小组
每天
实施实施组长
会议
各组项目周计划
当地实施组,项目领导小组
每周五
各地项目组组长
文档
项目状态报告和周计划
项目领导小组、项目经理、项目各小组负责人
每周五
项目组各小组负责人
文档
项目周例会
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 方案