第一篇:软件工程实验
作业一
1.请画出由下列文字描述的系统流程图,请用Microsoft Visio 或Word软件画图
设某城市招干考试成绩统计系统。
考生分三个专业,不同专业考试科目不同:
法律专业---考政治、语文、法律
行政专业---考政治、语文、行政
财经专业---考政治、语文、财经学
每个考生在报名时登记姓名、地址、年龄和报考专业。报名后招干办公室根据专业考生专业及地址在市区或郊区来编排准考证号码和考场。考生参加考试后,输入每个考生的各门课程的成绩,并统计出每个考生三门课程的总成绩。按准考证号的顺序打印出考生考试成绩单,分发给每个考生。各专业分别将考生按成绩总分从高到低的次序排序,以便决定录取名单。
作业二
画考务处理系统的数据流图。
考务处理系统功能如下:
(1)对考生送来的报名单进行检查;(2)对合格的报名单编好准考证号后将准考证送给考生,并将汇总后的考生名单送给阅卷站;•3)对阅卷站送来的成绩单进行检查,并根据考试中心制定的合格标准审定合格者;(4)制作考生通知单(含成绩及合格/不合格标志)送给考生;(5)按地区进行成绩分类统计和试题难度分析,产生统计分析表。
作业三
1、请为某仓库的管理设计一个ER模型。该仓库主要管理零件(包括零件编号、名称、颜色、重量)的定购和供应等事项。仓库向工程项目(包括项目编号、项目名称、开工日期)供应零件,并且根据需要向供应商(包括供应商编号、名称、地址)定购零件。
2、画复印机的状态转换图 复印机的工作过程大致如下: 未接到复印命令时处于闲置状态,一旦接到复印命令则进入复印状态,完成一个复印命令规定的工作后又回到闲置状态,等待下一个复印命令;
如果执行复印命令时发现没纸,则进入缺纸状态,发出警告,等待装纸,装满纸后进入闲置状态,准备接收复印命令;
如果复印时发生卡纸故障,则进入卡纸状态,发出警告等待维修人员来排除故障,故障排除后回到闲置状态。
作业四
请将上列给出的具有变换型的DFD图导出它的软件结构SC图
作业五
某程序流程图如下图所示,请分别用N-S图和PAD图表示。
作业六
练习题:用判定表和判定树表示“检查订货单”伪码 IF 客户订货金额超过5000元 THEN IF 客户拖延未还赊欠钱款超过60天 THEN 在偿还欠款前不予批准
ELSE(拖延未还赊欠钱款不超过60天)发批准书,发货单 ENDIF ELSE(客户订货金额未超过5000元)IF 客户拖延未还赊欠钱款超过60天 THEN 发批准书,发货单,并发催款通知书 ELSE(拖延未还赊欠钱款不超过60天)发批准书,发货单 ENDIF ENDIF
作业七
设计下列伪码程序的语句覆盖和路径覆盖测试用例: START
INPUT(A,B,C)IF A>5 THEN X=10 ELSE X=1 END IF IF B>10 THEN Y=20 ELSE Y=2 END IF IF C>15 THEN Z=30 ELSE Z=3 END IF PRINT(X,Y,Z)STOP
实习
请参考机票预订系统实例 飞机票预订系统.zip
一、课程实践任务
学生自行分组选择一个项目,完成一个实际软件项目的分析、设计、开发、测试全过程,领会软件工程的基本思想,明晰各个阶段的主要任务,使用 MicroSoft Visio、Project、Rose、VSS、Power Designer 等计算机辅助软件工具,采用规范化的软件工程方法进行软件项目的研发。
二、课程实践的要求
第二篇:软件工程实验二
实验二:需求分析报告
实验学时:2
课后2学时
实验类型:技能性
一、目的与任务
目的:明确需求分析任务的重要性,掌握需求分析的主要具的使用方法和步骤,写出需求规格说明书。
二、实验安排
1、装有Offic软件,Visio 2010的微机系统.2、实验安排方式:本实验为开放实验,各组可同时进行实验,每组8-10人。
三、实验内容及步骤
1、选择一个管理系统(人事管理系统、工资管理系统、学生档案管理系统等)。
2、软件工程的原理对该系统的问题进行分析;
3、分析系统的数据需求获得当前系统的物理模型,然后抽象出当前系统的逻辑模型,再建立目标系统的逻辑模型;理出系统的数据流程图;
4、用Visio 2010画出该系统的数据流图,用结构化分析方法对整个系统进行分析细化,用数据流图描绘系统的逻辑模型,描绘信息在系统中流动和处理的情况;数据流图是分析和设计的工具,它主要描述系统完成的功能而不是系统的物理实现。
5、在Microsoft Word文档下写出该系统的数据字典,用数据字典对人们不了解的条目进行解释,对所有被加工引用的数据流和数据存储进行解释;
6、用小说明来描述最底层的基本加工逻辑,小说明并不描述具体的加工过程,而只是这个加工的输入数据和输出数据的逻辑关系。
7、用Visio 2007画出该系统的IPO图,它的基本形式是左边框中列出有关的输入数据,在中间的框中列出主要的处理,在右边的框中列出产生的输出数据;
8、用层次方框图或Warnier图对系统进行说明;层次方框图是由树型结构的一系列多层次的矩形框描绘数据的层次结构数型结构的顶层是一个单独的矩形框,它代表完整的数据结构,下面的各层矩形框代表这个数据的子集,最底层的各个框代表组成这个数据的实际数据元素。
四、思考题
1、软件需求分析在整个软件生存周期中的地位?
2、在软件需求分析中要完成哪些任务,所完成的资料在以后的工作中起什么作用?
3、做需求分析的过程中有没有做社会调研?
附录一:
实验要求
软件工程实验要求学生采用“项目小组”的形式,结合具体的开发项目进行设计。具体要求如下:
1.班级按项目小组进行分组,每组不得超过10人 2.每个项目小组选出项目负责人或项目经理,由项目经理召集项目组成员讨论、选定开发项目
3.项目中的每项任务要落实到人且规定该任务的起止日期和时间
4.每个项目小组必须按照《软件工程实验指导书》附录中给定的文档规范标准提供项目文档
5.题目自定或采用附录二中的题目
6.软件开发的方法自定(结构化或面向对象的方法学)
附录二:
实验题目
题目一:“教务管理系统之子系统——学院课程安排” 1.系统简介
每个学期的期中,学校教务处向各个学院发出下各学期的教学计划,包括课程名称、课程代码、课时、班级类别(本科、专科、成人教育、研究生)、班号等;学院教学主管人员根据教学任务和要求给出各个课程的相关限制(如:任课教师的职称、上课的班数、最高和最低周学时数等);任课教师自报本人授课计划,经所在教研室协调任可,将教学计划上交学院主管教学计划的人员,批准后上报学校教务处,最终由教务处给出下个学期全学院教师的教学任务书。
假设上述排课过程全部由人工操作,现要求为上述过程实现计算机自动处理过程。2.限定条件
(1)每位教师的主讲课程门数不超过2门/学期:讲师以下职称的教师不能承担学院定主课的主讲任务。(2)学院中层干部的主讲课时不能超过4学时/周。
(3本学期出现严重教学事故的教师不能承担下各学期的主讲任务。
(4)本系统的输入项至少包括:教务处布置的教学计划,学院教师自报的授课计划和学院定的有关授课限制条件。(5)本系统的输出项至少包括:教务处最终下达全院教师的教学任务书和学院各个班级下各学期的课程表(可以不含上课地点)。
题目二:“学校教材定购系统” 1.系统简介
本系统可以细化为两个子系统:销售系统和采购系统 销售系统的主要工作过程为:首先由教师或学生提交购书单,经教材发行人员审核是有效购书单后,开发票、登记并返给教师或学生领书单,教师或学生可以到书库领书。
采购系统的主要工作过程为:若是教材脱销,则登记缺书,发缺书单给书库采购人员;一旦新书入库后,即发进书通知给教材发行人员。
以上功能要求在计算机上实现。2.技术要求和限制条件
(1)当书库中的各种书籍数量发生变化(包括进书和出书)时,都应修改相关的书库记录,如库存表或进/出库表。(2)在实现上述销售和采购的工作过程时,需考虑有关的合法性验证。
(3)系统的外部项至少包括:教师、学生和教材工作人员。(4)系统的相关数据存储至少包括:购书表、库存表、缺书登记表、待购教材表、进库表和出库表。
题目三:“机票预定系统” 1.系统简介
航空公司为给旅客乘机提供方便,需要开发一个机票预定系统。各个旅行社把预定机票的旅客信息(姓名、性别、工作单位、身份证号码(护照号码)、旅行时间、旅行始发地和目的地,航班舱位要求等)输入到系统中,系统为旅客安排航班。当旅客交付了预订金后,系统打印出取票通知和帐单给旅客,旅客在飞机起飞前一天凭取票通知和帐单交款取票,系统核对无误即打印出机票给旅客。此外航空公司为随时掌握各个航班飞机的乘载情况,需要定期进行查询统计,以便适当调整。
2.技术要求和限制条件(1)在分析系统功能时要考虑有关证件的合法性验证(如身份证、取票通知和交款发票)等。(2)对于本系统还应补充一下功能: 1.旅客延误了取票时间的处理 2.航班取消后的处理
3.旅客临时更改航班的处理(3)系统的外部输入项至少包括:旅客、旅行社和航空公司。
题目四:“学校内部工资管理系统” 1.系统简介
假设学校共有教职工约1000人,10个行政部门和8个系。每个月20日前各个部门(包括系和部门)要将出勤情况上报人事处,23日前人事处将出勤工资、奖金及扣款清单送到财务处。财务处于每个月月底将教职工的工资表做好并将数据送银行。每个月3日将工资条发给每个单位。若由员工调入或调出、校内调动、离退休变化,则由人事处通知相关部门和财务处。
2.技术要求和限制条件
(1)本系统的数据存储至少包括:工资表、部门汇总表、扣税款表、银行发放表等。
(2)除人事处、财务处外,其他职能部门和系名称可以简化表示。
(3)工资、奖金、扣款细节由学生自定义。
题目五:“实验室设备管理系统” 1.系统简介
每学年要对实验室设备使用情况进行统计、更新。其中:(1)对于已彻底损坏的做报废处理,同时详细记录有关信息。(2)对于由严重问题(故障)的要及时修理,并记录修理日期、设备名、编号、修理厂家、修理费用、责任人等。(3)对于急需修改但又缺少的设备,需以“申请表”的形式送交上级领导请求批准购买。新设备购入后要立即进行设备登记(包括类别、设备名、编号、型号、规格、单价、数量、购置日期、生产厂家、保质期和经办人等信息),同时更新申请表的内容。
(4)随时对现有设备及其修理、报废情况进行统计、查询,要求能够按类别和时间段等查询。
2.技术要求及限制条件
(1)所有工作由专门人员负责完成,其他人不得任意使用。(2)每件设备在做入库登记时均由系统按类别加自动顺序号编号,形成设备号;设备报废时要及时修改相应的设备记录,且有领导认可。
(3)本系统的数据存储至少包括:设备记录、修理记录、报废记录、申请购买记录。
(4)本系统的输入项至少包括:新设备信息、修理信息、申请购买信息、具体查询统计要求。本系统的输出项至少包括:设备购买申请表、修理/报废设备资
金统计表
题目六:“校园代金卡系统” 1.系统简介
校园代金卡系统配套符合金融标准的金融设备——自助缴费机(带圈存功能),以银行卡为辅助,从真正意义上实现全方位的现代化校园管理,实现校园货币电子化。它以非接触式IC卡又称射频卡为操作手段,配合校园计算机网络,实现整个学校的全方位智能卡网络化管理,将先进的IC卡技术服务用于学校的教学、科研、管理和生活等方面。用IC卡取代借书证、餐票、计算机房的上机卡、通道出入证件等;并作为校园信息查询卡,使教师和学生可以轻松查询教学设备、教室情况、图书音像资料、校园活动等各类信息。整个系统的建成,为学校从各项日常管理事务到各种长期数据处理提供科学的解决方案,以节约学校的人力物力,在提高学校管理能力的基础上,亦能为学校带来一定的经济效益。师生手持一张智能卡就可以实现学校全部事务,实现学校的各种消费的无纸币流通。
2.校园代金卡系统功能要求 在代金卡系统的功能要求中,首先应该划分出系统必须完成的所有功能。
校园代金卡系统能够运用于解决学生和教职工的消费既管理问题,包括购物消费、购饭消费、迟到、早退学生登记、图书借阅、机房上机、学生成绩查询、校园综合信息查询、学生身份验证等。其中校园代金卡系统又分为一卡通中心平台、银行接口子系统、图书管理系统、消费管理系统、学生学籍管理系统、身份验证识别系统、门禁考勤系统等子系统,各个系统所实现功能也不相同,主要分为: 一卡通中心平台
校园代金卡的一卡通中心平台实现了对校园卡的发放、挂失、取消等管理,能够传输和处理数据系统,交易数据,结算清算各种费用,在没有工作人员参与的情况下自己也能进行一系列的工作,节省时间和人力。
银行接口子系统
校园代金卡的银行接口子系统能实现银行卡和学生校园卡帐号对应,两卡分离,学生家长持银行卡,学生持校园代金卡。家长使用银行系统的全国异地通存通兑业务,给学生银行卡中汇款。通过设在校园内的圈存机,可以实现银行卡到校园卡的电子钱包圈存并可自助查询银行帐户余额。这样学生不必从银行取出现金然后再对校园卡进行充值,节约了人力,方便了学生充值校园代金卡。
附录三:
软件开发文档指南 可行性研究报告
可行性研究报告的编写目的是:说明该软件开发项目的实现在技术、经济和社会条件方面的可行性;评述为了合理地达到开发目标而可能先择的各种方案;说明论证所选定的方案。可行性研究报告的编写内容要求如下:
1.1 引言
1.1.1 编写目的 1.1.2 背景 1.1.3 定义
1.1.4 参考资料
1.2 可行性研究的前提
1.2.1 要求 1.2.2 目标
1.2.3 条件、假定和限制 1.2.4 进行可行性研究的方法 1.2.5 评价尺度
1.3 对现有系统的分析 1.3.1 数据流程和处理流程 1.3.2 工作负荷 1.3.3 费用开支 1.3.4 人员 1.3.5 设备 1.3.6 局限性
1.4 所建议的系统
1.4.1 对所建议系统的说明 1.4.2 数据流程各处理流程 1.4.3 改进之处 1.4.4 影响
1.4.4.1 对象设备的影响 1.4.4.2 对软件的影响
1.4.4.3 对用户单位机构的影响 1.4.4.4 对系统动行的影响 1.4.4.5 对开发的影响
1.4.4.6 对地点和设施的影响 1.4.4.7 对经费开支的影响 1.4.5 局限性
1.4.6 技术条件方面的可行性 1.5 可选择其他系统方案 1.5.1 可选择的系统方案1 1.5.2 可选择的系统方案2 ……
1.6 投资及收益分析 1.6.1 支出
1.6.1.1 基本建设投资 1.6.1.2 其他一次性支出 1.6.1.3 非一次性支出 1.6.2 收益
1.6.2.1 一次性收益 1.6.2.2 非一次性收益 1.6.2.3 不可定量的收益 1.6.3 收益/投资比 1.6.4 投资回收周期 1.6.5 敏感性分析
1.7 社会条件方面的可行性 1.7.1 法律方面的可行性 1.7.2 使用方面的可行性 1.8 结论 项目开发计划
编制项目开发计划的目的是用文件的形式,把对于在开发过程中各项工作的负责人员、开发进度所需经费预算、所需软、硬件条件等问题作出安排记载下来,以便根据本计划开展和检查本项目的开发工作。编制内容要求如下:
2.1 引言
2.1.1 编写目的 2.1.2 背景 2.1.3 定义
2.1.4 参考资料 2.2 项目概述 2.2.1 工作内容 2.2.2 主要参加人员 2.2.3 产品及成果 2.2.3.1 程序 2.2.3.2 文件 2.2.3.3 服务
2.2.3.4 非移交产品 2.2.4 验收标准
2.2.5 完成项目的最迟期限 2.2.6 本计划的审查者与批准者 2.3 实施总计划
2.3.1 工作任务的分解 2.3.2 接口人员 2.3.3 进度 2.3.4 预算
2.3.5 关键问题 2.4 支持条件
2.4.1 计算机系统支持 2.4.2 需要用户承担的工作 2.4.3 需由外单位提供的条件 2.5 专题计划要点 3 软件需求说明书
软件需求说明书的编制是为了使用户的软件开发者双方对该软件的起初规定有一个共同的理解,使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下:
3.1 引言
3.1.1 编写的目的 3.1.2 背景 3.1.3 定义
3.1.1 参考资料 3.2 任务概述 3.2.1 目标
3.2.2 用户的点 3.2.3 假定与约束 3.3 需求规定
3.3.1 对功能的规定 3.3.2 对性能的规定 3.3.2.1 精度
3.3.2.2 时间特性要求 3.3.2.3 灵活性
3.3.3 输入输出要求
3.3.4 数据管理能力的要求 3.3.5 故障处理要求 3.3.6 其它的专门的要求 3.4 运行环境规定 3.4.1 设备
3.4.2 支持软件 3.4.3 接口 3.4.4 控制 数据需求说明书
数据要求说明书的编制目的是为了向整个开发时期提供关于处理数据的描述和数据采集要求的技术信息。编制数据要求说明书的内容要求如下: 引言
编写目的 背景 定义
参考资料
数据的逻辑描述 静态数据 动态输入数据 动态输出数据 内部生成数据 数据约定 数据的采集 要求和范围 输入的承担者 处理 影响 概要设计说明书
概要设计说明书可称作系统设计说明书,这里说的系统是指程序系统,编制的目的是说明对程序的系统的设计考虑,包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等,为程序的详细设计提供基础。编制概要设计说明书的内容要求如下:
5.1 引言
5.1.1 编写目的 5.1.2 背景 5.1.3 定义
5.1.4 参考资料 5.2 总体设计 5.2.1 需求规定 5.2.2 运行环境
5.2.3 基本设计概念和处理流程 5.2.4 结构
5.2.5 功能需求与程序的关系 5.2.6 人工处理过程 5.2.7 尚未解决的问题 5.3 接口设计 5.3.1 用户接口 5.3.2 内部接口 5.3.3 外部接口 5.4 运行设计
5.4.1 运行模块组合 5.4.2 运行控制 5.4.3 运行时间
5.5 系统数据结构设计 5.5.1 逻辑结构设计要点 5.5.2 物理结构设计要点 5.5.3 数据结构与程序的关系 5.6 系统出错处理设计 5.6.1 出错信息 5.6.2 补救措施 5.6.3 系统维护设计 6 详细设计说明书
详细说明书可称作程序设计说明书。编制目的是说明一个软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑,如果一个软件系统比较简单,层次很少,本文件可以不单独编写,有关内容合并概要设计说明书。对详细设计说明书的内容要不得要求如下:
6.1 引言
6.1.1 编写目的 6.1.2 背景 6.1.3 定义 6.1.4 参考资料
6.2 程序系统的组织结构
6.3 程序1(标识符)设计说明 6.3.1 程序描述 6.3.2 功能 6.3.3 性能 6.3.4 输入项 6.3.5 输出项 6.3.6 算法 6.3.7 流程逻辑 6.3.8 接口 6.3.9 存储分配 6.3.10 注释设计 6.3.11 限制条件 6.3.12 测试计划
6.3.13 尚未解决的问题
6.4 程序2(标识符)设计说明 …… 数据库设计说明书
数据库设计说明书的编制目的是对于设计中的数据库所有标识、逻辑结构和理结构作出具体的设计规定。其内容要求如下:
7.1 引言
7.1.1 编写目的 7.1.2 背景 7.1.3 定义
7.1.4 参考资料 7.2 外部设计
7.2.1 标识符和状态 7.2.2 使用它的程序 7.2.3 约定
7.2.4 专门指导 7.2.5 支持软件 7.3 结构设计
7.3.1 概念结构设计 7.3.2 逻辑结构设计 7.3.3 理结构设计 7.4 运用设计
7.4.1 数据字典设计 7.4.2 安全保密设计 8 用户手册
用户手册的编制是要使用非专门术语的语言,充分地描述该软件系统工程所具有的功能及基本的使用方法。使用户(或潜在用户)通过本手册能够了解该软件的用途,并且能够确定在什么情况下,如何使用它。具体的内容要求如下:
8.1 引言
8.1.1 编写目的 8.1.2 背景 8.1.3 定义
8.1.4 参考资料 8.2 用途 8.2.1 功能 8.2.2 性能 8.2.2.1 精度 8.2.2.2 时间特性 8.2.2.3 灵活性 8.2.3 安全保密 8.3 运行环境 8.3.1 硬设备 8.3.2 支持软件 8.3.3 数据结构 8.4 使用过程
8.4.1 安装与初始化 8.4.2 输入
8.4.2.1 输入数据的现实背景 8.4.2.2 输入格式 8.4.2.3 输入举例 8.4.3 输出
8.4.3.1 输出数据的现实背景 8.4.3.2 输出格式 8.4.3.3 输出举例 8.4.4 文卷查询
8.4.5 出错处理与恢复 8.4.6 终端操作 9 操作手册
操作手册的编制是为了向操作人中提供该软件每一个运行的具体过程和有关知识,包括操作方法的细节。具体的内容要求如下:
9.1 引言
9.1.1 编写目的 9.1.2 背景 9.1.3 定义 9.1.2 参考资料 9.2 软件概述 9.2.1 软件的结构 9.2.2 程序表 9.2.3 文卷表
9.3 安装与初始化 9.4 运行说明 9.4.1 运行表 9.4.2 运行步骤
9.4.3 运行1(标识符)说明 9.4.3.1 运行控制 9.4.3.2 操作信息
9.4.3.3 输入-输出文卷 9.4.3.4 输出文段
9.4.3.5 输出文段的复制 9.4.3.6 启动恢复过程
9.4.4 运行2(标识符)说明 9.5 非常规过程 9.6 远程操作 10 模块开发卷宗
模块开发卷宗是在模块开发过程中逐步编写出来的,每完成一个模块或一级密切相关的模块的复审时编写一份,应该把所有的模块开发卷宗汇集在一起。编写的目的是记录和汇总低层次开发的进度和结果,以便于对整个模块开发工作的管理和复审,并为将来的维护提供非常有用的技术信息。具体的内容要求如下:
10.1 标题
10.2 模块开发情况表 10.3 功能说明 10.4 设计说明 10.5 源代码清单 10.6 测试说明 10.7 复审的结论 11 测试计划 11.1 引言
11.1.1 编写目的 11.1.2 背景 11.1.3 定义
11.1.4 参考资料 11.2 计划
11.2.1 软件说明 11.2.2 测试内容
11.2.3 测试1(标识符)11.2.3.1 进度安排 11.2.3.2 条件 11.2.3.3 测试资料 11.2.3.4 测试培训
11.2.4 测试2(标识符)……
11.3 测试设计说明
11.3.1 测试1(标识符)11.3.1.1 控制 11.3.1.2 输入 11.3.1.3 输出 11.3.1.4 过程
11.3.2 测试2(标识符)……
11.4 评价准则 11.4.1 范围
11.4.2 数据整理 11.4.3 尺度 测试分析报告
测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加发记载,具体的编写内容要求如下:
12.1 引言
12.1.1 编写目的 12.1.2 背景 12.1.3 定义 12.1.4 参考资料 12.2 测度概要
12.3 测试结果及发现 12.3.1 测试1(标识符)12.3.2 测试2(标识符)……
12.4 对软件功能的结论 12.4.1 功能1(标识符)12.4.1.1 能力 12.4.1.2 限制
12.4.2 功能2(标识符)……
12.5 分析摘要 12.5.1 能力
12.5.2 缺陷和限制 12.5.3 建议 12.5.4 评价
12.6 测试资源消耗 13 开发进度月报
开发进度月报的编制目的是及时向有关管理部门汇报项目开发的进展和情况,以便函及时发现或处理开发过程中出现的问题。一般地,开发进度月报是以项目组为单位每月编写的。如果被开发的软件系统规模比较大,整个工程项目被划分给若干个分项目组承担,开发进度月报将以项目组为单位按月编写。具体的内容要求如下:
13.1 标题
13.2 工程进度与状态 13.2.1 进度 13.2.2 状态
13.3 资源耗用与状态 13.3.1 资源耗用 13.3.1.1 工时 13.3.1.2 机时 13.3.2 状态
13.4 经费支出与状态 13.4.1 经费支出 13.4.1.1 支持性费用 13.4.1.2 设备购置费 13.4.2 状态
13.5 下个月的工作计划 13.6 建议 项目开发总结报告
项目开发总结报告的编制是为了总结本项目开发工作的经验,说明实际取得的开发结果以及对整个开发工作的各个方面的评价。具体的内容要求如下:
14.1 引言
14.1.1 编写目的 14.1.2 背景 14.1.3 定义 14.1.4 参考资料 14.2 实际开发结果 14.2.1 产品
14.2.2 主要功能和性能 14.2.3 基本流程 14.2.4 进度 14.2.5 费用
14.3 开发工作评价
14.3.1 对生产效率的评价 14.3.2 对产品质量的评价 14.3.3 对技术方法的评价 14.3.4 出错原因的分析
第三篇:软件工程实验文档
《软件工程课程设计》
一、提交实验报告文挡及要求
序报告名目 的 要 求
号 称
以全面、系统的分析为主要方法,经济效益为核心,围绕影响项目的可行性各种因素,运用大量的数据资料论证拟建项目是否可行,给出项目可1
分析
行性分析报告。2 3 项目需根据给定的的题目或自选题目进行需求分析工作;进行功能需求、非求分析 功能需求分析得出需求规格说明书。
项目概建立初始结构图,对初始结构构图进行改进、优化得出概要设计说明要设计 书。
项目详进行详细设计工作,得出详细设计说明书。
细设计
项目编本次实习不需编码
码 5
进行黑盒、白盒测试试用例设计形成测试用例表;
项目测进行黑盒测试,得出测试记录; 6
试 进行白盒测试,得出测试记录;
形成测试报告。7 项目管利用Project进行项目计划、进度、协调等管理材料。
理
二、课程实践选题(课程设计题目)
题目一:电子商务网站建设
是一个集客户购物、下订单、订单处理、销售统计等功能于一体的系统。通过浏览器,让客户可以查询货物,把货物放入购物车,创建账户/登陆账户,创建订单,通过信用卡支付等。系统划分成了多个模块,松耦合的设计架构,允许可以和多个数据源,EIS(企业信息系统)进行交互。功能如下: 1.用户
注册/登陆/忘记密码/管理个人信息
查询货物
购物车管理
提交订单
信用卡支付
查询历史购物记录 2.货物商店
接受/处理订单消息
手工接受/拒绝订单
用E-mail来通知客户
发订单给供应商 销售统计 3.供应商
接受订单
派送货物给用户
提供一个基于web的库存管理
维护库存数据库
题目二:外文图书采购系统 1.问题概述
某图书馆外文采购有两个组--征订组和验收登记组。分别承担书籍订购和进书验收任务。为了减轻劳动强度和提高工作效率,打算采用计算机进行管理。为此,系统分析员在进行了调查研究,描述出外文采购室现行系流程。
1)订书组从供书单价收到订书目录,根据各单位的需要选择出要订购的书目。2)为了避免浪费,对于已进入过或已订过的图书和订单留底。3)打印的订单,要送给订书单位和验收登记组,并留底。4)对所登记的书进行统计表。
5)验收登记组从供书单位收到图书和发票,根据订单留底进行验收。6)发票交给财务科进行报账。
7)为了避免浪费,对于已进图书再做查重,如果重了,转让出去或作别处理。如果不重,则登账和打印查重卡。8)查重卡要交给订书组用于查重。
9)已登记的书籍要送给编目室进行编目。
10)已进的书要记入图书总账并进行进书统计和打印进行统计表。11)订书统计表和进书统计表交馆领导。
这里没有考虑出错和例外情况的处理。这些验收不合格怎么办?查重的书号或书名输入错误怎么办?等等。在实际运行中,这些问题都必须考虑到。
2.这个问题比较适合用面向数据流的方法来求解。
求解这类问题应理解和当前系统(可能是人工系统可能是计算机系统)的业务流程,首先获得当前系统的物理模型。接着从当前系统的物理模型抽象出当前系统的的“怎么做到当前系统的”做什么“的现象到本质的抽象过程。然后通过分析目标系统与当前系统在逻辑上的差异,导出目标系统的逻辑型。最后通过对目标系统的逻辑模型,才能得到最终所要求的目标系统。
题目三:毕业设计指导网站
毕业设计指导网站的目的是使学生和教师能够通过网络进行毕业设计辅导,这样能够得到最新的毕业设计信息,更好的辅导效果。内容如下: 1.学生
注册/登陆/忘记密码/管理个人信息
上传文件和下载文件
向指导教师提问
查询问题 2.教师
登陆/忘记密码
管理所辅导学生的账户 上传文件和下载文件
回答问题
群发消息 3.管理员
管理教师和学生信息
查询统计数据(日问题量,答疑率)
提醒教师答疑
发布公告
群发消息
要求: 1.加入评价机制(学生评价教师;系统根据网络利用效率评价教师对学生的指导质量等)
2.扩展文档管理功能(根据毕业设计的特点,催交/管理/评价学生在不同阶段上交的毕业设计文档)
3.考虑适应所有学院/大学的毕业设计指导网站
题目四:教务处课程管理网站
教务处课程管理网站的目的是使教务处方便地管理学生的选课情况、学习成绩等信息,并通过该系统向学校的其他管理部门提供或获取数据。内容如下: 1.学生
登陆/忘记密码
查询成绩
上传平时作业 选课 2.教师
登陆/忘记密码 查询学生花名册 布置作业 批改学生作业 提交学生成绩
上传课程资料(教学大纲、教学日历和课件等)3.教务处
管理学生的账户 管理教师帐户 发布公告
启动/关闭课程注册功能 查询成绩 统计成绩数据
提供查询学生成绩服务的接口 4.学生处
提供学生信息导入的接口
要求:1.通过Web Service提供服务或使用服务(如查询成绩服务和学生处学生信息获取服务)
2.考虑通用的教务处课程网站 题目五:病员监护系统
本例为医院特级护理病房的病员监视系统。1)在每一病床旁有一个监护器。
2)在病员身上附着各种传感叹器,监测各种生理参数,诸如血压,呼吸,体温。信号被被送到监护器。
3)监护器带有输入键盘,用以输入病员的病号的病历号,各种监测的生理因素的安全范围值(上下限值),以及监测频率定期(监测周期)等。
4)各监测部件与中心计算机相连,后者按指定的监测频率定期地对监视器进行检查。
5)检查所得到的数据记录在每个病员的记录文件上。
6)如果发现病员的生理因数超出在安全范围时,在护理室有各病员的各种报警信号(灯光)出现。
7)每个监视器有一开关,用来控制监测工作。
8)本例中假设监视255个病员,每人设定4个因素。监视周期可从1秒到小时变化,对每一病员监视1秒时间。
9)安全范围为十进数值,内部表示为浮点数。病历号为9整数。
题目六:简易办公系统
很多办公室的计算机完成了大量的文字处理功能,并没有行使管理功能,现对其改进如下:
(1)收发文管理:
对收到的公文进行登记,分类编号,(学校主要发文部门分为:教务处、财务处、学生处、人事处、保卫处、工会以及其他),并形成文件主要内容关键字,使收文能够按照关键字、时间和部门查询;对发文进行登记,并形成文件主要内容关键字,使发文能够按照关键字、时间和部门查询。(2)会议管理:
对所管理的2个会议室进行自动化管理,即由申请部门提交申请,然后统一安排会议室以及各种会议资源(如投影仪、计算机、桌子、凳子等),能形成会议资源使用通知单送达申请部门,主管领导随时查询会议室使用情况(管理者直接负责管理)。能够按照申请者的要求自动生成会议通知单,由办公室负责通知发放。能够形成会议纪要,存档并送到需要的部门(由申请者提供的信息决定)
题目七:低值易耗品管理系统
为了加强对学校实验室低值易耗品的管理和监督,将指定专门的部门对其进行管理,为了方便管理,减少工作量,拟定开发一个低值易耗品管理系统,描述如下:(1)学校每个院系及工程训练中心均有一个实验室,每个实验室每学期均有低值易耗品。
(2)基本管理流程:
每学期期末由各实验室上报下学期的低值易耗品清单,由材料管理科负责分类汇总,并报送审计处、财务处和校长,由实验主管部门负责对所有清单进行审核,将清单中所有物品分为未批、待批、统购和自购四大部分。并将审批后的清单返还给实验室。其中统购和自购物品作为实验室计划内消耗,并根据参考价格计算出各个实验室下学期的计划消耗金额。并形成计划汇总表,报送上级部门。统购物品由材料管理科统一购买,应能自动生成全校统购物品清单,清单上的物品能够按院系和按物品类别分类汇总。物品购买后,入库。各个实验室按照指定计划到库房领用,其对应消耗进入实验室计划消耗内。
自购物品由实验室自行购买,购买后将清单送到材料管理科审核,备案后,方可报帐。自购物品也进入本实验室计划消耗内。
材料管理科应能随时查询当前还未购买的物品、以及当前各个实验室计划内物品的领和消耗情况。
对未在计划内的物品消耗,采取由实验室填报申请表(在表中,必须说明申报原因),送上级领导审核后,执行所需费用仍然进入相应院系的消耗。
学期末,应产生学校各类物品消耗汇总表,各个院系实际消耗汇总表,所有物品计划消耗与实际消耗对比分析表,各个院系计划消耗与实际消耗对比分析表。
题目八:软件工程课程自主学习课件建设
本课程主要在于采取一种全新的学习模式,采取网上自主教学的新模式,以自主教学,强调教学顺序,提出课件资源组件化、组件库的思想,其主要描述如下: 选定软件工程教材并对软件工程进行教学单元的划分,形成教学内容的划分,并形成教学资源勘查点,并形成不同的教学模式。
完成组件设计。并形成组件的建设和组件库管理的基本框架。完成服务器架构以及客户端界面的设计
题目九:超市管理系统一个面向小型超市的管理系统,可完成以下工作: 1.实现客户购物收银管理; 2.向超市仓库中添加商品,记录商品的损耗(如过期、变质等非购买方式的损耗); 3.查询某商品的库存情况;
4.当各种商品库存量少于某规定值时,系统给予提示; 5.实现月度、商品销售情况统计(如销售量最大的商品,销售额最多的商品,各商品的销售量、销售额汇总等)
题目十:学生管理系统
1.学生档案信息维护,包括注册、注销、更新等; 2.学生选课管理,从可选的课程中选择若干课程; 3.学生成绩管理,实现学生成绩的登记;
4.学生信息、选课情况、成绩的查询和报表输出; 满足以下限制:
每个学生选择的课程数在15~18之间;
学生信息注销后,便不允许对与之相关的信息作任何修改,但可查阅; 成绩的登记是按照课程来登记的;
学生只能实现2、4功能,且只涉及与自身相关的内容;
题目十一:企业单位物资管理系统
1.实现物资的购入、登记、报废等管理;
2.可将各类物资分配到企业各个科室以便使用; 3.可按照物资类别,名称,价格、科室等查询、统计; 4.可生成相应的统计报表; 其他说明、限制:
所管理的物资分两大类:固定资产(如家具、电器)、耗材(文具等); 每一件固定资产有唯一的资产编号;
物资管理员可以完成以上1、2、3、4功能,而普通员工只可查询本人、本科室相关的情况;
题目十二:高等数学学习和测试系统
系统紧扣高等数学教学大纲,根据教学大纲的要求,将高等数学的全部教学内容分为课程学习、随堂练习、综合测试三大部分。系统制作应遵循的几个原则
1.教学性原则; 2.可操作性原则; 3.科学性原则; 4.简约性原则; 5.艺术性原则; 6.适度信息量原则
题目十三:高等学校毕业生就业服务信息系统 不仅仅提供基础的信息服务,而且要充分利用丰富的网络资源,将现代化的管理手段与先进网络技术的有机结合,对毕业生顺利就业将起到重大的促进和保障作用。(最好要具有就业论坛的信息过滤功能).题目十四:学校教材订购系统 本系统可细化为两个子系统:销售系统和采购系统销售系统的工作过程为:首先由教师或学生提交购书单,经教材发行人员审核是有效购书单后,开发票、登记并返给教师或学生领书单,教师或学生即可去书库领书。
采购系统的主要工作过程为:若是脱销教材,则登记缺书,发缺书单给书库采购人员;一旦新书入库后,即发进书通知给教材发行人员。以上的功能要求在计算机上实现。技术要求和限制条件:
当书库中的各种书籍数量发生变化(包括领书和进书时),都应修改相关的书库记录,如库存表或进/出库表。
在实现上述销售和采购的工作过程时,需考虑有关单据的合法性验证。系统的外部项至少包含三个:教师、学生和教材工作人员。系统的相关数据存储至少包含6个:购书表、库存表、缺书登记表、待购教材表、进/出库表。
题目十五:机票预订系统
航空公司为给旅客乘机提供方便,需开发一机票预定系统。各旅行社把预定机票的旅客信息(姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地等)输入到该系统,系统为旅客安排航班。当旅客交付了预定金后,系统印出取票通知和帐单给旅客,旅客在飞机起飞的前一天凭取票通知和帐单交款取票,系统核对无误即印出机票给旅客。此外航空公司为随时掌握各航向飞机的乘载情况,需定期进行查询统计,以便适当调整。技术要求及限定条件:
(1)在分析系统功能时要考虑有关证件的合法性验证(如身份证、取票通知、交款发票等)。(2)对于本系统还应补充以下功能: 1)旅客延误了取票时间的处理 2)班机取消后的处理
3)旅客临时更改机票班次的处理
系统的外部项至少包含三个:旅客、旅行社和航空公司。
题目十六:实验室设备管理系统
每学年要对实验室设备使用情况进行统计、更新,其中:
(1)对于已彻底损坏的作报废处理,同时详细记录有关信息。
(2)对于有严重问题(故障)的要即使修理,并记录修理日期、设备名、修理厂家、修理费、责任人等。(3)对于急需但又缺少的设备需以“申请表”的形式送交上级领导请求批准购买。新设备购入后要立即进行设备登记(包括类别、设备名、型号、规格、单价、数量、购置日期、生产厂家、购买人等),同时更新申请表的内容。
(4)随时对现有设备及其修理、报废情况进行统计、查询,要求能够按类别和时间段(某日期之前)查询。技术要求及限定条件
(1)所有工作由专门人员负责完成,其他人不得任意使用。
(2)每件设备在作入库登记时均由系统按类别自动顺序编号,形成设备号;设备报废时要及时修改相应的设备记录,且有领导认可。
(3)本系统数据存储至少应包含:设备记录、修理记录、报废记录、购买申请。(4)本系统的输入项至少包含:新设备信息、修理信息、申请购买信息、报废信息、具体查询统计要求。
(5)本系统输出项至少包含设备购买申请表、修理/报废注销/设备资金统计表。
题目十七:通用试题库组卷系统的设计与实现
考试是进行教学目标评价的主要手段 ,试卷是测量学生学习质量的一把”尺子"。而命题的水平则是检验教学质量的关键。传统的试卷命题一般是用手工的方式实现的 ,不但工作量大、容易出错 ,而且不能把教师从繁重的出卷劳动中解放出来。在现行的教育中 ,虽然有些高等院校也有一些专门的课程的试题库管理系统 ,但是通用性的效果不佳。随着 Internet 的出现和广泛使用 ,WEB 使得实现广泛的网络共享、集中的安全控制和友好的使用界面达到了完美的结合。开发基于 Web 的在线组卷系统就具有很重要的意义。
开发网上的通用试题库组卷系统 ,不仅可以很好的实现教考分离 ,可以提高教学质量 ,而且可以使高校的教学管理质量更上一层楼。它是将系统架设在一个 WEB站 点上运行 ,通过浏览器访问 ,它提供了传统题库系统所不能完成的某些功能。充分利用网络资源 ,教师、专家可以在终端进行试题库的编辑、更新等操作 ,学生则可以通过动态的选择不同的类型、数量的试题来进行在线学习和考试 ,来检测自己的学习效果。
功能模块:
录入模块:在教学大纲和考试大纲的指导下 ,可以向组卷库里添加符合要求的试题和试卷。
查询模块:系统中的所有用户可以查询试卷、试题、用户等信息。组卷模块:是通用试题库组卷系统的一个核心模块 ,这部分的设计的优劣能够反映其试卷质量的高低。就目前而言 ,为了满足不同人的需求 ,组卷的形式大概可以分为以下两种。手工组卷是指系统根据一些条件后调出一定范围的试题,然后出题人员在这个范围的试题内逐个地通过复选来形成试卷的方法。出题者可以利用现有的试题库 ,按照条件查询 ,可以在查询结果中对每一试题进行率选, 顺序也可以进行调整 ,出题人员不断重复这个步骤 ,并可以依据每题的难易程度来控制整份试卷的难易。自动组卷是指出题人员向系统只提供一些很简洁的计划,完全由系统自动按照一定的算法和规则在试题库里自动 ,系统根据一些参数的设定 ,比如: 试题的考试时间 ,按题型比例出卷,随机抽取试题并试题不重复等等, 灵活地抽取各类型的试题组成试卷 ,那么就会导致试卷的内容随着库中的试题的变化而变化。
考试模块:本系统的另一个核心模块。其主要功能是为学生提供一个考试平台 ,根据对出题方式的设定 ,输入试卷编号,如果试卷确实存在 ,那就可以调出试卷进行在线测试 ,考生在页面上进行答题, 最后将答案提交给服务器 ,为了规范考试纪律,该系统采用了自愿交卷和自动交卷。
删除模块:只有管理员才具有权限去删除,可以选择删除试题、科目等信息。
题目十八:操作系统精品课程网站设计与实现 《操作系统》是软件学院软件工程专业的主干必修课,为嵌入式系统及其应用提供课程支持,它在计算机知识结构中有着极其重要的地位和作用,可为学生较全面的建立起关于计算机系统的概念。《操作系统》课程又是考研课程和软考重要必考课程之一,定位于计算机各相关专业的本科生,因此在授课内容上强调知识的完备性、实际系统的关联性、基本理论的应用性及新技术的引入。该课程要求学生能够很好地掌握计算机操作系统的基本概念、各种资源管理的思想和算法,能够较好的理解操作系统原理,而且能够拓展原理的应用,也为学生的底层程序开发及后续发展奠定基础。因此,开发一个操作系统精品课程网站显得尤其重要。
功能模块:
课程介绍:主要包括软件工程的课程简介、教学大纲、选用教材、参考文献等。师资队伍:主要是介绍软件工程的主讲教师、教学专家、教师风采(主要采用视频播放教师现场授课)、教学成果(包括教改课题、教改论文)教学资源:主要向学生提供丰富的课内和课外知识,使学生可在课外时间预习和复习课程知识,并能根据自己的兴趣了解相关的课外知识。这些模块还提供各类资源的下载功能,如电子课件、阅读资料、例题习题、课程设计等。
在线考试:管理员或教师维护题库、根据试题的题库设置考试的试卷规则、录入允许参加考试的考生名单、考生随机抽取题库试题进行考试、教师批卷或计算机自动判卷、统计考试成绩、查询考试结果。在线考试还具备学生的自测功能,即学生可任意选择自测章节、知识点和难度系数进行组题,以确定测试范围,系统将根据学生的选项,自动随机调出相应范围内的题目。学生答题结束后,系统记录学生的答题情况,以供学生日后参考复习。系统还会在答题结束后自动给出参考答案,供学生参考。对于客观性题目, 系统还会自动打出分数。
辅导答疑:是实现“网上答疑”,在网上学生提出问题,教师进行解答,这些提问和解答都被系统记录,以便其他用户查看和学习,达到信息的共享目的。用户管理:主要用于对用户分角色进行有效的授权管理,系统主要包含三类用户:学生、教师和系统管理员,每类用户对本系统有各自不同的使用权限。学生的权限最低,只有一般的使用权。教师和系统管理员具有较高的权限,如教师可以进行作业管理,题库模块的维护及答疑等;系统管理员则负责公告,教学资源,试题库,角色等各种功能的管理。
作业管理:该模块主要是学生在这里提交作业,教师可以在线批改作业,给出成绩,学生可以在查看作业批改情况。
第四篇:软件工程实验心得
早在我选择民政职业技术学院就读软件开发与项目管理这门专业的时候,我一直认为软件开发无非是努力的敲代码,从敲代码的过程中去体会各行代码的意思和用处,在没学软件工程时我一直都是努力的敲代码去学习软件开发这门专业。在大一的时候我敲代码的激情很好,但是到大二的时候就出现问题了,我根本就不喜欢敲代码了,看见代码就头疼。所以感觉厌恶这门专业,对学习也不感兴趣了。而且,还有一件更头疼的事是在写一个简单的程序时竟然老是出错,难一点的,复杂一点的程序竟然无从下手。但是去看程序的参考答案时都看得懂,又感觉很容易。学了软件工程以后,我就感觉我以前的学习方法是错误的。以前我只注重于代码,而不注重理论知识以及编程的思路,程序的架构。以至于在些程序时没有写程序的思路,不能形成程序的架构。只想到看脑袋里是否有与此类似的代码。越想程序越乱,最后脑袋里一片空白。不知道程序从哪个方面下手了。
软件工程这门课程是做软件开发的人必学的课程,通过学这门课程,程序员就会注重软件开发的理论知识,以及做项目开发的思路。学了这门课程后你写程序就不会去盲目的去套用代码,而是理清此程序的架构以及思路。程序该从什么时候开始,什么时候结束。在中间需要添加什么样的功能,以完善该软件。其实学软件工程并不难,而且很容易。软件工程与日常生活联系起来的话,就是在一天中你该先做什么,后做什么。理解了先做什么,后做什么了以后写程序就不是那么难了,再复杂的程序也可以分成几大块。你理清程序的思路后就可以一步步的解决其中的难题,最终实现软件的功能。如果没学软件工程不知道理清程序的思路的话,做一个大的项目开发,那么多的代码,没有一个很好的结构,最终只会导致程序混乱,错误百出,知道代码再多也会素手无策的。
总而言之,作为一个程序员学习软件工程这门课程是至关必要的,如果没学习软件工程,你就不会做项目开发,也不可能开发出一个完善的软件出来。
软件工程实验心得(2):
曾经看过一本书叫《道法自然》,内容略记得一二,但我最欣赏的是它的书名。软件设计没什么太神秘有东西,只要用心体会,其实一切都很自然。软件的设计之“道”,也不在于设计有多么的华丽、精巧,而在于其朴实、自然,最终达到“以无招胜有招”,进入一个全新的境界。
一、软件设计理论的层次
以我的拙见,软件设计领域中的各种概念,可以分为以下几个层次来进行理解:
1、软件设计的目的:重用性、扩展性。
这是最高的层次,是应对软件危机的需要。
2、设计原则:低耦合、高聚合。
各种软件设计的原则,如依赖倒置原则、单一职则原则、面向接口等,以及各种设计模式,其根本的目的其实只是为了降低耦合这么简单。因为只有低耦合才能更好的适应变化,更好的重用和扩展。
3、实现方法:运用设计模式封装变化、降低耦合。
设计模式只是用来“封装变化、降低耦合”的工具而已。它是面向对象设计时代的产物,其本质就是充分运用面向对象的三个特性,即:封装、继承和多态,进行灵活的组合运用。
二、关于耦合1、耦合的粒度
耦合无论如何也是不可避免的。当我们实现接口、继承父类的时候,就会不可避免的产生耦合。耦合是有不同粒度的,我们解耦到什么粒度为止,我认为应以模块的重用粒度为准。尽量解除重用模块或对象之间的耦合。而重用模块之内的耦合,应属于聚合的范畴,所以不要盲目的去解耦,否则就陷入了误区。
2、解耦的原理
怎样才能解耦呢,或者说为什么各种设计模式能达到解耦的目的呢?我觉得有以下几个思路:
(1)将具体的东西抽象处理
(2)将分散的东西集中处理
而面向对象中的接口、继承正为我们提供了这样的一种机制。通过访问接口或基类或抽象类,而不是具体的实现类,从而与具体的实现类达到了解耦的目的。我们还可以设计一些控制类,像润滑剂一样,协调各实现类之间的访问,也可以达到耦的目的。
事实上,各种设计模式的基本思想也就是这样。创建型模式是为了解除创建对象时产生的耦合,实际上是解除对类称名的依赖,而结构型和行为型是为了解除对象属性或方法的直接调用。不管什么设计模式,都是将对具体实现类的访问提升为对接口、基类或用于协调的控制类的访问。
三、关于接口
这一节更具体,谈一谈接口,因为使用接口是软件设计的重要手段,但已经不属于“道”了~
1、接口与继承
接口描述的是对象某一个方面行为特征。使用接口与使用继承关系各有优缺点,使用子类继承可以继承父类的功能,体现了重用的精神。而接品更加灵活,因为它解除了子类与父类之间的高度耦合,它体现在灵活扩展的精神。
2、接口与纯虚类
理论上接口可以由纯虚基类实现类似的功能,那为什么还我们不去掉接口的概念,而直接使用虚类呢?
接口存在的理由就是它更加灵活,关系简单,易于理解。比如一个类可以实现十几个甚至几十个接口,但一般开发工具只支持单继承(由于多继承太容易导致混乱和冲突),如果要继承十几层,系统结构想必会无法理解了,我以为这是接口存在的最重要的原因。
如果接口和虚类继承结合使用,可以产生强大的威力,这也是许多设计模式的“杀手锏”。
以上算是总结一下自己的心得。肯定有不少片面之处,请各位指教。
第五篇:软件工程实验心得体会
软件工程实验心得体会
软件工程实验心得体会一:软件工程实验心得体会
经过这学期软件工程实验的学习,深深感到用户需求对软件的重要性。成功的软件产品是建立在成功的需求基础之上的,而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决,而开发人员开始帮助用户解决这个问题,沟通就开始了。
需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识:用户知道需求是什么,我们所要做的就是和他们交谈从他们那里得到需求,只要问用户系统的目标特征,什么是要完成的,什么样的系统能适合商业需要就可以了,但是实际上需求获取并不是想象的这样简单,这条沟通之路布满了荆棘。首先需求获取要定义问题范围,系统的边界往往是很难明确的,用户不了解技术实现的细节,这样造成了系统目标的混淆。
其次是对问题的理解,用户对计算机系统的能力和限制缺乏了解,任何一个系统都会有很多的用户或者不同类型的用户,每个用户只知道自己需要的系统,而不知道系统的整体情况,他们不知道系统作为一个整体怎么样工作效率更好,也不太清楚那些工作可以交给软件完成,他们不清楚需求是什么,或者说如何以一种精确的方式来描述需求,他们需要开发人员的协助和指导,但是用户与开发人员之间的交流很容易出现障碍,忽略了那些被认为是'很明显'的信息。最后是需求的确认,因为需求的不稳定性往往随着时间的推移产生变动,使之难以确认。为了克服以上的问题,必须有组织的执行需求的获取活动。
需求获取活动要完成的任务或者步骤的过程如下:
1、编写项目视图和范围文档
系统的需求包括四个不同的层次:业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务,这在使用实例文档或方案脚本说明中予以说明。功能需求定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。
非功能性需求是用户对系统良好运作提出的期望,包括了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户需求,然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求,应该包括高层的产品业务目标,评估问题解决方案的商业和技术可行性,所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目相关人员对项目的目标和范围能达成共识,整个项目组都应该把注意力集中在项目目标和范围上。
2、用户群分类
系统用户在很多方面存在着差异,例如:使用系统的频度和程度、应用领域和计算机系统知识、所使用的系统特性、所进行的业务过程、访问权限、地理上的布局以及个人的素质和喜好等等。根据这些差异,你可以把这些不同的用户分成不同的用户类。与ULM中Usecase的Actor概念一样,用户类不一定都指人,也可以包括其他应用系统、接口或者硬件,这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点,并详细描述出它们的个性特点及任务状况,将有助于需求的获取和系统设计。
3、建立核心队
通常用户和开发人员不自觉的都有一种'我们和他们'的想法,产生一种对立关系,把彼此放在对立面,每一方都定义自己的'边界',只想自己的利益而忽略对方的想法。他们通过文档、记录和对话来沟通,而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的,不会给双方带来一点益处,良好的沟通关系没有建立导致了误解和忽略重要的信息。只有当双方参与者都明白要成功自己需要什么,同时也知道要成功对方需要什么时,才能建立起一种合作关系。
为了建立合作关系通常采取一种组队的方式来获取需求,建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方案和协商分歧,小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流,但交流时应注意以下原则:小组会议应该由中立方来组织和主持,用户和开发人员都要参加;交流预先要确定准备和参与的规则;议题要明确并覆盖所有关键点,但信息来源应该自由;交流目标要明确,并告知所有的成员。
4、确定使用实例
从用户代表处收集他们将使用系统完成所需任务的描述,讨论用户与系统间的交互方式和对话要求,这就是使用实例,一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。使用实例方法给需求获取带来的好处来自于该方法是用以任务为中心和以用户为中心的观点,比起使用以功能为中心和以开发者为中心的方法,使用实例方法可以使用户更清楚地理解和认识到新系统允许他们做什么和怎么做。描写使用实例的时候要注意使用简洁直白的表述,尽量使用主动语态,用'系统'或者'用户'作为主语,比如'用户提交用户密码,系统验证用户密码是否正确',还有一点在描述中不要设计界面细节,比如'用户从下拉框中选择产品类型'。使用实例为以后写用例场景描述中的基本路径和扩展路径提供了素材。
5、分析用户工作流程
分析用户工作流程观察用户执行业务任务的过程,通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求,统一建模语言的使用有助于与用户进一步交流。每个用例的描述应包括:编号,为每个用例分配一个唯一的编号,为需求的追溯提供了方便;参与者,与这个用例交互的 actor;前置条件,开始用例前所必须具备的系统状态;后置条件,用例完成后系统达到的状态;基本路径,用例完成的关键路径,也是用户期望的路径;扩展点,基本路径的分枝,表示意外情况;字段说明,路径中名称的进一步分解说明,对以后类属性的定义和数据库字段设计起作用;设计约束,实现用例的非功能约束。
6、检查问题报告
通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本提供了大量丰富的改进及增加特性的想法,负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
7、需求重用
如果客户要求的功能与已有的系统很相似,则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法,像分析模式和设计模式一样,需求也有自己的模式。
总结 :经过一学期的软工实验,深刻感到其重要性的同时也学到了不少的东西,将对我在今后的软件开发过程中起极大的作用
>软件工程实验心得体会二:软件工程实验心得>>(789字)
早在我选择民政职业技术学院就读软件开发与项目管理这门专业的时候,我一直认为软件开发无非是努力的敲代码,从敲代码的过程中去体会各行代码的意思和用处,在没学软件工程时我一直都是努力的敲代码去学习软件开发这门专业。在大一的时候我敲代码的激情很好,但是到大二的时候就出现问题了,我根本就不喜欢敲代码了,看见代码就头疼。所以感觉厌恶这门专业,对学习也不感兴趣了。而且,还有一件更头疼的事是在写一个简单的程序时竟然老是出错,难一点的,复杂一点的程序竟然无从下手。但是去看程序的参考答案时都看得懂,又感觉很容易。学了软件工程以后,我就感觉我以前的学习方法是错误的。以前我只注重于代码,而不注重理论知识以及编程的思路,程序的架构。以至于在些程序时没有写程序的思路,不能形成程序的架构。只想到看脑袋里是否有与此类似的代码。越想程序越乱,最后脑袋里一片空白。不知道程序从哪个方面下手了。
软件工程这门课程是做软件开发的人必学的课程,通过学这门课程,程序员就会注重软件开发的理论知识,以及做项目开发的思路。学了这门课程后你写程序就不会去盲目的去套用代码,而是理清此程序的架构以及思路。程序该从什么时候开始,什么时候结束。在中间需要添加什么样的功能,以完善该软件。其实学软件工程并不难,而且很容易。软件工程与日常生活联系起来的话,就是在一天中你该先做什么,后做什么。理解了先做什么,后做什么了以后写程序就不是那么难了,再复杂的程序也可以分成几大块。你理清程序的思路后就可以一步步的解决其中的难题,最终实现软件的功能。如果没学软件工程不知道理清程序的思路的话,做一个大的项目开发,那么多的代码,没有一个很好的结构,最终只会导致程序混乱,错误百出,知道代码再多也会素手无策的。
总而言之,作为一个程序员学习软件工程这门课程是至关必要的,如果没学习软件工程,你就不会做项目开发,也不可能开发出一个完善的软件出来。
>软件工程实验心得体会三:软件工程实验心得>>(1261字)
曾经看过一本书叫《道法自然》,内容略记得一二,但我最欣赏的是它的书名。软件设计没什么太神秘有东西,只要用心体会,其实一切都很自然。软件的设计之“道”,也不在于设计有多么的华丽、精巧,而在于其朴实、自然,最终达到“以无招胜有招”,进入一个全新的境界。
一、软件设计理论的层次
以我的拙见,软件设计领域中的各种概念,可以分为以下几个层次来进行理解:
1、软件设计的目的:重用性、扩展性。
这是最高的层次,是应对软件危机的需要。
2、设计原则:低耦合、高聚合。
各种软件设计的原则,如依赖倒置原则、单一职则原则、面向接口等,以及各种设计模式,其根本的目的其实只是为了降低耦合这么简单。因为只有低耦合才能更好的适应变化,更好的重用和扩展。
3、实现方法:运用设计模式封装变化、降低耦合。
设计模式只是用来“封装变化、降低耦合”的工具而已。它是面向对象设计时代的产物,其本质就是充分运用面向对象的三个特性,即:封装、继承和多态,进行灵活的组合运用。
二、关于耦合1、耦合的粒度
耦合无论如何也是不可避免的。当我们实现接口、继承父类的时候,就会不可避免的产生耦合。耦合是有不同粒度的,我们解耦到什么粒度为止,我认为应以模块的重用粒度为准。尽量解除重用模块或对象之间的耦合。而重用模块之内的耦合,应属于聚合的范畴,所以不要盲目的去解耦,否则就陷入了误区。
2、解耦的原理
怎样才能解耦呢,或者说为什么各种设计模式能达到解耦的目的呢?我觉得有以下几个思路:
(1)将具体的东西抽象处理
(2)将分散的东西集中处理
而面向对象中的接口、继承正为我们提供了这样的一种机制。通过访问接口或基类或抽象类,而不是具体的实现类,从而与具体的实现类达到了解耦的目的。我们还可以设计一些控制类,像润滑剂一样,协调各实现类之间的访问,也可以达到耦的目的。
事实上,各种设计模式的基本思想也就是这样。创建型模式是为了解除创建对象时产生的耦合,实际上是解除对类称名的依赖,而结构型和行为型是为了解除对象属性或方法的直接调用。不管什么设计模式,都是将对具体实现类的访问提升为对接口、基类或用于协调的控制类的访问。
三、关于接口
这一节更具体,谈一谈接口,因为使用接口是软件设计的重要手段,但已经不属于“道”了~
1、接口与继承
接口描述的是对象某一个方面行为特征。使用接口与使用继承关系各有优缺点,使用子类继承可以继承父类的功能,体现了重用的精神。而接品更加灵活,因为它解除了子类与父类之间的高度耦合,它体现在灵活扩展的精神。
2、接口与纯虚类
理论上接口可以由纯虚基类实现类似的功能,那为什么还我们不去掉接口的概念,而直接使用虚类呢?
接口存在的理由就是它更加灵活,关系简单,易于理解。比如一个类可以实现十几个甚至几十个接口,但一般开发工具只支持单继承(由于多继承太容易导致混乱和冲突),如果要继承十几层,系统结构想必会无法理解了,我以为这是接口存在的最重要的原因。
如果接口和虚类继承结合使用,可以产生强大的威力,这也是许多设计模式的“杀手锏”。
以上算是总结一下自己的心得。肯定有不少片面之处,请各位指教。