软件工程中的过程概论PPT电子课件教案.ppt

软件工程中的过程概论,软件工程过程及其量化基础概论 问题定义阶段 可行性研究阶段 软件需求分析阶段 软件总体设计阶段 软件详细设计阶段 软件编码阶段 软件单元测试阶段 软件系统测试阶段,软件工程过程及其量化基础概论,软件工程的量化问题概论 何以需要进行软件工程的量化处理 软件工程面临巨大的失败风险 失败的原因主要表现在软件过程的失控 量化是解决软件过程失控的必要条件 成功的软件工程： 得到一个达到预期特性的软件产品 按预期目标完成的软件过程 为使软件工程成功，对软件开发项目实施严格的、基于目标的计划管理是一条有效的途径，也可以说是一个必要条件 为此，准确地估算软件开发成本（或者开发工作量）与进度是十分必要的 其基础性环节即是实现软件工程的科学的量化处理,软件工程过程及其量化基础概论,软件工程的量化问题概论 量化涉及到以下两个方面： 软件过程的量化处理 面向软件产品的量化处理 软件过程的量化问题 为了实现软件过程科学、合理、符合实际、可操作性强的量化处理，必须处理好下述问题： 软件生命周期阶段的划分 一个软件产品从问题的提出直至其被废止(丧失运行平台/继续维护已无必要/用户已不再需要使用之)的完整软件生命周期可被划分为若干时序关联的、相对独立的生命周期阶段,这是毋容置疑的。然而，将软件生命周期划分为几个软件生命周期阶段却不是固定不变的 不同软件生命周期阶段需要达到的阶段目标、所需完成的开发/维护任务存在很大差异 软件生命阶段的目标、任务将因软件产品不同而不同,软件工程过程及其量化基础概论,软件工程的量化问题概论 软件过程量化的基础 软件过程的量化虽然存在上述种种问题，但也存在以下可供支持这种量化处理有效进行的知识/实践基础： 软件生命周期可被划分为三个时间阶段： 软件定义时期 形成软件产品的问题/需求定义 软件开发时期 产出可交付的软件产品 软件维护时期 发挥并维持软件的效能 软件维护时期的特殊性 在软件生命周期的上述三个时期中，“软件维护时期”具有下述特征： 时间跨度很大 相关软件技术需求在整体上与“软件开发时期”相同 软件维护时期的这种特殊性使得可在进行软件过程的量化处理时将其另外特殊处理,软件工程过程及其量化基础概论,软件工程的量化问题概论 软件维护时期的特殊处理使得软件过程的量化处理可集中于“软件定义时期”和“软件开发时期”的量化处理 在现代软件工程实践中，软件产品开发通常实施“项目管理”，而“项目组”的开发工作始于“可行性研究”阶段的工作结束之后（但项目的“计划”工作是“项目组”的重要工作内容 “计划”涉及自“需求分析”开始到软件进入维护状态止这段时间内的软件开发活动） 这也就是说，软件过程的量化可仅关注“软件定义时期”的 “需求分析与软件计划” （可简称为“计划与需求”）阶段及完整的“软件开发时期”这部分软件生命周期 一个软件生命周期阶段所要实现的阶段目标、所需完成的开发工作任务尽管会因具体生命周期阶段的不同而不同，因需要开发的软件产品不同而不同，但完成一个生命周期阶段的开发工作可被进一步细分为若干相对独立的“软件开发活动”，这是毫无疑问的,软件工程过程及其量化基础概论,软件工程过程的量化处理 基于软件工程的相关知识与上述有关讨论，可将自“可行性研究”结束至可交付软件产品生成这一段软件生命周期划分为以下几个生命周期阶段： “计划与需求”阶段 这一阶段包含两项相对独立的软件产品开发任务： 软件产品详细的需求分析 在已完成工作（在“问题定义”阶段完成的软件最高层次上的逻辑模型关联的“需求分析”工作及“可行性研究”阶段完成的软件高层逻辑模型关联的“需求分析”工作）的基础上完成“软件定义时期”的软件开发工作 软件计划 对自“可行性研究”结束至可交付软件产品生成这一段软件生命周期的开发工作作出符合软件“项目管理”相关管理控制工作要求的软件开发计划（以软件成本估算所获得的“软件开发工作量”数据和“开发进度”数据为基础,软件工程过程及其量化基础概论,软件工程过程的量化处理 “产品设计”阶段 这一软件生命周期阶段的阶段目标是确定软件产品的物理结构，即组成软件产品的单元（程序模块与全局性数据结构）及其相互关联 “编程”阶段 这一阶段在一些软件工程著述中被划分为“详细设计”和“编码与单元测试”两个软件生命周期阶段，也有一些软件工程著述中将其划分为“详细设计” 、“编码” 和“单元测试”等三个软件生命周期阶段，其阶段目标是实现软件产品、得到可用的软件产品组成单元 “集成与测试”阶段 这一阶段的阶段目标是将组成软件产品的单元基于“产品设计”阶段所确定的软件物理结构集成为软件产品个层次上的子结构并进行相应的测试，使得到经过测试的、可用的子结构以至完整的软件产品；在此基础上，进行软件产品的“验收测试”，得到一个可交付的软件产品 一个软件生命周期阶段的工作可被划分为8个开发活动,软件工程过程及其量化基础概论,软件工程过程的量化处理 将每一个软件生命周期阶段划分为系列“软件开发活动”的一种方法是将其分别划分为“需求分析” 、“产品设计” 、“编程” 、“测试计划” 、“验证与确认” 、“项目办公室职能” 、“配置管理和质量保证”以及“手册”等8项开发活动，这种划分虽然不一定是最好的，但能够切合现代软件工程实践 “需求分析”活动 在这里，“需求”应当一般性地理解为“为使确定的目标达到/确定的开发任务完成”而导致的信息技术/信息资源需求 “产品设计”活动 在这里，“产品”应当与“软件配置” （相应的软件生命周期阶段应当提供的新增软件配置）关联起来，“设计”是确定“产品”结构（“产品”的组成单元及其关联）的开发活动 “编程”活动 实现“产品”的组成单元并确保所实现的单元符合确定的技术目标要求的开发性劳动（它可被进一步地划分为“详细设计” 、“实现”与“单元测试”工作）,软件工程过程及其量化基础概论,软件工程过程的量化处理 “测试计划”活动 面向软件产品多层次的“测试”任务制定的软件开发活动，软件工程中的“测试” （在一般的软件工程著述中，通常将“验证与确认”也归入“测试”中，由于这里已将其作为个生命周期阶段中的一项独立软件开发活动故不计入其中）包括： 单元测试 系统测试，也称“集成测试” 验收测试 “测试计划”活动的主要内容就是为在后续相关软件生命周期阶段将要进行的“测试”确定： 需要检测的“故障”集 测试工作的序列性（检测“故障”的顺序性） 面向具体“故障”的“测试”/“测试序列”,软件工程过程及其量化基础概论,软件工程过程的量化处理 “验证与确认”活动 对本生命周期阶段产生的“软件配置”进行系统检测，以求确知：这些“软件配置”是满足阶段目标要求的、无遗漏的、必要的 “项目办公室职能”活动 实施对于本阶段开发工作的系统化管理 “配置管理和质量保证”活动 对于到目前为止所得到的“软件配置”进行系统化、规范化管理；基于现代企业管理方法中的“全面质量管理”技术实施系统化的质量管理（基于“产品质量”目标与“工作质量”目标对本阶段的“产品”与“工作”进行系统质量检测） “手册编制”活动 在现代软件工程中，与传统的在软件产品设计实现完成之后再系统提供面向用户的“使用说明” （“手册”）不同，在软件产品的开发过程中即自顶向下地给出软件面向用户的有关系统特征的说明，以期达到尽早发现并改正开发失误的目的,软件工程过程及其量化基础概论,关于软件开发活动 在原则上讲，每一个软件生命周期阶段所需完成的软件产品开发维护任务都可被划分为多项相对独立的开发维护“工作” 由此使得阶段任务得以完成，这是很显然的 在这里,相对独立的开发维护“工作” （“软件开发活动”）是可以向具体软件开发维护人员分派的,当然,这需要结合软件产品的逻辑/物理构成才能具体化 在现代软件工程实践中，有两个值得关注的基本事实： 软件产品开发实施“项目管理” 软件开发项目组实施现代企业管理 “项目管理”是指软件开发组织具有现代企业属性，它可能同时承担多个软件产品开发任务，其所拥有的软件开发人员（需要时可临时招聘人员）可根据各项目的工作需要灵活调度（开发人员不附属于“项目组”），项目组在一个软件开发项目的“可行性研究”完成后开始运作，项目实施独立核算,软件工程过程及其量化基础概论,关于软件开发活动 由此也就确定了现代软件工程中的“项目管理”必然： 有着独立的管理机构（包括独立管理人员在内） 项目的管理机构独立地按照现代管理科学的相关成就对软件开发项目实施现代企业管理 在软件工程的软件开发过程特性中必须考虑项目管理机构与项目管理机制的作用与影响 就其过程特性而论，管理的过程包括四项时序关联的管理活动：计划、组织、领导、控制 质量控制：质量管理是软件项目管理极为重要的内容之一，在现代企业管理中，对之，实施面向目标的“全面质量管理”，即在软件产品的开发过程中，基于软件产品总的质量目标（与软件的定价相关联）对各生命周期阶段的“工作”与需产生的“软件配置”确定需达到的质量目标，基于该目标对阶段中的开发工作与产出实施质量控制,软件工程过程及其量化基础概论,关于软件开发活动 为了系统反映现代软件工程中独立“项目管理”的作用，在面向各软件生命周期的系列“软件开发活动”中，关于“项目管理”的相关工作，被归纳为两项软件开发活动： “项目管理办公室职能”软件开发活动 “配置管理和质量保证” （cm/qa）软件开发活动 关于“项目管理办公室职能”软件开发活动 这项软件开发活动的主要工作内容包括： “项目经理”所承担的专职管理工作 “人员安排”相关的管理类工作 “计划和控制”相关的管理类工作 “项目经理” 在现代软件工程中，通常实行“项目经理制”，由一到多名“项目经理”具体负责实施软件工程中的管理工作，他们或者专职担任“项目经理”或者兼职（担任一定的开发工作）担任“项目经理”,软件工程过程及其量化基础概论,关于软件开发活动 “人员安排” 将本阶段需要完成的开发工作与责任具体落实，产生本阶段的“组织系统图” “计划和控制” 这是两项相互关联的管理工作，“计划”确定本阶段工作的详细工作计划，“控制” （“管理控制”）确保阶段任务按照计划有序地完成 “配置管理和质量保证” 这是两项相对独立但又密切关联的软件工程管理工作 “软件配置” 为了在“工作”和“产出”两个方面实施软件工程的质量目标管理（软件工程中的“全面质量管理”），引入“软件配置”以描述软件开发过程的中间产物，它指向软件工程中“当前阶段的产出物”/“迄今为止的产出物” “配置管理” 面向软件工中的“软件配置”的管理控制，其基本内容是实施软件配置的系统化管理并提供对于先前已产生的软件配置的修改的系统控制机制，以系统化地控制软件质量（包含“差错管理”在内）,软件工程过程及其量化基础概论,关于软件开发活动 “质量保证” 基于软件产品的质量目标，确定本阶段细化的开发工作的质量目标与新增软件配置的质量目标，以之控制本阶段的软件工程质量，确保质量目标的实现 “手册编制”活动 与传统的软件开发不同，在现代软件工程中，强调面向软件用户的资料（“手册” ，即通常所论的“用户手册”）的尽早产生，由此可达到如下直接的目的： 使用户较早地了解软件产品的特性 为软件开发人员系统把握软件问题提供支持 使系统分析员对于后期开发工作的控制变得更为有效 综合而论，可有效降低软件产品的开发风险、控制软件质量、降低软件开发成本（可有效防止需求分析工作中的遗漏/大量减少开发工作中“返工”），这是已为大量实践所证实了的（从实践的较大来看，这可使得更多的人能够有效地参与到软件工程的质量监控工作中来）,软件工程过程及其量化基础概论,关于软件开发活动 在“软件定义时期”，“手册编制”软件开发活动所形成的相应资料应当包括： 软件产品整体可见的“功能说明” （“问题定义”） 软件产品的系统作用过程 说明在软件产品投入运行后其系统功能的发挥与软件的“用户系统”特性基于过程的关联（作为系统开发文档，这部分内容可用“系统流程图”来规范描述之，作为“用户手册”的最高层次内容，可对应地用用户系统语言对之予以文字说明 一般的，这些内容并不实际出现在“用户手册”中） 软件产品子系统级的“功能说明” 与“可行性研究”进行软件产品高层逻辑模型相关联的“需求分析”活动产出的“软件配置”相对应，对软件产品的功能作出较之于“问题定义”的“功能说明”在粒度上更小的说明 更详细的“软件产品系统作用过程”说明（发生在“可行性研究”阶段）,软件工程过程及其量化基础概论,关于软件开发活动 在“软件定义时期”的“需求分析”阶段，需要导出软件产品详细的逻辑模型，它包括了： 软件产品的功能定义所涉及到的“用户系统”中多层次的数据对象 所涉数据对象在“用户系统”中的系统关联 软件产品的功能定义所涉及到的“用户系统”中多层次的、与确定数据对象关联的数据处理操作 所涉数据处理操作在“用户系统”中的系统关联 各数据处理操作被引发执行的条件 数据对象的“奇异数据样本值”集合及其相应的系统处理机制描述 数据处理操作关联的数据对象的“奇异数据样本值”集合及其相应的处理机制描述,软件工程过程及其量化基础概论,关于软件开发活动 在“需求分析”阶段，基于现代软件工程科学成就（与软件工程实际可能存在一定差异），“手册编制”软件开发活动应当： 对软件产品的功能进行系统说明 这种说明包括所涉及的数据对象、相关的用户可见逻辑过程等 对软件产品所涉及到的重要/主要数据对象及其系统处理进行基于用户可见的特性的系统说明 对软件产品运行时用户可见的系统状态及其关联进行系统说明 “软件设计”阶段 由“软件工程”的相关知识可知，“软件设计” （在一些著述中称作“总体设计”/“产品设计”）阶段的阶段目标是确定软件产品的“物理结构”，即实际组成软件产品的单元（程序模块、数据单元及由之组合所形成的可被独立访问/引用的软件构件）及其相互关联（物理关联而非逻辑关联 包括调用/引用等）,软件工程过程及其量化基础概论,关于软件开发活动 “软件设计”阶段的“手册编制”活动 值得注意的是，“软件设计”所产生的关于软件产品“物理结构”的信息属于“系统开发文档”，而软件产品组成单元的逻辑描述（基于软件功能实现的作用等）则被归入“用户资料”中，基于软件的功能、系统过程对软件产品物理结构进行系统化描述，则是“软件设计”阶段的“手册编制”活动的产物（由此，可从“子系统”/“模块”级描述系统功能的实现与系统工作过程） 与“需求分析”阶段的“手册编制”活动对软件产品的构成与系统过程的描述不同， “软件设计”阶段的“手册编制”活动所描述的 “子系统”是软件产品中“物理子系统” （前者给出的是逻辑意义上的“子系统”），所描述的“模块”是直接反映软件产品物理构成的（前者给出的是“逻辑构成单元”） 在现时的实践中，人们仅在“手册”中给出了关于软件产品逻辑构成及相关系统过程的描述信息，然而，如果能将软件物理构成关联的上述“手册”信息给出，则有益于对“软件设计”阶段工作质量的系统审查，有益于软件质量的提高,软件工程过程及其量化基础概论,关于软件开发活动 “详细设计”阶段 这一阶段的阶段目标是细化“软件设计”阶段所产生的软件产品物理结构中所包含的“结构单元”的设计（“软件设计”侧重于“软件物理结构”的确定及软件产品的结构优化，为了突出这个重点 这对于软件产品整体目标的实现与产品整体优化是至关重要的，这一阶段忽略构成单元的细节），为软件产品的实现提供坚实的基础（“详细设计”的结论可被直接用于软件实现而“软件设计”的结论则不能直接用于软件产品的实现） 在现代软件工程中，一个软件产品的详细设计一旦完成，则意味着从解决软件问题的整体技术需求的角度来看，其主要开发工作已基本结束（剩下的工作虽然在工作量上仍然很大但已不涉及到其用户观察 除非后期工作未能实现其工作目标），因此，这一阶段的“手册编制”软件开发活动应当提供完整的、详细的“用户手册”（事实上，这也为人们确认后期开发工作，尤其是系统测试的工作质量提供了基础，也为人们组织软件的 “验收测试”提供了基础）,软件工程过程及其量化基础概论,关于软件开发活动 “需求分析”活动 在软件工程的每一个生命周期阶段都包含“需求分析”这一项软件开发活动，其工作内容因具体的阶段不同而不同 在“问题定义”阶段，由于其阶段目标是确定待开发的软件产品的“系统抽象”，因此，这一阶段的“需求分析”活动是面向软件问题整体展开的，通过这项活动可导出： 软件功能直接关联的数据对象集（功能 对什么数据对象进行何种处理操作） 对每一个这样的数据对象可执行（需要软件产品实现的）的处理操作集 这些数据对象间的关联 这些数据对象（及其关联的数据处理操作）与用户系统特性（包括其过程特性）间的关联 软件产品的其它整体性需求,软件工程过程及其量化基础概论,关于软件开发活动 在“可行性研究”阶段，其阶段目标是确定待开发软件产品的“系统开发方案”，这一阶段的“需求分析”活动是面向用户系统中与软件产品存在直接关联的部分系统结构 相应的组成部分（其细节被忽略）及其关联 展开的（通常称作“子系统级的需求分析” 子系统：用户系统的子系统），通过这项活动可导出： 各相关子系统中软件功能相关联的数据对象集 新导出的各数据对象关联的数据处理操作集 新导出的数据对象间基于关联子系统的特性（包括子系统的过程特性在内）的关联 新导出的各数据对象与已（在问题定义阶段）导出的数据对象间的关联 解决软件产品开发（设计实现）问题的关键性技术需求及其系统特征,软件工程过程及其量化基础概论,关于软件开发活动 在“软件需求分析”阶段，其阶段目标是确定软件产品的详细逻辑模型，这一阶段的“需求分析”活动基于已获得的需求分析结论对用户系统的软件产品特性需求进行全面深入地分析，以期导出： 软件产品功能相关的所有数据对象（除了已获得的数据对象之外）构成的集合 新导出的各数据对象关联的数据处理操作集 新导出的数据对象间基于用户系统特性（包括其系统过程特性在内）的相互关联 新导出的数据对象（及其关联的数据处理操作集）与已导出的数据对象间基于用户系统特性（包括其系统过程特性在内）的相互关联 数据对象（及其关联的数据处理操作集）与系统状态及其转换间的系统关联,软件工程过程及其量化基础概论,关于软件开发活动 “软件设计”阶段的阶段目标是确定目标软件产品的“物理结构”，它是在软件产品的需求定义已经产生、软件产品的目标要求与系统开发方案已经确定、软件产品的开发/运行平台已被设定的基础上展开工作的，这里的“需求分析”活动旨在为开发人员确定软件产品的物理结构提供支持，为人们形成“软件结构设计方案”建立基础，对之，相应的，有： 分析 对“系统开发方案” 、软件逻辑模型、开发/运行平台的特性进行系统综合分析 分析的目的 确定可行的软件设计方案并优化之 需求 对于软件产品物理结构的系统要求 针对具体的软件产品，存在多种可行的软件产品结构设计方案，这些方案的提出是基于本阶段的“需求分析”活动的，“分析”使开发者明了软件产品结构设计的系统要求,软件工程过程及其量化基础概论,关于软件开发活动 “详细设计”阶段、“编码”阶段、“单元测试” 阶段与“系统测试”阶段的“需求分析”活动都比较简单，其主要内容是分析相应阶段目标实现的基础与系统要求，为相应阶段任务的完成提供基础 各软件生命周期阶段的“产品设计”活动是与相应阶段需要提供的（新增的）“软件配置”相关联的，因为，它们是这些阶段的“产品”；“设计”是确定一个“产品”的“结构”的开发活动，即确定相应“产品”的组成单元及其相互关联 类似于“产品设计” ，“编程”活动也是与相应阶段需要提供的（新增的）“软件配置”相关联的，它们确定相应“产品”的实现，提供符合要求的“软件配置” “测试计划”活动为后续相关阶段中的软件测试（“单元测试” 、“集成测试” 也称“系统测试” 、“验收测试”）确定测试目标、测试数据、测试的顺序性等，为相关测试工作的进行提供基础,软件工程过程及其量化基础概论,关于软件开发活动 在现代软件工程中，如何进一步提高软件开发维护工作的劳动效率是人们极为关注的，在制定测试计划上，有： 软件的“单元测试”发生在单元的“编程”工作完成后，而软件单元实现（“编程”）是直接基于“详细设计”所流出的单元设计细节进行的，不言而喻，在“详细设计”阶段完成“单元测试计划”的制定，其劳动效率是最高的 软件的“集成测试”主要是对软件产品进行面向软件产品物理结构的测试，而软件产品的“物理结构”是在“软件设计” （“产品设计”/“总体设计”/“概要设计”）阶段确定的，因此，“系统测试计划”应当在这一阶段制定 “验收测试”的目的在于确认软件产品的设计实现是否完整准确地反映了软件的问题要求（它在工程上主要表现为以“逻辑模型”为主体的“需求规格说明”），而软件的“需求规格说明”是在“需求分析”阶段最终确定的，因此，软件的“验收测试计划”应在这一阶段制定,软件工程过程及其量化基础概论,关于软件开发活动 “测试计划” 由软件工程的相关知识可知，对于一个软件产品，不可能进行“完全测试”（即使所讨论的对象是软件产品的一个组成单元），这就使得在具体的测试工作进行之前制定相应的“测试计划”变得极为重要 测试计划 这使得“测试计划”有着两重的属性： 作为“开发活动”的“测试计划”，通常人们说成是“制定测试计划”，其目的是针对确定的测试问题（“单元测试”/“集成测试”/“验收测试”），基于软件产品的“可靠性”目标和项目所分配的资源，制定既能使软件产品的目标实现又不突破所分配资源（进度的限制、生产率的限制、成本/工作量的限制等限制性条件）的测试工作计划 作为“软件配置”的“测试计划”，它是“测试计划”开发活动的产物，详细地描述了应当检测的问题（专业上称作“故障”）、测试用例（被测对象的输入/输出序列）、测试的过程等,软件工程过程及其量化基础概论,关于软件开发活动 “验证与确认” 面向本生命周期阶段新增的“软件配置”的开发活动，通过进行这项活动，以求确认： 新增“软件配置”的质量是满足软件产品的目标要求的 新增“软件配置”的内容是必要的（基于阶段目标） 在软件工程科学中，通常将“验证与确认”归入“软件测试”中，这是因为，支持这两者的知识基础是一致的、其目的性也是基本相同的（两者的直接作用就是为了发现相关“软件配置”中可能存在错误与疏漏） 然而，这两者在下述方面是存在差异的： “测试”通常是指通过运行软件来发现可能存在的错误与疏漏，因此，“测试”发生在软件产品的实现完成之后；而“验证与确认”则通常不是通过运行软件来完成的 “测试”的对象是先前阶段所产生的”软件配置”，而“验证与确认”则面向本阶段所产生的“软件配置”,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 软件工程的量化处理也包括关于软件产品（“软件配置”）的量化，对之，相应的，有： 软件产品是一个有机的整体（“软件系统”），其“规模” （可用“源指令行数”来标识之）是其重要的量化指标 软件产品既有着其“逻辑结构”，也有着其“物理结构” 软件产品的“逻辑结构” 为了实现其确定的外部特性软件产品应当包含的组成部分及其关联（它指向软件产品在逻辑意义上的构成部分及其关联），之所以称之为软件产品的“逻辑结构”，是因为这里的“组成单元”是逻辑意义上的，在实际交付的软件产品中并不一定存在这样实际构成（这里的“组成单元”可以对应着交付的软件产品中多个相关的构件，也可以对应着交付的软件产品中某个实际构件的一种特性），相应的，“逻辑结构”中的“单元间关联”所反映的也不一定是交付的软件产品中实际存在的软件构成间的实际关联,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 软件产品的“逻辑结构”是在“软件定义时期”确定的，其所面向的是软件产品的功能需求，指出为了实现软件产品的功能目标软件理应包含的组成成分及其关联 软件产品的逻辑结构有着两种描述方式： 以“组件”为单元的软件逻辑结构描述 以“模块”为最简单元的三层软件逻辑结构描述 确定并规范地描述软件产品的逻辑结构，其目的在于： 系统化地描述已产生的软件配置，为后续的软件产品开发活动提供系统支持 为更准确地估算后期开发的开发成本以便能更有效地通过管理控制有效控制软件工程确立基础 以“组件”为软件产品逻辑构成单元来描述软件产品逻辑结构，在实践中发生在“可行性研究”阶段，其主要作用是支持对于软件开发/维护成本进行较准确地估算,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 在现代软件工程实践中，通常把“问题定义”和“可行性研究”两个软件生命周期阶段合在一起称作软件产品开发的“系统分析”阶段，以之作为软件产品开发的“前期开发工作” （在之后的各开发阶段在管理上被归入“项目管理”），通过这一阶段的工作，使软件产品的系统目标、软件产品的系统开发方案、软件开发的总体计划（在一些著述中称作“项目计划”）被确定下来，如果软件产品是“受托开发” （“合同开发”），这一阶段的开发工作一旦结束即与委托方签订软件产品开发合同 在软件开发合同中，需要给出的主要内容有： 软件产品应达到的功能目标 软件产品应达到的新能目标与质量目标 软件产品的预计开发费用与交付时间 软件产品投入运行后的维护方式与预计维护费用,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 在进行软件产品开发、维护费用的估算时，为了使得估算结果较为准确，应当使估算的基础建立在“可行性研究”所提供的软件高层逻辑模型上（由之可得到软件产品基于组件的逻辑结构），基于对软件产品高层逻辑模型（及软件产品性能/质量目标）实现所需软件技术的系统理解与把握，可以系统地确定软件产品以“组件”为单元的逻辑结构、估算出各“组件”的规模及使“组件”实现关联所需的“开发工作量”，由此可以较准确地估算软件产品的规模，并进而估算出软件产品的“开发成本” （或“开发工作量”与进度）与维护成本，这样一来，可： 与开发的委托方签署一个双方都可接受并能按要求完成相关工作的合同 为在成立项目组后开始软件产品的开发活动确立了基础，也为软件开发组织有效控制软件工程确立了坚实的基础,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 “软件需求分析”阶段在现代软件工程实践中有着特殊的地位，这主要表现在： 这是“软件定义时期”中的最后一个开发阶段 这一阶段工作结束后，软件产品的需求细节将被确定，随后的开发工作主要关注如何使交付的软件产品在预期的资源消耗下达到确定的产品目标 在实施“项目管理”的软件工程中，它是软件开发项目组开始运作所要历经的第一个软件生命周期阶段，这时，除了要完成软件工程学意义上的需求分析工作外，还要为“项目组”制定全面的开发工作计划，因此，在一些软件工程著述中称其为“计划与需求（分析）”阶段，相应的软件计划将用于项目组完整工作的整体性管理控制实施的依据 为了制定切实可行的软件计划，需要有关于后期开发工作的、准确的软件开发成本估算,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 在“计划与需求”阶段中的“需求分析”活动结束后，软件产品的详细逻辑模型即已导出，这使得可将“可行性研究”阶段所确立的软件产品逻辑结构细化，形成三层描述的软件产品逻辑结构，这三个层次分别是： 系统层 抽象软件产品的总体需求 子系统层 这里的“子系统”即是“可行性研究”阶段所导出的软件产品逻辑结构中的“组件” 模块层 抽象本阶段的“需求分析”活动导出的分析结论所形成的、细化的软件产品逻辑结构 在这种结构框架下，软件产品的整体功能（及其他系统目标，主要考虑的是软件的功能）由多个逻辑意义上的子系统及其关联实现；每一个这样的子系统的目标（功能目标及其他系统目标）由一个以上（特殊的可以是一个）的逻辑意义上的模块（通常称其为“功能模块”，有时即简称其“模块”）及其关联实现,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 在这种结构框架下,人们在估算软件开发成本时,可以： 可以把“模块”视为软件产品的最小构成单元并较准确地估算出其规模（“交付的源指令行数”）并相应的估算出各子系统及整个软件产品的规模 可以基于模块的较准确的成本估算相应导出软件产品较准确的成本估算 在进行软件成本估算时,可对影响软件开发成本的因素进行“构造性”考虑以获得若干个相对独立的“成本驱动因子”使之反映出影响软件开发成本的主要因素 在进行软件成本估算时，可针对“模块”/”子系统“对于软件技术需求的特殊性考虑软件开发成本的软件生命周期阶段分布，由此使估算结果进一步精确化 基于已获得的经验数据可将软件产品的成本估算模型化（通过量化成本驱动因子与开发阶段影响）,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 在“软件开发时期”，极具特色的软件生命周期阶段是： “详细设计”阶段、“编码”阶段和“单元测试”阶段，这三个阶段所需耗费的软件开发工作量占软件产品开发总工作量的60%左右，但可安排很多软件开发人员同时进行工作以缩短软件产品的开发周期，一些软件工程著述中将它们合在一起，称作“编程”阶段 “系统测试”阶段，其工作任务是在软件“单元测试”阶段的工作完成后，按照软件产品结构设计所确定的软件产品“物理结构”将“单元”进行“集成”并对所涉单元间的关联进行“测试”，基于此，一些软件工程著述中将其称作“集成与测试”阶段，这一阶段的特殊性主要在于：一方面，所需耗费的软件开发工作量在软件产品的总开发工作量中占据很大的比值；另一方面，这一阶段的软件开发工作量随软件产品非功能特性要求的不同与开发工作的组织等不同变异很大,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 在“软件开发时期”，第一个，也是最重要的是确定软件产品“物理结构”的软件生命周期阶段，这一开发阶段通常被称为“总体设计” 、“概要设计” 、“软件设计”或者“产品设计”，其阶段目标是确定软件产品的“物理结构” 与软件产品的“逻辑结构”不同，软件产品的“物理结构”反映的是一个软件产品中实际存在的构成单元及其相互关联，对之，相应的，有： 程序模块 它们是软件产品中可被独立存储、编译、引发执行（因而可在“单元测试”阶段被单独测试）、可被独立调度的系统共享“代码”资源 数据单元 可被多于一个的程序模块共享的数据结构（可被称为“全局性数据结构”），在软件工程实践中，通常将其与共享该数据结构的程序模块一起备用相关联的编程语言中提供的设施（如“面向对象的程序设计语言”中的“类”管理机制）集成在一起,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 在软件工程实践中，通常通过一个程序模块（而不是编程语言的设施）将一个数据单元与共享它的程序模块集集中管理使得外部对该数据单元及其逻辑独立成份的访问都通过该模块来实现（当然，共享该数据单元的模块在软件产品中通常仍可被独立引用），由此使相应软件产品的组成部分（它们通常有着独立的逻辑抽象 对应着确定的软件需求）与软件产品的其他组成保持物理意义上的相对独立性，这样形成的软件产品独立组成被称为软件产品的“子系统” （在一些软件著述中，也将通过编程语言的设施将数据单元及共享它的程序模块集成后形成的软件成份称作“子系统”，但在有些著述中则将其与“子系统”区分开来，称其为“组件”） 由于一个数据结构可以包含另一个数据结构作为其独立成份，由此形成软件产品中数据单元间的层次关联，因此，共享一个数据结构的“模块”也可实际上是一个“子系统”并进而形成软件产品中多层次的“子系统”,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 包含在两个“子系统”中的数据单元可以是同一个数据单元不同的逻辑独立成份，这样的两个数据单元间存在“并列”关联，相关的两个子系统可从属于软件产品中的同一个子系统 由此，一个软件产品的“物理结构”可被描述为三层/四层的物理结构 软件产品的三层物理结构为： 软件产品 也被称为“软件系统” “子系统” 由一个程序模块作为“管理者”模块、包含一个以上的数据单元和多个程序模块作为其内容，也可包含其他子系统作为其内容；特殊的“子系统”由一个数据单元和共享该数据单元的程序模块组成 数据单元和程序模块 有时统称其为“模块” 四层物理结构描述包含“组件”结构层次,软件工程过程及其量化基础概论,软件产品与软件工程的量化处理 在“软件开发时期”的“产品设计” （也称“总体设计”/“概要设计”/“软件设计”）阶段，软件的“物理结构”被确定，“系统测试计划”也被相应确定，这时，软件的规模可被精确估算出来，为了有效控制“软件开发时期”其余生命周期阶段的开发工作，人们可能需要制定相应的软件开发计划（面向“软件开发时期”余下各阶段的开发工作） 综合而论，软件工程的量化包括： 软件过程的量化 软件生命周期阶段的量化 软件产品的量化,问题定义阶段,问题定义阶段的目标与任务 阶段目标 确定目标软件产品的系统抽象 一个软件产品的系统抽象： 软件产品的功能定义 软件产品的性能要求 软件与用户系统间的关联 软件的系统作用过程 软件产品的“功能” 指出软件产品被加载到计算机系统后系统能给用户带来的信息、信息处理便利，包括： 由此可使用户获得其所需的确定信息资源（缺乏该软件，用户将不能直接获得这些信息资源） 由此可使得一些用户关注的数据能被以用户所需的方式被系统化处理（缺乏该软件，相应数据的处理将不能系统化地按用户需求的方式进行）,问题定义阶段,问题定义阶段的目标与任务 软件产品的“性能” 软件产品在实现其功能时因使用的技术不同而赋予其的用户可见特性的系统评价，主要包括： 可靠性 因人们对相关问题的关注点的不同而有着稍有差异的说法： 若从软件作为一种产品、“可靠性”为对于一个产品的可用性的系统评价出发，“可靠性”可被定义为：在系统的一个运行时段中，系统可按预期处理相关问题的概率 若从软件工程学的目标出发、将“可靠性”视为开发高品质软件应探索的技术目标问题，“可靠性”可被定义为：完整准确地反映软件的问题抽象（如果人们在开发软件产品的过程中可使得软件产品的设计实现完整准确地反映软件的问题抽象，必然会使得所得到的软件产品满足人们对之的可靠性要求）,问题定义阶段,问题定义阶段的目标与任务 如果从约束软件产品开发的成本与开发工作的角度出发，把“可靠性”作为目标，以之来来控制软件开发资源的投入、工作质量目标，可按软件产品的失效会给软件用户带来的损害的程度将“可靠性”划分为若干个等级并由此确定其对软件产品开发的影响（如果软件的失效仅给用户带来工作上的不便“可靠性”的等级定为“低” 则可简化开发工作、降低软件开发成本；反之，如果软件的失效会给用户带来人生伤害等严重后果“可靠性”的等级定为“很高” 则必须增加软件开发成本、强化对于软件开发工作/软件中间产品的质量的管理控制、实施极严格的系统测试）；此时，通常将软件的“可靠性”等级定为“很低” 、“低” 、“一般” 、“高”和“很高” ；相应的，这需要将相应可靠性等级给出严格定义并对各可靠性等级下软件开发工作/软件空间产品的质量目标给出系统化的规范要求；同时，需要对可靠性等级对成本的影响量化,问题定义阶段,问题定义阶段的目标与任务 可修改性（包含软件的“可移植性”和“可维护性”等在内） 指在软件产品投入运行后改变软件产品的设计实现的简便性；可修改性越好，改变软件产品的设计实现所需的代价就越低（相应软件产品的开发成本自然就越高） 有效性 软件产品的“有效性”通常从两个方面来评价: 软件产品的技术特性评价 从这一角度出发，“有效性”具有定义：“充分有效的利用系统资源”，由此，一个软件产品的有效性评价指该软件产品的设计实现对于其工作平台可用资源的有效利用情况的系统评价 软件产品的外部特性评价 在软件产品投入运行后，由于该软件的作用，相应计算机系统在单位时间内的信息流量（也称“信息流通量”）被称为该软件产品的有效性（也可用实测的信息流通量与理想/理论信息流通量的比值来度量软件产品的有效性）,问题定义阶段,问题定义阶段的目标与任务 可理解性 通常，人们将一个软件产品运行使得下列特征综合性的归纳为软件的“可理解性”： 要求用户输入数据或自行确定操作时所给出的“提示信息”的用户易理解性与不易误解性 在用户向系统提供输入数据时，针对用户输入的“非法数据”，软件的检测能力、软件所给出的“错误信息”的用户易理解性与不易误解性 软件检测系统工作异常（因获得的输入数据等使系统的工作处于“异常”状态）的能力 软件的预警能力 软件发现系统工作异常时发出的系统消息的用户易理解性与不易误解性 软件预警机制发出的“警告信息”的用户易理解性与不易误解性,问题定义阶段,问题定义阶段的目标与任务 软件与用户系统间的关联 在现代，典型的软件产品是“应用软件” 。由之所确立的一个计算机系统通常是作为软件用户关联的一个客观系统（可将其简称为“用户系统”）中的一个相对独立的子结构（“子系统”）存在并发挥作用的。这样，相应计算机系统（“软件”）与用户系统中的一些确定成分之间的关联是人们在开发软件产品时首先应当高度关注的，此即“软件与用户系统间的关联” 软件的系统作用过程 这里的“系统”指“用户系统”，“系统作用过程”是指当拟开发的软件（“目标软件产品”）得以发挥作用时“用户系统”（“新系统”）的相关过程特性，由此可反映出软件产品的用户系统效能。从软件产品开发的角度出发，这为软件产品的分析、设计与实现确立了整体性的约束条件（软件产品的系统分析可以此为线索展开，软件产品的设计实现必须不违背这里确定系统规范），为确保目标软件产品的实用性确立了基础,问题定义阶段,问题定义阶段的目标与任务 软件产品的功能定义 软件产品的功能定义仅关注软件产品整体可见的、面向用户的软件功能，且其应当使用用户系统中的术语描述（以便于用户的参与），功能定义应当给出关于软件功能的下述属性： 功能的系统命名 软件产品中规范的符号命名 功能的用户系统标准名 功能的（用户系统）别名 如果存在，可有多个 被处理数据对象的系统命名 被处理数据对象的用户系统标准名 被处理数据对象的别名 结果数据对象的系统命名 结果数据对象的用户系统标准名 结果数据对象的别名,问题定义阶段,问题定义阶段的目标与任务 问题定义阶段的开发任务 总的来说，问题定义阶段作为软件生命周期的第一个生命周期阶段，其任务就是通过对用户系统进行总体性的分析，为目标软件产品确定一个可为用户接受的、可在预期的开发费用与开发周期内实现的系统目标 所谓“用户可接受的”软件产品，是指： 软件产品的功能是用户所期盼的 软件的投入 - 产出特性是对用户有益的 软件的应用将不会造成任何对于用户损害与妨碍 软件产品的功能反映的是软件支持用户系统的信息处理要求的能力，用户系统之所以需要软件产品的支持，是因为用户系统的系统优化是与适时获得满足确定要求的信息资源密不可分的；一般地讲，用户系统中有许多信息需要处理，但并非所有的信息处理需求的满足都能导致用户系统特性的改善与优化,问题定义阶段,问题定义阶段的目标与任务 为使软件产品具有期望的实用性，使软件产品的功能目标与用户期盼保持一致是必须的，这就需要对用户系统进行系统分析，通过这种分析了解用户系统特性与信息资源需求、与信息处理的有效性间的系统关联，由此确定软件产品的功能目标（对用户系统中的哪些数据进行怎样的处理） 在知识需求上，相关知识属于传统经济学 宏观经济学/微观经济学 范畴（“软件工程经济学”的基础性内容） 一个软件产品要为用户所接受，除了其功能能为用户所接受外，另一个重要的方面是软件的“投入 产出”特性能够为用户所接纳，这里的“投入”主要包括： 获得软件产品本身所需的直接费用 软件运行时所需配套的其他软件的购置费用 如果软件运行还需诸如“操作系统” 、 “支撑软件”等 软件维护费用 软件运行所需的相关费用（包括人员费用等在内）,问题定义阶段,问题定义阶段的目标与任务 硬件平台的购置费用 系统运行维护等其他相关费用 一个其功能为用户所期盼的软件产品在投入运行后是能为用户带来可核算（可评价）的收益的，这可简单地称作软件产品的“产出”；仅当软件产品的“投入”低于软件产品的“产出”时，用户才能乐意使用该软件产品 相关知识被归入“微观经济学”的范畴 所谓“软件的应用将不会造成任何对于用户损害与妨碍” 通常是指：软件的用户除了应对其自身的相关问题（如企业的经济利益获取）外，还要承担确定的社会责任，一个在现代环境下可被称为“实用”的软件产品除了应当给用户带来确定的利益（基于软件产品的“投入 产出”特性分析结论确定）外，还应当不因此影响到用户的社会责任承担等问题 现代软件工程学倡导基于“人类经济学”相关成就而不是传统经济学成就来确定一个软件产品的系统目标,问题定义阶段,问题定义阶段的目标与任务 “问题定义”阶段的主要开发工作就是对用户系统及其环境进行系统分析，通过这种分析来确定软件产品的系统目标 由于不同软件产品在规模、所从属的应用问题域等诸方面的差异，使得“问题定义”阶段的任务及支持相关开发任务完成的软件方法技术离散性很大，难以形成一般性研究结论，但一些面向过程的指导是具有一般意义的 “问题定义”的首要任务是确定软件产品的功能目标 通过对用户系统的系统分析，人们可以确知： 用户系统的系统分类及系统特性评价 用户系统的效能模式及其与信息处理机制间的关联 用户系统现行信息处理机制的特性评价 优化用户系统信息处理机制对用户系统效能的影响、优化用户信息处理机制所需耗费概算、信息处理机制优化所涉及的用户系统构成,问题定义阶段,问题定义阶段的目标与任务 通过这些系统分析，人们可以确认开发一个相应的软件产品的必要性与可能性；在确认了其必要性的基础上即可相应确定软件产品的功能目标，并由此可确定： 在软件产品的作用得以发挥时将给用户带来的利益 软件产品的功能与系统特性（包括系统作用过程在内）间的关联 一些著述中记作“软件功能与系统过程” 软件失效将给用户带来的损害 由此可确定软件产品的“所需可靠性”等级、软件可靠性目标、软件成本 为使用户系统获得相应利益，软件关联的计算机系统（由软件产品的功能所确定的计算机系统抽象）应当达到的系统有效性 这是确定软件“有效性”目标的基础 软件功能关联的用户系统机制在软件产品预期的“寿命”中可能发生的变化及其对软件产品特性的影响 这是确定软件产品“可修改性”目标的重要依据,问题定义阶段,问题定义阶段的目标与任务 软件产品功能目标的确定，也相应揭示了： 软件产品在其最高逻辑抽象上应当识别/执行的： 数据对象集 各相关数据对象的用户系统命名等 各数据对象所关联的、软件整体可见的数据处理操作集 各相关数据处理操作的用户系统命名等 各所涉数据对象间的用户系统关联 软件产品功能目标关联的数据对象、数据对象关联的数据处理操作、数据对象间的系统关联组成了软件产品最高抽象上的逻辑模型 它是之后的软件生命周期阶段（“可行性研究”阶段）的“需求分析”活动进行的基础 软件功能与用户系统特性间的相互关联的确定，为人们利用“系统流程图”来描述这种关联（这对后续阶段的开发工作的有序进行是极为重要的），并进而确认软