集装箱优化设计的质量策划书.docx

上传人:b****8 文档编号:9871434 上传时间:2023-02-07 格式:DOCX 页数:21 大小:57.69KB
下载 相关 举报
集装箱优化设计的质量策划书.docx_第1页
第1页 / 共21页
集装箱优化设计的质量策划书.docx_第2页
第2页 / 共21页
集装箱优化设计的质量策划书.docx_第3页
第3页 / 共21页
集装箱优化设计的质量策划书.docx_第4页
第4页 / 共21页
集装箱优化设计的质量策划书.docx_第5页
第5页 / 共21页
点击查看更多>>
下载资源
资源描述

集装箱优化设计的质量策划书.docx

《集装箱优化设计的质量策划书.docx》由会员分享,可在线阅读,更多相关《集装箱优化设计的质量策划书.docx(21页珍藏版)》请在冰豆网上搜索。

集装箱优化设计的质量策划书.docx

集装箱优化设计的质量策划书

武汉工程大学

计算机科学与工程学院

课题设计报告

设计名称:

集装箱优化设计的质量策划书

学生学号:

     

专业班级:

      

学生姓名:

   

学生成绩:

指导教师(职称):

王庆春

课题工作时间:

2011-10-23至2011-11-07

说明:

1、报告中的第一、二、三项由指导教师在综合设计开始前填写并发给每个学生;四、五两项(中英文摘要)由学生在完成综合设计后填写。

2、学生成绩由指导教师根据学生的设计情况给出各项分值及总评成绩。

3、指导教师评语一栏由指导教师就学生在整个设计期间的平时表现、设计完成情况、报告的质量及答辩情况,给出客观、全面的评价。

4、所有学生必须参加综合设计的答辩环节,凡不参加答辩者,其成绩一律按不及格处理。

答辩小组成员应由2人及以上教师组成。

5、报告正文字数一般应不少于5000字,也可由指导教师根据本门综合设计的情况另行规定。

6、平时表现成绩低于6分的学生,取消答辩资格,其本项综合设计成绩按不及格处理。

7、此表格式为武汉工程大学计算机科学与工程学院提供的基本格式(适用于学院各类综合设计),各教研室可根据本门综合设计的特点及内容做适当的调整,并上报学院批准。

成绩评定表

学生姓名:

学号:

班级:

类别

合计

分值

各项分值

评分标准

实际得分

合计得分

备注

平时表现

10

10

按时参加综合设计,无旷课、迟到、早退、违反实验室纪律等情况。

由设计负责人给出

完成情况

30

20

按设计任务书的要求完成了全部任务,能完整演示其设计内容,符合要求。

10

能对其设计内容进行详细、完整的介绍,并能就指导教师提出的问题进行正确的回答。

报告质量

35

10

报告文字通顺,内容翔实,论述充分、完整,立论正确,结构严谨合理;报告字数符合相关要求,工整规范,整齐划一。

5

课题背景介绍清楚,综述分析充分。

5

设计方案合理、可行,论证严谨,逻辑性强,具有说服力。

5

符号统一;图表完备、符合规范要求。

5

能对整个设计过程进行全面的总结,得出有价值的结论或结果。

5

参考文献数量在3篇以上,格式符合要求,在正文中正确引用。

答辩情况

25

10

在规定时间内能就所设计的内容进行阐述,言简意明,重点突出,论点正确,条理清晰。

15

在规定时间内能准确、完整、流利地回答教师所提出的问题。

总评成绩:

补充说明:

指导教师:

(签字)

日期:

年月日

答辩记录表

学生姓名:

学号:

班级:

答辩地点:

答辩内容记录:

答辩成绩

合计

分值

各项分值

评分标准

实际得分

合计得分

备注

25

10

在规定时间内能就所设计的内容进行阐述,言简意明,重点突出,论点正确,条理清晰。

15

在规定时间内能准确、完整、流利地回答教师所提出的问题。

答辩小组成员(签字):

年月日

指导教师评语

指导教师:

(签字)

日期:

