1、第一页，编辑于星期三：十七点 四十分。概论概论第一局部第一局部管理到底是个啥东东？成功的管理者应该是什么样软件生存周期模型IT工程管理的主要领域及其相互关系第二页，编辑于星期三：十七点 四十分。关于工程成功的讨论：关于工程成功的讨论：什么样的工程是成功的工程？完成预定业务目标？客户满意？盈利？.业务目标业务目标进度进度Time本钱本钱Cost范围范围Scope工程经理工程经理第三页，编辑于星期三：十七点 四十分。如何把握管理如何把握管理1 面向目标的管理方式 目标对交付物的强调别人给你的目标是什么？工作的分解方式你给别人的目标是什么？2 前期的投入大以换取执行阶段的相对稳定 方案3 工程需求多
2、变以及资源紧张的推动 跟踪4 大量信息交换带来的沟通管理的需求 模板5 由抽象到具体的管理过程 分解以往的成果可以被重复使用学习过程较长关注方法而耐心6 高管理本钱换取低出错率从而降低总体本钱 周期关注“管理周期第四页，编辑于星期三：十七点 四十分。工程的生命周期工程的生命周期工程方案工程方案确定需求确定需求工程选择工程选择工程执行工程执行工程控制工程控制工程评估工程评估工程完毕工程完毕定义定义方案方案实施实施收尾收尾软件开发流程分为软件开发流程分为:需求确认需求确认概要设计概要设计详细设计详细设计编码编码单元测试单元测试集成测试集成测试系统测试系统测试维护维护 第五页，编辑于星期三：十七点
3、四十分。概念计划开发公用基础模块建立参考架构管理产品族 确认设计重用的机会生产较简单的派生产品使用决定性的测试GBM（Global Brand M anagerPDT投资组合管理确认市场机会/产品竞争力（可选）流程度量早期警告指示完美的行评审点执行阶段性的时间和投资等客户$APPEALS确定用户采购标准确认所有市场混合因素设计渠道IPMT发布项目管理完整的依赖关系管理关键路径分析/恢复方法验证生命周期概念决策评审点计划决策评审点可获得性决策评审点寿命终止决策评审点研发流程研发流程(IPD)管理控制整个流程管理控制整个流程第六页，编辑于星期三：十七点 四十分。工程经理在IPD中PDT团队的角色及
4、义务领导项目组指导产品从概念设计到市场接受保证实现设计、收益、市场份额及利润目标解决冲突管理项目制定项目计划及预算确定/管理参与项目的人员/资源（与职能部门经理协调）跟踪相对于项目基线的进展与管理层沟通提供项目进展状况准备并确定决策评审点作为产品领导提供对项目组成员的工作绩效评审的输入高级管理组项目领导职能部门领导核心小组成员PDT是临时小组 在工程开场时成立 在产品成功发布后解散 PDT成员在概念阶段一起作整个工程的方案PDT成员在方案阶段一起管理整个工程第七页，编辑于星期三：十七点 四十分。一个专业的经理需要那些素质？一个专业的经理需要那些素质？管理的知识相关的行业知识 业务与技术知识领导
5、能力(Leadership)制定目标的能力执行的能力-方案以及控制能力沟通的能力 包括协调冲突分析决策能力应变承压能力三种知识，五种能力三种知识，五种能力第八页，编辑于星期三：十七点 四十分。IBM Leadership Competencies for ManagersFOCUS TO WINCustomer InsightBreakthrough ThinkingDrive to AchieveMOBILIZE TO EXECUTETeam LeadershipStraight TalkTeamworkDecisiveness/Decision MakingSUSTAIN MOMENTUM
6、Building Organizational CapabilityCoaching/Developing TalentPersonal DedicationTHE COREPassion for the business第九页，编辑于星期三：十七点 四十分。成功的管理者应该是什么样成功的管理者应该是什么样对专业管理人士的最真实的考验不是你知道怎样做，而是在你不知道时也知道如何行动。决策决策=“我不知道我不知道+人人第十页，编辑于星期三：十七点 四十分。管理者的假设干规那么：管理者的假设干规那么：弄清团队业务的目标、所面临的问题，以及时机理解团队中的处突是必然的识别团队工程和业务的干系人，以及
7、他们的利益关系利用组织的政治色彩，并利用政治手段获得优势善于应用管理(Manage-Process)与领导(Lead-Vision)不要因小事而停滞不前，迷失了工程的整体目标有效的利用好时间方案、方案、再方案，跟踪、跟踪、再跟踪从实践中获取经历寻求别人的反映与资深的管理者进展探讨多学习，多阅读第十一页，编辑于星期三：十七点 四十分。管理者常犯的错误：管理者常犯的错误：拒绝承担个人责任只控制工作成果不能因人施管经理仅仅是职员的伙伴附和错误的一方忘却利润的重要性只专注日常业务问题未能培育人才第十二页，编辑于星期三：十七点 四十分。?IT工程管理工程管理?讲些啥东东？讲些啥东东？第十三页，编辑于星期
8、三：十七点 四十分。问题：问题：“软件的定义？“IT工程管理的定义？“IT工程管理的“方法有啥？“IT工程管理管理啥？第十四页，编辑于星期三：十七点 四十分。软件计算机系统中的程序及其文档。程序是计算任务的处软件计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规那么的描述；文档是为了便于了解程序所需的理对象和处理规那么的描述；文档是为了便于了解程序所需的说明性资料。说明性资料。工程将理论和所学的知识应用于实践的科学。工程将理论和所学的知识应用于实践的科学。IT工程管理工程管理是将系统化的、标准的、可度量的方法应用于软件的是将系统化的、标准的、可度量的方法应用于软件的开发、运行和维护的
9、过程，即将工程化应用于软件中。开发、运行和维护的过程，即将工程化应用于软件中。IT工程管理还工程管理还包括上述方法的研究。包括上述方法的研究。第十五页，编辑于星期三：十七点 四十分。从病症追溯到根本原因从病症追溯到根本原因需求没有满足需求没有满足需求混杂需求混杂模块难集成模块难集成系统很难维护系统很难维护缺陷发现晚缺陷发现晚不好的质量不好的质量不好的性能不好的性能开发人员协作难开发人员协作难构建和发布问题构建和发布问题不正确的需求不正确的需求模糊不清的沟通模糊不清的沟通脆弱的架构脆弱的架构 过分的复杂性过分的复杂性未发现的不一致未发现的不一致测试不充分测试不充分 主观的估计主观的估计瀑布行的开
10、发瀑布行的开发不可控的变更不可控的变更缺乏自动化缺乏自动化病症病症根本原因根本原因IT工程管理实践工程管理实践迭代开发迭代开发需求管理需求管理基于组件的架构基于组件的架构 可视化建模可视化建模UML持续的质量验证持续的质量验证管理变更管理变更 持续的质量验证持续的质量验证 不好的质量不好的质量 未发现的不一致未发现的不一致测试不充分测试不充分 主观的估计主观的估计 第十六页，编辑于星期三：十七点 四十分。Learning Roadmap迭代开发迭代开发管理需求管理需求基于组件的架构基于组件的架构可视化建模可视化建模 持续的质量验证持续的质量验证管理变更管理变更IT工程管理实践工程管理实践Lea
11、rning Topic软件开发过程软件开发过程软件工程管理软件工程管理软件需求管理软件需求管理软件架构软件架构SOASOA，J2EEJ2EE，.Net.Net软件设计与软件设计与UMLUML软件质量管理软件质量管理软件测试软件测试软件变更管理软件变更管理IT工程管理工程管理IT工程管理：围绕五大要素工程管理：围绕五大要素(人员、进度、质量、本钱人员、进度、质量、本钱和需求的实现进展和需求的实现进展“规规划和组织、划和组织、“领导和控领导和控制以及制以及“评估等责任评估等责任第十七页，编辑于星期三：十七点 四十分。课程的考核课程的考核采用作业和考试相结合的方式，其中作业占采用作业和考试相结合的方
12、式，其中作业占50%，考试占，考试占50%，开卷。，开卷。建议教学参考书建议教学参考书课程讲义课程讲义?软件工程管理：一个统一的框架软件工程管理：一个统一的框架?Software Project Management-A Unified Framework?IT工程管理：实践者的研究方法工程管理：实践者的研究方法?Software Engineering:A practitioners Approach微软技术丛书：微软技术丛书：?快速软件开发快速软件开发?Mark C.Paulk,et al.“The Capability Maturity Model:Guidelines for Impr
13、oving the Software Process.Addison-Wesley,Reading,Mass.1995.Watts S Humphrey.Managing the Software ProcessM.The 26th printing.USA：Addison-Wesley，2000(5):247-285第十八页，编辑于星期三：十七点 四十分。软件生存周期模型软件开发模型软件生存周期模型软件开发模型第十九页，编辑于星期三：十七点 四十分。软件生存周期模型软件开发模型软件生存周期模型软件开发模型根本概念根本概念软件生存周期模型软件生存周期模型IEEE Standard 12207.
14、0-1996 IEEE Standard 12207.0-1996 把一个软件生存周期模型描述为：一个包括软件产品开发把一个软件生存周期模型描述为：一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，覆盖了从该系统、运行和维护中有关过程、活动和任务的框架，覆盖了从该系统的需求定义到系统的使用终止。的需求定义到系统的使用终止。中国计算机科学与技术百科全书中国计算机科学与技术百科全书 称软件生存周期模型为称软件生存周期模型为“软件开发模型，并把它定义软件开发模型，并把它定义为：软件过程、活动、任务的构造框架。为：软件过程、活动、任务的构造框架。第二十页，编辑于星期三：十七点 四十分。根本
15、的开发活动及其目标根本的开发活动及其目标1 1软件需求分析：是在一个抽象层上建立概念模型的活动，产生软件需求分析：是在一个抽象层上建立概念模型的活动，产生软件需求规约，作为开发人员和客户间契约的根底，并作为以后软件需求规约，作为开发人员和客户间契约的根底，并作为以后开发阶段的输入。开发阶段的输入。2 2软件设计：是指定义实现需求规约所需的构造，包括软件体系构造软件设计：是指定义实现需求规约所需的构造，包括软件体系构造数据和程序构造，以及详细的处理算法，即所谓设计规约，给出了数据和程序构造，以及详细的处理算法，即所谓设计规约，给出了实现软件需求的软件解决方案。实现软件需求的软件解决方案。3 3实
16、现：即软件编码，是由设计规约到代码的转换。实现：即软件编码，是由设计规约到代码的转换。其中可选其中可选择一些可用的构件，或以一种选定的语言，对给定的软件项进展编码。择一些可用的构件，或以一种选定的语言，对给定的软件项进展编码。软件测试：是指一种有规程的发现软件错误的活动包软件测试：是指一种有规程的发现软件错误的活动包括软件编码测试、括软件编码测试、软件集成测试以及软件合格测试等。软件集成测试以及软件合格测试等。第二十一页，编辑于星期三：十七点 四十分。5维护是在软件发布之后所进展的开发或修改维护是在软件发布之后所进展的开发或修改modi-fication，包括对发现错误的修正以及对环境的变化所
17、进展，包括对发现错误的修正以及对环境的变化所进展的必要调整等。的必要调整等。完善性维护完善性维护 纠错性维护纠错性维护 *演化性维护演化性维护 第二十二页，编辑于星期三：十七点 四十分。系统需求系统需求软件需求软件需求需求分析需求分析设设 计计编编 码码测测 试试运运 行行归纳逻辑：归纳逻辑：P P Q Q P P Q Q 瀑布模型瀑布模型 1970年，年，W.Royce Thebasis for most current practice and has many variations.Its name come from the progression of activities base
18、d on the output of one phase“falling as input to the following phase.It is driven by the needs to schedule project milestones which are provided by the completion of documents at each level or phase.第二十三页，编辑于星期三：十七点 四十分。工程的开发依次经过：需求、设计、编码和单元测试、工程的开发依次经过：需求、设计、编码和单元测试、集成以及维护集成以及维护 这一根本路径。这一根本路径。在每一阶段
19、提交以下产品：软件需求规约、设计文档、在每一阶段提交以下产品：软件需求规约、设计文档、实际代码、测试用例、最终产品等。工作产品又称可实际代码、测试用例、最终产品等。工作产品又称可提交的产品，提交的产品，Deliverables 流经流经“正向开发的根本步正向开发的根本步骤路径。骤路径。“反向步骤流表示对前一个可提交产品的重复变更又反向步骤流表示对前一个可提交产品的重复变更又称为称为“返工返工(Rework)。由于所有开发活动的非确定性，因此是否需要重复变由于所有开发活动的非确定性，因此是否需要重复变更，这仅在下一个阶段或更后的阶段才能认识到。更，这仅在下一个阶段或更后的阶段才能认识到。返工不仅
20、在以前阶段的某一地方需要，而且对当前正返工不仅在以前阶段的某一地方需要，而且对当前正在进展的工作也是需要的。在进展的工作也是需要的。第二十四页，编辑于星期三：十七点 四十分。关于瀑布模型的几点说明关于瀑布模型的几点说明(瀑布模型的优点瀑布模型的优点 虽然瀑布模型是一个比较虽然瀑布模型是一个比较“老的、甚至过时的开发模型，老的、甚至过时的开发模型，但其优点为：但其优点为：在决定系统怎样做之前，存在一个需求阶段，鼓励对系在决定系统怎样做之前，存在一个需求阶段，鼓励对系 统统“做什么进展规约即设计之前的规约。做什么进展规约即设计之前的规约。在建造构件之前，存在一个设计阶段，鼓励规划系统结在建造构件之
21、前，存在一个设计阶段，鼓励规划系统结 构即编码之前的设计。构即编码之前的设计。在每一阶段完毕时进展复审，允许获取方和用户的参与。在每一阶段完毕时进展复审，允许获取方和用户的参与。允许基线和配置早期承受控制。允许基线和配置早期承受控制。前一步工作产品可作为下一步被认可的、文档化的基线。前一步工作产品可作为下一步被认可的、文档化的基线。第二十五页，编辑于星期三：十七点 四十分。瀑布模型存在的缺乏瀑布模型存在的缺乏 客户必须能够完整、正确和清晰地表达他们的需求；开发客户必须能够完整、正确和清晰地表达他们的需求；开发 人员一开场就必须理解其应用。人员一开场就必须理解其应用。在开场的两个或三个阶段中，很
22、难评估真正的进度状态在开场的两个或三个阶段中，很难评估真正的进度状态;设计、编码和测试阶段都可能发生延期。设计、编码和测试阶段都可能发生延期。在一个工程的早期阶段，过分地强调了基线和里程碑处在一个工程的早期阶段，过分地强调了基线和里程碑处 的文档的文档;可能要花费更多的时间，用于建立一些用处不可能要花费更多的时间，用于建立一些用处不 大的文档。大的文档。当接近工程完毕时，出现了大量的集成和测试工作。当接近工程完毕时，出现了大量的集成和测试工作。直到工程完毕之前，都不能演示系统的能力。直到工程完毕之前，都不能演示系统的能力。第二十六页，编辑于星期三：十七点 四十分。3瀑布模型适用的情况瀑布模型适
23、用的情况在开发中，向下、渐进的路径占支配地位。也就是说，在开发中，向下、渐进的路径占支配地位。也就是说，需求已被很好地理解；并且需求已被很好地理解；并且 过程设计人员也很清楚：开发组织非常熟悉为实现这一模过程设计人员也很清楚：开发组织非常熟悉为实现这一模 型所需要的过程或经过培训后，熟悉什么时候来支持这型所需要的过程或经过培训后，熟悉什么时候来支持这 一工程，以实现这一模型所需要的过程。一工程，以实现这一模型所需要的过程。因此为了防止产生过多的反复迭代工作，增加开发本钱，因此为了防止产生过多的反复迭代工作，增加开发本钱，一般在准备采用瀑布模型一般在准备采用瀑布模型(也包括其他模型也包括其他模型
24、)时，需要考虑以下时，需要考虑以下2个问题：第一个问题是，过程设计人员必须对初始产品个问题：第一个问题是，过程设计人员必须对初始产品(通常通常 是软件需求规约，是软件需求规约，SRS)的不确定性进展评估。的不确定性进展评估。另一个问题是，组织是否具有熟练实施每个活动和另一个问题是，组织是否具有熟练实施每个活动和 任务的历史经历。任务的历史经历。第二十七页，编辑于星期三：十七点 四十分。13259101167121384增量增量1 1 1,2,5,9 1,2,5,9 增量增量2 2 3 3,6,7,4,10,11,6,7,4,10,11 增量增量3 3 8 8,12,13,12,13 管理管理增
25、量规约增量规约增量设计增量设计纠错性分析纠错性分析增量实现增量实现增量1增量2增量33 增量模型增量模型该模型有一个假设，即需求可以分段，成为一系列增该模型有一个假设，即需求可以分段，成为一系列增量产品，每一增量可以分别地开发。量产品，每一增量可以分别地开发。第二十八页，编辑于星期三：十七点 四十分。关于增量模型的几点说明：关于增量模型的几点说明：(1(1增量模型的优点增量模型的优点 作为瀑布模型的第一个变体，具有瀑布模型的所有优点。作为瀑布模型的第一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：此外，它还有以下优点：第一个可交付版本所需要的本钱和时间是很少的；第一个可交付版本所需要的
26、本钱和时间是很少的；开发由增量表示的小系统所承担的风险是不大的；开发由增量表示的小系统所承担的风险是不大的；由于很快发布了第一个版本，因此可以减少用户需求由于很快发布了第一个版本，因此可以减少用户需求 的变更；的变更；允许增量投资，即在工程开场时，可以仅对一个或两允许增量投资，即在工程开场时，可以仅对一个或两 个增量投资。个增量投资。第二十九页，编辑于星期三：十七点 四十分。(缺点：缺点：如果增量模型不适于某些工程，或使用有误，那么有如果增量模型不适于某些工程，或使用有误，那么有以下缺点：以下缺点：如果没有对用户的变更要求进展规划，那么产生的初始如果没有对用户的变更要求进展规划，那么产生的初始
27、 增量可能会造成后来增量的不稳定；增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增如果需求不像早期思考的那样稳定和完整，那么一些增 量就可能需要重新开发，重新发布；量就可能需要重新开发，重新发布；管理发生的本钱、进度和配置的复杂性，可能会超出组管理发生的本钱、进度和配置的复杂性，可能会超出组 织的能力。织的能力。注：如果采用增量投资方式，那么客户就可以对一些增量进注：如果采用增量投资方式，那么客户就可以对一些增量进行招标。然后，开发人员按提出的截止期限进展增量开发，这行招标。然后，开发人员按提出的截止期限进展增量开发，这样客户就可以用多个契约来管理组织的资源和本
28、钱。样客户就可以用多个契约来管理组织的资源和本钱。第三十页，编辑于星期三：十七点 四十分。(该模型的适用情况该模型的适用情况 在开场开发时，需求很明确，且产品还可被适当地分解为一些独立的在开场开发时，需求很明确，且产品还可被适当地分解为一些独立的、可交付的软件构造增量：、可交付的软件构造增量：Build incrementsBuild increments如果一个增量并不需如果一个增量并不需要交付给客户的话，那么这样的增量通常称为一个要交付给客户的话，那么这样的增量通常称为一个“构造构造(Build)(Build)。如。如果增量被交付，那么它们就被认为是发布版本果增量被交付，那么它们就被认为是
29、发布版本(Released version)(Released version)。；在开发中，期望尽快提交其中的一些增量产品。在开发中，期望尽快提交其中的一些增量产品。例如：例如：一个数据库系统，它必须通过不同的用户界面，为不同类型的用户提一个数据库系统，它必须通过不同的用户界面，为不同类型的用户提供不同的功能。在这一情况下，首先实现完整的数据库设计，并把一供不同的功能。在这一情况下，首先实现完整的数据库设计，并把一组具有高优先级的用户功能和界面作为一个增量；以后，陆续构造其组具有高优先级的用户功能和界面作为一个增量；以后，陆续构造其它类型用户所需求的增量。它类型用户所需求的增量。第三十一页，
30、编辑于星期三：十七点 四十分。需求需求设计设计编码编码测试测试集成集成需求需求设计设计编码编码测试测试集成集成开开发发反反馈馈开开发发反反馈馈.核核 心心 系系 统统 开开 发发第第 二二 次次 迭迭 代代演化模型演化模型 Evolutionary model是一种有弹性的过程模式，由一些小的开发步组成，每一步历经需求分是一种有弹性的过程模式，由一些小的开发步组成，每一步历经需求分析、设计、实现和验证，产生软件产品的一个增量。通过这些迭代，完成最析、设计、实现和验证，产生软件产品的一个增量。通过这些迭代，完成最终软件产品的开发。终软件产品的开发。针对事先不能完整地定义需求针对事先不能完整地定义
31、需求 针对用户的核心需求针对用户的核心需求,开发核心系统开发核心系统 根据用户的反响根据用户的反响,实施活动的迭代实施活动的迭代第三十二页，编辑于星期三：十七点 四十分。关于演化模型的几点说明关于演化模型的几点说明(1(1主要特征主要特征 该模型显式地把增量模型扩展到需求阶段。由图可以看出，该模型显式地把增量模型扩展到需求阶段。由图可以看出，为了第二个构造增量，使用了第一个构造增量来精化需求。为了第二个构造增量，使用了第一个构造增量来精化需求。这一精化可以有多个来源和路径。这一精化可以有多个来源和路径。首先，如果一个早期的增量已向用户发布，那么用户会以变首先，如果一个早期的增量已向用户发布，那
32、么用户会以变更要求的方式提出反响，以支持以后增量的需求开发。更要求的方式提出反响，以支持以后增量的需求开发。第二，通过实实在在地开发一个构造增量，为以前还没有认第二，通过实实在在地开发一个构造增量，为以前还没有认识到的问题提供了可见性，以便实际地开场这一增量的工作。识到的问题提供了可见性，以便实际地开场这一增量的工作。第三十三页，编辑于星期三：十七点 四十分。(2(2与瀑布模型的关系与瀑布模型的关系 在演化模型中，仍然可以使用瀑布模型来管理每一个演化的增量。在演化模型中，仍然可以使用瀑布模型来管理每一个演化的增量。一旦理解了需求，就可以像实现瀑布模型那样开场设计阶段和编码阶段一旦理解了需求，就
33、可以像实现瀑布模型那样开场设计阶段和编码阶段。(3(3使用演化模型应注意的问题使用演化模型应注意的问题 不能弱化需求分析阶段的工作。其原因是：在工程开场时，考虑所不能弱化需求分析阶段的工作。其原因是：在工程开场时，考虑所有需求来源的重要性和风险，对这些来源的可用性进展评估。只有采用有需求来源的重要性和风险，对这些来源的可用性进展评估。只有采用这一方法，才能识别和界定不确定的需求，并识别第一个增量中所包含这一方法，才能识别和界定不确定的需求，并识别第一个增量中所包含的需求。的需求。第三十四页，编辑于星期三：十七点 四十分。(4(4演化模型的长处和缺乏演化模型的长处和缺乏 演化模型还具有以下优点：
34、与增量模型是类似的。特别地，演化模型还具有以下优点：与增量模型是类似的。特别地，在需求不能予以规约时，可以使用这一演化模型。在需求不能予以规约时，可以使用这一演化模型。用户可以通过运行系统的实践，对需求进展改进。用户可以通过运行系统的实践，对需求进展改进。与瀑布模型相比，需要更多用户与瀑布模型相比，需要更多用户/获取方的参与。获取方的参与。缺点有：缺点有：演化模型的使用仍然处于探索阶段，因此具有较大演化模型的使用仍然处于探索阶段，因此具有较大 的风险，需要有力的管理。的风险，需要有力的管理。演化模型的使用很容易成为不编写需求或设计文档的借口，演化模型的使用很容易成为不编写需求或设计文档的借口，
35、即使很好地理解了需求或设计。即使很好地理解了需求或设计。用户用户/获取方不易理解演化模型的自然属性，因此当结果不获取方不易理解演化模型的自然属性，因此当结果不 够理想时，可能产生抱怨。够理想时，可能产生抱怨。第三十五页，编辑于星期三：十七点 四十分。5 螺旋模型螺旋模型 该模型是由该模型是由Dr.Barry Boehm Boehm 1988开发的。开发的。该模型将软件生存周期的活动分为四个可重复的阶段：该模型将软件生存周期的活动分为四个可重复的阶段：规划、风险分析、开发和评估：规划、风险分析、开发和评估：工程的进度是工程的进度是“螺旋式的。螺旋式的。risk analysis stageDev
36、elopment stagePlanning stageEvaluation stagestartResource use第三十六页，编辑于星期三：十七点 四十分。其中：其中：评估和风险分析阶段都可作出一个决策：工程是否继续。评估和风险分析阶段都可作出一个决策：工程是否继续。螺旋循环的次数指示了已消耗的资源；螺旋循环的次数指示了已消耗的资源；在规划阶段、风险分析阶段和开发阶段均进展需求规约活在规划阶段、风险分析阶段和开发阶段均进展需求规约活 动；动；在早期螺旋循环中，为了为最终的实现给出一些指导性决在早期螺旋循环中，为了为最终的实现给出一些指导性决 策，经常使用原型构造；策，经常使用原型构造；
37、设计和实现活动一般是在开发阶段进展；设计和实现活动一般是在开发阶段进展；V&V 活动在开发阶段和评估阶段进展；活动在开发阶段和评估阶段进展；第三十七页，编辑于星期三：十七点 四十分。验证验证/确认确认:一种评估活动一种评估活动验证验证verification：确定一个阶段的产品是否到达：确定一个阶段的产品是否到达 前阶段确立的需求的过程。前阶段确立的需求的过程。实施过程质量控制的根本措施实施过程质量控制的根本措施 确认确认(veridation)：评价开发的软件与需求是否一致的：评价开发的软件与需求是否一致的 过程。过程。实施产品质量控制的根本措施实施产品质量控制的根本措施活动1活动2活动3活
38、动1活动2活动3第三十八页，编辑于星期三：十七点 四十分。关于螺旋模型的几点说明：关于螺旋模型的几点说明：(1(1该模型关注解决问题的根本步骤该模型关注解决问题的根本步骤:标识问题标识问题;标识一标识一些些 可选方案，选择一个最正确方案可选方案，选择一个最正确方案;遵循动作步骤，并实施遵循动作步骤，并实施 后续工作。其中只要完成了开发的一个迭代，开发的后续工作。其中只要完成了开发的一个迭代，开发的另另 一个迭代就开场。一个迭代就开场。(2(2螺旋模型的一个特征是，实际上只有一个迭代过程真正螺旋模型的一个特征是，实际上只有一个迭代过程真正 开发可交付的软件。因此开发可交付的软件。因此,如果如果
39、工程的开发风险很大，或工程的开发风险很大，或 客户不能确定系统需求，在更广泛的意义上来讲，还客户不能确定系统需求，在更广泛的意义上来讲，还 包括系统或系统类型的要求，包括系统或系统类型的要求，这时螺旋模型就是一个好的生存周期模型。这时螺旋模型就是一个好的生存周期模型。第三十九页，编辑于星期三：十七点 四十分。(3)(3)与其它模型的关系与其它模型的关系 与演化模型一样，螺旋模型也使用瀑布模型作为一个嵌与演化模型一样，螺旋模型也使用瀑布模型作为一个嵌入的过程入的过程-即分析、设计、编码、实现和维护的瀑布过程，是即分析、设计、编码、实现和维护的瀑布过程，是螺旋一周的组成局部。螺旋一周的组成局部。尽
40、管螺旋模型和一些迭代模型在框架和全局体系构造尽管螺旋模型和一些迭代模型在框架和全局体系构造方面是等同的，但所关注的阶段以及它们的活动是不同的方面是等同的，但所关注的阶段以及它们的活动是不同的。具体地说：具体地说：标识客户想要的是一个什么样的系统；标识客户想要的是一个什么样的系统；确定风险和效益的可选路线；确定风险和效益的可选路线；选择最优方案；选择最优方案；开发系开发系统；统；评估完成情况等；评估完成情况等；重新开场。重新开场。即即 螺旋模型扩展了增量模型的管理任务范围。而增量模螺旋模型扩展了增量模型的管理任务范围。而增量模型是基于以下假定：需求是最根本的、并且是唯一的风险源型是基于以下假定：
41、需求是最根本的、并且是唯一的风险源。而在螺旋模型中，决策和降低风险的空间是相当广泛的。而在螺旋模型中，决策和降低风险的空间是相当广泛的。第四十页，编辑于星期三：十七点 四十分。6 6 小结小结所有模型的内在根本特征：所有模型的内在根本特征：描述了开发的主要阶段；描述了开发的主要阶段；定义了每一个阶段要完成的主要活动；定义了每一个阶段要完成的主要活动；规约了每一个阶段的输入和输出产品；规约了每一个阶段的输入和输出产品；提供了一个框架，可以把必要的活动映射到该框架中。提供了一个框架，可以把必要的活动映射到该框架中。外征：软件开发活动的组织外征：软件开发活动的组织 内涵：求解软件的计算逻辑内涵：求解
42、软件的计算逻辑第四十一页，编辑于星期三：十七点 四十分。关于软件开发风范关于软件开发风范 -开发活动的组织开发活动的组织:风格与准那么风格与准那么 尽管在实践中，每一项尽管在实践中，每一项IT工程管理都有自己特定的软件开发工程管理都有自己特定的软件开发过程，但软件开发风范过程，但软件开发风范paradigms主要有五种，它们是：主要有五种，它们是：迭代迭代iterative风范，风范，也称为演化也称为演化evolutionary风范风范;转换转换transformational风范风范;螺旋螺旋 spiral风范风范;瀑布瀑布 waterfall风范，以及风范，以及 第四代第四代fourth
43、generation风范。风范。第四十二页，编辑于星期三：十七点 四十分。其中，转换风范的过程模式其中，转换风范的过程模式 基于待开发系统的形式化需求规约。基于待开发系统的形式化需求规约。在此根底上，通过一系列转换，将这一形式化的在此根底上，通过一系列转换，将这一形式化的 需求规约转化为它的实现。需求规约转化为它的实现。其中，如果需求规约发生变化的话其中，如果需求规约发生变化的话,可以重新应用可以重新应用 这些转换这些转换,对其实现进展更新对其实现进展更新.对于形式化的表示，需要在研究环境之外所使用对于形式化的表示，需要在研究环境之外所使用 的环境中保持这一风范的环境中保持这一风范.第四十三页
44、，编辑于星期三：十七点 四十分。其中，第四代风范其中，第四代风范 是围绕特定语言和工具而设计的。这一风范的过程是围绕特定语言和工具而设计的。这一风范的过程,依据高层依据高层 描述，自动生成代码。描述，自动生成代码。软件开发技术经常被认为经历了以下四代：软件开发技术经常被认为经历了以下四代：第一代是单个开发人员使用低级程序设计语言第一代是单个开发人员使用低级程序设计语言.第二代第二代,使使用过程语言用过程语言,为多用户开发软件为多用户开发软件.第三代其主要特征是使用高级第三代其主要特征是使用高级通用的语言通用的语言,为大量工业应用开发软件为大量工业应用开发软件.随后随后,出现并使用了高出现并使用
45、了高级的非过程语言级的非过程语言,称为第四代称为第四代.第四代开发风范没有广泛地应用第四代开发风范没有广泛地应用,只是在一些特定的应用领只是在一些特定的应用领域得以应用域得以应用,并通常使用数据库系统保持所有开发信息并通常使用数据库系统保持所有开发信息.原因：原因：这些特定语言和工具限制了开发中对其它技术的选择这些特定语言和工具限制了开发中对其它技术的选择;为了完成软件产品的开发为了完成软件产品的开发,必须学习大量设计和实现工作必须学习大量设计和实现工作.第四十四页，编辑于星期三：十七点 四十分。软件生存周期过程软件生存周期过程第四十五页，编辑于星期三：十七点 四十分。软件开发涉及的根本问题软
46、件开发涉及的根本问题 软件开发本质软件开发本质软软件件生生存存周周期期过过程程定义定义软软件件生生存存周周期期模模型型软软件件工工程程生生存存周周期期过过程程活活动动与与定定序序形形成成软件开发方法学软件开发方法学构造化方法构造化方法面向对象方法面向对象方法面向数据构造面向数据构造 方法方法维也纳开发方维也纳开发方 法法(VDM)给给出出实实现现开开发发过过程程的的途途径径IT工程管理工程管理管理活动管理活动管理技术与方法管理技术与方法作用于作用于 1)做哪些工作做哪些工作?2)谁做谁做?3)如何组织这些工作如何组织这些工作?4)怎么做怎么做?5)如何管理如何管理?IT工程管理知识构造工程管理
47、知识构造第四十六页，编辑于星期三：十七点 四十分。二、软件生存周期过程二、软件生存周期过程 -答复要做哪些答复要做哪些“工作，而没有答复如何进展工作，而没有答复如何进展“工作工作 1、根本概念、根本概念 为了表述软件开发需要做为了表述软件开发需要做“什么活什么活(映射映射),引入了以下三引入了以下三 个概念：个概念：软件过程软件过程(process)：活动的一个集合；：活动的一个集合；活动活动(activity)：任务的一个集合；：任务的一个集合；任务任务(task)：将输入转换为输出的操作。将输入转换为输出的操作。第四十七页，编辑于星期三：十七点 四十分。2 2 过程分类过程分类 按过程的主
48、体按过程的主体,可分为三类过程：可分为三类过程：1 1根本过程根本过程(primary processes)(primary processes)是指那些与软件生产直接相关的活动集。是指那些与软件生产直接相关的活动集。2 2支持过程支持过程(supporting processes)(supporting processes)是有关各方按其目标所从事的一系列支持活动集。是有关各方按其目标所从事的一系列支持活动集。3 3组织过程组织过程(institutional processes)(institutional processes)是指那些与软件生产组织有关的活动集。是指那些与软件生产组织有关
49、的活动集。根本过程根本过程支持过程支持过程组织过程组织过程第四十八页，编辑于星期三：十七点 四十分。1 1根本过程根本过程 又按过程中活动的不同主体，将根本过程类分又按过程中活动的不同主体，将根本过程类分 为为5 5个过程：获取过程、供给过程、开发过程、个过程：获取过程、供给过程、开发过程、运行过程、维护过程运行过程、维护过程 获取过程获取过程根本过程根本过程支持过程支持过程组织过程组织过程组织为组织为供给过程供给过程开发过程开发过程运行过程运行过程维护过程维护过程第四十九页，编辑于星期三：十七点 四十分。例如例如1：开发过程：开发过程 是软件开发者所从事的一系列活动。是软件开发者所从事的一系
50、列活动。包括包括13个活动：个活动：过程的实施准备过程的实施准备 系统需求分析系统需求分析 系统构造设计系统构造设计 软件需求分析软件需求分析 软件体系构造设计软件体系构造设计 软件详细设计软件详细设计 软件编码和测试软件编码和测试 软件集成软件集成 软件合格测试软件合格测试 系统集成系统集成 系统合格测试系统合格测试 软件安装软件安装 软件验收支持软件验收支持 第五十页，编辑于星期三：十七点 四十分。2 2支持过程支持过程 又按过程中活动的不同主体，将支持过程类分为又按过程中活动的不同主体，将支持过程类分为 8 8个过程：文档过程、配置管理过程、质量保证、验证过程、个过程：文档过程、配置管理
