厦门门户网站制作服务商,登封网站建设公司,网站图片怎么做超链接,微信小程序网站建设方案第五章节——软件工程基础知识 软件工程基础知识 第五章节——软件工程基础知识一、软件工程概述1. 计算机软件2. 软件工程基本原理3. 软件生命周期4. 软件过程 二、软件过程模型1. 瀑布模型2. 增量模型3. 演化模型#xff08;原型模型、螺旋模型)4. 喷泉模型5. 基于构建的开发…第五章节——软件工程基础知识 软件工程基础知识 第五章节——软件工程基础知识一、软件工程概述1. 计算机软件2. 软件工程基本原理3. 软件生命周期4. 软件过程 二、软件过程模型1. 瀑布模型2. 增量模型3. 演化模型原型模型、螺旋模型)4. 喷泉模型5. 基于构建的开发模型6. 形式化方法模型7. 统一过程UP模型8. 敏捷方法 三、需求分析1. 软件需求2. 需求分析原则3.需求工程 四、系统设计1. 概要设计2. 详细设计 五、系统测试1. 系统测试与调试2. 传统软件测试策略3. 测试方法4. 调试 六、运行和维护1. 系统转化2. 系统维护概述 七、软件项目管理1. 软件项目管理涉及的范围2. 软件项目估算3. 进度管理4. 软件项目的组织5. 软件项目配置6. 风险管理 八、软件质量1. 软件质量特性2. 软件质量保证3. 软件评审4. 软件容错技术 九、软件度量1. 软件度量分类2. 软件复杂性度量 十、软件工具与软件开发环境 一、软件工程概述
软件工程指的是应用计算机科学、数学及管理科学等原理以工程化的原则和方法来解决软件问题的工程目的是提高软件生产率、提高软件质量、降低软件成本。
1. 计算机软件
计算机软件指的是计算机系统中的程序及其文档。按照软件应用领域将计算机软件分为以下十类
系统软件应用软件工程/科学软件嵌入式软件产品线软件Web应用软件WebApp人工智能软件开放计算网络资源开源软件 2. 软件工程基本原理
美国著名的软件工程专家B.W.Boehm于1983年提出了软件工程的七条基本原理
用分阶段的生命周期计划严格管理坚持进行阶段评市实现严格的产品控制采用现代的程序设计技术结果应能清楚地审查开发小组的人员应少而精承认不断改进软件工程实践的必要性 3. 软件生命周期
同其他事物一样一个软件产品或软件系统要经历孕育、诞生、成长、成熟、衰亡等阶段一般称为软件生存周期。软件生存周期包括以下七个方面
1可行性分析与项目开发计划 这个阶段主要确定软件的开发目标及其可行性。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档有可行性分析报告、项目开发计划。
2需求分析 该阶段的任务不是具体的解决问题而是要确定软件系统要做什么确定软件系统的功能、性能、数据和界面等要求从而确定系统的逻辑模型。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档主要是软件需求说明书。
3概要设计 该阶段开发人员把确定的各项功能需求转换成需要的体系结构。概要设计就是设计软件的结构明确软件由哪些模块组成 这些模块层次结构是怎样的调用关系是怎样的每个模块的功能是什么。参与该阶段的人员有系统分析师、软件设计师。产生的文档主要是概要设计说明书。
4详细设计 该阶段的主要任务是对每个模块的功能进一步详细、具体的描述。参与该阶段的人员有软件设计师、程序员。产生的文档主要是详细设计文档。
5编码 把每个模块的控制结构转换成计算机可接受的程序代码即写成某种特定程序设计语言表示的源程序清单。
6测试 测试是保证软件质量的重要手段。参加测试的人员通常是另一部门(或单位〉的软件设计师或系统分析师。产生的文档主要是软件测试计划、测试用例、测试报告。
7维护 软件维护是软件生存周期中时间最长的阶段。软件己交付且正式投入使用后便进入维护阶段。 对软件进行修改的原因包括: ①运行中发现隐含的错误而需要修改②为了适应变化的(或变化后的工作环境而修改③需要对软件功能进行扩充、增强而进行的修改④为将来软件维护活动做预先准备。 文档是软件开发使用和维护中的必备资料。文档能提高软件开发的效率保证软件的质量而且在软件的使用过程中有指导、帮助、解惑的作用尤其在维护工作中文档是不可或缺的资料。 4. 软件过程
软件开发中遵循一系列可预测的步骤即路线图该路线图称为“软件过程”。过程是活动的集合活动是任务的集合。 软件过程的能力成熟度模型: 1能力成熟度模型CMM 能力成熟度模型CMM是对软件组织进化阶段的描述随着软件组织定义、实施、测量、控制和改进其软件过程软件组织的能力经过这些阶段逐步提高。将软件过程改进分为五个成熟度级别 1能力成熟度模型CMMI
CMMI是若干过程模型的综合和改进是支持 多个工程学科 和领域的、系统的、一致的过程改进框架。CMMI提供了两种表示方法阶段式模型和连续式模型。 阶段式模型。 结构类似于CMM它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版本中有五个成熟度等级。
初始级: 过程不可预测且缺乏控制。已管理级: 过程为项目服务。已定义级: 过程为组织服务。定量管理级: 过程已度量和控制。优化级: 集中过程改进。
连续式模型 关注每个过程域的能力一个组织对不同的过程域可以达到不同的过程域能力等级简称CL。CMMI中包括六个过程域能力等级。
CL0 (未完成的)﹔过程域未执行。CL1 (已执行的): 其共性目标是过程将可标识的输入工作产品转换成可标识的工作产品CL2 (已管理的): 其共性目标集中于已管理的过程的制度化。CL3 (已定义级的): 其共性目标集中于已定义的过程的制度化。CL4 (定量管理的: 其共性目标集中于可定量管理的过程的制度化。CL5 (优化的): 使用量化手段改变和优化过程域。
二、软件过程模型
软件过程模型习惯上称为软件开发模型它是软件开发全部过程、活动和任务的结构框架。典型的软件过程模型有瀑布模型、增量模型、演化模型原型模型、螺旋模型)、喷泉模型、基于构件的开发模型、形式化方法模型和统一过程模型等。
1. 瀑布模型
瀑布模型将软件生命周期中的各个活动规定为依据线性顺序连接的若干阶段的模型包括需求分析、设计、编码、测试、运行与维护。如同瀑布流水逐级下落如下图所示。瀑布模型以项目的阶段性评审和文档控制为手段有效地对整个开发过程进行指导所以它是 以文档作为驱动、适合软件需求很明确的软件项目的开发。
优点: 容易理解、成本低、强调开发的阶段性早期计划及需求调查和产品测试。缺点: 客户必须能完整、正确和清晰地表达需求;难以评估项目进度状态;项目快结束时出现大量的集成与测试工作;需求或设计的错误往往只有到了项目后期才能被发现对项目风险的控制能力较弱通常会导致项目延期开发费用超出预算。 2. 增量模型
增量模型将需求分段为一系列产品每一个增量都可以分别开发如下图。
优点 第一个可交付的版本成本和时间很少。开发由增量表示的小系统所承担的风险不大;由于很快发布了第一个版本因此可减少用户需求的变更。同时它也具有瀑布模型所有的优点。缺点 若没有对用户的变更要求进行规划那么产生的初始增量可能会造成后来增量的不稳定;若需求不像早期思考的那样稳定和完整那么一些增量就可能需要重新开发或重新发布;管理发生的成本、进度和配置的复杂性可能会超出组织的能力。 3. 演化模型原型模型、螺旋模型)
经典的演化模型有原型模型和螺旋模型。演化模型适用于软件需求不够明确的情况。
原型模型快速原型模型 原型是预期系统的一个可执行版本。原型模型开始于沟通目的是定义软件的总体日标、标识需求然后快速构建原型并交付用户使用收集客户反馈意见并在下一轮中对原型进行改进。原型模型适用于用户需求不明确、需求经常变化且系统规模不太大、不太复杂的软件项目。
螺旋模型 对于一个复杂的大项日开发一个原型往往达不到要求。螺旋模型将瀑布模型和原型模型结合起来加入两种模型均忽略的风险分析弥补了这两种模型的不足。螺旋模型中的每个螺旋周期分为以下四个步骤:①制订计划:确定软件目标选定实施方案明确项日开发的限制条件。②风险分析:对所选方案进行分析识别风险消除风险。③实施工程:实施软件开发验证阶段性产品。④用户评估:评价开发工作提出修正建议建立下一个周期的开发计划。螺旋模型强调风险分析与瀑布模型相比支持用户需求的动态变化。螺旋模型适合用于庞大、复杂且具有高风险的系统。 4. 喷泉模型
喷泉模型是以用户需求为动力以对象为驱动的模型适用于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。喷泉模型如下图所示。
优点 各个阶段没有明显的界线开发人员可以同步进行;可以提高软件项目的开发效率节省开发时间。缺点 由于在各个开发阶段是重叠的在开发过程中需要大量的开发人员不利于项目的管理;要求严格管理文档使得审核的难度加大。 5. 基于构建的开发模型
基于构件的开发模型是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件,也可以是商品化成品软件构件。基于构建的开发模型具有许多螺旋模型的特点它本质上是演化模型需要以迭代方式构建软件。其不同之处在于基于构件的开发模型采用预先打包的软件构建开发应用系统。
构件是面向软件体系架构的可复用软件模块。构件(Component是可复用的软件组成成份可被用来构造其他软件。它可以是被封装的对象类、功能模块、软件框架Framework)、软件架构、文档、设计模式等。 6. 形式化方法模型
形式化方法是建立在严格数学基础上的一种软件开发方法主要活动是生成计算机软件形式化的数学规格说明。 7. 统一过程UP模型
统一过程模型是一种“用例和风险驱动以架构为中心迭代并增量”的开发过程由方法和工具支持。统一过程定义了四个技术阶段及其主要工作产品: (1起始阶段 专注项目的初创活动主要工作产品有构想文档、初始用例模型、初始项日术语表、初始业务用例、初始风险评估、项目计划、业务模型及多个原型需要时。 (2精化阶段 主要工作产品有用例模型、补充需求、分析模型、整体体系结构描述、可执行的软件休系结构原型、初步设计模型、修订的风险列表、项目计划及初始用户手册。 (3构建阶段 关注系统的构建产生实现模型主要工作产品有设计模型、软件构件、集成软件增量、测试计划及步骤、测试用例及支持文档用户手册、安装手册等。 (4移交阶段 关注软件提交方面的工作产生软件增量主要工作产品有提交的软件增量、测试报告和综合用户反馈。统一过程的典型代表是RUP (Rational Unified ProcessRUP是UP的商业扩展完全兼容UP比UP更完整、更详细。 8. 敏捷方法
敏捷方法的总体目标是通过“尽可能早地、持续地对有价值的软件进行交付”使客户满意。敏捷过程的典型方法有很多每一种方法基于一套原则这些原则实现了敏捷方法所宣称的理念即敏捷宣言。常用的敏捷方法
极限编程XP)四大价值观沟通、简单性、反馈和勇气。水晶法(Crystal)认为人对软件质量有重要的影响随着开发人员素质的提高项目和过程的质量〈也随之提高。并列争球法(Scrum)使用迭代的方法其中把每30天一次的迭代称为一个“冲刺”并按需求的优先级别来实现产品。自适应软件开发(ASD)是一种敏捷软件开发方法倡导根据需求的变化及时调整开发过程实现软件开发的自适应性能力。敏捷统一过程(AUP)采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。 三、需求分析
需求分析 也称为软件需求分析、系统需求分析或需求分析工程等是开发人员经过深入细致的调研和分析准确理解用户和项目的功能、性能、可靠性等具体要求将用户非形式化的需求表述转化为完整的需求定义从而确定系统必须做什么的过程。
1. 软件需求
软件需求包括以下内容
功能需求 考虑系统要做什么什么时候做如何修改或升级。性能需求 考虑软件开发的技术性指标如存储容量限制执行速度响应时间吞吐量等。用户或人的因素 考虑用户的类型环境需求 考虑软件应用的环境界面需求 考虑来自其他系统的输入或到其他系统的输出等文档需求 考虑需要那些文档文档针对那些读者数据需求 考虑输入输出格式接收发送数据的频率数据的精准度数据流量数据保持时间。资源使用需求 考虑软件运行时所需要的资源/安全保密需求 考虑是否需要对访问系统或系统信息加以控制。可靠性需求 考虑系统的可靠性需求系统是否必须检测和隔离错误错误后重启系统所允许的时间等。软件成本消耗或开发进度需求 考虑开发是否有规定的时间表其他非功能性需求 如采用某种开发模式确定质量控制标准里程碑和评审验收标准等。
2. 需求分析原则
需求分析过程有不同的分析方法它们要遵循的操作原则有
必须能表示和理解问题的信息域。必须能定义软件将完成的任务。必须能表示软件的行为。必须划分描述数据、功能和行为的模型。分析过程应该从要素信息移向细节信息。
3.需求工程 需求工程是一个不断反复的需求定义、文档记录、需求演进的过程并最终在验证的基础上冻结需求。需求工程可以细分为六个阶段:
需求获取。需求分析与协商。系统建模模型以一种简洁、准确、结构清晰的方式系统地描述软件需求。常用的需求分析方法有面向数据流的结构化分析方法SA面向对象的分析方法OOA。需求规约;通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准给出对目标软件的各种需求作为用户和开发者之间的一个协议。需求验证;其目的是要检验需求功能的正确性、完整性和清晰性是否能够反映用户的意愿。需求管理。
四、系统设计
进入设计阶段要把软件“做什么”的逻辑模型转换成“怎么做”的物理模型。系统设计的主要内容包括新系统总体结构设计、代码设计、输入设计、输出设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。主要目的就是为系统制定蓝图。常用的设计方法有:面向数据流的结构化设计方法(SD)、面向对象的设计方法OOD)。系统设计包括两个基本的步骤:概要设计、详细设计。
1. 概要设计
概要设计主要包括
软件系统总体结构设计将系统按功能划分成模块;确定每个模块的功能;确定模块之间的调用关系;确定模块之间的接口即模块之间传递的信息;评价模块结构的质量。数据结构及数据库设计如E-R图。编写概要设计文档概要设计说明书、数据库设计说明书、用户手册及修订测试计划。评审。
2. 详细设计
详细设计主要包括
对每个模块进行详细的算法设计对模块内部的数据结构进行设计对数据库进行物理设计即确定数据库的物理结构其他设计代码设计输入/输出设计用户界面设计编写详细设计说明书评审
系统设计的结果是一系列的系统设计文件这些文件是物理实现一个信息系统包括硬件设备和编制软件程序的重要基础。
五、系统测试
1. 系统测试与调试
系统测试是为了发现错误而执行程序的过程成功的测试是发现了至今尚未发现的错误的测试。
测试的目的是以最少的人力和时间发现潜在的各种错误和缺陷。信息系统测试包括软件测试、硬件测试、网络测试。 测试应遵循的基本原则 ①应尽早并不断地进行测试;②测试工作应避免原先开发软件的人员或小组参与;③设计测试方案时要确定输入数据还要根据系统功能确定预期的输出结果;④设计测试用例时要设计合理、有效的输入条件还要包含不合理、失效的输入条件。人们在测试时通常忽略了对异常、不合理、意想不到的情况进行测试这可能就是隐患;⑤在测试时要检查程序是否做了该做、不该做的事多余的工作会影响程序的效率;⑥严格按照测试计划进行测试;⑦妥善保存测试计划、测试用例;⑧要精心设计测试用例。
测试的过程包括①制定测试计划;②编制测试大纲;⑧根据测试大纲设计和生产测试用例;④实施测试;⑤生成测试报告。 2. 传统软件测试策略
软件测试分为四步单元测试集成测试确认测试和系统测试
1单元测试 单元测试特称模块测试在模块编写完成且编译无误后进行侧重于模块中的内部逻辑和数据结构。单元测试环境如下图由于模块不是独立运行的程序各模块之间存在调用与被调用的关系。在对每个模块进行测试时需要开发两种模块 驱动模块相当于一个主程序 桩模块用来代替测试模块中所调用的子模块 (2) 集成测试 集成测试就是把模块按系统设计说明书的要求组合起来进行测试。 集成测试通常有以下两种方法:
非增量集成 分别测试各个模块再将这些模块组合起来进行整休测试。增量集成 以小增量的方式逐步进行构造和测试。
常用的增量集成策略包括:自顶向下集成测试、自底向上集成测试、回归测试、冒烟测试等。 3确认测试
确认测试始于集成测试的结束即已测试完单个构件软件已经组装成完整的软件包而且接口错误已被发现和改正。确认过程的一个重要成分是配置评审主要检查软件、文档、数据是否齐全、分类是否有序。
当为客户开发软件时执行一系列验收测试能使客户确认所有的需求验收测试是由用户而不是软件工程师进行的。
α测试最终用户在开发者的场所进行测试。 β测试在一个或多个最终用户场所执行与α测试不同开发者通常不在场。 4系统测试
系统测试是将已经确认的软件、硬件、外设、网络等其他因素结合在一起进行各种集成测试和确认测试。目的是通过与系统的需求(SRS进行比较发现所开发的系统与用户需求不符或矛盾的地方。主要包括恢复测试、安全性测试、压力测试、性能测试、部署测试。
3. 测试方法
软件测试分为静态测试和动态测试。
静态测试 被测程序不在机器上运行采用人工检测和计算机辅助静态分析的手段对程序进行测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行而对代码的静态测试包括桌前检查、代码审查、代码走查的方式。使用这种方法能够有效地发现30%-70%的逻辑设计和编码错误。动态测试 通过运行程序发现错误一般采用黑盒测试和白盒测试。
1黑盒测试
也称功能测试 在不考虑软件内部结构和特性的情况下测试软件的外部特性。 常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图等。 等价类划分将程序的输入域划分为若干等价类然后从每个等价类中选取一个代表性数据作为测试用例。等价类划分有两种有效等价类(对于需求规格来说合理的数据集合)和无效等价类(对于需求规格来说异常的数据集合)。 边界值分析是对等价类划分方法的补充。边界值分析选择等价类边界的测试用例。所谓边界值是指相对于输入等价类和输出等价类而言稍高于其最高值或稍低于最低值的一些特殊情况。边界值分析的步骤包括确定边界选择测试用例两个步骤。 例如如果程序的规格说明中规定:“重量在10公斤至50公斤范围内的邮件其邮费计算公式为…”。作为测试用例我们应取10至50还应取9.9910.0149.99以及50.01等 错误推测基于经验和直觉推测程序中所有可能存在的各种错误。 因果图从自然语言描述的程序规格说明中找出因输入条件和果输出或程序状态的改变)通过因果图转换为判定表。因果图(Cuase-effect Graph是一种描述输入条件的组合及每种组合对应的输出的图形化工具。在因果图的基础上可以设计测试用例。
2白盒测试 也称结构测试根据程序的内部结构和逻辑来设计测试用例对程序的路径和过程进行测试检查是否满足设计的需要。常用的白盒测试技术有逻辑覆盖、循环覆盖和基本路径测试。 逻辑覆盖语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
语句覆盖(SC)是指选择足够多的测试用例使被测程序的每条语句至少执行一次。语句覆盖是一种很弱的逻辑覆盖。判定覆盖DC)又称分支覆盖是指设计足够的测试用例使得不仅每条语句至少执行一次而且每个判定表达式的每种可能的结果分支都至少执行一次。判定覆盖比语句覆盖强。条件覆盖(CC是指设计一组测试用例不仅每条语句至少执行一次而且使判定表达式中的每个条件的所有可能的值至少满足一次。条件覆盖不一定包含判定覆盖、判定覆盖也不一定包含条件覆盖。判定/条件覆盖(CDC)是指同时满足判定覆盖和条件覆盖的逻辑覆盖。设计足够的测试用例,使得判定表达式中每个条件的所有可能的值至少满足一次而且每个判定本身的所有可能结果也至少出现一次。条件组合覆盖MCC)设计足够的测试用例使得每个判定表达式中条件的所有值的组合都至少出现一次。满足条件组合覆盖的测试用例也一定满足判定覆盖、条件覆盖和判定/条件覆盖。路径覆盖设计足够的测试用例覆盖被测程序中所有可能的路径如果程序中有环路则要求每条环路至少经过一次。路径覆盖考虑了程序中各种判定结果的所有可能组合因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合并不能代替条件覆盖和条件组合覆盖。
4. 调试
调试发生在测试之后其任务是根据测试时所发现的错误找出原因和具体的位置进行改正改正后要进行回归测试。调试工作主要由程序开发人员进行谁开发的程序就由谁来进行调试。日前常用的调试方法有以下五种 (1试探法 调试人员分析错误的症状猜测问题所在的位置一步步试探和分析问题所在。该方法效率氐适用于结构比较简单的程序。 (2回溯法 调试人员从发现错误的位置开始人工沿着程序的控制流程往回追踪代码直到找出问题根原为止。该方法适用于小型程序。 (3对分查找法 该方法主要用来缩小错误范围直到把故障范围缩小到比较容易诊断为止。 (4)归纳法 从测试所暴露的问题出发收集所有正确、不正确的数据并分析它们之间的关系提出假识的错误原因用这些数据证明或反驳从而查出错误所在。 (5演绎法 根据测试结果列出可能的错误原因分析已有的数据排除不可能和彼此矛盾的原因。若多个错误同时存在就要重新分析提出新的假设直到发现错误为止。
六、运行和维护
1. 系统转化
一个系统开发完成后让它实际运行一段时间是对系统最好的检验和测试方法。 新旧系统之间的转换方法有直接转换、并行转换和分段转换。
直接转换直接启用新系统终止旧系统。适用于一些处理过程不太复杂、数据不太重要的场合。并行转换新旧系统并行工作一段时间经过一段时间的考验后新系统正式替代旧系统■适用于较复杂的大型系统。主要特点是安全、可靠但费用和工作量都很大。分段转换直接转换和并行转换的结合。在新系统全部正式运行前一部分一部分地替代旧系统。既保证了可靠性又不至于费用太大。
2. 系统维护概述
系统维护是在软件已经交付使用之后为了改正错误或满足新的需求而修改软件的过程。系统可维护性的评价指标有可理解性、可测试性和可修改性。文档是软件可维护性的决定因素。
系统维护主要包括硬件维护、软件维护和数据维护。软件维护的内容
正确性维护改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。占整个维护工作量的17%~21%。修正BUG、错误。适应性维护使应用软件适应信息技术变化和管理需求变化而进行的修改。占整个维护工作量的18%~25%。应变。完善性维护为扩充功能和改善性能而进行的修改。占整个维护工作的50%~60%。新需求。预防性维护为改进应用软件的可靠性和可维护性为适应未来的软/硬环境的变化应主动增加预防性的新功能以使应用系统适应各类变化而不被淘汰。占整个维护工作量的4%左右。针对未来。
七、软件项目管理
1. 软件项目管理涉及的范围
有效的软件项日管理集中在4P上人员(Person)、产品(Product)、过程(Procedure)、项目(Project。
人员参与项目的人员类型有项目管理人员、高级管理人员、开发人员、客户、最终用户。产品开展项目计划之前应先进行项目定义即定义项目范围其中包括建立产品的目的和范围、可选的解决方案、技术、管理约束等。过程对于软件项目来说强调的是对其进行过程控制通常将项目分解为任务、子任务等。项目常见的软件项目办法有明确目标及过程、保持动力、跟踪进展、作出明智的决策、进行事后分析。 2. 软件项目估算
软件项目估算涉及人、技术、环境等多种因素因此很难在项目完成前准确地估算出开发软件所需的成本、持续时间和工作量。常用的估算方法有三种基于已经完成的类似项目进行估算、基于分解技术进行估算、基于经验估算模型的估算。
1成本估算方法 常见的成本估算方法有白顶向下估算方法、自底向上估算方法、差别估算方法、专家估算法、类推估算法和算式估算法等。
2COCOMO模型 COCOMO模型是一种精确的、易于使用的成本估算模型。其公式如下: Ea(L)bD cEd 其中E表示工作量单位是人月D表示开发时间单位是月L是项目的源代码行估计值单位是千行代码a、b、c、d都是常数。
3COCOMOⅡ模型 COCOMOⅡ模型也是一种基于层次结构的估算模型分为3个阶段性模型应用组装模型基于对象点数量进行估算)、早期设计阶段模型基于功能点数量进行估算和体系结构阶段模型基于早期架构设计也是基于功能点数量进行估算。
4Putnam估算模型 Putnam模型是一种动态多变量模型它是假设在软件开发的整个生存周期中工作量有特定的分布。 3. 进度管理
进度管理的目的是确保软件项目在规定的时间内按期完成。进度安排的常用图形描述方法有甘特图(GanttChart和项目计划评审技术图(PERT)。
1甘特图 Gantt图是一种简单的水平条形图它以日历为基准描述项目任务。横坐标表示时间纵坐标表示任务图中的水平线段表示对一个任务的进度安排线段的起点和终点对应在横坐标上的时间分别表示该任务的开始时间和结束时间线段的长度表示完成该任务所需的时间。
优点能清晰地描述每个任务从何时开始到何时结束任务的进展情况以及各个任务之间的并行性。缺点不能清晰地反映出各个任务之间的依赖关系难以确定整个项目的关键所在也不能反映计划中有潜力的部分。 2项目活动图PERT图
下面是一个软件项目的活动图(PERT图)顶点表示里程碑连接顶点的边表示活动边上的权重表示完成该活动所需要的时间(天。
关键路径从开始顶点到结束顶点之间距离最长的一条路径。关键路径上的长度就是完成整个工程项目的最短工期。松弛时间:最迟开始时间-最早开始时间最迟开始时间从后往前推关键路径长度-该活动开始顶点到项目活动图的结束顶点的最长长度)最早开始时间从前往后推等于项目活动图的开始顶点到该活动开始顶点的最长长度)或者关键路径的总时间-包含该活动的最长路径的总时间。关键路径上的活动的松弛时间均为0。 4. 软件项目的组织
开发组织采用什么形式不仅要考虑到项目的特点还要考虑参与人员的素质。软件项目组织的原则有①尽早落实责任②减少交流接口③责权均衡。
程序设计小组的组织方式 (1) 主程序员制小组 由一名主程序员、若干名程序员、一名后援工程师和一名资料员组成。主程序员通常由高级工程师承担突出主程序员的领导作用小组内的通信主要体现在主程序员与程序员之间。
(2民主制小组 小组成员之间地位平等工作日标和决策由全体成员决定这种形式的组内通信路径较多。
(3层次式小组 由一名组长领导若干名高级程序员每名高级程序员领导若干名程序员。组长通常是项日负责人负责全纽的技术工作进行任务分配组织评审。高级程序员负责项目的一个部分或一个子系统。
5. 软件项目配置
软件配置管理(SCM用于整个软件工程主要目标是识别变更、控制变更、确保变更正确实现、报告有关变更。
基线 基线即软件生存周期中各个开发阶段的一个特定点作用是将各阶段的工作划分更加正确。软件配置项 软件配置项(SCI是配置管理的基本单位对己经成为基线的SCI虽然可以修改但必须按照一个特殊的、正式的过程进行评估确认每一处修改。版本控制 版本控制实际上是一个动态的概念一方面随着软件生存周期向前推进SCI的数量在不断增加一些文档经过转换生成另一些文档并产生一些信息:另一方面又随时会有新的变更出现形成新的版木。变更控制 对软件配置的变更加以控制和管理。是一项最重要的软件配置任务。
6. 风险管理
软件风险包括两个特性:不确定性和损失。不确定性是指风险可能发生也可能不发生;损失是指风险发生后会产生的恶性后果。常见的商业风险有:市场风险、策略风险、销售风险、管理风险、预算风险。
**风险识别**当识别出已知风险和可预测风险后项日管理者首先要做的是尽可能回避这些风险在必要时控制这些风险。风险因素可以定义为:性能风险、成本风险、支持风险、进度风险。**风险预测**风险预测又称为风险估计它试图从两个方面评估一个风险:风险发生的可能性或概率;风险发生后所产生的后果。**风险评估**一种对风险评估很有用的技术就是定义风险参考水准。对于大多数软件项日来说成本、进度和性能就是3种典型的风险参考水准。**风险控制**应对风险最好的办法是主动地避免风险即在风险发生前分析引起风险的原因然后采取措施避免风险的发生。
八、软件质量
1. 软件质量特性
软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。讨论软件质量首先要了解软件的质量特性在ISO/IEC 9126中软件质量模型由三个层次组成第一层为质量特性第二层为质量子特性第三层为度量指标如下图所示。
2. 软件质量保证
软件质量保证(Software Quality AssuranceSQA是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动其目的是生产高质量的软件。在软件质量方面强调以下三个要点: ①软件必须满足用户规定的需求②软件应遵循规定标准所定义的一系列开发准则③软件还应满足某些隐含的需求。软件质量保证包括与以下七个主要活动相关的各种任务: ①应用技术方法②进行正式的技术评审③测试软件④标准的实施⑤控制变更⑥度量⑦记录、保存和报告。
3. 软件评审
软件评审的内容包括以下三个方面
设计质量的评审 包括评审软件的规格说明书是否符合用户的要求;评审可靠性;评审保密措施的实施情况;评审操作特性的实施情况;评审性能;评审软件是否具有可修改性、可扩充性、可互换性和可移植性;评审软件可测试性;评审软件可复用性。程序质量的评审 从开发者的角度进行评审与开发技术直接相关着眼于软件本身的结构与运行环境的接口以及变更带来的影响。与运行环境的接口 运行环境包括硬件、其他软件和用户主要检查项目与硬件的接口与用户的接口
4. 软件容错技术
提高软件质量和可靠性的技术大致分为两类避开错误和容错技术。实现容错的主要手段是冗余常见的冗余技术有:
结构冗余 又分为静态冗余、动态冗余和混合冗余。信息冗余 为检测或纠正正在运算或传输中的信息错误需外加的一部分信息。时间冗余 以重复执行指令或程序来消除瞬时错误带来的影响。冗余附加技术 为实现上述冗余技术所需要的资源和技术包括程序、指令、数据、存放和调动它们的空间和通道等。
九、软件度量
1. 软件度量分类
软件度量用于对产品及开发产品的过程进行度量如成本、效益、开发人员的生产率、可靠性、可维护性等。软件度量的方法 1面向规模的度量 面向规模的度量主要是通过对质量和生产率的测量进行规范化得到的而这些量都是根据开发过的软件的规模得到的。面向规模的度量公式如下表所示 2面向功能的度量 面向功能的度量以功能测量数据为规范化值。应用最广泛的面向功能的度量是功能点(FP。功能点是根据软件信息域的特性及复杂性来计算的。
2. 软件复杂性度量
软件复杂性度量是指理解和处理软件的难易程度。软件复杂性度量的参数有很多主要包括①规模②难度③结构④智能度。软件复杂性包括程序复杂性和文档复杂性。 典型的程序复杂性度量有McCabe环路复杂性度量和Halstead复杂性度量。 McCabe度量法是一种基于程序控制流的环路复杂性度量方法以图论为工具先画出程序图退化的程序流程图然后用该图的环路数作为程序复杂性的度量值。
在一个强连通的有向图G中环路的个数V(G)山以下公式给出 V(G) m - n 2p 其中V(G)是有向图G中的环路数m是图G中弧的个数n是图G中的结点数p是G中的强连通分量个数。 McCabe环路复杂性度量定量给出了程序的逻辑复杂度还可以用下述3种方法中的任何一种来计算环路复杂度 1程序图G中的区域数等于环路复杂度封闭区域数1一个非封闭区域。 2程序图G的环形复杂度V(G) E - N2其中E是程序图中边的条数N是结点数。 3程序图G的环形复杂度V(G) P 1其中P是程序图中判定结点(有2条输出弧的数目。有n (n2)条输出弧的判定结点对应程序中的n-1个判断。 (个人感觉方法3最好用又快又简单)
十、软件工具与软件开发环境
1软件工具 对应于软件开发的各种活动软件开发工具通常有需求分析工具、设计工具、编码与排错工具、测试工具等。
2软件开发环境 软件开发环境(Software Development Enviromment指支持软件产品开发的软件系统它由软件工具集和环境集成机制构成。
