软件工程案例分析

软件工程案例分析软件工程案例分析软件特征（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.编码修正模型CodeandFixCodelikeHell(鲁莽编码)从一个大致的想法开始工作，然后经过非正规的设计、编码、调试和测试方法，最后完成工作可能有可能没有的规范发布（可能）软件工程案例分析编码修正模型好处：成本可能很低只需要很少的专业知识，任何写过程序的人都可以对于一些非常小的、开发完后就会很快丢弃的软件可以采用对于规模稍大的项目，采用这种模型是很危险的软件工程案例分析B.瀑布模型（WaterfallModel)所有过程模型的祖宗项目从开始到结束按照一定的顺序执行瀑布模型是文档驱动的，各个阶段不连续也不交叉软件工程案例分析B.瀑布模型

(WaterfallModel)可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段适应场合？优缺点？软件工程案例分析瀑布模型的适用场合有一个稳定产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适对一个定义得很好的版本进行维护或将一个产品移植平台，瀑布模型也特别合适。纯瀑布模型能够降低管理费用，因为你可以预先完成所有计划。对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。在质量需求高于成本需求和进度需求的时候，它尤为出色。当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。软件工程案例分析瀑布模型缺点纯瀑布模型在项目开始时，在设计工作完成前和代码写出来前，很难充分描述需求。瀑布模型最主要问题是缺乏灵活性。必须在项目开始前说明全部需求。但这恰恰是非常困难的。软件工程案例分析按照传统瀑布模型开发软件的特点阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。软件工程案例分析C.瀑布模型变种：V型模型该方法是对瀑布模型的修正，强调了验证活动可行性研究用户需求系统设计程序设计编码程序测试系统测试用户接受评价修正修正修正修正软件工程案例分析D.瀑布模型变种：生鱼片模型把阶段重叠起来的瀑布模型起源于日本硬件开发模型（富士通—施乐）软件概念需求分析架构设计详细设计编码和调试系统测试软件工程案例分析生鱼片模型的特点和缺点传统的瀑布模型强调阶段之间最小重叠，而生鱼片模型强调大幅度重叠，即在需求分析完成之前就可以进行架构设计和部分详细设计纯瀑布模型强调在任意两个阶段交接时，文档从一个团队交给另一个完全隔离的团队，但是如果一个团队完成各个阶段任务时，可以没有那么多文档。问题：缺点是什么？生鱼片模型因为阶段重叠，因而里程碑不明确，很难有效地进行过程跟踪和控制。软件工程案例分析E.瀑布模型变种：具有子项目的瀑布模型纯瀑布模型的问题：必须完成全部架构设计后才能进行详细设计，但是，整个系统中有些部分可能有些特殊性，可以有自己的步骤，即将这些部分划分为子项目。问题：该模型有何问题？这种方法的主要风险是相关性无法预料。软件工程案例分析F.瀑布模型变种：能够降低风险的瀑布模型纯瀑布模型：要求在开始架构设计前，必须将用户的所有需求都搞清楚，但是实际中是很困难的。可降低风险的瀑布模型是在顶端，即需求分析和架构设计阶段引入螺旋以便降低风险。螺旋中，先开发一个用户界面原型，采用系统情节串联图版（systemstoryboarding）引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。软件工程案例分析G.快速原型模型（RapidPrototypeModel）建造/修改原型用户测试运行原型

听取用户意见原型范型软件工程案例分析原型模型需求分析原型开发最终系统设计原型评价最终系统实现用户反馈软件工程案例分析分析定义系统需求生成原型系统设计程序设计编码测试运行和维护原型化含原型化的软件生存期采用原型模型的软件生存周期软件工程案例分析原型法的分类原型是项目系统中的一个方面或者多个方面的工作模型。抛弃型原型：用于试验某些概念，试验完系统将无用处进化型原型：原型系统不断被开发和被修正，最终它变为一个真正的系统。软件工程案例分析原型法的优点从实践中学习(Learningbydoing)改善的沟通改善的用户参与使部分已知的需求清晰化展示描述的一致性和完整性可能可以减少文档减少了维护成本特征约束（利用工具构造原型可以将某些特性落到实处，而非在纸上写的那样容易失误）试验是否能产生期待的结果软件工程案例分析原型法的缺点用户有时误解了原型的角色，例如他们可能误解原形应该和真实系统一样可靠缺少项目标准，进化原型法有点像编码修正缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制额外的花费：研究结果表明构造一个原型可能需要10%额外花费运行效率可能会受影响原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。软件工程案例分析从另外的角度看待原型从中学到什么？学生经常会做一些软件作业，这些作业被称为原型，问题：这些原型和软件系统原型是否相同？但是作为一个原型必须：描述他们希望从中学到的东西，规划原型评价的方法，报告从原型中真正学到的内容。在不同的阶段，原型具有不同的作用。原型起作用的程度实物模型（Mock-ups）仿真交互部分模型：水平，垂直（某些特性构造详细原型）软件工程案例分析H.演化模型增量模型(IncrementalModel)螺旋模型(SprialModel)软件工程案例分析H.1增量模型(递增模型)先完成一个系统子集的开发，再按同样的开发步骤增加功能(系统子集),如此递增下去直至满足全部系统需求。系统的总体设计在初始子集设计阶段就应作出设想。软件工程案例分析分析设计编码测试分析设计编码测试分析设计编码测试分析设计编码测试增量1增量2增量3增量n

