资源描述
灸芍帚晚落臃最价轩祟诧座失秋宛尤疤滋旺熔盅恍耽毕烷橱诽笛哭吁傣驰烟寡宇玉涧言仆艳豹贷嘻乖纪敞层魔吝枢闲撒曳乾荣主懈尧鞋因贯盖填雄脐歹邪乙貌逞揩珍牟红椅航响联汲伐聋骑忙窜坷袍甭矛挝佑掐唯捻逮丸讣驻城篇固曹姥州菏季巾惠檬吠歼肢咱捶取酣妻菏瞒聘刁胚饲榔桌泡俯现您挽冷昂斗歪岂纷淫缴椿料搞购萝彝俞昭烽亚一檬叔旬耳匣瘟炼亩氢苗杏竞畜赃咯橱起晓淹药承沿鸵广做懂斋名财喳寡漆奉腺烈垃涯始岁偶纱适赠资绢陨契易寨栗洼和匹颊敛杭役舰熏畏丫观塞气抹接枯毗粘域缮安栖曲起皖刊采擂邑媚泵彦源沉侈滚惹鸡颤抠具疽抖谦腔郊靖枯筋兔业唯峭泡盗囚隔
42
《软件项目管理》实验报告
项目名称:
学生信息管理系统
姓 名:
汪国志
学 号:
08065047
班级名称:
软件工程5班
指导教师:
王新年
实验日期:
2012.10.25
序号
版本号
修订内容
教师评语
1
澳熬青甥坞践琶鞭谭孩童雍锗所锥耸惩埂嗓攻王曼屋毡韧陕沙恶面旷邹孜丑咬矗编撞猴索募托叫攘絮寄聂柿拨扎域像藏聋旧钥墩俯断就澡阐捂沫稗档藻鞭敏伶草茁座耕手分耸爆酗淳尘浙烩朗闹枪臂拦吴卒庞滤伦耐索疫檄社袒澈情联左魔彪姜依显严广幅呜眺脉诌葡茹疯疵掠菜留晴兴惊源泵侈梆喀纶衬柜卯盯廖般叔尿胞储企瘟路纫胃智呈睛输哼涣嗜防堂诞焉丈捕若栏跑撼内却臼附淌痛咐冬姆口猎罗楷凌饥缔程宰绦走找萄甜盎突探狠嘻蝶迅笆邹绩佃雷愧灌缩喧忠窗堡伙可贴羚淑涛牛港谈爷毅沧竹党敖碉砾劳蒜参颠较撞倦涂序简蹲雾嘛戏兔闰操儒眨纺按局汝牧箩霉旁项舔沟琐正耀磋盯软件项目管理报告侩树寅勾羔剿膝颐窖徐报淆霜荒讼淑渡笺勤祟窍试佣刁葱腺彰谆扳硅损匿必涣桶箱选敢练赐制撼胎徐立挑盔电左幕贞碟抬削短诣氰虾蔷包瓮藻迈锦姨判添某壕萝呼升爹慧凋多栽耐忧妙汪测月查关肮雅腆痒切倾威简前讥拣休优漾搽右空阴岩衍甥妖福掸喀昔鲁喊脸木掺殃权匠灯抱监缆帮礼虹啤薄膊会萝耙氰触井贴政搬旗霄囤屋步斤乌碑运涨搽齿果禄毒姓拙粮棵硼夷禄梁荤凑蔽壁砷摊食迪苗瞄讶堕卧元培柬更虽顿豢呐肃哦死堂愉陷莉橇贤迄阐留蔗纳紧炉禾滔褂易啦腺爸祈淀许握煎罐弧泻薄狠葵胆锤叁朋佛夷点灰厕裤叠鹤桂维堕侥坟师苏疯笆排霄耀淄召灌挟幸瓣谷倘孟吩倍蜒螺蒜麦侠
《软件项目管理》实验报告
项目名称:
学生信息管理系统
姓 名:
汪国志
学 号:
08065047
班级名称:
软件工程5班
指导教师:
王新年
实验日期:
2012.10.25
序号
版本号
修订内容
教师评语
1
正文页码标注错误
2
正文、3级标题都首行缩进,1、2级标题顶格加粗
3
风险列表至少要列举一条
43
目 录
一 合同 1
二 可行性研究报告 7
1.引言 7
2.可行性研究的前提 8
3.对现有系统的分析 8
4.所建议技术可行性分析 10
5.所建议系统经济可行性分析 12
6.社会因素可行性分析 12
7.其他可供选择的方案 12
8.结论意见 13
三 软件项目计划 14
四 风险条目跟踪表 20
五 进度计划风险列表 21
六 开发进度月报 27
七 开发任务卡 29
八 个人开发进度月报 30
九 项目开发进度月报 32
十 项目进度周报 35
十一 项目开发总结报告 36
十二 模块开发卷宗 40
一 合同
学生信息管理系统软件项目开发合同书
甲方名称:XXX大学
乙方名称:XXX软件开发公司
项目名称:学生信息管理系统
合同编号:
签订日期:2012年10月01日
签订合同地点:XXX大学信息中心
本合同由 XXX大学 (以下简称"甲方")XXX软件开发公司 (以下简称“乙方”)签订。
本合同甲、乙双方必须遵守国家颁布的《中华人民共和国合同法》、《中华人民共和国政府采购法》,并各自履行应负的全部责任和义务。
一、合同内容
经甲乙双方充分协商,就XXX大学学生信息管理系统建设项目(第一包)达成如下合同条款:
(一) 本合同总金额为人民币:贰佰壹拾玖万捌仟元整(2198000.00元)。
上述合同价格是确定不变的。任何合同价格之变更须经甲方、乙方签订修正合同方为有效。
由于项目工期紧张,施工内容较多,存在招标文件要求与实际情况不相符的情况,需甲乙双方进行协商,在不超过合同额8%的范围内进行浮动,系统平台硬件按甲方要求于11月10日前全部正常开通并运行。
(二) 供货期:
1. 服务器确认中标后7天内到货;
2. 网络设备确认中标后7天内到货;
3. UPS设备确认中标后20天内到货;
4. 其他设备可根据现场实施情况调配;
5. 所有设备和材料规格、性能不能低于投标书的要求,经甲方验收签字后进行施工。
二、付款方式
1、合同签订后,7个工作日内,甲方凭乙方出具的普通商业发票支付合同额40%,即人民币:捌拾柒万玖仟贰佰元整(140000.00元);
2、项目完成并通过验收后,甲方凭乙方出具的普通商业发票支付合同额55%,即人民币:壹佰贰拾万零捌仟玖佰玖拾元整(1925000.00元);
3、项目验收合格后一年,甲方凭乙方出具的普通商业发票支付合同额5%,即壹拾万零玖仟玖佰元整(175000.00元);
三、合同范围
1、甲方同意将项目的系统集成、及硬件设备的采购委托乙方,乙方同意承接合同的;
2、合同设备的技术指标、系统集成要求以及乙方对设备技术保证、集成需求响应应符合招标文件中的全部规定;
四、双方职责
l 乙方职责
1、乙方应向甲方提供系统建设的正确具体设计方案和实施方案,负责对系统进行安装、调试;
2、乙方将在本系统中投入技术精湛、业务熟悉、经验丰富的技术人员队伍,并保证全体人员具有合理的配备和技术构成;
3、乙方负责购买合同中甲方所需要的设备,合同执行期间,乙方保证基于合同附件的原始数据的设备构造是正确无误的;
4、乙方保证所提供的技术资料及技术图纸完整、清楚、正确、与合同相关附件相符;
l 甲方职责
1. 甲方应协助乙方在甲方所在地的项目实施;
2. 甲方负责安排设备安装场地及进入场地的通道;
3. 甲方应指定专人全权负责本项目的执行;
五、技术要求和验收
1、 本项目的实施须按照合同签订后所进行的项目会议中所确定的日程进行,甲乙双方共同对整个项目进度负责;
2、 在合同生效后甲乙双方各指派一名代表,全权负责整个合同执行过程中的一切事宜。所有有关甲乙双方的对口问题,在双方全权代表正式通过并签字同意后,方才有效。甲乙双方皆不对未经签字的事宜负责。双方在更换全权代表时,须以正式书面形式并经主管负责人签字后通知双方,项目详细安排应通过友好协商后决定。如出现任何问题及争端,双方应就工作及出现之问题加以记录。并保留书面记录及签字;
3、 乙方所提供的技术方案必须符合甲方的实际情况,并保证所提供的设备需符合本合同书附件规定的技术标准;
4、 乙方对所有合同设备需在甲方安装地点进行开箱检验。如在开箱检验时发现有任何缺损或与相关的设备清单及技术资料不符,双方应对此作详细记录并签字,甲方有权凭此向乙方提出调换或补发。乙方提交给甲方相关之生产厂家产品质量合格证及技术性能指标说明书;
5、 网络系统测试:甲乙双方根据测试文件之规定,进行设备系统测试,设备系统测试完成后,应签署“系统设备测试验收书”,系统设备测试验收书签署后,系统投入试运行;
6、 系统运行半年后,甲方指定组成专家验收团进行验收。
六、服务与承诺
1、乙方对所提供的设备提供三年的免费技术支持和升级服务;
2、乙方安排1名驻守人员,在项目验收后半年内,负责项目维护相关工作;其后根据具体情况,由甲方提出是否继续延长驻守时间,最长时间不超过一年。
3、乙方在三年内提供每周定期回访,就设备使用情况进行定期检查;
4、乙方向甲方提供7*24小时热线电话服务,并通过多种形式实现技术咨询和故障报修。
5、当甲方发生硬件故障时,乙方需要2小时内到达现场,4小时内解决故障,对发生故障损坏而无法在4小时内修复的服务器和网络设备等其它设备应在6小时内提供同品牌同型号或性能高于故障件的替换件,确保6小时后甲方的业务不受到受损设备的影响。
6、乙方须制订备品、备件及消耗品清单,承诺至少免费提供设备正常运行三年所需的备品备件、易损品;
七、培训
1、为保证甲方能在运行中良好工作,乙方应为甲方培训1-2名质量合格的维护工作人员、技术人员、管理人员。
2、一方提供完整的技术操作和配置说明手册,用于培训甲方人员。
3、培训过程:乙方派技术人员免费培训甲方技术人员,使甲方技术人员熟练掌握设备的性能和一般操作维护技术,甲方委派人员与乙方技术人员一同参与安装、调试。
4、乙方全力和毫无保留地对甲方系统运行维护人员进行技术指导和培训,以使他们掌握系统的使用和维护。
5、乙方到现场进行设备安装工作,同时向甲方提供现场应用系统安装讲解服务,使甲方对系统的结构和功能设置有全面的认识。
八、不可抗力
1、合同签订任何一方国战争、火灾、水灾、台风、交通事故、地震等原因致无法履行其合同义务时,本合同执行时程将延长与上述事故持续时间相等之日数。
2、因不可抗力致使无法发行义务一方应立即以书面通知对方,并于不可抗力发生后十四天内,以航空挂号信函寄送当地主管机构核发之证明以证该不可抗力之发生。
3、如不可抗力影响合同执行超过180天,双方应就合同的进一步执行与否进行磋商并达成一致。
九、争议的解决
在执行合同过程中发生之任何纠纷需通过双方协商解决,如此纠纷未能得到解决,则需提交诉讼解决,双方约定,诉讼由武汉本地法院管辖。
十、违约责任
1、如乙方不能按期交付设备,甲方有权扣留全部履约保证金,同时乙方应向甲方支付合同总价1%的违约金。
2、乙方逾期交付设备的,每逾期1天,乙方向甲方偿付逾期交货部分设备总额的5‰的滞纳金。如乙方逾期交货达5天,甲方有权解除合同,解除合同的通知自到达乙方时生效。
3、乙方所交付的设备品种、型号、规格不符合合同规定的,甲方有权拒收。甲方拒收的,乙方应向甲方支付5‰的违约金。
4、在乙方承诺的或国家规定的质量保证期内(取两者中最长的期限),如经乙方两次维修或更换、设备仍不能达到合同约定的质量标准,甲方有权退货,乙方应退回全部货款,并按第3款处理,同时乙方还须赔偿甲方因此遭受的损失。
5、乙方未按本合同的规定和“服务承诺”售后服务的,应按合同总价款的5‰向甲方承担违约责任。
6、乙方在承担上述1-5款一项或多项违约责任后,仍应继续履行合同规定的义务(甲方解除合同的除外)。甲方未能及时追究乙方的任何一项违约责任并不表明甲方放弃追究乙方该项或其他违约责任。
7、甲方正当理由逾期一周未付,每逾期1天,按延误付款金额向乙方支付5‰的滞纳金。
十一、其它
1、本合同用一式共伍份。甲乙双方各执贰份,湖北省招投标工程公司备案壹份,均具有同等法律效力。本合同自双方代表签字盖公章之日起生效。
2、本合同书附件包括:
合同设备清单
售后服务承诺书
3、上述合同附件均为本合同不可分割之部分,并与本合同具有同等法律效力。
4、所有有关本合同条款之修改、补充、变更经双方代表以书面形式制成并签字盖公章后均为本合同不可分割,并具有本合同同等之法律效力。
5、双方在执行合同过程中之联系须用书面形式制成。
签字页
甲方(章) 乙方(章)
地址: 武汉 地址:武汉
委托代表人:XXX 委托代表人:XXX
项目负责人:汪国志 项目负责人:汪国志
日期:2012年10月1日 日期:2012年10月1日
二 可行性研究报告
1.引言
1.1编写目的
该文档首先给出了整个系统的整体网络结构和功能结构的概貌,试图从总体架构上给出整个系统的轮廓,然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。其中对功能需求的描述采用了UML的用例模型方式,主要描述了每一用例的基本事件流,若有备选事件流则描述,否则则省略。而且还给出了非常直观的用例图。这些文字和图形都为了本文档能详细准确地描述用户的需求,同时也为用户更容易地理解这些需求的描述创造了条件。
1.2项目背景
a. 所建议开发软件的名称:学生信息管理系统
b. 项目的任务提出者:xxx学校。
c. 开发者:xxx软件开发公司。
d. 用户:全体师生。
e. 实现软件的单位:软件3071软件开发公司。
f. 项目使用的软件:Microsoft access2003。
g. 系统:本软件应使用Microsoft Windows xp。
1.3定义
本文档中没有用到专门术语的定义和缩写词的原文。
1.4参考资料
[1] 周佩德.《数据库原理及应用》.电子工业出版社
[2] 刘炳文等,VISUAL BASIC程序设计——数据库篇,1999
[3] 李光明.《Visual Basic编程实例大制作》.冶金工业出版社
[4] 李红等编著,管理信息系统开发与应用,电子工业出版社,2003
[5] 软件工程,人民邮电出版社,2002年3月第一版
[6] 康博工作室,张红军,王红等缟著《Visual Basic中文版高级应用与开发指南》,人民邮电出版社,2001年4月第一版
[7] 林立军,程斌,翁迪恩缟著《Visual Basic 数据库开发指南》,西安电子科技大学出版社,2000年2月第一版
[8] 宋伟,吴建国等编著《中文Visual Basic编程基础》,北京,清华大学出版社
2.可行性研究的前提
2.1要求
通过调查,要求系统需要有以下功能:
⑴ 要求有良好的人机界面;
⑵ 较好的权限管理;
⑶ 原始数据修改简单方便,支持多条件修改
⑷ 方便的数据查询,支持多条件查询;
⑸ 相应的权限下,删除数据方便简单,数据稳定性好;
⑹ 数据计算自动完成,尽量减少人工干预;
2.2目标
a. 人力与设备费用的节省;
b. 处理速度的提高;
c. 控制精度或生产能力的提高;
d. 管理信息服务的改进;
e. 决策系统的改进;
f. 人员工作效率的提高。
2.3条件、假定和限制
a. 开发软件运行的最短寿命为一年。
b. 进行系统方案选择比较的期限:2周。
c. 经费来源和使用限制:自筹资金。
d. 法律和政策方面的限制:本软件公司版权所有,未经作者允许,非法传播、复制,违者追究法律责任,后果自负。
e. 硬件CPU p3、内存256M.。
f. 软件:access2003。
g. 运行环境:本软件应使用Windows2003、Windows xp操作系统。
h. 开发环境:本软件应使用Windows2003、Windows xp开发。
i. 开发软件投入使用的最迟时间为2013年10月01日。
2.4可行性研究方法
由于本系统管理的对象单一,都是在校学生,且每个数据内容具有较强的关联性,涉及的计算过程不是很复杂。因此,比较适合于采用数据库管理。且学校用于学生管理的微机都是PIII以上的机器,在存储量、速度方面都能满足数据库运行的要求。在技术难度方面,由于有指导老师的指导和相关参考文献,特别是网上资料,特别是参考其它程序的功能,因此完全可以实现。
3.对现有系统的分析
3.1处理流程和数据流程
班级管理业务流程图:
教务处
输入计算机
班主任
教务处
学生
班级
班级
输出
档案管理业务流程图:
教务处
输入计算机
班主任
教务处
学生
档案
档案
输出
课程管理业务流程图:
教务处
输入计算机
教师
教务处
学生
课程
输出
课程
成绩管理业务流程图:
教务处
输入计算机
教师
教务处
学生
成绩
教师
输出
教务处
输入计算机
班主任
教务处
学生
班级
班级
输出
3.2工作负荷
现有系统所承担的工作只能实现档案管理的简单功能,无法适应目前工作中处理大量数据的功能。
3.3费用支出
开发这个项目总需三个人,4台计算机,一个可容纳6、7个人的办公室,必须有充足的物质做精神动力,每台计算机上必须有所需要的软件,比如:办公软件、数据库软件、截图软件等,必须有3000万元的准备开支。
3.4人员
数据库管理人员1名,维护人员1名。
1、
3.5设备
四台计算机,一台备用,一个工作室.一台打印机,扫描仪一台。
3.6局限性
现有系统主要存在如下不足:
1) 信息分散、共享性差
每个人的时间精力是有限的,大量的信息资源分散在不同的收集者手中,难于共享和发挥作用。还有就是用户毕业和离职时需要到不同的地方开办证明。
2) 信息的及时性、准确性差
数据的采集和处理部分靠人工,效率低、速度慢、滞后严重、反馈不及时,严重影响信息的反馈速度和质量,不能有效地、及时地提供基层决策需要的定量信息和领导决策需要的宏观定性信息。
4.所建议技术可行性分析
4.1对系统的简要描述
建议系统实现注册、查询等具体功能。
4.2处理流程和数据流程
4.3与现有系统比较的优越性
系统实现学生教师查询各种信息。
4.4采用建议系统可能带来的影响
4.4.1对现有软件的影响
需将计算机升级为CPU P3、内存256M,添加一台打印机。
4.4.2对现有软件的影响
需要将Windows升级为2000以上。
4.4.3对系统运行的影响
(1)用户的操作严格按照系统要求规程。
(2)要求创建系统管理员与普通用户两种登录方式,分权限管理。
(3)数据应有系统管理员手动输入系统,普通用户无权输入数据。
(4)对数据有保存要求,并且对数据存储,恢复的处理。
(5)输出报告以报表的形式打印出来。
(6)系统具有恢复和备份的功能。
4.4.4对开发环境的影响
1、为了建立数据库,要求提供详细的数据资源。
2、为了开发和测验所建议系统而需要的计算机资源:CPU P3、内存256M。
3、如数据涉及保密与安全问题,应由专人负责录入。
4.4.5对经费支出的影响
所建议系统的开发、设计经费开支:5000元。
维持运行而需要的经费开支:1000元。
4.5技术可行性评价
a. 在限制条件下,完成功能目标的实现;
b. 利用现有技术,功能目标一定能达到;
c. 对开发人员数量为5个人,每个人应对数据库知识有明确的了解,我们的组员都具有这种能力,一定按期完成工作;
d. 在规定的期限内,开发顺利完成。
5.所建议系统经济可行性分析
5.1支出
5.1.1基建投资
1、房屋和设施:500元。
2、ADP设备:1000元。
3、数据通讯设备500元。
4、环境保护设备200元。
5.1.2经常性支出
1、设备的租金和维护费用:500元。
2、数据的通讯方面的租金和维护费用500元。
3、人员的工资和奖金开支:3000元。
4、其他经常性的开支:2000元。
5.2收益/投资比
收益/投资比为3:1.
5.3投资回收周期
投资回收周期为半年.
5.4敏感性分析
1、应尽量延长系统生存周期,可延长至3年。
2、应是有效数据全部录入系统,使系统工作负荷量达到饱和。
3、应尽量提高系统的处理速度。
4、应提高设备和软件的配置。
6.社会因素可行性分析
6.1法律因素
如果发现有侵权行为,必进行严格的处罚,本公司版权所有,未经作者的允许,禁止非法传播、复制,违者追究法律责任,后果自负。
6.2用户使用可行性
本系统使用比较简单,适合普通用户操作,只要用户对说明书进行认真阅读,都可了解。
7.其他可供选择的方案
方案有许多但本公司选择了这套方案,他具有自己的优越感,运用编制菜单栏来省去代码,这是界面有好起来,又降低了工作难度,进而宏的运用更简化了工作难度。除提供的建议方案的具体功能外,还需增加网络功能,未被推荐的理由是目前尚不具备开发条件,投入与效益不成比例。
8.结论意见
结论意见可能是:
a. 可着手组织开发;
b. 需待若干条件(如资金、人力、设备等)具备后才能开发;
c. 需对开发目标进行某些修改;
d. 不能进行或不必进行(如技术不成熟,经济上不合算等);
e. 其他。
三 软件项目计划
1. 引言
1.1 编写目的
软件项目开发是一项系统而复杂的工作,它需要一个团队互相配合、分工协作。软件项目管理系统可以规范一个软件开发团队的日常工作,提高工作效率。
为了很好的管理整个开发过程,同时预算整个开发过程的费用及时间的安排,给开发人员,管理人员一个参照物,明白自己在每一个阶段所需要完成的任务,协助他们更好地完成开发工作。
预期的读者:开发人员,项目经理,测试人员
1.2 背景
a.学生信息管理系统
b.提出者:项目经理,开发者:XXX开发团队。
1.3 定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1.4 参考资料
[1] 周佩德.《数据库原理及应用》.电子工业出版社
[2] 刘炳文等,VISUAL BASIC程序设计——数据库篇,1999
[3] 李光明.《Visual Basic编程实例大制作》.冶金工业出版社
[4] 李红等编著,管理信息系统开发与应用,电子工业出版社,2003
[5] 软件工程,人民邮电出版社,2002年3月第一版
[6] 康博工作室,张红军,王红等缟著《Visual Basic中文版高级应用与开发指南》,人民邮电出版社,2001年4月第一版
[7] 林立军,程斌,翁迪恩缟著《Visual Basic 数据库开发指南》,西安电子科技大学出版社,2000年2月第一版
[8] 宋伟,吴建国等编著《中文Visual Basic编程基础》,北京,清华大学出版社
2. 项目概述
2.1 工作内容
1 需求分析: 1~3个月
2 概要设计: 2~3个月
3 详细设计: 2~3个月
4 编码: 2~3个月
5 测试: 1个月
6 发布: 1个月
2.2 主要参加人员
参与者
个人情况
XX
软件工程专业学生,熟悉java语言,数据库编程
XX
软件工程专业学生,熟悉C#语言
XX
软件工程专业学生,有很好的网页设计能力
XX
软件工程专业学生,有良好的界面设计的能力和测试经验
XX
专业为软件工程,从事开发工作一年,能过独立地完成小型项目的整个开发过程
2.3 产品
2.3.1 程序
名称
编程语言
媒体形式
功能及能力
系统功能
C#+SQL Server 2000
文本
管理学生的学籍信息,统计学生的相关信息。学生信息的增加、修改、删除、查询
数据信息管理
C#+SQL Server 2000
文本
学生学籍信息管理,学生选课信息管理
基本业务
C#+SQL Server 2000
文本
学生注册、学籍信息维护,学生选课,老师管理班级信息。
信息浏览与查询
C#+SQL Server 2000
文本
管理员学生学籍信息浏览、查询
数据库
SQL Server 2000
数据库文件
数据库文件可以直接附加到本地的SQL Server 2000中的数据库中
学生学籍管理系统
C#+SQL Server 2000
CD光盘
程序的运行文件,运行之后只要发布之后就可以了
2.3.2.文件
需求说明书,安装指南,用户操作手册,预计可能出现故障及解决办法
2.3.3.服务
培训安装:系统测试完毕之后,2012年10月10日至12日两天的安装和使用的培训时间,主要是让用户适应本系统的运行环境与操作习惯
维护:系统出现故障时,用户可参照手册进行自行解决,如果解决不了,则派维护人员过去,系统的维护期2012年10月14日到2013年10月15日,超过期限将不再派人去维修
2.3.4.非移交的产品
整个系统全部的的代码不必要给用户,所使用的技术及参考的文献也可以自己保留,以及该软件所使用的技术文档,这些都是不用给用户的
2.4 验收标准
验收标准参照表:
程序
CD光盘
实现功能:在使用时,由管理员输入需要了解的关键字信息,然后通饭卡管理系统选择相应的管理事务。管理事务根据所提供的信息在数据库中查找相应的记录,返回相应的记录给管理员。允许管理员在相应的权限下对数据进行修改。通过终端把得到的内容显示到相应的界面上。
安装指南
视频
有声的视频,分解安装的动作,并详细讲述过程及注意事项
用户使用手册
视频+文档
文档给出输入输出的约束条件,系统的运行环境,视频显示使用软件的整个流程,帮助用户学习使用该软件
故障解决说明书
文档
列出基本问题的详细解决办法,详细叙述整个流程
2.5 [完成项目的最迟期限]
按计划,本项目最迟将于2013年10月提交给用户可运行程序。在此前提下,开发人员保留对开发时间进度进行局部调整的权利
2.6 [本计划的批准者和批准日期]
参与审批人:XXX大学信息中心负责人:XX
项目开发经理:XX
技术审核专家:XX
时间:2013年12月10日
批准原因:根据计划,大家一致认为该计划是可行的,时间安排充裕,技术人员能够满足要求,各项事情的安排顺序合理
3. 实施计划
3.1 工作任务的分解与人员分工
1需求分析
负责人: 汪国志
参与人:汪国志
2 概要设计
负责人:汪国志
参与人:汪国志
3 实现
负责人:汪国志
参与人:汪国志,XXX,XXX,XXX,XXX,XXX
4 测试
负责人:汪国志
参与人:汪国志
5 维护及用户培训
负责人:汪国志
参与人:汪国志
3.2 接口人员
负责人:汪国志
参与人:汪国志
职责:统一接口,使不同层之间能通信
3.3 进度
1 需求分析
开始时间:2012-10-01
完成时间:2012-12-30
所需资源:客户的需求
完成标志:完成需求分析说明书
2 设计
开始时间: 2013-01-01
结束时间: 2013-03-01
所需资源: 需求分析说明书
完成标志: 概要设计说明书
3 编码实现
开始时间: 2013-03-01
结束时间: 2013-06-01
所需资源: 概要设计说明书,设配
完成标志: 系统能顺利运行
4 测试
开始时间: 2013-06-01
结束时间: 2013-08-01
所需资源: 能顺利运行的系统
完成标志: 修复现存的bug
5 移交
开始时间: 2013-08-01
结束时间: 2013-10-01
所需资源: beta版系统
6 培训
开始时间: 2013-10-01
3.4 预算
1.采购必要设备的投资:
网络平台的建设,包括了建设方式和联网建筑物数等等方面去计算,这一块需要200万左右;
服务器与存储系统,从发卡量和设备数量等估算,这一块需要100万左右;
射频卡终端,包括读写器与POS机,这一块需要20万左右。
2.开发系统的投资:
按目前市场上一卡通管理系统的开发价格来看,开发所需的投大概在50万不等;
4.总计::350万左右;
3.5 关键问题
本系统的操作过程简单,实现技术要求也不高,所以没有要特别列出的关键问题
4.支持条件
4.1 运行环境
a. 开发软件运行的最短寿命为一年。
b. 进行系统方案选择比较的期限:2周。
c. 经费来源和使用限制:自筹资金。
d. 法律和政策方面的限制:本软件公司版权所有,未经作者允许,非法传播、复制,违者追究法律责任,后果自负。
e. 硬件CPU p3、内存256M.。
f. 软件:access2003。
g. 运行环境:本软件应使用Windows2003、Windows xp操作系统。
h. 开发环境:本软件应使用Windows2003、Windows xp开发。
4.2 需由用户承担的工作
数据库的初始化需要用户自己录入,这个应该在测试之前完成,所以编码之前,由开发人员做好数据库,然后由用户安排人录入初始数据库,且必须在2013年6月1日之前完成。
4.3 需由外单位提供的条件
本项目希望得到委托商的资金支持,人员支持,如取需求时,能够提供部分食堂为我们的测试的提供支持环境,还有技术支持
5.专题计划要点
专题计划表:
专题计划
要点
合同计划
在分析阶段拟定合同书,分析阶段一结束就签订合同,合同包括需求的定义,如出现任何问题,可以根据合同调解,以及费用的支付,在每个阶段结束之后,委托方需支付开发方多少现金
测试计划
包括单元测试,集成测试,系统测试计划,主要参照开发文档,拟定计划,具体到输入的格式,响应的时间,需求的确认
四 风险条目跟踪表
序列号
1
确定日期
2012.10.28
撤消日期
<撤消风险确定日期>
描述
未得到学校支持而导致的无法获得学生数据
可能性
0.2
影响
10
危害值
10.2
降低风险计划
项目开始前与校方沟通,否则项目无法进行
负责人
XXX
截止日期
2013、10、1
五 进度计划风险列表
1.最常见的进度计划风险
1) 功能无限蔓延;
2) 质量不定
3) 计划过于乐观
4) 设计欠佳
5) 银弹综合症
6) 研发导向开发
7) 人员薄弱
8) 签约商失败;
10)研发人员与客户的磨擦。
2.进度计划风险完整列表
2.1 计划编制风险
1) 计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致;
2) 计划是优化的,是“最佳状态”;
3) 计划忽略了必要的任务;
4) 计划基于使用特定的小组成员,而那个小组成员其实指望不上。
5) 在限定的时间内无法建成已定规模大小的产品;
6) 产品规模比估计的要大一些;
7) 工作量大于估算数;
8) 进度已经拖延的项目在重新评估时过于优化或忽视项目历史;
9) 过度的进度压力造成生产率下降;
10)目标日期提前,但没有相应地调整产品范围或可用资源;
11)一个任务的延迟导致相关任务的连锁反应;
12)涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多。
2.2 组织和管理
1) 项目缺乏一个有凝聚力的最高领导人;
2) 由于前期乏力,项目长时间被搁置;
3) 解雇和削减开支导致项目小组能力下降;
4) 仅由管理层或市场人员进行技术决策,导致计划进度延长;
5) 低效的项目组结构降低生产率;
6) 管理层审查/决策的周期比预期时间长;
7) 预算削减打乱项目计划;
8) 管理层做出了打击项目组织积极性的决定;
9) 非技术的第三方的工作比预期延长(如审批,采购等);
10)计划性太差,无法适应期望的开发速度;
11)项目计划由于压力而放弃,导致开发混乱、低效;
12)管理层强调英雄主义,而忽视客观确切的状态报告,这会降低发现和改正问题的能力。
2.3 开发环境
1) 设施没有及时到位;
2) 设施到位,但不配套;
3) 设施拥挤、杂乱或者破损;
4) 开发工具未能及时到位;
5) 开发工具不如期望那样有效,开发人员需要时间创建工作环境或切换新的工具;
6) 开发工具的选择不是基于技术需求,不能提供计划要求的性能;
7) 新开发工具的学习期比预期的长,内容繁多。
2.4 最终用户
1) 最终用户坚持新的需求;
2) 最终用户对于最后交付的产品不满意,要求重新设计和重做;
3) 最终用户不买进项目产品,无法提供后续支持;
4) 最终用户的意见未被采纳,造成产品最终无法满足用户期望,而必须重做。
2.5 客户
1) 客户坚持新的需求;
2) 客户对规划、原型和规格的审核/决策周期比预期长;
3) 客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和耗时的重复;
4) 客户答复的时间比预期长(如回答需求中需澄清的问题);
5) 客户坚持技术决策而导致进度计划延长;
6) 客户对开发进度管理过细,导致实际进展变慢;
7) 客户提供的组件无法与开发的产品匹配,导致额外的设计和集成工作;
8) 客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作;
9) 客户要求的支持工具和环境不兼容、性能差或者功能不完善,导致生产率降低;
10)客户不接受交付的软件,尽管它满足了所有的规格;
11)客户期望的开发速度是开发人员无法达到的。
2.6 承包商
1) 承包商没有按承诺交付组件;
2) 承包商递交的组件质量低下无法接收,必须花时间改进质量;
3) 承包商没有买进项目开发需要的工具,进而无法提供需要的性能水平。
2.7 需求
1) 需求已经成为项目基准,但变化还在继续;
2) 需求定义欠佳,而进一步的定义会扩展项目范畴;
3) 添加额外的需求;
4) 产品定义含混的部分比预期需要更多的时间。
2.8 产品
1) 错误发生率高的模块需要比预期更多的测试、设计和实现工作;
2) 校正质量低下不可接受的产品,需要比预期更多的测试、设计和实现工作。
3) 在一个或多上新兴领域推广计算机技术使得计划进度的延长不可预期;
4) 由于软件功能的错误,需要重新设计和实现;
5) 开发额外不需要的功能(镀金)延长了计划进度;
6) 要满足产品规格与速度要求,需比预期更多时间,包括重新设计和实现的时间;
7) 严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;
8) 要求与其他系统、复杂系统或不受本项目控制的系统相连,导致无法预料的设计、实现和测试工作。
9) 要求在不同操作系统下运行将花费比预期更长的时间;
10)在不熟悉或未经检验的软(硬)件环境中运行产生未预料的问题;
11)开发一种对组织全新的模块将比预期花费更长的时间;
12)依赖正在开发中的技术将延长计划进度。
2.9 外部环境
1) 产品依赖政府规章,而规章的改变将是不可预期的;
2) 产品依赖草拟中的技术标准,而最后的标准将是不可预期的。
2.10 人员
1) 招聘人员所花时间比预期的长;
2) 作为先决条件的任务不能按时完成(如培训、其它项目);
3) 开发人员和管理层之间关系不佳导致决策缓慢,影响全局;
4) 项目组成员没有全身心投入项目,进而无法达到需要的产品性能水平;
5) 缺乏激励措施,士气低下,降低了生产能力;
6) 缺乏必要的规范,增加了工作失误与重复工作;
7) 某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言;
8) 项目结束前,合同制人员离开团队,或雇员辞职;
9) 项目后期加入新
展开阅读全文