软件工程概论报告
西南交通大学
软件工程概论报告
课 程 《软件工程概论》 学 院 信息科学与技术学院
专 业 软件工程
姓 名
学 号
日 期 2016年月日
目录
一、软件工程的诞生与发展 . .......................................................................................................... 3
二、软件工程领域中软件开发的方法与过程 . .............................................................................. 3
(一) 、需求调研分析 . .............................................................................................................. 4
(二)、概要设计 . .................................................................................................................... 4
(三)、具体设计 . .................................................................................................................... 4
(四)、编码 . ............................................................................................................................ 4
(五)、测试 . ............................................................................................................................ 4
(六)、软件交付预备 . ............................................................................................................ 4
(七)、验收 . ............................................................................................................................ 5
三、软件开发过程中常出现的问题与对策 . .................................................................................. 5
(一)、正确的理解和管理需求及其变更 . ............................................................................ 5
(二)、配置管理方面 . ............................................................................................................ 6
(三)、缺陷管理方面 . ............................................................................................................ 6
四、软件开发过程管理的重点 . ...................................................................................................... 7
(一)、持续集成的重要性 . .................................................................................................... 7
(二)、重视文档 . .................................................................................................................... 7
(三)、保持工件的一致性 . .................................................................................................... 7
(四)、重视风险管理 . ............................................................................................................ 7
(五)、重视周报和月报 . ........................................................................................................ 8
(六)、了解培训的重要性 . .................................................................................................... 8
五、心得体会 . .................................................................................................................................. 8
一、软件工程的诞生与发展
随着计算机应用的日益普及,软件数量急剧膨胀。在程序运行时发现的错误必须设法改正;用户有了新的需要时必须相应地修改程序;硬件或操作系统更新时,通常需要修改程序以适应新的环境。上述种种软件维护工作,无时无刻地消耗着大量的资源。更严重的是,许多程序的个性化特性使得它们最终成为不可维护的程序。就这样软件危机就爆发了,由于受到软件危机的困扰,软件甚至成为了限制计算机系统发展的瓶颈。为了彻底地摆脱软件危机,并更好地更有效地开发与维护软件,软件工作者不断地寻找消除软件工程的途径,于是便出现了软件工程这门新的科学。
自从软件工程概念提出以来,经过几十年的研究与实践,虽然“软件危机”没得到彻底解决,但在软件开发方法和技术方面已经有了很大的进步。尤其应该指出的是,自80年代中期,开始认识到,在软件开发中,最关键的问题是软件开发组织不能很好地定义和管理其软件过程,从而使一些好的开发方法和技术都起不到所期望的作用。也就是说,在没有很好地定义和管理软件过程的软件开发中,开发组织不可能在好的软件方法和工具中获益。
软件工程的研究热点是随着软件技术的发展而不断变化的。即便在软件工程的领域内,研究热点也在不断转移。以往软件工程一直不能像其他产品一样,做到标准化,但是,随着技术条件的不断成熟和相应标准的出台,软件人员已经开始重视这方面的工作。实际上可以将许多软件工作分成许多部件去构造。很有可能今后的软件队伍会分为两个部分,一部分专门从事评估,另一部分专门从事集成,集成的对象是软构件。
软构件的开发与运用刚刚开始。在一些公共领域,例如软件的用户界面,通用软构件的使用已经屡见不鲜。然而,对于各行各业的专业领域来说,领域构件的开发和使用还基本处于空白状态。这一工作的进行,意味着各行各业要对本专业领域内的知识形态加以归纳整理,然后以最新的软件形式表达出来。如果全面铺开,这就是一件规模浩大的社会工程,需要各行各业的领域专家和软件专家通力合作才能完成。如果软件生产的“构件-集成”格局的趋势成为现实,各种应用领域里的构件的设计与生产将开辟出一个十分广阔的新天地,产生出巨大的市场需求,而且软构件的使用可以渗透到符合软构件标准规范的所有系统中。
在软件开发过程中人们开始研制和使用软件工具,用以辅助进行软件项目管理与技术生产,人们还将软件生命周期各阶段使用的软件工具有机地集合成为一个整体,形成能够连续支持软件开发与维护全过程的集成化软件支援环境,以期从技术和管理两方面解决软件危机问题。
此外,人工智能与软件工程的结合成为 80年代末期活跃的研究领域。基于程序变换、自动生成和可重用软件等软件新技术的研究也已取得一定的进展,把程序设计自动化的进程向前推进了一步。在软件工程理论的指导下,发达国家已经建立起较为完备的软件工业化生产体系,形成了强大的软件生产能力。软件标准化与可重用性得到了工业界的高度重视,在避免重复劳动、缓解软件危机方面起到了重要作用。
二、软件工程领域中软件开发的方法与过程
软件开发流程即软件设计思路和方法的一般过程,包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测
试以及编写、提交程序。
(一) 、需求调研分析
相关系统分析员和用户初步了解需求,然后用WORD 列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以初步定义好少量的界面。系统分析员深进了解和分析需求,根据自己的经验和需求用WORD 或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚例用系统大致的大功能模块,大功能模块有哪些小功能模块,并且还例出相关的界面和界面功能。系统分析员和用户再次确认需求。
(二)、概要设计
首先,开发者需要对软件系统进行概要设计,即系统设计。概要设计需要对软件系统的设计进行考虑,包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等,为软件的具体设颊贯供基础。该阶段需要形成的文档和图释有:流程图、数据库结构图、静态页面、模块划分。
(三)、具体设计
在概要设计的基础上,开发者需要进行软件系统的具体设计。在具体设计中,描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系,需要说明软件系统各个层次中的每一个程序(每个模块或子程序) 的设计考虑,以便进行编码和测试。应当保证软件的需求完全分配给整个软件。具体设计应当足够具体,能够根据具体设计报告进行编码。该阶段需要形成的文档和图释有:具体设计文档(按照模块划分,具体描述每个模块的实现细节,包括主要算法、处理逻辑、关键技术应用等)。
(四)、编码
在软件编码阶段,开发者根据《软件系统具体设计报告》中对数据结构、算法分析和模块实现等方面的设计要求,开始具体的编写程序工作,分别实现各模块的功能,从而实现对目标系统的功能、性能、接口、界面等方面的要求。该阶段需要形成的文档和图释有:根据需求、具体设计在编码之前对所编写模块整理出《测试用例excel 文档文档》、对每个模块要有juint 单元测试 。
(五)、测试
测试编写好的系统。交给用户使用,用户使用后一个一个的确认每个功能。测试有功能测试、性能测试、压力测试(根据用户群体数据量进行模拟)。
(六)、软件交付预备
在软件测试证实软件达到要求后boke.heimaseo.com ,软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。《用户安装手册》应具体先容安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服
务器端及中间件的具体安装步骤、安装后的系统配置。《用户使用指南》应包括软件各项功能的使用流程、操纵步骤、相应业务先容、特殊提示和留意事项等方面的内容,在需要时还应举例说明。
(七)、验收
用户验收。例如某家公司想找人订做一套人事治理软件, 从某种渠道上得知某家软件开发公司有提供这种服务,所以进行联系。
用户看了方案后,确定他们就是要做一套这样的软件,开发方就开始开发这套软件。开发方把开发出来的软件交给用户使用,其中在使用的过程中哪里使用不方便或哪里达不到要求,开发方会第一时间修改这些功能,直到用户要求的所有功能都能很完美的解决掉。 用户假如由于公司发展壮大的需要,需要将软件升级开发方会做功能拓展。
三、软件开发过程中常出现的问题与对策
(一)、正确的理解和管理需求及其变更
问题1: 从项目的需求搜集开始,业务专家搜集和提出基于整个业务的需求体系,但是在从初始的需求转化为软件特性和功能的过程中,由于业务专家和技术人员的沟通不充分或者需求描述不完善,导致技术人员对需求的理解产生曲解,从而影响该软件完成后不符合用户提出的真实需求。
问题2: 从初始的业务需求转化为软件特性的过程中,缺乏有效的跟踪和管理,导致软件功能特性与用户需求脱节。
问题3: 在项目过程中,用户提出改进的需求或者增加软件功能和特性,项目组在了解需求后,对软件架构进行调整或者重构,但是如此频繁的重复下来,需求来源不清楚,软件规格书未反应需求变化,或者接受需求但未调整项目的整体进度,导致一些混乱情况的发生。
上述1,2个问题其实都是对需求跟踪和管理机制的不完善引起的。在任何一个软件开发过程中,都充分地强调了需求管理的重要性。因此,在项目初期,相对花比较多的时间做需求的搜集和跟踪,完善业务人员和技术人员的沟通机制是很重要的。这会减少大量的由于曲解需求导致软件不符合用户需求从而返工造成的人力和物力的浪费。避免这种情况产生的一种方式是,在项目立项后,由专人或专门的团队(这些人必须是了解该项目业务领域的知识,并且有相关的技术经验) 搜集该项目的原始需求,然后和技术专家(或团队) 进行充分的沟通和讨论,保证技术专家对原始需求乃至一些用户要求的细节有完整而正确的理解,接着技术专家就会根据原始需求的文档,根据对需求的理解撰写软件规格书,在写的过程中,应该不断让业务专家一定程度的参与(例如审稿或一定程度的修订,并且参与评审) ,这样的软件规格书才能为进一步正确地进行软件分析设计提供素材和指导。
对第3个问题,用户提出的对软件进行改进可能是经常有的事情,遇到这种情况,有两种处理办法。一种办法是用户提出的改进建议在下一个发布版本中实现。但是用户往往要求能够在当前版本中进行实现。第二种办法就是认真考虑用户用户的建议,用各种方法来满足用户的需求,其中包括系统重构。在这些过程中,可能会造成一些混乱。其实归根结底还是需求的跟踪机制不完善引起的。建议采用需求和变更跟踪工具(比如rational clearquest)来对需求和变更进行全过程
的跟踪,这样在形成需求文档的时候,每个需求来源和其状态都是非常清楚的。
(二)、配置管理方面
配置管理占据了越来越重要的角色,对文档,图形,代码和各种项目数据进行分类管理,并对不同的人拥有的权限进行控制,方便技术人员对其负责的配置项进行创建,提交和修改,提高项目整体的运作效率。但是在配置管理中也存在着一些问题: 问题1: 没有制定好 文档 ,图形,代码应放的位置,配置项命名比较随意,无权限控制,造成各配置项存放混乱,寻找不易。
问题2: 培训和支持不充分,对配置管理工具的用法不了解。目前配置管理工具很多,比如大家常用的vss ,可能相对比较熟悉一些。但是诸如CVS 和ClearCase 等工具,由于软件功能非常复杂,并且对国内用户来说易用性比较差,虽然功能强大,但是没有真正派上用场。
对第一个问题,在小型项目中可能尚不明显,但是在大型项目中,由于各种文档,代码等非常多,如果不能进行正确的配置管理,很有可能被弄得一团糟。因此,在项目启动后,经过技术人员之间的讨论,在配置项的命名规定,目录结构,存放位置等达成共识,因为这些在具体使用上还和开发工具,开发语言等是密切相关的,在讨论的时候也应充分考虑这些因素,给技术人员在使用它们的时候提供最大的便利。当然,为了安全起见,大型项目中,权限的控制也是很重要的。另外,在一些情况下,如果没有权限控制,项目成员可以随意修改其它文件,这样可能会导致一些混乱情况的发生。 第二个问题,对ClearCase 等大型的配置管理工具,如果不作充分的研究和大量的培训,对软件配置和使用不当,缺乏对组织内人员的统一培训,因为配置管理工具是几乎每个人都会用到的,这样造成的问题会相当多。在ClearCase 中,比如基线的概念,可能很多人都不甚了解,还有动态视图,静态视图,集成视图,流等,这些如果不能做充分而细致的培训,技术人员会感到相当的困惑,如果支持不到位或在使用中的问题无法解决,会造成项目进度的延迟乃至停滞。所以,在对待此类问题上,培训和支持的工作是必不可少的,虽然可能会在初期浪费一些资源,但是磨刀不误砍柴功,组织内人员都掌握了强大工具的使用方法,将会极大地提高开发效率和节省时间。
(三)、缺陷管理方面
一般缺陷的生命周期必然要经历 提交-打开-解决-关闭 三个阶段,但问题是,一些公司对诸如ClearQuest 的缺陷管理工具进行了一些定制和二次开发,制定了一套严格的流程,缺陷的生命周期变得更加复杂化了。但是在执行的时候,开发人员往往仅在缺陷提交后,匆匆修正了缺陷,然后置为解决状态,等待测试人员来关闭它。因此,这些情况下,缺陷状态的很多阶段都显得有些多余。但是有人认为,在缺陷生命周期阶段多的情况下,可以让关注该缺陷的人员更准确地了解该缺陷目前的状态。怎样化解矛盾呢?事实上,给缺陷定义过多的生命周期阶段是不必要的。开发人员不愿意在解决缺陷的过程中不断的更新该缺陷的状态,另外,有些缺陷实际上很快就能解决的,过多的步骤反而降低效率,浪费时间。因此,从统计和了解缺陷数量和状态,这样的做法是好的。但是,从现实的角度来看,在实施的过程中缺乏可操作性。
四、软件开发过程管理的重点
(一)、持续集成的重要性
在大型组织中,一个产品要分为若干个部分,而且可能由于种种原因,接口可能会经常进行改动,但是涉及到的模块未做相应的变化,则在后期集成消耗的资源会相当大。因此,在产品整体构架稳定后,进行增量式的开发,并不断进行集成,会避免后期集成的风险,并且产品进行每日或实时集成(即不断进行全部产品的整体编译) 后,如果接口被改变了,则其涉及到的模块可能编译不通过,可以在初期以最快的速度进行调整,便于及早发现和解决问题。
(二)、重视文档
国内进行软件开发从最初的完全不重视文档,到后来吸取无数的经验教训后,对文档的重视又被提高到前所未有的地步。但是不少公司对应该写多少文档,怎么写文档不能把握好,因为技术人员往往对文档方面的任务是抵触的,认为不如多抽点时间专注在技术方面,写文档纯粹是浪费时间。但是文档却是必不可少的,应该怎样处理好这种矛盾呢? 事实上,这种矛盾天生就是难以化解的,因为技术人员对技术和相关情况最了解,其它人很难撰写这些文档,项目经理所需要做的是,通过斟密的项目进度安排,给技术人员留出一些时间来书写文档(在工作时间而不是在加班时间里完成,否则难免会有怨言的) ,并在规定的进度下进行评审。在Rup 和Xp 中,对文档的看法有些不一样。在RUP 中,对文档非常的重视,每个阶段都有一些工件是必须要评审和交付的,其中除了代码外,绝大部分都是文档,写起来相当费时费力。而在XP 流程中,强调的是通过代码和面对面的沟通,来加强团队的协作性,文档除了一些设计性和需要保留的资源需要撰写外,只是起到一些辅助性的作用。但不管怎样,重要和必要的文档总是要写的。让每个技术人员了解文档的重要性,合理的分配和预留写文档的时间,都是可以一定程度上化解矛盾的做法。
(三)、保持工件的一致性
在软件开发过程中,不断有新的工件产生,而且有些工件随着一些变更的发生,就需要进行更新,但工件数量太多,一则维护更新不容易,另外有些工件只是项目结束后参考性的资源,立即更新也不必要,求大求全则会一定程度上占用项目资源,耽误进度。因此,一个建设性的建议就是,对必要的工件,如 需求规格书,产品定义书,概要设计书,详细设计书..... 等工件是一定要根据项目和评审情况立即进行修订和更新的,但是,对另外一些衍生的工件,如用户指南等工件,虽然在开发流程中,可能是在每个阶段都必要写的,但是却可以在评审进行前集中进行更新一些,避免频繁修订造成的资源占用和进度延迟。
(四)、重视风险管理
建立风险管理体系,让风险意识贯穿整个流程体系,对不断出现的可能的风险进行预测,分析和讨论对策,划分风险级别,采用各种方法来降低风险变成现实后对整个项目所造成的损失。
风险管理体系是一个项目预防可能潜在风险的一个很好的保障方式,在项目初期,根据项目情况如资金,人员和可能的进度对整个项目的风险作一个预先的
评估,采用的方式可以是以项目经理为中心,集体讨论的形式来进行。在讨论结束后形成一份risk list,项目经理由此整理出一份文档,即风险管理文档。在项目进行当中,随着情况不断变化,项目经理应该不断组织一些专题会议,对风险进行讨论,并统一对策。这样在风险变成现实后,整个项目组不至于束手无策,而是可以采取一些补救的措施来把风险可能造成的损失降到最低。
(五)、重视周报和月报
在很多公司中,都要求开发人员填写周报和月报,以便在项目周会,月总结上了解每个人任务的进展情况和对人员进行考核。但是技术人员总是对此类工作不胜其烦,往往敷衍了事,填几个比较大的任务(如开发XX 系统等) ,而且一连几周都是如此,这样对了解项目进展和对人员考核的参考作用就失去了意义。 虽然技术人员比较反感写这类东西,但是还是必须要写的。应该怎样化解此类矛盾呢?实际上,这类任务主要是人的因素在发挥作用。要想达到有效性的目的,对项目成员进行一定程度的指导和培训是必要的。例如,一种比较好的方法就是,可以推荐项目成员进行daily plan一类每日计划的编写,每个人对每日工作任务进行划分和规划时间,然后在每日工作结束后对预先计划和完成情况进行对比,并在下一个工作日进行改进。坚持下去,项目成员必然在工作计划和完成情况间越来越接近,养成良好的习惯,这样不仅在保障进度上人的正面因素可以被大大增强,而且在编写周报和月报时就有所依据而不是匆匆了事,能够发挥应有的效果。
(六)、了解培训的重要性
在各类组织中,都会对员工进行一定程度的培训。在项目立项过程中,就应该考虑人员配备情况。比较理想的情况当然是项目组每个成员都对该项目的技术了如指掌,对软件开发流程比较了解,相互之间能够进行充分的沟通,能充分理解沟通对象的意图等等。但是理想情况往往不是经常存在的。由于IT 行业的人员具有一定的流动性,而且项目组的人员配备往往不是非常固定的。因此,项目经理应该充分考虑到这些因素,在项目成员比较确定后,如果有一些新手,就必然要进行一些技术,业务,开发流程等方面进行有计划的正式培训,当然,还应该指定每个老资历的项目成员带1-3个新手,这样,新手在各方面都能够迅速提高,也能促进整个项目按照预先计划高质量地完成。
五、心得体会
通过对软件工程领域中软件开发的过程和管理维护的研究学习,我对软件工程的各方面,如它的起源与发展、管理与维护等都有了进一步的认识。在计算机广泛被运用的今天,软件工程越发地体现着它的重要性,它渗透在计算机应用开发的每一个环节。但从这方面就跟以前软件工程的认识不一样,以前认为软件工程只是指软件的开发或者说是软件程序代码的编写。所以说,这次学习研究不但加深了自己对软件工程这门学科或者说是科学的了解,还使自己狭隘的视野得到了极大的开阔。更值得自己庆幸的是,通过这次的论文报告的研究和学习,我发现自己对这门产生了很大的兴趣,因此我不会就此而放弃软件工程这门学科的学习,希望可通过自己的努力,将来成为软件工领域的一份子。