增量1交付客户

增量2交付客户

增量3交付客户

增量n交付客户日历时间…..H.1增量模型软件工程案例分析风险分析工程实施用户通信用户评估产品维护项目产品增强项目新产品开发项目概念开发项目计划建造及发布H.2螺旋模型软件工程案例分析螺旋模型的优缺点优势：随着迭代的增加（成本的增加），风险程度随之降低缺陷：比较复杂，需要责任心，专注和管理方面的知识。软件工程案例分析H.3

WIN-WIN螺旋模型在螺旋模型中，通过与客户的通信获取客户的需求，实际上，客户的需求与最终确定的需求是不一致的，客户与开发者之间需要进行协商，最终达到双赢的局面。Boehm提出的WIN-WIN螺旋模型中，客户与开发者之间需要识别系统或子系统的关键stakeholders确定涉及者的“winconditions”对这些条件进行协商获得互赢条件软件工程案例分析WIN-WIN螺旋模型WIN-WIN螺旋模型还引入了三个过程的里程碑，被称为定位点（Anchorpoints）生命周期目标（lifecycleobjectives）:定义每个主要活动的目标生命周期体系结构（lifecyclearchitecture）:定义系统和软件的体系结构目标初步操作能力（initialoperationalcapability）:定义软件安装，发布目标。软件工程案例分析I.并行开发模型并行开发模型（concurrentdevelopmentmodel）又被称为并行工程（concurrentengineering）（ByDavisandSitaram）软件开发中的所有活动可能同时并存，但是都处于不同状态中并行开发模型定义了活动从一个状态转化为另一个状态的事件软件工程案例分析并行开发模型NoneAwaitingchangesUnderrevisionUnderreviewBaselinedDoneUnderdevelopmentAnalysisactivity软件工程案例分析并行开发模型并行过程模型经常被用于开发C/S系统。该系统的活动可以被分为系统维和部件维。系统维:包含设计，装配和使用三个活动部件维:包含设计和实现两个活动并发性表现在两个方面：系统和部件的活动同时发生各个部件可以并行设计和开发软件工程案例分析“基于版本发布”的特点V1.0功能时间V2.0V1.1软件工程案例分析Trade-offDecision(折中决定)√√√

可靠性发布日期

功能

最优约束范围可接受正确的Trade-off

决定软件工程案例分析J.面向对象模型喷泉模型(FountainModel)可重用部件组装模型(构件集成模型ComponentIntegrationModel)软件工程案例分析分析设计实现测试集成演化J.1喷泉模型软件工程案例分析喷泉模型特点

主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征软件工程案例分析J.2可重用部件组装模型(构件集成模型)使用重用技术的软件工程模型构件(components)：可重用的软件成份可复用性（Reusability）集成化软件开发环境（ISEE）软件工程案例分析用户通信计划产品开发及发布用户评估风险分析标志候选构件查找构件若存在则提取构件若不存在则构造构件进行下一次迭代将新构件存入库中可重用部件组装模型软件工程案例分析基于构件的软件工程(CBSE)过程模型

构件开发分析设计编程测试领域分析系统测试构件提交领域专家经验现有系统资料领域构件需求构件/构架库领域构架领域构件系统开发系统专用构件应用系统构件生产线领域构架领域构件问题域用户需求系统生产线

系统组装分析设计编程构架细化专

用

构件

开

发分析设计编程测试软件工程案例分析

软件生产线应用构件提取车间构件生产车间标准规范与质量保证1基础构件，2功能构件3接口构件，4用户界面构件

应用构件库

构件库组装车间领域

1领域

2应用系统...1234软件工程案例分析

转换模型(TransformationalModel)

净室模型(CleanroomModel)K.形式化方法模型软件工程案例分析K.1转换模型形式化规格说明与需求比较后修正形式化开发记录变换n变换2变换1测试系统需求目标系统软件工程案例分析形式化规格语言及其变换技术基于模型的规格说明及其变换技术基于代数结构及其变换技术基于时序逻辑的规格说明和验证技术基于可视形式化技术软件工程案例分析K.2净室模型(形式化的增量开发模型)基于思想：力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的制作。三个关键技术置于统计过程控制之下的增量开发基于函数的规范、设计、验证统计测试和软件认证软件工程案例分析