年月日

1.项目概述1

1.1系统开发背景2

1.2项目开发目的2

2.集装箱结构3

3.资源设计4

3.1执行软件并输入参数4

3.2计算装箱方案与实际装箱方案的比较4

4.成本计划6

5.项目费用计划6

6.质量计划8

6.1软件质量的确立8

6.2评审和检查9

6.3功能检查10

6.4物理检查10

6.5综合检查10

6.6管理评审10

6.7软件配置管理10

6.8工具、技术和方法11

6.9媒体控制11

6.10对供货单位的控制11

6.11记录的收集、维护和保存12

7.风险控制计划13

7.1风险分析方法13

7.2风险评估14

7.3风险控制方法14

总结15

致谢16

参考文献..........................................................17

项目概述

1.1系统开发背景

需求分析是软件生命周期计划阶段的重要组成部分,是开发者对待软件开发项目的“理解、分解与表达“的过程,是借助于当前系统的逻辑模型推出新系统的逻辑模型。

集装箱优化需求分析文档设计是软件工程课程的核心内容之一,是了解和熟悉软件工程方法和过程设计的有效途径。

编写集装箱优化设计需求文档主要是对软件工程课程的强化练习,熟悉需求分析文档编写的形式,同时给老师指导并且加深对需求分析的理解。

集装箱优化设计需求分析文档主要是要求我们是要使用最优化的方法将正方形、长方形和三角形三种形状的物体装在一个矩形箱子里的文档。

需求分析的任务就是借助于当前系统(或手工)的逻辑模型推导出新系统的逻辑模型,解决性新系统做什么的问题。

所谓“需求”指的是软件系统的功能需求、性能需求、数据需求、其他有效的需求,通过深入了解和分析,确定这些需求以及确定软件设计的限制和软件与其他系统元素的接口细节,从而确定系统必须完成哪些工作,幸存对新系统准确、清晰、具体的要求。

集装箱,是指具有一定强度、刚度和规格专供周转使用的大型装货容器,是现代重要的运输工具,提高集装箱的容积率可以使企业在货物运输这一重要环节降低成本与费用,是进出口和运输等企业普遍关心的问题。

在运输过程中,物流成本一般包括库存费用、运输成本和物流管理费用三部分。

其中运输成本占三分之一左右,如何有效地降低运输成本是企业非常关心的问题。

利用好集装箱,可以节约大量运输费用,降低物流成本,反之,要造成巨大浪费。

1.2项目开发目的

不同的集装箱制造商生产的集装箱尺寸标准不同。

了解集装箱的生产商及其集装箱的规格十分重要找那个药。

为了最大显得的利用集装箱空间,我们会尽量把货物塞满,让集装箱里面的剩余空间到达最小。

目前,很多企业还是依赖于人工精心的计算装箱,而且仍设计的装箱方案的优化设计程度还远远不够理想。

同时经验装箱存在着不准确性,只有在装箱工作结束以后才能知道每个集装箱载了哪些货物以及每种货物的装箱数量,企业才可以去报关,从而导致发货周期较长。

需求分析是指理解用户需求,就软件功能与客户达成一致,估计软件风险和评估项目的代价,最终形成开发计划的一个复杂过程。

在这个过程中,用户的确处于主导地位,需求分析工程师和项目经理要负责整理用户需求,为之后的软件设计打下坚实的基础。

从广义上来讲:

需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

本实验中通过图形,即正方形、长方形、三角形等来进行模拟,主要功能是有足够的容积容纳商品并从强度和刚度方面良好地保护它们。

集装箱结构

集装箱:

是指具有一定强度、刚度和规格专供周转使用的大型装货容器。

使用集装箱转运货物,可直接在发货人的仓库装货,运到收货人的仓库卸货,中途更换车、船时,无须将货物从箱内取出换装。

集装箱优化:

指在固定大小的集装箱箱内,尽可能的放入最多数目的货物纸箱(本系统中为三类图形,即正方形、长方形及三角形),从而使空间利用率达到最小。

