软件项目管理大作业文档格式.docx
- 文档编号:14630291
- 上传时间:2022-10-23
- 格式:DOCX
- 页数:7
- 大小:73.31KB
软件项目管理大作业文档格式.docx
《软件项目管理大作业文档格式.docx》由会员分享,可在线阅读,更多相关《软件项目管理大作业文档格式.docx(7页珍藏版)》请在冰豆网上搜索。
元)
管理和质量成本:
800,000×
20%=160,000
总成本:
800,000+160,000=960,000
四、项目进度安排
预计项目将在前3个月完成需求分析、总体框架设计及系统设计,前6个月完成软件代码编写并开始测试环节,利用最后4个月试运行完成软件各种功能、性能及安全性测试,争取10个月后项目完成验收。
需求分析
功能需求:
本系统是B/S结构的Web应用系统。
二、为用户实现自助转帐、自助缴费和网上支付的功能,方便用户。
根据实际案例和自己的能力,我们将系统划分为八个功能模块:
账户管理模块、自助转帐模块、自助缴费模块、网上支付模块、贷款管理模块、客户服务模块、登陆模块、后台管理模块。
系统用户用例图如下图所示:
外部接口需求:
界面设计为适合最小分辨率为800*600,同时要适合1024*768、1280*800等使用15寸以上显示器用户,因此,界面要在浏览器上居中显示。
性能需求:
人们都不希望一个交易提交后花费太多的等待时间,所以此系统对时间要求比较高,
在服务器上测试,响应时间不能超过1/10s。
同时对于在不同的平台上兼容性要求较高,故本系统采用JSP作为实现语言,JAVA很好的移植性与平台无关性可以保证系统在其他软件或硬件平台上无障碍运行。
软件属性需求:
1.正确性:
系统要正确处理用户请求,并正确返回结果
2.可靠性:
系统安全无故障运行直到下一次系统检查
3.安全性:
系统需要有良好的安全性,如防止被窃取密码造成经济损失
软件人员分工:
1、前期由5个员工去做调研完成需求分析,同时5个员工完成风险控制管理,另外5个员工完成概要设计详细设计,最后5个人把握项目规模成本项目总体方向及定位。
2、中期可以有4个员工来完成界面设计,4个员工来完成数据库设计,12个员工来完成代码编写和文档说明。
3、后期可以由10个员工左右来完成程序功能、性能及安全性测试,另外10个员工完成项目文档及项目验收。
当然对于一个大项目来说,一定要实验对风险控制和质量保证。
风险管理
产生阶段
任务
可能风险描述
可能产生原因
风险发生的后果
避免措施
发生后的处理
筹备
开发环境的配置
配置环境不符合项目组要求的标准
对开发环境不熟悉
可能造成项目集成时bug增多
抽出专门人员对环境统一配置
把程序放进标准环境调试
学习熟悉开发环境
学习不够深入导致开发时对开发环境不熟悉,延迟项目进度
项目组没有认真学习开发环境
延迟项目开发进度
筹备阶段应该加强相关项目开发基础知识的学习
对不熟悉开发环境的成员抽专人对其培训
分析
模块划分
模块划分不够准确,对项目功能需求分析不明确
对网银系统业务了解不够
造成项目延期甚至无法进行开发
对需求深入了解,准确划分功能模块
不惜时间反复多次对模块划分
编写需求分析文档
文档对需求说明不够明确细致
对项目业务了解不深入
导致后面的概要设计详细设计等无法明确进行实施
加强对需求的理解
继续对需求进行分析直至需求完善
设计
概要设计
模块功能概要不明确
需求做的不够,业务不了解
导致详细设计不能进行,项目无法开发
做好需求,了解业务逻辑
深入调查了解网银业务需求与逻辑
界面设计
界面不够友好,可操作行不够好
对网银业务流程不了解,对网页设计知识不熟练
导致项目后期编码困难,项目成形后对用户可操作行困难
了解网银业务流程,加强对静态网页设计技术的学习
修改界面
详细设计
对系统各个模块内部数据流与程序逻辑设计不够完善
对网银业务的内部数据流理解不够,对JSP,Servlet等相关知识不熟悉
导致项目编码阶段的程序设计调试程序困难甚至无法进行
做好详细设计,规划好数据流和程序逻辑
及时更改程序逻辑,修订详细设计
数据库设计
数据库不够完善,存放数据的表划分不合设计要求
对系统的用户、业务、操作等相关数据规划混乱
导致系统内部数据混乱,不便管理,甚至造成数据的不一致,丢失等严重错误
对数据库进行反复思索,反复设计,反复验证直至符合业务逻辑,达到数据便于管理
对数据库重新建设,回头对数据再分析再规划
开发
编码
程序无法调试通过
对相关技术JSP,Servlet等不熟练,造成编码困难,程序无法调试运行
无法实现此模块功能
加强对J2EE规范的网站设计技术和知识的学习
反复调试程序
单元测试
测试用例无法通过
编码时程序对功能的实现不够完善
测试失败,重新调试程序
编码时对各种存在情况,如边界值,错误的操作等综合考虑
调试程序
测试
系统测试
系统安全性,稳定性不够
开发阶段没有对各功能做到完善,系统运行环境达不到要求
系统崩溃,无法运行
开发阶段尽量做到各功能的测试完善
回头对各模块功能进行测试调试,对系统运行环境搭建好
质量保证计划:
本计划的目的在于对所开发的网上银行系统软件规定各种必要的质量保证措施,以保证所交付的软件能够满足项目需求分析中的各项需求。
软件开发单位在开发该银行软件系统所属的各个子系统时,都应该执行本计划中的有关规定,但可根据各自的情况对本计划作适当的剪裁,以满足特定的质量保证要求。
在本软件系统整个开发期间,必须成立软件质量保证小组负责质量保证工作,该组成立时指定小组成员负责。
在项目的软件质量保证小组中,应合理分配任务,明确职责。
职责分配在进展中可以互相沟通、合理安排。
软件质量保证工作涉及软件生存周期各阶段的活动,应该贯彻到日常的软件开发活动中,而且应该特别注意软件质量的早期评审工作。
软件质量保证小组要派成员参加所有的评审与检查活动。
评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。
在软件开发过程中,要进行如下几类评审与检查工作:
a.阶段评审:
在软件开发过程中,要定期地或阶段性地对某一开发阶段或某几个开发阶段的阶段产品进行评审。
b.日常检查:
在软件的工程化生产过程中,各成员应该填写项目进展报表
c.软件验收:
必须组织专门的小组成员对银行软件系统进行验收。
验收内容应包括文档验收、程序验收、演示、验收测试与测试结果评审等几项工作。
对文档要求:
为了确保软件的实现满足需求分析的各项需求,小组应编写以下文档:
a.软件需求规格说明书b.软件设计说明书c.软件测试计划
d.软件测试报告e.项目进度计划f.项目开发总结。
除了基本文档之外,对于尚在开发中的软件,还应该包括以下四个方面的文档:
a.软件质量保证计划;
b.风险管理计划
c.项目进展报表;
d.会议纪录。
文档质量的度量准则
a.完备性:
所有承担软件开发任务的单位,都必须按照规定编制相应的文档,以保证在开发阶段结束时其文档是齐全的。
b.正确性:
在软件开发各个阶段所编写的文档的内容,必须真实地反映该阶段的工作且与该阶段的需求相一致。
c.简明性:
在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简练,适合各种文档的特定读者。
d.可追踪性:
在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。
文档的可追踪性包括纵向可追踪性与横向可追踪性两个方面。
前者是指在不同文档的相关内容之间相互检索的难易程度;
后者是指确定同一文档某一内容在本文档中的涉及范围的难易程度。
e.自说明性:
在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。
文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。
f.规范性:
在软件开发各个阶段所编写的各种文档应该具有良好的规范性。
文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。
项目验收总结
在验收时,同时也要对文档提出严格的要求,非软件人员能直接使用该系统,若不了解,可在用户使用说明文档帮助下简单使用,软件人员在文档帮助下能清晰阅读代码和测试。
在经历大量的测试及试运行的阶段确保完成了用户需求的所有功能,确保性能足够优化,确保运行足够安全的情况下完成软件验收,系统成功上线投入使用。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 管理 作业