净室模型盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量#1盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量#2盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量#1............软件工程案例分析L.阶段交付阶段交付持续地在确定的阶段向用户展示软件。和渐进原型不同，在阶段交付的时候，你明确地知道下一步要完成什么工作。阶段交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。软件工程案例分析阶段交付软件概念需求分析构架设计阶段1：详细设计，编码，调试，……阶段2：详细设计，编码，调试，……软件工程案例分析阶段交付的优缺点优点：项目结束交付全部成果前，分阶段将有用的功能交付给用户。缺点：如果管理层面和技术层面上缺乏仔细规划，工作就无法进行。使用阶段交付的注意点：必须确定每一阶段的交付是对用户有用的必须确保考虑了不同产品组成部分的技术依赖关系软件工程案例分析M.面向进度的设计类似于阶段交付，但是面向进度的设计生命周期模型在开始的时候不必知道究竟能达到何目标，但是要确保最后的期限。该模型的关键是要按优先级别划分系统特性并规划开发阶段，保证前面的阶段具有高优先级的特性，低特性具有低优先级别。是否采用这种方法决定于你是否对系统目标具有足够的信心，如果有信心，则没必要采用这种方法。软件工程案例分析N.渐进交付渐进交付是一种跨越了渐进原型和阶段交付两种模型的过程模型。基本过程：开发一个产品的版本，展示给用户，根据反馈改善产品。如果计划满足用户的绝大部分需求，渐进交付与渐进原型差不多，如果计划满足少量的需求，渐进交付就和阶段交付差不多。渐进原型，强调的是系统看得见的样子，再回来堵漏洞，渐进交付中，最初的重点是系统核心和底层系统功能。软件工程案例分析渐进交付软件概念需求分析构架和内核设计开发一个版本并入用户反馈交付该版本开发一个版本交付最终版本软件工程案例分析确定渐进交付目标的一种方法价值成本比软件工程案例分析软件开发方法

软件开发过程遵循的方法和步骤几种典型的开发方法：模块化方法（modularmethod）结构化方法面向数据结构方法面向对象方法软件工程案例分析软件开发需要项目管理软件开发是个系统工程需要资源的协调软件开发过程的选择与项目的协调紧密相关软件工程案例分析项目管理、工具、技术、流程与组织软件工程案例分析主要内容回顾软件项目实施的方法选择软件开发过程模型的选择软件开发方法项目管理项目管理基本概念实施项目管理的工具与技术项目管理的流程项目管理的流程特征（产品／项目／软件项目）项目管理组织结构软件项目管理的流程软件工程案例分析•建立不现实的最终期限•不断变更的客户需求•对努力的低估•可预见和不可预见的风险•技术的困难性•项目成员的沟通不畅通•项目管理不利为什么项目会失败?软件工程案例分析People—项目成功的最重要因素Product—建立的软件Process—框架活动集合和得到工作的软件工程任务Project—实现产品所需要的所有工作The4P’s软件工程案例分析软件梯队被解决问题的难易程度代码和功能点形成的结果程序的规模梯队的生存周期问题被模块化的程度被建立系统所需要的质量和可靠性发布日期的严格性项目的社会化程度（沟通程度）选择软件项目梯队结构所要考虑的因素

...软件工程案例分析建立范围—陈述性描述，约束问题表达分解—建立功能性分割问题定义软件工程案例分析发现项目的关键系统为什么被开发?做什么?什么时候?谁对某一功能负责?他们组织定位在哪里?从技术和管理上工作怎样被做?多少资源需要(e.g.,人,软件,工具,数据库)?BarryBoehm软件工程案例分析形式的风险分析经验成本和进度估算基于度量的项目管理价值跟踪（Earnedvaluetracking）质量目标下的跟踪人要意识到项目管理关键实践软件工程案例分析什么是项目项目是什么没有例行的任务需要计划特定的目标需要满足或者特定的产品需要生成项目有一个预定义的时间范围工作不仅仅是为自己，也是为他人工作中有些特性工作分为若干阶段项目完成需要资源项目是大型的或者复杂的软件工程案例分析什么是项目管理项目管理是在项目活动中应用知识，技能，工具和技术来满足项目需求的过程，它通过初始化，计划，执行，控制和结束等活动来完成。软件工程案例分析项目生命周期项目生命周期定义一个项目的开始与结束。项目生命周期定义的阶段顺序通常包括某些技术转移或“握手”(handoff)，如从需求到设计，从构造到运行，但是在风险允许下，也可以下一阶段提前进行，这种重叠的阶段被称为快速跟踪(fasttracking)。项目生命周期通常定义：各个阶段需要完成的技术工作；每个阶段需要涉及的人。软件工程案例分析项目生命周期绝大多数项目生命周期有一些共同的特点，如成本和人员消耗的变化曲线。项目生命周期与产品生命周期是不同的。软件工程案例分析项目中的人员项目影响者(stakeholders)项目小组内部：项目小组外部，但是在同一组织内：项目小组和组织外部：如客户不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ross提出软件项目管理的“W理论”，该理论关注于所有各方都能从项目种获益因而对项目的成功都有兴趣。（W代表EveryoneaWinner）软件工程案例分析软件项目管理定义软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件工程案例分析软件项目包含的活动需求分析描述设计编码校验安装维护支持软件工程案例分析应用项目管理方法开展软件开发项目的可行性分析需求开发与需求管理软件项目工作量估算软件项目计划与资源分配软件项目监控风险管理软件质量管理与软件开发规范软件项目中的人员管理软件配置管理软件工程案例分析