软件设计的功能结构主要分为三大模块来处理,分别是,输入模块,主要用于用户选择性的要求展开处理。

处理模块,主要对集装箱的平面容器进行优化设计处理。

输出模块,根据用户输入的选择方案,输出其方案结果,并且得出最佳方案。

其功能如下IPO图所示:

输入框:

处理框:

输出框:

图1-1IPO图

资源设计

3.1执行软件并输入参数

启动“集装箱优化设计软件”后,可以输入(选择)集装箱尺寸(内部空间的尺寸)。

说明:

所有的参数值都是以厘米(CM)为单位的(2.54厘米=1英寸,1英尺=12英寸)。

3.2计算装箱方案与实际装箱方案的比较

在参照装箱示意图制定实际装箱方案时,有以下几点因素需要注意。

(1)“集装箱装箱优化软件”最后给出的装箱方案,是对应于众多优化算中装箱结构较为简单且装箱数量较多的一种,因此本软件并不能保证最后的结果是装箱数量最多的一种。

(2)“集装箱装箱优化软件”在计算可程中装集装箱当作一个长方体(没有考虑角件等因素),因此如有角件等,则需要移动装箱位置(或在有角件的地方空出一箱)等手工处理。

(3)由于“集装箱装箱优化软件”在计算过程中将包装箱视为标准的长方体,而实际情况下,包装箱的尺寸总会有误差,还会有不同程度的尺寸不一,鼓胀,变形等。

而且,要想顺利地装卸,包装箱和集装箱箱壁之间也需要多少有一点空隙。

这种误差的大小随情形而异。

一般地,为了计算这种差额,可以视具体情形而在包装箱本身长宽高的基础上增添一个增量,比如原来包装箱是39×29×24(CM),计算时可以输入40×30×25(CM)。

输入数据要求:

(1)数据类型:

输入数据为选定图形的尺寸,故为3位整型即可,即Int32类型的整数;

(2)格式:

数值;

(3)媒体:

该数据是通过文本框进行输入的;

(4)数值范围:

长小于等于40m,宽小于等于20m,单个图形面积不超过800平方米;

(5)精度:

精确到0.01m;

图2-1集装箱平面设计图

输出数据要求:

(1)数据类型:

图形部分为图片,结果部分为优化后装入集装箱的图形数目,故为Int32类型;

(2)格式:

bmp和数值类型;

(3)媒体:

文本框输出优化后装入集装箱的最大图形数目,bmp位图保存的是优化后的图形方式,主要在panel上显示;

(4)数值范围:

(5)精度:

由于输出结果为位图类型和纯数字类型,所以输出精度没有特殊要求;

(6)控制输出量:

装入图形后,剩余空间最少且在此情况下装入的数量最多,即可输出结果。

具体组合方案:

图2-2集装箱资源分配图

成本计划

4.1项目费用计划

项目成本估算(ProjectCostEstimate)项目成本估算是指根据项目的资源需求和计划,以及各种项目资源的价格信息,估算和确定项目各种活动的成本和整个项目总成本的一项项目成本管理工作。

成本估算是对完成项目所需费用的估计和计划,是项目计划中的一个重要组成部分。

要实行成本控制,首先要进行成本估算。

理想的是,完成某项任务所需费用可根据历史标准估算。

但对许多工业来说,由于项目和计划变化多端,把以前的活动与现实对比几乎是不可能的。

费用的信息,不管是否根据历史标准,都只能将其作为一种估算。

1.项目成本的构成

1)项目定义与决策工作成本;

2)项目设计成本;

3)项目采购成本;

4)项目实施成本。

2.具体的项目成本科目

1)人工成本(各种劳力的成本)

2)物料成本(消耗和占用的物料资源费用)

3)顾问费用(各种咨询和专家服务费用)

4)设备费用(折旧、租赁费用等)

5)其他费用(如保险、分包商的法定利润等)

6)不可预见费(为预防项目变更的管理储备)

3.软件开发成本估算的经验模型

  Putnam模型,1978年Putnam提出的,一种动态多变量模型。

