软件项目管理大作业.docx
- 文档编号:12897895
- 上传时间:2023-06-09
- 格式:DOCX
- 页数:41
- 大小:51.12KB
软件项目管理大作业.docx
《软件项目管理大作业.docx》由会员分享,可在线阅读,更多相关《软件项目管理大作业.docx(41页珍藏版)》请在冰点文库上搜索。
软件项目管理大作业
软件项目管理大作业
软件项目购销合同
本合同由下述双方签署:
甲方:
联系电话:
乙方:
联系电话:
根据《中华人民共和国合同法》及其他有关规定,甲乙双方在平等、自愿、公开、诚实信用的基础上就XXXXXX储蓄软件项目事宜,经甲乙双方友好协商如下:
第一条储蓄软件项目实施所需的条件(人工及人工费由甲方负责,但技术和质量全部由乙方负责),所进行项目开发所需的事宜明细见附件,附件与本合同不可分割,具有同等法律效力。
第二条产品交付甲方验收前所有质量问题由乙方负责,当交付甲方验收合格后,所有利害由甲方负责。
第三条交货方式双方见面交易。
合同为证。
第四条交货时间为2014年9月17日,交货地点xxx。
对于产品的数量、质量等问题,全部由乙方负责。
第五条合约执行内容
经甲乙双方协商约定,整个软件项目设计由乙方提供专业人员和技术进行开发,甲方不用参与,按照乙方技术进行开发且监工由乙方负责,开发完成后,应达到国家验收标准,当与国家标准发生冲突时,按国家标准执行,测试达到标准后,视为乙方工程全部验收合格。
如未达到验收标准时,所人工费由乙方负责承担,如能补救,由乙方尽快全部负责,直至达到验收标准。
第六条补充说明
乙方计算的全部材料已全部包含软件项目的全部,甲方不再支付任何费用,经乙方设计与预算得出以上内容与附件包含的内容外,不再有任何增项费用,如有乙方全部承担。
第七条双方职责
1、甲方职责
甲方负责协调乙方与同期作业的其他工程之间的关系(作业时间、作业面等)。
2、乙方职责
(1)乙方负责交付工程的可靠性、安全性,如因未按规定施工造成甲方工期延误、财产损害等严重问题,一切责任由乙方承担。
(2)乙方施工人员应遵守国家及甲方的有关规定,遵守安全操作规程,在施工过程中佩戴必要的防护器具,确保施工安全,避免人身事故的发生。
如发生人身安全事故及乙方施工人员违法违纪事件,全部责任和由此发生的费用由乙方承担。
(3)项目实施中,乙方应接受甲方监督。
当甲方发现问题向乙方提出时,乙方应认真对待,如问题属实,乙方应及时拿出解决方案并告知甲方,在取得甲方同意后,立即纠正解决。
(4)乙方要服从甲方对施工作业的有关安排。
第八条工程质量与检验
甲方可随时对作业进度、工程质量进行检查,对不符合设计要求和合同约定及国家质量标准的材料、设备,有权通知乙方更换合同规定的材料、设备。
对不符合规范和质量标准的工序和不安全施工作业,有权通知乙方停工整顿和返工,乙方得到甲方复工令才能复工。
第九条付款方式
合同总价格为xxxx元整,合同签订之日支xxxx工程款,设备进场后支付xxx尾款验收合格后全部付清。
第十条本合同一式两份,甲乙双方各执一份。
甲方:
乙方:
1
储蓄业务软件工程项目管理计划书
1.简介
1.1编写目的
主要为保证整个项目能够按时,保质,保量的完成,每个人在项目开发中都能够发挥自己的作用,使整个软件开发过程顺利,平稳,有序的进行,提供有效的进度参考。
1.2范围
本文档适用于《储蓄业务软件》这一软件项目。
1.3项目概述
本项目要开发一个银行系统,系统一共分为储蓄业务、贷款业务、外汇交易、网上银行、信用卡业务和系统管理六个子系统。
本团队负责其中的有关储蓄业务
的子系统。
通过团队合作开发整个子系统,使团队成员获得软件工程开发的实际训练。
本系统采用目前主流的B/S开发架构,将与整个银行系统一起发布。
不单独发布。
交付的产品包括可执行的文件、源代码、技术文档与用户使用手册等。
本系统的开发过程中的主要工作是子系统需求分析、系统总体设计、子系统源代码开发、子系统测试、交付团长进行最后的集成、整个系统的测试。
关键里程碑是制定项目管理计划书、制定需求设计规格说明书初稿、制定系统设计报告的初稿、进行子系统运行情况的检查与测试、进行系统集成后的运
周,工11行情况的检查与测试。
项目所需工具是个人电脑和开发工具。
进度为/天。
人程量为31.4项目范围说明
2
(1)提交文档:
项目管理计划、需求规格说明,设计报告、测试报告、用户使用手册和项目个人总结。
其中项目总结为每人一份,每个小组所有成员的总结装订在一起;其余文档每组提交一份。
每个团队可将各小组的文档综合到一起,各小组也可自行分开提交,具体方式由团队内部协商确定。
所有文档需要提交电子版和打印稿。
(2)源程序检查:
一共两次。
第一次检查每个小组的子系统运行情况。
第二次检查每个团队内六个小组集成后完整的银行系统运行情况,检查完成后需要提交程序源文件和可执行的系统。
程序检查安排在上机时间进行。
1.5项目生存期:
该项目的特点
此项目需求比较模糊,在开发过程中极有可能发生需求的变更,即使在开发结束后,也常常需要功能上的扩充,
面向的用户群体相当广泛,不同的用户都有可能提出该系统针对某一类群体的改进意见和要求。
项目组内部对此系统的认识也不够统一,对大量辅助功能及新增功能有不同的看法,需要在基本的核心功能完成之后,随着项目的进行,由项目经理进一步收集用户及成员的想法意见进行决策。
用户及成员都需要在短时间内得到一个系统最初的版本,对其进行评价并在后续的开发上对其定位,并得出更多明确的需求。
在项目本身的开发上,为了使系统锦上添花,会用到许多开发人员也并不熟悉的技术,这可能需要开发人员进一步的学习后,再对系统进行改进。
针对该项目的这些特点,权衡各个生存期的适用条件,该项目组选用了增量式模型来开发此系统。
增量式模型的特点如下:
可以避免一次性投资太多带来的风险,将主要的功能或者风险大的功能首先实现,然后逐步完善,保证投入的有效性。
可以更快地开发出可以操作的系统。
可以减少开发过程中用户需求的变更。
一些增量可能需要重新开发(如果早期开发的需求不稳定或者不完整)。
可见,增量式模型充分迎合了该项目的特点,并且提供了多种途径解决项目3
中的一些难题。
生存期中各阶段的描述如下:
项目规划阶段阶段
时间计划和资目确定项目的规模根据合同和初步的需求分析需SOW合同文本输
项目规划,计划确过
项目计输出
阶需求分析阶确定客户的需目SOW
输项目计划需求获取,需求分析,需求控过输原型系统,需求规格
设计阶阶
目总体系统结构设输原型系统,需求规总体设过输系统设计说明书,数据库结构定义
1增量阶段实现实现系统的通用功能目标
系统设计说明书,数据库结构定义输入
详细设计,编码,代码走查,代码评审,单元测试过程
详细设计说明书,源代码,可运行版本输出--1
增量阶段2实现
4
实现系统的用户管理功能目标系统设计说明书,数据库结构定义输入过程详细设计,编码,代码走查,代码评审,单元测试--2
详细设计说明书,源代码,可运行版本输出
阶增实实现系统的文章管理功目输系统设计说明书,数据库结构定过详细设计,编码,代码走查,代码评审,单元测--3
详细设计说明书,源代码,可运行版输
实增阶目实现系统的好友管理功输系统设计说明书,数据库结构定过详细设计,编码,代码走查,代码评审,单元测
--4
详细设计说明书,源代码,可运行版输出
阶增实目实现系统的在线聊天功
输系统设计说明书,数据库结构定过详细设计,编码,代码走查,代码评审,单元测试--5
输出详细设计说明书,源代码,可运行版本
集成测试阶段
目标通过集成环境下的软件测试输入测试计划,测试用例过程集成测试,系统测试输出系统软件包,测试报告,产品说明书
5
阶段产品提交目标产品可投入使用输入系统软件包产品提交过程
验收报输
软件项目计划书的演化1.6软件项目计划书在第三周周末前经由小组讨论、共同撰写、汇总整合三步骤形成初稿,第四周以后根据项目的进展可以对其进行修改,需要有组员提出修改意,在全体会上讨论通过,并由组长整理修改意见并作出相应的修改。
其余组员同步获得更新稿。
项目计划组成结构图:
简要描计划名对应部
确定项目的范围,为制定其他计划打下基础。
范范围计管理是项目实施的依据和变更的输入,另外还包范对可交付成果落实到个人上的分解,即项目分解清楚明确地组织并定义了整),通WB构WB项目的范围,以及该项目的参与者各自的分工成本计划是对完成项目所需费用的估计和计划,成本计项目估项目计划中的一个重要组成部分。
软件成本估算是成本管理的核心,是预测开发一个软件系统所需要的总工作量的过程。
软件成本估算以从软件计、需求分析、设计、编码、单元测试、集成测试到接受测试等这些过程所花费的代价为依据,对完成项目所需要的所有费用进行估算。
进度计划是从时间的角度对项目进行规划。
时间是间项目时进度计划一种特殊的资源,以其单向性、不可重复性、不可计划替代性而有别于其他资源,因此进度计划也是项目6
计划中最难、最重要、最核心的部分。
在进度计划)再进一步分解WBS中,首先根据任务分解的结果(出主要的任务(活动),确立任务(活动)之间的关联关系,然后估算出每个任务(活动)需要的资
最后编制出完整的进度计(如进度表历时源风险计划是在项目进行过程中不断对风险进行风险计别、评估、制定策略、监控风险的过程,它是项分管理中最容易被忽略而且最难以管理的环节。
通风险分析和风险评价去认识项目的风险风险识别并以此为基础合理的使用各种风险应对措施,管方法、技术和手段对项目的风险进行有效的控制妥善处理风险事件造成的不利后果,以最小成本证项目总体目标的实现人是软件项目中最重要的因素,因此软件项目人人力资源资源管理计划也是项目计划中根本的一项计划。
结
力资源管理是保证参加项目的人员能够被最有效用所需要的过程,是对项目组织所储备的人力资开展的一系列科学规划、开发培训、合理调配、当激励等方面的管理工作,是项目组织各方面人的主观能动性得到充分发挥,做到人尽其才,事其人、人事相宜,同时保持项目组织高度的团结和战斗力,从而成功地实现项目组织的既定目标。
关键资源计划是对项目所需关键资源根据生存期阶源键资关键资源计关段所做的计划。
关键资源包括引起竞争的人力和设计划划
备资源。
实施工具计划是对项目开发所需的设备和支持工具具设设施工具计施工计划所做的计划。
划
质量管理计划主要是确定项目应达到的质量标准,理质质量管理计量管以及决定如何满足质量标准的计划安排和方法;依划计划7
据公司的质量方针、产品描述以及质量标准和规则等制定出实施策略,其内容全面反映用户的需求,为质量小组成员有效工作提供指南,也为项目相关人员了解在项目进行中如何实施质量保证和控制提
供依据。
合适的质量标准是质量计划的关键软件配置管理计划用来确定软件配置管理的解决配置管理案,软件配置管理的解决方案涉及面很广,将影计软件软件开发环境、软件过程模型、配置管理系的使用者、软件产品的质量和用户的组织机构。
计划由配置管理者负责制定,它是软件配置管理划过程的产品,并在整个软件项目开发过程中作配置管理活动的依据进行使用和维护保证项目成功必须进行沟通,为了有效的沟通,沟通计沟通计要创建一个沟通计划。
沟通计划决定项目相关人谁需要什么信息、什么时候需要信息和沟通需求怎样获得、选择的沟通模式——什么时候采用书沟通和什么时候采用口头沟通、什么时候使用非式的备忘录和什么时候使用正式的报告等等。
项目组织管理22.1过程模型
8
团队的分工与合作2.2
9
职责角色成员
领导项目团队、张三组长、主程序员执行和管理团
负责软件队交付工作同时作为主序员还要负软件设计和并撰写代码软件设计报告整理需求分程序员文档李
并撰写需求护维护析报告及时修改和布已更新技作为程文档。
员还要参与软件设计与代码开发。
主要负责软件软件测试员、秘王五代码测试和用书、美工10
并撰写户测试、测试文档初稿并对界面美工
付主要责任为秘书要主每周的讨论以及团内沟工作
管理过程.2
管理目标及优先级3.1基本管理原则:
每位成员既是积极的建言者,又是负责的合作者,同时也是决策的制定者。
决策应在充分的讨论基础上由大家共同做出,一旦决策做出就必须被及时有效的执行。
禁止再有异议。
:
按时按量完成项目的基本功能,按时发布产品及文档,这是本团队1目标的最高目标。
:
遵循规范化的项目运作标准,文档严谨完整,代码注释充分,便于目标2后续维护,这是第二目标。
:
产品运行稳定,界面友好,用户易操作,尽量从用户的角度去看问目标3题,并提出解决问题的方案。
:
注重团队建设,成员分工合理,团队成员合作默契,气氛融洽。
每4目标周的讨论会积极建言。
在开发过程中积极协作。
5目标:
项目设计和开发上尽量有创新,有亮点。
3.2项目风险管理项目风险管理的目的3.2.1这些事件将会对项目按预期时风险是指在项目进行过程中可能发生的事件,间,资源和预算完成产生重大影响。
风险管理的目标是在潜在问题发作以前就标志它们,这样就可以在生命周期中可以适时地计划和启用风险处理活动。
11
本次开发过程中存在的风险及规避方法如下表:
风险类型存在风险规避方法
由于时间紧张导充分考虑各种潜进度风险
致项目最后无在因素,适当按期完成有余地;任务解要详细,便
考核;在执行程中,应该强项目按照进度行的重要项,时,都要经保进度作为先决件;同时,合利用赶工期及速跟进等方法,充分利用资源。
如果出现必须延期的情况,组长需及时同银行相关负责人沟通,并申请延期时12
间。
持续地监控,项系统没有足够的目进度控制随着测试时间
项目的进行而断进行的,保每个环节都有够的时间选用正版软件开发软件结构技术风
系存在问题,完成的软件产未能实现项目定目提前制定好两对开发软件的的学习计划,握不够深入,组员要对开发成开发出的产性能以及质量低vs2005+sqlseve劣。
,cssr2005,及photoshop进行快速flash的学习。
尽快掌握其中的要点。
13
同时在软件的设计上尽可能降低难度使项目最后
能成功完成经常和用户交质量不符合用质量风
工作成果、品要管理采用符合求的开发流程认真组织对产审、计划和组严格的独立测等
在项目的启动软件项目开发
段就落实好各实施过程,所
工具的来源或可须用到的管理工能的替代工具,具、开发工具、在这些工具需要测试工具未能及使用之前跟踪并时到位
落实工具的到位事宜。
在进行项14
目开发之前先设计和搭建出系统的基础架构并进
行性能测试,保架构符合性指标后再进行续工作事先同用户商人力资源组员成员因意解决办无法参加设计风险的控制3.2.2.控制方法11()风险管理计划重点是制定一个计划,以处理在排位靠前的高风险项。
迭代重新评估一次。
风险监控时选取风险管理计划中风险管理计划每阶段/迭代启动时,选取“风险管理/没有关闭的前10大风险进行监控即可。
每阶段迭代的周例会上进行/10大风险,用于本阶段计划”中处于“监控”状态的前。
迭代启动时监控的前跟踪和监控(注意:
周例会时只监控阶段/10大风险)
(2)风险的化解避免风险(即:
不要做冒险的活动)(可能对于系统的其他部分此风险不将风险从系统的一部分转移到另一部分会发生或发生时影响不大)购买关于风险的信息(例如:
做实验性项目,请咨询专家等)消除风险的根源接受风险(如果风险后果较小,而处理它可能代价很大,滚动处理可能是最有效的途径)15
特别注发布风险(将风险发布给相关涉众,如:
管理者、市场人员、客户{等)意策略}控制风险制定风险无法化解时的“风险应急计划”
分配额外的资源来处理风险为处理风险留出额外的时间记住风险(为将来的项目积累)风险监控3.2.3
)周例会检查风险(1在周工作例会上,项目经理需要跟踪项目的风险。
大风险,确认已经风险状态是否“发生”或10根据风险列表,逐一分析前;“关闭”PM如果风险发生则启动“风险应急计划”或项目组协商解决办法,必要时负责在风险管理计划中将此条请求相关高级管理者解决已发生的风险,并且PM风险标示为“发生”。
“关闭”。
如果风险已经消除,则PM负责在风险管理计划中将此条风险标示为。
周数统计每项风险的停留时间()
储蓄项目的风险管理3.2.4客户要求的另外,储蓄项目的主要风险是开发人员对客户需求不是很熟悉,进度比较紧,而且具体需求不是很明确,客户可能随时提出需求和对项目的改进,需求的不稳定性和项目规模的不断扩展,可能导致项目存在规模风险。
功能的无限追加,在强大的压力下放弃计划都造成了项目的进度风险。
下面的这个风险列表就是通过一系列的风险识别、风险评估、风险应对,等到的储蓄项目的风险列表。
排序输入风险事件可能性影响风险值风险应对措施
9
1.采取加班的方1
客户3
的需求不明确,3
SOW
法增加需求,导16
修改计划去掉.2致需求蔓延一些任务与客户商量延3.长一些时间
对复杂模块进3622WBS外技术难可以请一些实63进度要求紧23合的学生做辅助一来成二来可.
快进多选择几个可3134WBS供货商外作为备份的外商和供应
注意项目团3135历史项的沟通,及时信流
解开发人员的控制好项目程中的文从其他的项3组借调人员从外部招聘有4.过此类开发经验人员
让有类似项目经22殊项规模成本目的特16
验的小组成员对成本估算性,估算
成本估算审查不准确
17
对每一个里程碑2到1
2软件达不7质量计划进行严格的质量质量指标,软审查件性能欠缺
3采取加班的方法3计划进度要求紧,18
可以请一些实时间紧
的学生做辅助
3.3项目沟通管理报告机制:
要求各组员以周为单位记录工作进展,形成开发日志,并以电子文档的1.
形式提交给秘书进行整理,最后由文档维护员进行维护。
由组每周例会上各位组员积极对当前的开发工作进行积极的评审和建言,2.长做最后的作口头总结,由秘书主持会议并记录和整理会议的内容。
文档维护员修改和维护相应的文档。
并交由小组进行会议评审并给出意见。
小组成员都要密切监控风险状态,发现风险后提交风险报告。
由秘书定3.
期提交风险报告。
必要时将突发风险通知所有组员,并由组长做出临时处理决定。
然后在该周的例会上由小组成员共同讨论对风险的处理意见。
并形成风险处理的日志做为以后的经验。
在项目进行的过程当中,组员之间应该多进行各种形式的非正式沟通,以4.使沟通更加的方便、快捷。
报告格式:
报告主题,时间段,发现人,报告内容,审核意见评审机制:
每周例会上小组讨论形成一致意见后并,并邀请团长和其他组长参加评议。
对于重大的风险处即为通过,相关负责人针对改进意见开展下一周工作,严格执行例会上所制定的决策。
小组会议持续评估其成效。
每一项目阶段结束之前(里程碑前后),组织一次阶段评审会,评估整个阶段的工作效率和成果质量。
尽量与项目例会合理意见,应该由团长及其他组长组成评审团对处理意见进行审议和评估。
并以评审团的决议作为重要参考来制定决策。
项目人力资源管理3.4
3.4.1项目所需人员C#程序员:
张三,李四.Net平台编程和微软要求:
熟悉C#界面设计员:
王五18
要求:
熟悉CSS、Photoshop、.Net平台
数据库设计员:
张三
要求:
熟悉SQL语句,熟练使用SQLSever2005
文档维护员:
李四
要求:
熟悉使用Word及Powerpoint
沟通交流员:
王五
要求:
较强的沟通能力,能及时调解组内以及组与组之间的矛盾。
软件测试人员:
全体组员,有王五付总责
要求:
熟练使用开发工具的debug工具,有耐心。
3.4.2技能培训
C#以及.Net编程培训
培训对象:
全体组员。
培训内容:
熟练掌握C#编程、基本了解.Net平台的特性、并掌握vs2005的调试工具。
于第6周完成。
美工培训:
全体组员
培训内容:
熟悉Css及Photoshop、了解Flash以及Dreamever的基本操作。
于第8周完成。
3.技术过程
4.1开发工具、方法和技术:
本小组的团队组织结构为主程序员式组织结构;编程语言为C#;采用面向对象的分析设计方法;利用Windows.Net平台作为开发平台;使用SqlSever2005作为数据库管理系统图;并采用统一的C#标准的文件命名方式、代码版式、注释等编码规范;编码人员对代码进行严格检查后再进行代码编译;测试人员根据测试文档进行单元测试;最后实现软件的交付。
开发环境:
Sqlsever2005+.Net2.0+VisualStudio2005。
4.2软件需交付的文档:
1.软件项目管理计划
该文档由组长完成,介绍项目的整个管理过程。
该文档在软件设计需求分析初级阶段完成,后续阶段由文档维护员进行相应的更新。
1.需求规格说明初稿
在需求分析阶段,由全体小组成员采集分析用户的需求,并在例会上作出决策,有文档维护员撰写整理需求规格说明初稿,并在后续各个阶段进行需求变更的更新。
2.设计报告初稿
19
在总体设计阶段,小组根据需求规格说明文档,完成软件体系结构的设计,由组长编写软件体系结构设计文档初稿,并在后续开发阶段补充和更新。
该文档由文档维护员负责维护更新。
4.测试文档
在软件开发阶段,测试人员需要编写测试规格说明文档,并在后续测试阶段
更新。
开发人员将根据测试规格说明文档建立测试环境、准备测试数据。
5.用户手册
在更新用需求分析阶段,测试人员需要开始着手编写用户手册,并在需求分析结束后需要形成初稿;在后续阶段不断由文档维护员户文档;并在系统交付阶段随着系统一起被交付。
6.个人项目总结
由组内成员各自独立完成,对开发过程中获得的工作经验进行总结。
在提交系统时一并提交。
7.其他文档
软件开发过程中的其他文档,如开发日志(按组员意见选择公开与否),风险报告及其处理意见等,由秘书进行整理与汇聚。
作为以后软件开发以及交流的经验。
5.项目进度及成本管理
项目估算5.1声明
项目规模估算使用Delphi法进行估算,具体步骤如下:
协调人向小组成员提供项目规格和估计表格;
协调人召集小组讨论与规模相关的因素;
小组成员匿名填写迭代表格;
协调人整理出一个估计总结,以迭代表的形式返回各成员;
协调人召集小组会,讨论较大的估计差异;
成员复查估计总结并在迭代表上提交另一个匿名估计;
5.2项目规模估算
经过小组内部讨论得出项目规模估算如下:
项目名称:
《储蓄软件系统》
规模预测:
20
15,000LOC代码行:
月周期:
1
人月工作量:
6
5530元费用:
¥
项目进度估任完成时资备
开发人员参2013.6.张5
李全体人员参2013.6.8
2013.6.王全体人员参
2张开发人员参设2013.6.
6
2013.7.9李全体人员参
开
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 管理 作业