项目可行性分析与评估软件工程案例分析内容安排可行性分析的内容项目范围管理技术评估经济评估风险评估可行性报告项目建议书需求建议书软件工程案例分析可行性分析目的“说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性；评述为合理地达到开发目标可能选择的各种方案”。GPS监控系统的投资失误做什么？近期目标？人员配备，怎样整合需求调研问题开发费用问题风险规避顶新国际集团：在投资新产品时1400万：全国28个城镇居民消费习惯调查700万：委托28个城镇社会科学院进行全国七大区域总体经济投资环境的分析任务了解客户要求及现实环境，从技术、经济和社会因素研究并论证软件项目可行性，编写可行性报告，制定初步项目开发计划“什么都不做”永远是一个可考虑的方案软件工程案例分析可行性分析的内容项目范围策略评估技术评估经济评估风险评估软件工程案例分析项目范围管理内容保证项目包括并且仅仅包括需要包括的内容。它由以下步骤组成：初始化：对项目或阶段授权范围计划：开发一个作为将来项目决策基础的书面的范围声明范围定义：将项目交付物细分为更小的，更易管理的元件范围校验：形式化项目范围的接受条件范围变更控制：控制项目范围的变更软件工程案例分析范围的含义“范围”包含产品范围和项目范围产品范围：产品或服务的特点和功能项目范围：为了生产具有特定特点和功能的产品所需要的工作软件工程案例分析软件范围软件项目计划的第一项任务就是确定软件的工作范围，即软件的用途及对软件的要求。因此，应从管理角度和技术角度出发，确定明确的可理解的软件项目范围。软件工程案例分析软件范围的叙述明确给出定量的数据（例如，同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等）指明约束条件和/或限制（例如，产品成本限制了存储的容量）叙述某些质量因素（例如，给出的算法是否容易理解、是否使用Ada语言等）软件工程案例分析软件范围的估计软件范围包括功能、性能、限制、接口和可靠性。功能：软件功能评价，并进行适当细化功能分解，满足未来成本和进度估算要求性能包括处理和响应时间的需求。约束条件：外部硬件、可用存储或其他现有系统对软件限制。功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。如果功能保持相同而性能可变，则开发软件所需的工作量和成本将有显著的差异。软件工程案例分析价值驱动的电子商务分析方法业务流程模型业务概念模型策略规划级结构级实施级电子商务技术层业务策略的概念结构概念建模协商建模价值驱动流程建模软件工程案例分析资源价值配置伙伴网络价值链构架信息策略发布渠道客户信任客户关系企业能力价值建议目标客户产品与服务创新Revenue