L=Ck*K1/3*td4/3,其中:

L源代码行数(以LOC计);K整个开发过程所花费的工作量(以人年计);td开发持续时间(以年计);Ck--技术状态常数,它反映“妨碍开发进展的限制”,取值因开发环境而异;Ck的典型值开发环境开发环境举例;2000差没有系统的开发方法,缺乏文档和复审;8000好有合适的系统的开发方法,有充分的文档和复审;11000优有自动的开发工具和技术

从上述方程加以变换,可以得到估算工作量的公式:

K=L3/(Ck3*td4)还可以估算开发时间:

td=[L3/(Ck3*K)]1/4

COCOMO模型按其详细程度可以分为三级:

基本COCOMO模型,中间COCOMO模型,详细COCOMO模型。

其中基本COCOMO模型是是一个静态单变量模型,它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。

中级COCOMO模型在基本COCOMO模型的基础上,再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。

详细COCOMO模型包括中间COCOMO模型的所有特性,但更进一步考虑了软件工程中每一步骤(如分析、设计)的影响。

  基本COCOMO模型,通过统计63个历史项目的历史数据,得到如下计算公式。

总体类型工作量进度

  组织型MM=10.4*(KDSI)1.05TDKV=10.5(MM)0.38

  半独立型MM=3.0*(KDSI)1.12TDKV=10.5(MM)0.35

  嵌入型MM=3.0*(KDSI)1.20TDKV=10.5(MM)0.32

4.项目成本估算-估算难点

1.需求信息的复杂性。

与其他有些传统项目不同,信息系统要满足的客户的主观需要。

由于人的复杂性,给信息系统带来了无数的难以确定的因素。

而且,随着项目的进展,许多具体情况的明确,项目的成本估算也会相应的有所变化。

2.开发技术和工具的不断变化。

开发工具软件的不断升级,技术方案不断更新,这些技术的进步让信息系统项目可以提供功能越来越强,但是给信息系统项目的成本估算带来困难。

3.缺乏类似项目估算数据可供参考。

有效的项目成本估算是建立在大量的同类项目的成本估算的基础上的。

没有大量的同类项目的经验,信息系统项目的成本估算也就非常困难了。

4.缺乏专业和富有经验的人才。

5.信息系统研发人员技术能力的差异。

不同人员的不同态度、经验和能力都会造成不同人员的截然不同的效率,这也给信息系统的成本估算带来了困难。

6.管理层的压力与误解。

质量计划

6.1软件质量的确立

集装箱在软件质量确立主要有以下几个方面:

1.明确集装箱在使用范围和目的及需达到的质量目标;

2.组织实际运作的各过程的步骤;

3.在项目的不同阶段,相关职责、权限和资源的具体分配;

  4.采用的具体的文件化程序和指导书;

  5.适宜阶段适用的检验、试验、检查和审核大纲;

  6.随项目的进展进行更改和完善质量计划的文件化程序;

7.达到质量目标的度量方法及所采取的措施。

6.2评审和检查

具体规定了应该进行的阶段评审、阶段评审的内容和评审时间要求。

对新开发的或正在开发的各个子系统,都要按照GB8566的规定认真进行定期的或阶段性的各项评审工作。

就整个软件开发过程而言,至少要进行软件需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查以及管理评审等八个方面的评审和检查工作。

如本计划第2.2条所述,经总体组研究决定,在集装箱优化设计软件及其所属各个子系统的开发过程中,把前七种评审分成三次进行。

在每次评审之后,要对评审结果作出明确的管理决策。

下面给出每次评审应该进行的工作。

6.2.1软件需求评审

这次评审会对软件需求进行评审,软件需求评审(SRR)应确保在软件需求规格说明书中规定的各项需求的合理性。

6.2.2概要设计评审

在软件概要设计阶段结束后必须进行概要设计评审(PDR),以评价软件设计说明书中所描述的软件概要设计在总体机构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。

6.2.3详细设计评审

