软件工程案例分析

软件工程案例分析陈天洲浙江大学计算机学院软件特征（1）最根本的：软件是一种逻辑元素而不是物理元素软件是开发出的，而不是用传统的方法制造出来的软件不会被用坏时间失败概率一般产品的浴盆曲线软件特征（2）时间失败概率软件失败概率实际曲线软件失败概率理想曲线软件特征（3）工业界已经走向了标准化装配时代，然而绝大多数软件还是定制出来的。–科学计算函数库（60年代）–重用数据结构–重用组件成本结构发生了巨大的变化一次性的制造成本介质成本的可忽略性－逻辑产品不可回逆的投入维护成本的增加服务是质量要素中的重点软件危机“软件危机”是1958年在NATO会议上作为一个正式的议题被提出来软件项目不成功的例子比比即是：–1999年10月，耗资1.25亿美元的NASA的火星气象卫星失踪（公英制转换）软件危机一些数据：–大约70％的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20％到50％，90％以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高–美国政府审计局：只有不到2％的合同定购软件在发布时具有可用性——98％以上的项目都失败了软件危机一种看法–“两难境地（CrunchMode）”：处于两难境地的项目面临无法达到最初目标的威胁（费用、进度表、功能性等），而项目团队努力想跨越困境。•“我们正处于两难境地，在半夜之前是不会回家”–“死亡行军（DeathMarch）”：用来描述其进度表几乎不可能完成的项目。•“这是一个死亡行军项目，我希望自己不要参与进去”软件危机更准确的说法：慢性痛苦（chronicaffliction)SuggestedbyProf.DanielTiechrow,UniversityofMichigan尽管忍受痛苦，但是软件依然在我们这个世界起着越来越重要的作用，但是如果能够医治痛苦，那么软件业将发展得更加健康。软件危机的主要特征软件开发周期大大超过规定日期;软件开发成本严重超标;软件质量难于保证软件成功的标准用户在用用户可很容易做完要做的事失败的根本原因：开发人员写出的东西达不到用户要求(人的问题.技术问题)•规模•复杂性•生产率软件技术面临的问题Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人例:•Windows95有1000万行代码•Windows2000有5000万行代码，3000多个工程师，几百个小团队。Exchange2000和Windows2000开发人员结构“软件工程案例分析”课程与其它软件专业课的区别(1)立足于系统的整体。(2)系统分析、系统设计、测试及维护的方法实践。(3)构筑一个软件系统，实践软件开发全过程。用户分析员程序员系统分析员的地位“一个好的工业，应有一套良好的标准来配套”软件工业化生产过程应具备的特点–明确的工作步骤–详细具体的规范化文档–明确的质量评价标准软件产品的标准化软件开发过程的标准化软件工程技术的两个明显特点•强调规范化•强调文档化新世纪软件产业的趋势•网络化趋势：计算机与通信的融合趋势万维网智能网络•服务化趋势：“打包式”软件“服务式”软件•全球化趋势中国软件产业发展主要问题产业规模小、集中度低产业竞争力弱，缺乏核心技术市场秩序较为混乱，盗版严重制约软件产业发展的因素软件开发规范与标准知识产权环境知识结构公司体制项目与项目管理项目是什么–没有例行的任务–需要计划–特定的目标需要满足或者特定的产品需要生成–项目有一个预定义的时间范围–工作不仅仅是为自己，也是为他人–工作中有些特性–工作分为若干阶段–项目完成需要资源–项目是大型的或者复杂的项目管理是什么–项目管理是在项目活动中应用知识，技能，工具和技术来满足项目需求的过程，它通过初始化，计划，执行，控制和结束等活动来完成。软件项目与软件项目管理软件项目的特征–不可见–复杂性（以每一单位货币来看）–灵活性：软件去适应人或组织而不是相反–一致性软件项目管理–为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目的活动需求分析描述设计编码校验安装维护支持软件项目分类按软件类别–信息系统：与组织接口–嵌入式系统：接口是机器–操作系统是一个信息系统还是嵌入式系统？有些项目是为了生成某一产品，而某些项目的进行是为了达到某些目标。许多软件项目分为两个阶段，第一阶段是目标驱动，第二阶段再生成真正的软件产品。从系统的角度看软件项目一个项目关注于生成一个系统和/或将一个旧系统转换为一个新系统系统，子系统和环境开放和封闭系统–项目失败的一个原因是技术人员不能够开放系统和立即接受外界的变化。部分优化–例如：可能很高效，但是难于修改社会技术系统–软件项目属于此类软件项目中的人员项目影响者(stakeholders)–项目小组内部：–项目小组外部，但是在同一组织内：–项目小组和组织外部：如客户不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ross提出软件项目管理的“W理论”，该理论关注于所有各方都能从项目种获益因而对项目的成功都有兴趣。（W代表EveryoneaWinner）软件开发面临的挑战处理最终日期（deadlines）(85%)处理资源约束（83％）与任务小组有效的沟通（80％）从小组成员处得到承诺（74％）建立可测量的milestone（90％）处理变化（60％）得到团队公认的项目计划（57％）从管理层得到承诺（45％）处理冲突（42％）管理销售商和子项目承包商（38％）项目经理面临的挑战估计和计划缺少质量标准和度量缺少组织决策的指南缺少使进度可视化的技术角色定义不正确的成功准则缺少标准项目成员面临的挑战工作的不正确的描述IT的管理失误缺少应用领域的知识缺少及时的文档前续任务没有及时完成——包括设备没及时提供用户与技术员之间缺乏交流缺少质量控制软件环境的改变Deadline压力软件项目常见错误选自《快速软件开发》产品相关的错误–需求镀金：项目具有比实际需求多得多的性能–功能蔓延：项目平均会有25%的需求变更（Jones1994）–开发人员的镀金：开发人员着迷于新技术–又推又拉的交易：经理在批准项目进度顺延时又加入了新的功能–研究导向的开发软件项目常见错误（续）过程中的错误–缺乏计划–过于乐观的计划–在压力下放弃计划–缺乏足够的风险管理–承包人导致的失败–在模糊的项目前期浪费时间–前期活动不合要求过程中的错误–设计低劣–缺少质量保证措施–缺少管理控制–太早和过于频繁的集成–项目估算时遗漏必要的任务–追赶计划–鲁莽编码软件项目常见错误（续）技术相关的错误–银弹综合症:过于相信以前没有采用过的技术的宣传–过高估计了新技术或方法带来的节省量–项目中间切换工具–缺少自动的源代码控制手段软件项目常见错误（续）人员相关的错误–挫伤积极性–人员素质低–对有问题的员工失控–英雄主义–项目后期加入人员：“火上加油”–办公环境差–开发人员与客户之间发生摩擦–不现实的预期软件项目常见错误（续）–缺乏有效的高层对项目的支持–缺乏各种角色的齐心协力–缺乏用户介入–政治高于物质–充满想像：“项目组没人真正相信他们能够按给定的计划进度完成项目，但他们认为如果每个人能够努力工作，并且不出现问题，他们可能会很幸运地按时完成任务。软件项目常见的错误试分析以下故事中的项目所存在的错误：一天，一位年青人被选来“写”一个用在自动化制造设备上的程序。选择他的理由很简单：他是技术小组中唯一参加过编程培训的人。他懂得汇编语言和Fortran语言，但是他不知道软件工程，更不知道软件计划和跟踪方面的知识。软件开发过程模型选择主要内容项目实施的方法选择问题识别项目中的高风险软件开发过程模型的选择–可选择的模型–软件开发项目过程的选择软件开发方法项目实施的方法选择技术选择–技术选择将影响：•开发人员的训练需要•人员招聘•开发环境——硬件和软件•系统维护安排方法选择–方法选择将影响：•开发人员组合•实施的进度安排•开发策略选择项目实施的方法选择步骤：•分析目标驱动还是产品驱动•分析项目其他特征–面向数据还是面向控制–通用还是专用–是否需要专用工具支持的专门技术–是否有特殊的安全性要求–对软硬件有何要求识别项目中的高风险产品不确定性：系统需求理解的准确性。用户在开始时有可能对系统应该什么样都无法确定。在某些环境中，精确而有效的需求描述可能迅速变得过时。过程不确定性：在项目开始时需要选择方法或过程模型，或者一种新的工具，任何对原先采用的开发方法的变化都将引入不确定性资源不确定性：项目进行中资源的数量可能发生变化软件开发过程模型的选择开发一个软件需要选择开发策略（包括过程，方法和工具）以及通用阶段，这些策略和阶段被称为过程模型“过程”：相关联的活动过程模型的选择基于项目和应用的特性，使用的工具和方法，所需要的控制方法和交付物。软件生存周期(SoftwareLifeCycle)–软件产品或软件系统从设计、投入使用到被淘汰的全过程软件生存期的阶段划分–可行性研究与计划–需求分析–总体设计–详细设计–实现–集成测试–确认测试–使用和维护软件生存周期《计算机软件开发规范》上游下游新的国际标准定义的软件生存过程（1995ISO/IEC12207）软件生存期过程支持过程组织过程主要过程获取过程供应过程开发过程运行过程维护过程文档编制过程配置管理过程质量保证过程验证过程确认过程联合评审过程审核过程问题解决过程管理过程基础设施过程改进过程培训过程只考虑编写程序涉及整个软件生存周期扩展到软件工作的范围软件开发全部过程、活动和任务的结构框架。直观表达软件开发全过程明确规定要完成的主要活动、任务和开发策略也称为：–软件过程模型–软件生存周期模型–软件工程范型软件开发模型问题求解的一般过程问题求解的一般过程–实际问题并不能简单划为四个阶段，各个阶段会在问题的不同层次上同时并存–软件开发实际上是一个“混沌”（chaos）过程问题定义方案集成技术开发现状A.编码修正模型CodeandFixCodelikeHell(鲁莽编码)从一个大致的想法开始工作，然后经过非正规的设计、编码、调试和测试方法，最后完成工作可能有可能没有的规范发布（可能）编码修正模型好处：–成本可能很低–只需要很少的专业知识，任何写过程序的人都可以–对于一些非常小的、开发完后就会很快丢弃的软件可以采用对于规模稍大的项目，采用这种模型是很危险的B.瀑布模型（WaterfallModel)所有过程模型的祖宗项目从开始到结束按照一定的顺序执行瀑布模型是文档驱动的，各个阶段不连续也不交叉B.瀑布模型(WaterfallModel)可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段适应场合？优缺点？瀑布模型的适用场合有一个稳定产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适对一个定义得很好的版本进行维护或将一个产品移植平台，瀑布模型也特别合适。纯瀑布模型能够降低管理费用，因为你可以预先完成所有计划。对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。在质量需求高于成本需求和进度需求的时候，它尤为出色。当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。瀑布模型缺点纯瀑布模型在项目开始时，在设计工作完成前和代码写出来前，很难充分描述需求。瀑布模型最主要问题是缺乏灵活性。必须在项目开始前说明全部需求。但这恰恰是非常困难的。按照传统瀑布模型开发软件的特点阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。C.瀑布模型变种：V型模型该方法是对瀑布模型的修正，强调了验证活动可行性研究用户需求系统设计程序设计编码程序测试