Model价值结构收入模型收益/损失资产、财务电子商务概念模型软件工程案例分析初始化初始化(Initiation)正式授权一个新项目或者决定一个已有项目继续进行下一阶段项目是由于下面一些原因产生的：市场需要（新性能汽车）业务需要（培训中心新课程设计）客户需要（客户定制产品）技术进步（如计算机技术进步）法规需要（污染处理）社会需要（政府水处理系统）软件工程案例分析初始化输入：产品描述策略计划：企业的战略计划项目选择准则（经济回报，市场回报，公共形象）历史信息：以前项目的结果和性能工具和技术项目选择方法专家判断输出：项目章程（授权项目的正式文档，包括业务需求，产品描述）项目经理指派约束假设软件工程案例分析范围计划范围计划是将生成产品的项目工作（项目范围）逐步细化的过程。输入：产品描述项目章程约束假设工具和技术产品分析利益成本分析(Benefit/CostAnalysis)备选方案（brainstormingorlateralthinking)专家判断软件工程案例分析范围计划输出范围声明（ScopeStatement)，包括项目理由：ProjectJustification(Businessneed)项目产品:概述项目交付物：projectdeliverables项目目标:判断项目是否成功的定量准则支持细节（包括假设和约束）范围管理计划软件工程案例分析范围定义范围定义涉及到将主要的项目交付物细分以：提高成本，周期和资源估计的准确性定义性能度量和控制的基线便于清晰定义责任分配范围定义正确与否将影响项目的节奏，进度，生产率和项目人员的士气。软件工程案例分析范围定义输入范围声明约束假设其它计划输出历史信息工具和技术WBS(Workbreakdownstructure)模板分解技术软件工程案例分析策略评估中的模块管理模块管理（Programmmanagement)“模块是一组协调管理的项目，通过将项目组成模块，将获得比单个管理项目更大的效益。”——D.C.Ferns有效的模块管理需要有一个模块目标，项目必须根据模块目标来选择在大的组织中，将可能有模块管理的机构，例如模块主管或者模块经理即使没有专门的组织来管理模块，项目的选择也需要根据组织的整个业务目标来评价软件工程案例分析策略评估的内容目标：提出的系统对组织目标具有怎样的贡献？例如它是否能够增加市场份额？IS计划：提出的系统如何与IS计划相适应？它将替换或者与那些系统接口？它与将来开发的系统有何交互关系？组织结构：新系统对目前的部门和组织结构有何影响？例如一个新的订单处理系统是否与目前的销售与库存控制的功能相重叠？MIS:系统将在组织的何层次上提供何种信息？它将以何种方式对现存管理信息系统进行补充何提高？人员：系统将以何种方式影响人力水平何现存雇员的技术？它对组织整个人员开发策略有何影响？情形：系统将使客户对组织的态度有何变化？是否采用一个自动化的系统将与提供友好的服务相冲突？软件工程案例分析策略评估中的业务管理业务管理选定的项目将成为业务的一部分，项目将对资源产生竞争竞争中对业务的调整是必要的软件工程案例分析技术评估技术的成熟程度实验室技术经过中试的技术已经工业化应用的技术市场需求显在潜在：转化为显在的条件竞争态势：与竞争技术相比，所采用技术的优势及缺陷技术转换成本支撑体系与条件：原料、销售网络、用户体系、政策技术发展趋势及所采用技术的发展前景软件工程案例分析技术方案选择要考虑的制约条件需求制约：现存的需求结构及需求结构可能的变化资源制约：资金、人力资源、自然资源、其它要素环境制约：经济技术环境、社会文化环境、自然环境选择原则经济性原则：以最小的投入取得最好的效果发展原则：发展的前景及适应发展的能力兼容性原则：与原有经济、技术、环境、社会的兼容性相关效果原则：相关的经济、技术、环境、社会效果选择视角技术先进性技术适用性软件工程案例分析经济分析开发所需要的成本和系统运行所需要的成本与得到的效益的比较识别出项目进行中所需要的所有成本和效益并对其进行聚集将成本和效益用单元来表达成本分为开发成本安装成本运行成本软件工程案例分析经济分析效益直接效益可见的间接效益不可见的效益软件工程案例分析经济分析净收益（NetProfit):项目的净收益是在项目生命周期内总的收入与总的成本的差。没有考虑时间因素回收期限（PaybackPeriod）：将初始投资收回的期限忽略了整个项目的盈利空间软件工程案例分析经济分析投资回报(Returnoninvestment):也被称为回报率(accountingrateofreturn)(ARR)ROI=（平均年收益/总投资）×100例如项目1：ROI=10,000/100,000*100=10%缺点：没有考虑时间因素该回报率易与银行利率混淆软件工程案例分析经济分析净现率(NetPresentValue)考虑了时间因素对将来的收益打一个折扣“拿在手里的钱才是真正的钱”如果假定年折扣率为10％，那么明年的100元等于现在手中的91元，后年的100元等于现在的83元目前值＝t年的值/(1+r)t软件工程案例分析系统开发和每年运行费用举例1.系统开发费用（一次）人员：.2名系统分析员(450小时/名,45美元/小时)$40,500.5名系统开发人员(275小时/名,36美元/小时)$49,500.1名数据通讯专家(60小时/名,42美元/小时)$2,400.1名数据库管理员(30小时/名,42美元/小时)$1,260.2名技术写作者(120小时/名,25美元/小时)$6,000.1名秘书(160小时/名,15美元/小时)$2,400.2名在转换期间数据输入人员$49,500(40小时/名,12美元/小时)软件工程案例分析系统开发和每年运行费用举例培训：三天的开发人员内部培训课程$7,00030个用户，三天的内部培训课程$10,000物资：复印$500磁盘、纸张等消耗品$650软件工程案例分析系统开发和每年运行费用举例购买硬件、软件：20台工作站Windows软件$1,00020台工作站内存升级$8,000网络软件$17,50020台工作站办公软件产品$20,000系统开发总费用$161,670软件工程案例分析系统开发和每年运行费用举例2.年运行费用（每年）人员：维护程序员/分析员(250小时/年,42美元/小时)$10,500网络管理员(300小时/年,50美元/小时)$15,000购买硬件、软件升级：硬件$5,000软件$6,000物资和杂项$3,500每年总运行费用$40,000软件工程案例分析可行性研究的步骤

(1)复查确认系统目标、规模

(2)研究正使用系统工作流程

(3)导出新系统高层逻辑模型

(4)重新定义问题

(5)导出和评价供选择的方案

(6)推荐可行的方案

(7)草拟开发计划

(8)编写可行性研究报告，送审软件工程案例分析可行性分析可行性分析报告的格式软件工程案例分析可行性研究报告的编写提示

GB8567-88《计算机软件产品开发文件编制指南》1引言

1.1编写目的

1.2背景

1.3定义

1.4参考资料软件工程案例分析可行性研究报告的编写提示2可行性研究的前提

2.1要求

2.2目标

2.3条件、假定和限制

2.4进行可行性研究的方法

2.5评价尺度软件工程案例分析可行性研究报告的编写提示3对现有系统的分析

3.1数据流程和处理流程

3.2工作负荷

3.3费用开支

3.4人员

3.5设备

3.6局限性软件工程案例分析可行性研究报告的编写提示4所建议的系统

4.1对所建议系统的说明

4.2数据流程和处理流程

4.3改进之处

4.4影响

4.5局限性

4.6技术条件方面的可行性软件工程案例分析可行性研究报告的编写提示5可选择的其它系统方案

