软件项目计划书1.docx
- 文档编号:7240482
- 上传时间:2023-01-22
- 格式:DOCX
- 页数:17
- 大小:305.31KB
软件项目计划书1.docx
《软件项目计划书1.docx》由会员分享,可在线阅读,更多相关《软件项目计划书1.docx(17页珍藏版)》请在冰豆网上搜索。
软件项目计划书1
虚拟星空
软件项目计划书
审核:
批准:
第一章项目概述
1.1目的
可以用作学习夜空知识的教具,还可以作为天文爱好者星空观测的辅助工具,或者仅仅是满足一下好奇心。
1.2项目背景
随着人们生活水平的提高,人们对自然的渴望越来越浓烈,其中“追星族”人数的增多就体现了这一点。
更多的人希望能象以前一样仰望星空,辨识星座。
不过在大城市,强烈的光污染与较差的空气质量限制了人们在户外观星的条件。
本软件就为人们提供了一片数字化的星空,让用户足不出户,在个人电脑上便可以了解天文,爱上天文。
1.3主要功能
(1)概述:
根据观测者所处的时间和地点,计算天空中太阳、月球、行星和恒星的位置,并将其显示出来。
它还可以绘制星座、虚拟天文现象(如流星雨、日食和月食等)
(2)功能描述:
扩展目录包含超过2.1亿颗恒星
星宿和星座的绘画
星云图像
逼真的銀河
非常真实的大气和光线效果
八大行星及其恒星
强大的缩放功能
自由控制时间流动
多语言界面
望远镜控制功能
赤道/地平坐标网格
星体闪烁
流星
超新星模拟
第二章项目估算
2.1使用的历史数据
天文一般数据
1天文单位1.4960*10^m
1光年9.4605*10^15m=6.324*10^4天文单位
1秒差距3.0857*10^16m=206265天文单位=3.262光年
黄赤交角(2000年)23°26'21.448"
1恒星日0.99726957平太阳日=23时56分01.0905秒(平太阳时)
1平太阳日1.00273791恒星日=24时03分56.5554秒(恒星时)
1朔望月29.530589平太阳时=29日12时44分11.4秒(平太阳时)
1回归年365.24220平太阳日
1恒星年365.25636平太阳日
1儒略年365.25平太阳时=8766时=525960分=31557600秒
1格里年365.2425平太阳日=365日5时49分12秒
1太阴年12朔望月=354.36平太阳日
历书时1秒1900年1月0日历书时12时瞬刻回归年长度的1/31556925.9747
原子时1秒绝原子跃迁频率9192631770周所经历的时间
太阳数据
太阳视差8.794"
日地平均距离1天文单位=1.4960*10^11m
日地最近距离1.4710*10^11m
日地最远距离1.5210*10^11m
太阳直径1392530千米
太阳表面积6.087*10^12平方千米
太阳体积1.412*10^18立方千米
太阳质量1.989*10^33g
太阳平均密度1.41g/cm^3
太阳常数平均值1.37千瓦/平方米
太阳表面有效温度5770K
太阳中心温度1.5*10^7K
太阳年龄~5*10^9年
太阳活动周期的平均长度11.04年
2.2使用的评估技术
1、数学方法:
线性加权和函数法、乘数合成法、加乘混合合成法、代换法。
2、多元统计方法:
主要有主成分分析法(principalcomponentanalysis)、因子分析法(factoranalysis)、判别分析、聚类分析、距离综合评价方法、数据包络分析方法。
3、模糊综合评价方法:
模糊聚类分析、模糊综合评判法。
4、灰色聚类评价方法:
灰色关联度、灰色关联度聚类、灰色变权聚类、灰色定权聚类、多层次灰色评价、灰色最优聚类分析。
2.3工作量,成本,时间的估算
工作量:
规划天文数据库数据。
较多
成本:
2000元
时间:
45天
第三章风险评估
3.1风险识别
(1)打开软件时间过长
(2)退出时延迟
(3)具体信息显示失误
(4)长时间不操作容易卡机
(5)定位信息不准确
(6)天体运行速度快,捕捉不到
(7)汉化失败
(8)在使用过程中,自动最小化。
(9)在使用过程中,因操作失误有可能会出现按键无功能或出错现象
(10)开发人员的技术层次不同
3.2风险对应策略
用多种方法进行测试,反复测试。
让开发人员大致处于同一层次。
第四章项目进度计划
项目任务分解:
可行性研究报告:
1.要求
主要功能:
为用户提供天体观测服务,方便天文爱好者的观测。
性能要求:
天文数据库提供的信息必须及时的反映在用户的工作平台上。
输出要求:
数据完整,详实,简捷,快速,实时。
完成期限:
预计几个月。
2目标
为用户提供一个天文观测平台,降低天文观测的费用,使用户可以便捷的观看天体。
3条件,假定和限制
建议软件寿命:
2年
经费来源:
无
硬件条件:
服务器,终端为pc机。
运行环境:
Linux/Unix、Windows95/98/2000/NT/XP/7、MacOSX10.3或更高。
4决定可行性的主要因素
技术可行,现有技术可完全承担开发任务。
操作可行,软件能被用户快速接受。
5技术可行性分析
系统实现后,它可以根据观测者所处的时间和地点,计算天空中太阳、月球、行星和恒星的位置,并将其显示出来。
它还可以绘制星座、虚拟天文现象(如流星雨、日食和月食等)。
可以用作学习夜空知识的教具,还可以作为天文爱好者星空观测的辅助工具,或者仅仅是满足一下好奇心。
6经济可行性分析
支出:
--
效益:
--
收益/投资比:
--
投资回收周期:
--
7用户使用可行性
用户只需要少量的计算机基础就可以操作。
8结论意见
技术、经济、操作都有可行性,可以进行开发。
需求分析:
需求分析是整个设计中重要的一环,当可行性分析完成,项目立项,确定开发角色后,有关的设计开发人员与相关业务人员共同对业务流程、管理方式进行分析,并进行资料的收集、整理。
在完成了对有关数据信息的收集、归纳和分析整理后,确定了用户需求,对软件必须完成的功能进行了定义,在此基础上完成了数据定义,建立了数据字典。
步骤:
⑴首先调查组织机构情况
包括了解该组织的部门组成情况,各部门的职能等,为分析信息流程作准备。
⑵然后调查各部门的业务活动情况
包括了解各个部门输入和使用什么数据,如何加工处理这些数据,输出什么信息,输出到什么部门,输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求
包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界
确定哪些功能由计算机完成或将来准备让计算机完成,哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
⑸分析系统功能
⑹分析系统数据
⑺编写分析报告
常用类型:
⑴跟班作业
通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求,但比较耗费时间。
⑵开调查会
通过与用户座谈来了解业务活动情况及用户需求。
座谈时,参加者之间可以相互启发。
⑶请专人介绍。
⑷询问
对某些调查中的问题,可以找专人询问。
⑸设计调查表请用户填写
如果调查表设计得合理,这种方法是很有效,也很易于为用户接受的。
⑹查阅记录
即查阅与原系统有关的数据记录,包括原始单据、账簿、报表等。
通过调查了解了用户需求后,还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
数据库设计:
概念设计:
对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等),通过对其中诸处的分类、聚集和概括,建立抽象的概念数据模型。
这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。
所建立的模型应避开数据库在计算机上的具体实现细节,用一种抽象的形式表示出来。
以扩充的实体—(E-R模型)联系模型方法为例,第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等,从而给出各部门内所用信息的局部描述(在数据库中称为用户的局部视图)。
第二步再将前面得到的多个用户的局部视图集成为一个全局视图,即用户要描述的现实世界的概念数据模型。
逻辑设计:
主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式,即适应于某种特定数据库管理系统所支持的逻辑数据模式。
与此同时,可能还需为各种数据处理应用领域产生相应的逻辑子模式。
这一步设计的结果就是所谓“逻辑数据库”。
物理设计
根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施,对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。
这一步设计的结果就是所谓“物理数据库”。
在上述设计的基础上,收集数据并具体建立一个数据库,运行一些典型的应用任务来验证数据库设计的正确性和合理性。
一般,一个大型数据库的设计过程往往需要经过多次循环反复。
当设计的某步发现问题时,可能就需要返回到前面去进行修改。
因此,在做上述数据库设计时就应考虑到今后修改设计的可能性和方便性。
运行与维护设计
在数据库系统正式投入运行的过程中,必须不断地对其进行调整与修改。
至今,数据库设计的很多工作仍需要人工来做,除了关系型数据库已有一套较完整的数据范式理论可用来部分地指导数据库设计之外,尚缺乏一套完善的数据库设计理论、方法和工具,以实现数据库设计的自动化或交互式的半自动化设计。
所以数据库设计今后的研究发展方向是研究数据库设计理论,寻求能够更有效地表达语义关系的数据模型,为各阶段的设计提供自动或半自动的设计工具和集成化的开发环境,使数据库的设计更加工程化、更加规范化和更加方便易行,使得在数据库的设计中充分体现软件工程的先进思想和方法。
总体设计
界面设计:
软件启动封面设计
清晰直观的显示该软件的特点,插图以深蓝色为背景,地球简笔画相互配合,让人耳目一新。
上面有醒目的标注制作,产品商标,软件名称,版本号,网址,版权声明等信息。
方便使用者在软件启动的时候得到提示。
软件框架设计
这款软件的操作界面非常的清晰直观,首先以一个地球形状我为主体,并与太阳相结合,以及用蓝天做背景。
整个界面的右上角为观察框架,下方正是主要的浏览工具栏。
左上角则是所观察天体的详细信息。
清晰直观。
初学者也容易上手。
软件按钮设计
所有按钮均为单次点击,图标为正常鼠标模式,进行360度旋转的时候鼠标会变成小手模式。
此外所有的功能按钮均为形象化,让使用者能够轻易地选择出应用的功能。
按钮的反应速度也是非常的灵敏,缩放功能滑动滑轮即可。
操作简便。
菜单设计
为方便使用者,只需将鼠标移至屏幕最下方,菜单自动滑出。
安装过程设计
安装界面简洁易操作,安装过程中还能够了解的该软件的基本信息。
包装及商品化
打包信息完整,图标鲜明友好。
打包过程中产品的信息业都一并被打包进去。
网页设计:
确定网站主题
网站主题主要为该产品的相关介绍,特点鲜明,直观大方得体!
附加另外公司基本信息以便于更加了解软件。
搜集材料
从国家天文数据库中获取材料
制作网页
专门网络人员设计
上传测试
网页制作完毕,最后要发布到Web服务器上,才能够让全世界的朋友观看,现在上传的工具有很多,有些网页制作工具本身就带有FTP功能,利用这些FTP工具,你可以很方便地把网站发布到自己申请的主页存放服务器上。
网站上传以后,你要在浏览器中打开自己的网站,逐页逐个链接的进行测试,发现问题,及时修改,然后再上传测试。
维护更新
公司会不定期将软件优化与调试,尽量满足客户的需求。
相关美工设计:
运用美化工具,遵循独特性、易用性、规范性、合理性、美观与协调性、界面的简明的美化准则。
测试计划:
运用白盒测试的测试方法对软件经行测试,完善整个软件。
操作手册:
1、Stellarium
用户可以通过拖拽天空看到头顶上的星际。
默认是实时显示,所以波斯的截图就不是夜间版了,夜间版比较有说服力的说。
背景的图,就是下图可见的树木房屋之类都是可换的。
2、设置语言
1)、打开软件,点到“设定”(快捷键F2);
2)、看到“主设定画面”(Main),出现“程序介面语言”(Programlanguage);
3)、然后打开中间的语言选项,在末尾处就有,以及内地和香港的。
4)、最后别忘记点保存设置,不然下次会还原语言的。
3、星空及显示
1)、在软件左侧有各种选项栏,其中F4是在软件内显示的各种内容(其余的F1是说明;F2是设定;F3是搜索;F5是日期及时间;F6是所在地点)点开它,其中有4个大项,及“天空”“标示”“地景”“星空术语”、在“天空”中,你可以选择天体绝对.相对的大小;行星以及卫星还有大气层的显示;流星天顶的小时率(你所调整的数据越高,流星就出现得越多)。
2)、在“标示”中,可以选择天球的显示,各种坐标.网格(不调整各种网格的显示,画面会有干净,浩瀚的感觉,如果调整,有一种“天文范”,感觉标准,权威);可以选择各种星座的显示,名称,连线和亮度等(喜欢星座的人当然会选择);在下方还可以调整投影方式。
3)、在“地景”中,你可以据个人喜好,调整地景;还有,假设你想体验没有地面的全景星空,在右下方选项中调整。
你甚至可以自己制作地景,把自己观测地点的各项地标嵌入软件,方便根据地面各地标从空中寻星。
(右图即是用户根据自己的观测环境制作的地景。
N41°,E126°九月下旬日出)
4)、“星空术语”中,就是根据需要,调整各国各地区对星座,行星,卫星等命名,其中包括中国。
测试分析报告:
编写目的
编写该测试总结报告主要有以下几个目的
通过对测试结果的分析,得到对软件质量的评价
分析测试的过程,产品,资源,信息,为以后制定测试计划提供参考
评估测试测试执行和测试计划是否符合
分析系统存在的缺陷,为修复和预防bug提供建议
背景
在研究各种天文现象的前提下,更立体的感受天空的美感
用户群
有兴趣的天文爱好者
定义
严重bug:
出现以下缺陷,测试定义为严重bug
系统无响应,处于死机状态,需要其他人工修复系统才可复原。
点击某个菜单后出现“Thepagecannotbedisplayed”或者返回异常错误。
进行某个操作(增加、修改、删除等)后,出现“Thepagecannotbedisplayed”或者返回异常错误
当对必填字段进行校验时,未输入必输字段,出现“Thepagecannotbedisplayed”或者返回异常错误
系统定义不能重复的字段输入重复数据后,出现“Thepagecannotbedisplayed”或者返回异常错误
测试对象
虚拟天文馆
测试阶段
系统测试
测试工具
Bugzilla缺陷管理系统
参考资料
《虚拟天文馆需求和设计说明书》
《虚拟天文馆数据字典》
《虚拟天文馆后台管理系统测试计划》
《虚拟天文馆后台管理系统测试用例》
《虚拟天文馆项目计划》
测试概要
虚拟天文馆后台管理系统测试从2012年7月2日开始到2012年8月10日结束,共持续39天,测试功能点174个,执行2385个测试用例,平均每个功能点执行测试用例13.7个,测试共发现427个bug,其中严重级别的bug68个,无效bug44个,平均每个测试功能点2.2个bug。
虚拟天文馆总共发布11个测试版本,其中B1—B5为计划内迭代开发版本(针对项目计划的基线标识),B6-B8为回归测试版本。
计划内测试版本,B1—B4测试进度依照项目计划时间准时完成测试并提交报告,其中B4版本推迟一天发布版本,测试通过增加一个人日,准时完成测试。
B5版本推迟发布2天,测试增加2个人日,准时完成测试。
B6-B11为计划外回归测试版本,测试增加5个工作人日的资源,准时完成测试。
虚拟天文馆测试通过Bugzilla缺陷管理工具进行缺陷跟踪管理,B1—B4测试阶段都有详细的bug分析表和阶段测试报告。
测试执行
此次测试严格按照项目计划和测试计划执行,按时完成了测试计划规定的测试对象的测试。
针对测试计划规定的测试策略,在测试执行中都有体现,在测试执行过程中,依据测试计划和测试用例,对系统进行了完整的测试
测试用例
功能性
系统实现的主要功能,包括星空,地景,星空术语。
系统实现的次要功能,包括为用户查找星座,立体观看星空
需求规定的输入输出字段,以及需求规定的输入限制
易用性
操作按钮提示信息正确性,一致性,可理解性
限制条件提示信息正确性,一致性,可理解性
必填项标识
输入方式可理解性
中文界面下数据语言与界面语言的一致性
测试环境
硬件环境
应用服务器
数据库服务器
客户端
硬件配置
CPU:
Intel(R)Celeron(R)CPU2.40GHzstepping01
Memory:
1048256k
HD:
ST380817AS80GSATA
CPU:
Intel(R)Celeron(R)CPU2.40GHzstepping01
Memory:
1048256k
HD:
ST380817AS80GSATA
CPU:
Intel(R)Celeron(R)CPU2.40GHzstepping01
Memory:
1048256k
HD:
ST380817AS80GSATA
软件配置
OS:
CentOS4.2
JDK1.5.0_06
Apache2.2.0
Tomcat5.5.15
OS:
CentOS4.2
MySQL5.0.17Linux
Window2000Professional(SP2)IE6.0.2900.2180.xpsp_sp2
网络环境
10MLAN
10MLAN
10MLAN
测试结论
功能性
系统正确实现了通过数据字典管理基础数据的功能,实现了数据内容的多语言功能,实现了中英文界面。
实现了基础数据管理,酒店集团管理,酒店基础信息管理,渠道管理,代理管理,用户管理的查询,添加,修改,删除的功能,系统还实现了将权限控制细化到菜单按钮的功能。
系统在实现用户管理下的权限管理功能时,存在重大的缺陷,权限控制不严密,权限设计有遗漏。
易用性
现有系统实现了如下易用性:
输入限制的正确性
输入限制提示信息的正确性,可理解性,一致性
现有系统存在如下易用性缺陷:
界面排版不美观
输入,输出字段的可理解性差
输入缺少解释性说明
中英文对应的正确性
中英文混排
可靠性
现有系统的可靠性控制不够严密,很多控制是通过页面控制实现的,如果页面控制失效,可以向数据库插入数据,引发错误。
现有系统的容错性不高,如果系统出现错误,返回错误类型为找不到页面错误,无法回复到出错前的状态
兼容性
现有系统支持window下的IE浏览器和傲游浏览器,支持linux系统下的IE浏览器和火狐浏览器。
现有系统未进行其他兼容性测试
安全性
现有系统控制了以下安全性问题:
把某一个登录后的页面保存下来,不能单独对其进行操作不进行登录
直接输入某一页面的Url能否打开页面并进行操作不应该允许。
现有系统未控制以下安全性问题:
用户名和密码应对大小写敏感
登陆错误次数限制
分析摘要
覆盖率
此次测试,所有测试用例都是在中文界面下执行,未在英文界面下执行,测试不包括英文界面下的测试,也不包括正对英文翻译的测试。
此次测试,部分页面需求描述无明确的定义,对输入限制无详细定义,无明确的测试依据,在测试过程中,测试是根据输入字段含义,测试人员理解,以及和项目经理,开发人员沟通获得测试依据,无法保证测试依据的正确性和完整性,因此,没有进行完整的,正确的无效数据的测试,测试覆盖率不够,无法保证测试的有效性和正确性
下面为此次测试测试用例覆盖率分析图:
遗留缺陷的影响
1.缺陷描述:
星座物语添加页面,“距离”字段无单位,建议增加单位
缺陷影响:
距离字段无单位说明,无衡量标准,用户易用性不好
推迟原因:
需求定义无单位定义,统一在升级版本中解决
2.缺陷描述:
tomcat日志有乱码,日志无项目名称,查看不方便
缺陷影响:
其他项目日志都有项目名称,日志无项目名称,查看不方便
推迟原因:
目前的日志为了调试方便,显示了很多其它信息,在项目正式发布时会统一处理的。
建议
在项目开始的时候应该制定编码标准,数据库标准,需求变更标准,开发和测试人员都严格按照标准进行,可以在后期减少因为开发,测试不一致而导致的问题,同时也可以降低沟通成本。
发布版本的时候,正确布置测试环境,减少因为测试环境,测试数据库数据的问题而出现的无效bug。
开发人员解决bug的时候,填写bug原因以及解决方式,方便bug的跟踪。
开发人员在开发版本上发现bug,可以通知测试人员,因为开发人员发现的bug很有可能在测试版本上出现,而测试人员和开发人员的思路不同,有可能测试人员没有发现该bug,而且,这样可以保证发现的bug都能够被跟踪。
度量
测试时间
2012年7月2日至2012年8月6日共35天
测试人力
1人×7天+1人×35天=42人天
硬件资源
服务器:
PC2台
客户端:
PC2台
功能性错误
功能没有实现,导致无法进行需求规定的功能的测试。
主要是无法进入酒店
项目开发总结:
1引言
1.1编写目的
为了总结报告在工作过程中产生的问题、行到经验,并且总结报告设计和制作者过程中的逻辑和想法。
1.2背景
项目名称:
模拟天文馆
开发背景:
通过开发此软件的过程,提高用软件园工程序分析问题、解决问题的能力,增强对c#和数据库的使用能力,同时了解各种文档的标准编写方式。
1.3定义
系统:
模拟天文馆。
数据库:
存储数据。
1.4参考资料
《软件工程》(美)RogerS.Preassman著.机械工业出版社。
《VisualC#程序设计教程》曹青,邱李华,郭志强,机械工业出版社
《数据库系统概念》,AbrahamSilberschatzHenryF.Korth,S.sudarshan著
《软件项目管理》阳王东中国水利水电出版社连灿红高等教育出版社
《软件文件文档编写》辛明海潘孝铭五晋隆
2实际开发结果
2.1产品
产品名称:
模拟天文馆
产品功能:
能够查找星座
2.2主要功能和性能
详细参见《需求分析说明书》
2.3进度
按计划进行
2.4费用
无开发费用。
3开发工作评价
3.1对生产效率的评价
实际生产时间:
两周。
平均每使用小时数:
3个小时
3.2对产品质量的评价
产品质量较好,在测试过程中相对来说稳定但是由于数据问题,信息量不在,不适合大规模普及。
3.3对技术方法的评价
在开发过程中风们严格按照开发阶段行事,掌握了整个开发流程,但是由于而死组员技术问题和时间问题峭得不选用功能相对来说简单但是纺定也不简单易懂的c#程序,编写方法结合了软件工程序的要求。
3.4出错原因的分析
1、对于程序员设计师不够科学,对于设计师语言的掌握不够了解。
2、由于没有大量的时间来制作,选用了易学易懂的c#语言。
3、小组人员沟通时间不足。
私人时间协调困难,造成了很大的开发困难。
4经验与教训
经过这段时间开发过程风们了解了软件工程序的具体涵义,熟悉了开发流程,也撑握了软件文档的编写标准,学到了很多以前没有了解到的知识,但是由于设计时间估计,等等,没有很好的分安排好组员的工作,因为大量的时间都用作学习,所以留给软件开发的时间相对较少一些,造成的结果是,开发的过程不是均匀,但是经过
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 计划书