在软件详细设计阶段结束后必须进行详细设计评审(DDR),以确定软件设计说明书中所描述的详细设计在功能、算法和过程描述等方面的合适性,应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性。

6.2.4软件验证与确认评审

在制订软件验证与确认计划之后要对它进行评审,以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。

6.3功能检查

在软件释放前,要对软件进行检查,功能检查(FA)应验证所开发的软件已经满足在软件需求规格说明书中规定的所有需求。

6.4物理检查

在验收软件前,要对软件进行物理检查(PA),以验证程序和文档已经一致并已做好了交付的准备。

6.5综合检查

在软件验收时,要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查(CA),以验证代码和设计文档的一致性、接口规格说明之间的一致性(硬件和软件)、设计实现和功能需求的一致性、功能需求和测试描述的一致性。

6.6管理评审

要对计划的执行情况定期(或按阶段)进行管理评审(MA);这些评审必须由獐独立于被评审单位的机构或授权的第三方主持进行。

6.7软件配置管理

对集装箱优化设计软件系统的各项配置进行及时、合理的管理,是确保软件质量的重要手段,也是确保该软件具有强大生命力的重要措施。

有关集装箱优化设计软件的配置管理工作,可按开发该系统的软件工程小组编写的《集装箱优化设计软件配置管理计划》。

在软件配置管理工作中,要特别注意规定对软件问题报告、追踪和解决的步骤,并指出实现报告、追踪和解决软件问题的机构及其职责。

6.8工具、技术和方法

在集装箱优化设计项目所属的各个子系统(其中包括有关的支持软件)的研制与开发过程中,都应该在各自的软件质量保证活动中合理地使用软件质量活动的支持工具、技术和方法。

这些工具主要有下列三种:

a.C软件测试工具。

它支持用C语言编写的模块的静态分析、结构测试与功能测试。

主要功能为:

协助测试人员判断程序结构与变量使用情况是否有错;给测试人员提供模块语句覆盖率Co和分支覆盖率C1的值,并显示未覆盖语句和未覆盖分支的号码及其分支谓词,给出不同测试用例有效性的表格;同时提出功能测试的有效情况,并协助组织最终交付给用户的有效测试用例的集合。

b.软件配置管理工具。

它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织;支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围;同时还应支持软件配置管理小组对软件配置更改进行科学的管理。

c.文档辅助生成工具与图形编辑工具。

它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能(输入、输出关系)的曲线以及绘制描述控制系统特性的一些其他图形,同时还可生成若干与集装箱优化设计软件文档编制大纲相适应的文档模块板。

用户利用这个工具的正文与图形编辑功能以及上述辅助功能,可以比较方便地产生清晰悦目的文档,也有利于对文档进行更改,还有助于提高文档的编制质量。

6.9媒体控制

为了保护计算机程序的物理媒体,以免非法存取、意外损坏或自然老化,集装箱优化设计软件系统的各个子系统(包括支持软件)都必须设立软件配置管理人员,并按照开发该系统的软件工程小组制订的、且经集装箱优化设计总体组批准的《集装箱优化设计软件配置管理计划》妥善管理和存放各个子系统及其专用支持软件的媒体。

6.10对供货单位的控制

集装箱优化设计项目所属的各个子系统开发组,如果需要从软件销售单位购买、委托其他开发单位开发、从开发单位现存软件库中选用或从项目委托单位或用户的现有软件库中选用软部件时,则在选用前应向开发该系统的总体组报告,然后由总体组组织“软件选用评审小组”进行评审、测试与检查,只有当演示成功、测试合格后才能批准选用。

如果只选用其中部分内容,则按待开发软件的处理过程办理,此时开发该系统的总体组不作干预。

6.11记录的收集、维护和保存

在集装箱优化设计项目及其所属的各个子系统的研制与开发期间,要进行各种软件质量保证活动,准确记录、及时分析并妥善保存有关这些活动的记录,是确保软件质量的重要条件。

在软件质量保证小组中,应有专人负责收集、汇总与保存有关软件质量保证活动的记录。