5.1可选择的其它系统15.2可选择的其它系统2......软件工程案例分析可行性研究报告的编写提示6投资及收益分析

6.1支出

6.2收益

6.3收益/投资比

6.4投资回收周期

6.5敏感性分析软件工程案例分析可行性研究报告的编写提示7社会条件方面的可行性

7.1法律方面的可行性

7.2使用方面的可行性软件工程案例分析项目建议书起源：组织内部认识到需要利用信息技术改进目前的业务运行改进目前的信息系统开发新的产品目的：使管理层能够作出项目决策软件工程案例分析准备招标书目的：从客户的角度全面地、详细的论述，为了达成确定的需求应需要作何准备一份招标书应当是全面的，能提供足够详细的信息，以使承约商或项目团队能针对顾客的需要相应地准备一份最优的招标书软件工程案例分析招标书招标书中需要提供工作表述招标书中必须包括客户要求，此要求中规定了规格和特征招标书应当说明客户期望承约商或项目团队提供什么样的交付物招标书中应当列举客户供应条款招标书中可以表述出客户对需要的确认招标书中可以提到客户想要用的合同类型软件工程案例分析招标书表述出客户想用的付款方式表述出项目完成所需的进度计划提供有关承约商申请书的格式和内容安排支持客户希望潜在承约商提交申请书的最后期限可能包括评价标准可能会指出客户所拥有的可用于此项目的资金量。软件工程案例分析案例分析宁波市第五次全国人口普查办公室的宁波市人口地理信息系统地理空间分析、人口统计与分析一体化宁波人口普查、日常管理、统计与分析的数字化、可视化人口信息存储、管理与分析，建立规范化的空间地理信息与人口信息统一管理、分析、统计、发布、录入、更新与维护对空间数据和人口数据的快速采集、建库、维护、查询、管理、显示、输出、统计分析、共享与发布功能软件工程案例分析案例分析性能要求满足宁波全部市县人口的数据存储不同县区都可以调用数据，操作数据保证调查高峰操作响应的人机交互保证数据统计的响应时间软件工程案例分析案例分析限制要求Windows平台客户端服务器选用Intel服务器存储RAID，保证存储安全与DOMINO办公系统可以实现接口，可以抽取数据报表软件工程案例分析需求开发与需求管理软件工程案例分析主要内容从一个故事看软件开发的实际问题需求管理的困难性管理需求的目的软件需求特性需求工程如何获取需求需求规格说明需求管理工具软件工程案例分析软件开发面临的实际问题软件工程案例分析软件开发面临的实际问题软件工程案例分析软件开发面临的实际问题软件工程案例分析为什么？？？需求？？？软件工程案例分析什么是需求需求为用户解决问题或达到目标所需的条件或权能系统或系统部件要满足合同、标准、规范和其它正式规定文档所需具有的条件或权能一种反映上述条件或权能的文档说明软件工程案例分析举例系统必须提供基于PPPoE协议的用户接入模式产品应当提供机架式安装，并提供两个千兆以太网端口系统使用的用户是信息中心和网络管理员系统在运行时必须提供自动数据备份功能软件工程案例分析简要的解释需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整文档，该文档详细地说明了产品“必须或应当”做什么。如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。软件工程案例分析需求管理的困难性需求不总是显而易见的，而且它可来自各个方面。需求并不总是能容易用文字明白无误地表达。存在不同种类的需求，其详细程度各不相同。如果不加以控制，需求的数量将难以管理。需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。需求有唯一的特征或特征值。例如，它们的重要性和容易满足的程度都各不相同。需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。需求会变更。软件工程案例分析为什么要管理需求为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率需求管理带来其他好处StandishGroup的CHAOS报告进一步证实了与成功项目关系最大的因素是良好的需求管理。软件工程案例分析什么是软件需求从软件开发过程看软件需求开发软件工程案例分析从软件发展周期看软件开发过程时期年代阶段涉及注重主要使用语言标准模型初期50-60程序设计点编程技巧ALGOLFORTRANCOBOLBASIC

中期70-80软件开发线结构化模块化PASCALGB8566软件开发规范瀑布原型现代90-软件过程面过程能力C,C++JAVAVB、VCISO/IEC12207软件生存期过程ISO9000螺旋CMM软件工程案例分析计算机系统

人员硬件软件数据传输机构执行机构（剧作家、导演）（舞台剧本演员道具）软件开发全过程软件工程案例分析活动－任务

⑴系统需求分析⑵系统结构设计⑶软件需求分析 建立软件需求 评价软件需求 联合评审 ⑷软件结构设计 ⑸软件详细设计 ⑹软件编码和测试 ⑺软件集成⑻软件鉴定测试⑼系统集成⑽系统鉴定测试⑾软件安装⑿软件验收支持

软件开发过程软件工程案例分析⑴

定义（IEEE-STD-610）用户为解决某个问题、或为实现某一目标，要求软件必须满足的条件或能力。⑵软件需求的三个层次业务需求

用户需求

功能需求和非功能需求

软件需求的层次性软件工程案例分析软件系统需求(1)系统需求分配软件工程组硬件系统需求(2)其它成分系统需求(n)软件需求客户最终用户系统工程组系统需求分配软件工程案例分析业务需求业务说明使用实例用户需求功能需求约束条件非功能需求软件需求规格说明软件需求的层次软件工程案例分析需求的层次性业务需求项目视图与范围文档用户需求质量属性系统需求功能需求约束条件其它非功能需求UseCase文档软件需求规格说明软件工程案例分析非功能需求

过程需求：交付需求，实现需求，遵循的标准性能需求：速度，容量，可靠性外部需求：互操作性，伦理性，机密性，安全性，使用要求

非功能软件需求软件工程案例分析系统需求ACCS应能使汽车保持在预期车速的2KMH范围内行驶分配给硬件的需求硬件应能使车速在规定的精确度1.5KMH范围内分配给软件的需求软件应能在车速超出预期车速0.5KMH时给硬件加/减速命令软件需求软件应能：读入当前车速值计算当前车速与预期车速之差若差值0.5KMH给出加/减速命令汽车限速系统ACCS的需求分配分配需求的实例软件工程案例分析产生不合格需求的原因产生不合格的需求说明的原因无足够的用户参与，原因感到与用户合作不如编写代码有意思因为开发人员觉得已经明白用户的需求了用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划软件工程案例分析优秀需求具有的特性正确性无二义性必要性完整性，完备性可行性，可实现性可验证性划分优先级软件工程案例分析制定目标的原则SMARTSpecial,Measure,Agree,Realistic,Time特指,可量测,一致认同感,现实的,实在的,时间软件工程案例分析需求工程什么是需求工程把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构图软件工程案例分析1．需求工程＝需求开发＋需求管理

获取需求分析需求定义需求验证需求需求变更控制需求跟踪需求状态跟踪需求文档版本控制需求开发需求管理需求工程需求工程的构成软件工程案例分析需求开发过程需求开发：通过调查与分析，获取用户需求并定义产品需求。需求调查：通过各种途径获取用户需求信息（原始材料），产生《用户需求说明书》。需求分析：对各种需求信息进行分析，消除错误，刻画细节。常见分析方法“问答分析法”和“建模分析法”两类。需求定义：根据需求调查和需求分析结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。软件工程案例分析需求管理过程需求管理：在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求确认：开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪：通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制：依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。软件工程案例分析用户/系统市场管理者初始需求变更的需求获取,分析,定义,验证需求控制需求变更需求规格说明项目环境需求开发需求管理软件工程案例分析（1）获取需求确定目标用户、服务对象明确用户代表用户培训了解实际业务和业务需求（2）分析需求分清功能需求、性能需求、使用需求……必要性可行性需求开发软件工程案例分析（3）定义需求编写软件需求规格说明（SRS）作用要求：完整、正确、可行、无歧意、可验证形式：图、表、文字（4）验证需求联合评审

需求开发软件工程案例分析需求获取需求的来源与有潜力用户探讨目前或竞争产品的描述文档系统需求规格说明当前系统问题报告和增强要求市场调查和用户问卷调查观察正在工作的用户用户任务内容分析软件工程案例分析3.2.2需求获取的内容

1.用户需求分类

(1)功能性需求:

定义了系统做什么（描述系统必须支持的功能和过程）

(2)非功能性需求（技术需求）:

定义了系统工作时的特性（描述操作环境和性能目标）软件工程案例分析2.两类需求包括的内容(1)功能(2)性能(3)环境(4)界面(5)用户或人的因素(6)文档(7)数据(8)资源(9)安全保密(10)软件成本消耗与开发进度(11)质量保证软件工程案例分析(1)功能需求

系统做什么？系统何时做什么？系统何时及如何修改或升级？软件工程案例分析(2)性能需求

软件开发的技术性指标例如：存储容量限制执行速度、相应时间吞吐量软件工程案例分析(3)环境需求

硬件设备：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等软件：操作系统网络数据库软件工程案例分析(4)界面需求

有来自其它系统的输入吗？到自其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？软件工程案例分析(5)用户或人的因素

用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？软件工程案例分析(6)文档需求

需哪些文档？文档针对哪些读者？软件工程案例分析(7)数据需求

输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？软件工程案例分析(8)资源需求

软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等。软件工程案例分析(9)安全保密要求

需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作系统隔离？系统备份要求？软件工程案例分析(10)软件成本消耗与开发进度需求开发有规定的时间表吗？软硬件投资有无限制？软件工程案例分析(11)质量保证

系统的可靠性要求？系统必须监测和隔离错误吗？规定系统平均出错时间？出错后，重启系统允许的时间？系统变化如何反映到设计中？维护是否包括对系统的改进？系统的可移植性？软件工程案例分析需求开发实例对用户有效管理，防止不合法占用网络资源造成收入流失协助运营公司或部门管理网络和用户向用户提供有效接入服务，满足用户多元化需求政府部门（信产部、公安部等）对运营商及其管理的要求以城市为基本管理单位，分层分级管理，全程全网管理和运营以汇聚点为单位逐步部署（切换）用户使用方便（“首次认证”方案）－－宽带接入系统目标软件工程案例分析构架需求分配系统需求宽带接入（交换式以太网构造