要收集、汇总与保存的记录名字及其保存期限见表1。

表1记录名称及其保存的期限

记录的名称与分类

要保存的的期限

阶段评审记录

阶段评审总结

整个软件开发周期

阶段评审问题记录

整个软件开发周期

阶段评审主要问题

整个软件开发周期

阶段评审成员

整个软件开发周期

日常检查记录

软件阶段进度表

整个软件开发周期

软件阶段产品完成情况

整个软件开发周期

软件开发费用统计表

整个软件生存周期

修改记录

软件问题报告单

整个软件生存周期

软件问题修改单

整个软件生存周期

组织

软件质量保证小组成员登记表

整个软件开发周期

风险控制计划

7.1风险分析方法

风险分析根据对各要素的指标量化以及计算方法不同分为定性分析、半定量分析和定量分析的风险分析方法,或者是这些分析的组合。

1)定性分析方法是被广泛使用的一种风险分析方法,也是出现在大部分标准中的一种方法。

它对风险产生的可能性和风险产生的后果基于“低/中/高”这种表达方式,而不是准确的可能性和损失量。

该方法通常只关注威胁事件所带来的损失(Loss),而忽略事件发生的概率(Probability)。

多数定性风险分析方法依据组织面临的威胁、脆弱点以及控制措施等元素来决定安全风险等级。

在定性评估时并不使用具体的数据,而是指定期望值,如设定每种风险的影响值和概率值为“高”、“中”、“低”。

有时单纯使用期望值,并不能明显区别风险值之间的差别。

可以考虑为定性数据指定数值。

例如,设“高”的值为3,“中”的值为2,“低”的值为

定量分析

2)定量分析方法利用两个基本的元素:

威胁事件发生的概率和可能造成的损失。

把这两个元素简单相乘的结果称为ALE(AnnualLossExpectancy)或EAC(EstimatedAnnualCost)[2]。

理论上可以依据ALE计算威胁事件的风险等级,并且做出相应的决策。

文献[1]提出了一种定量风险评估方法。

该方法首先评估特定资产的价值V,把信息系统分解成各个组件可能更加有利于整个系统的定价,一般按功能单元进行分解;然后根据客观数据计算威胁的频率P;最后计算威胁影响系数μ,因为对于每一个风险,并不是所有的资产所遭受的危害程度都是一样的,程度的范围可能从无危害到彻底危害(即完全破坏)。

根据上述三个参数,计算ALE:

ALE=V×P×μ?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

但是这种方法存在一个问题,就是数据的不可靠和不精确。

对于某些类型的安全威胁,存在可用的信息。

例如,可以根据频率数据估计人们所处区域的自然灾害发生的可能性(如洪水和地震)。

也可以用事件发生的频率估计一些系统问题的概率,例如系统崩溃和感染病毒。

但是,对于一些其他类型的威胁来说,不存在频率数据,影响和概率很难是精确的。

此外,控制和对策措施可以减小威胁事件发生的可能性,而这些威胁事件之间又是相互关联的。

这将使定量评估过程非常耗时和困难。

7.2风险评估

(1)对风险本身的界定。

包括风险发生的可能性;风险强度;风险持续时间;风险发生的区域及关键风险点。

 

(2)对风险作用方式的界定。

包括风险对企业的影响是直接的还是间接的;是否会引发其他的相关风险;风险对企业的作用范围等。

 (3)对风险后果的界定。

在损失方面:

如果风险发生,对企业会造成多大的损失?

如果避免或减少风险,企业需要付出多大的代价?

在冒风险的利益方面:

如果企业冒了风险,可能获得多大的利益。

7.3风险控制方法

风险控制方面应该注意:

(1)可能的硬件故障:

计算机蓝屏;硬件资源得不到满足而无响应;

(2)可能的软件故障:

输入无响应,程序计算错误;

(3)在性能方面产生的后果:

硬件故障可能使程序终止,而软件故障则可能得不到正确的结果,用户均得不到期望的结果;

(4)对硬件故障或软件故障

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 院校资料

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1