）身份认证，计费策略，网络安全，访问监测，接入服务，用户管理分配给硬件的需求交换机，PPPoE接入，访问控制设备，认证与安全服务器，网络构架，流量控制分配给软件的需求端口隔离,用户信息（ID-Addr-Mac-IP）,身份认证（ID-Passwd）,访问信息（IP-Sock-Time-Len），流量，接入软件需求软件应能：通过目录服务进行用户管理，实现PPPoE接入与管理，具有安全包过滤，提供DHCP分配，营帐，实时策略软件工程案例分析宽带接入控制系统适合于宽带网络环境（交换式以太网构造）用于用户接入网络的访问控制，包括：用户身份认证网络接入服务（DHCP、DNS、ARP……）不合法用户和访问监测与控制网络安全体系支撑多样化计费策略支持（按时、预付费……）用户基本信息管理（ID、Pswd、MAC……）软件工程案例分析硬件技术需求分析交换机交换机AC用户用户用户软件工程案例分析用户管理机制用户端口隔离用户基本信息（ID-Addr-Mac-IP）用户身份认证（ID-Password）用户访问信息（IP-Sock-Time-Len）IDIPAddrMacTimeSock软件工程案例分析体系构架总部区域城市社区收费管理用户信息用户接入服务系统社区网络管理系统用户信息用户信息客户服务收费管理计费管理开户交费投诉上网欠费补交销户计费管理计费管理客户服务网络管理网络管理网络管理收费管理软件工程案例分析平台支撑总部区域和城市汇聚和社区客户管理系统计费管理系统流量监测系统网络管理系统接入控制系统ERP软件工程案例分析系统的协作关系计费管理系统客户管理系统接入控制系统网络管理系统流量监测系统账单收费计时用户流量监测开关软件工程案例分析主要功能用户认证及其管理（首次认证）接入服务（DHCP、MAC-IP捆绑，ID-Sock）不合法用户和访问操作的监测与控制多样化计费操作和管理按时间计费（以后扩展按流量、带宽计费）预付费或记账式计费支持全网漫游与客服管理系统、公安安全监测系统接口软件工程案例分析部署结构城市中心ACBackupAC汇聚点4000or2000AC汇聚点4000or2000社区接入网社区接入网社区接入网社区接入网软件工程案例分析环境与要求基于Web的构架认证WindowsClientUnixServer响应时间软件工程案例分析用户分类－需求开发中的关键用户及其分类各种用户对系统具用不同要求，没有经验用户－－是否简单易用高级用户－－产品易用性和高效需要对用户分类，每一用户类有自己一系列功能和非功能要求在项目中，要尽早为产品确定并描述不同的用户类，这样就能从每一个重要的用户类代表中获取不同需求。软件工程案例分析用户“用户”（user）是泛称“客户”（customer）、“最终用户”（theenduser）和“间接用户”（关系人）。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。客户是掏钱买软件的人，所以他是“上帝”

“先有鸡还是先有蛋”哲学如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。“现代营销学之父”菲利普•科特勒客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。与客户打交道的主要目的是：一是获取需求，二是签合同。软件工程案例分析用户(续)即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。项目规模大，开发方与最终用户来往多。从最终用户获取详细需求，请最终用户试验软件，对最终用户进行培训等。重视“间接用户”，千万别“大意失荆州”

间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大影响。财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则“非法经营”。

软件工程案例分析寻找用户代表寻找用户代表每一个用户类必须有一名和几名用户代表参与软件开发项目周期对于直接面向客户的项目，用户代表相对容易找到，对于商品化软件,用户代表（产品代表）比较难找到。产品代表必须是真正用户，而不是用户代理人，如主办者，产品客户，市场人员必须给产品代表足够尊重，否则将挫伤他们积极性软件工程案例分析产品代表者如何寻求产品代表者？与大公司建立联系通过产品打折或者免费使用方式来吸引产品代表者要注意技术泄漏问题真正聘请具有丰富经验的合适产品代表者软件工程案例分析“谁说了算”“谁说了算？”问题同一用户类：个别用户需求不一致，由产品代表者作出决策。（实质是授权给产品代表者，由其解决用户类需求冲突）不同用户类：不同用户类意见不一致，决策哪一类用户需求更重要。了解产品类信息和业务目标，决定哪一用户类所占份额最大软件工程案例分析“谁说了算”不同公司客户：要求产品按照自己的喜好设计。运用项目业务目标决定最有价值客户。非核心客户的需求可以安排在下一个版本开发。客户经理与真正用户需求相冲突。用户需求必须与业务需求一致，说服客户经理服从产品代表者的用户需求和功能性规格说明。开发者构想产品与客户需求冲突，由客户作出决策，但不要陷入“客户总是对的”的陷阱中去，现实中，客户并不总是对的。软件工程案例分析某出版社系统调查表编号提出问题1您在哪个部门工作？2出版业务流程是什么？3您每日都处理那些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效率的问题有哪些？6您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？软件工程案例分析某出版社系统调查表编号提出问题7您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？9