软件工程
第一章 软件工程的内容与方法
1.软件定义
软件 = 程序 + 数据 + 文档
软件 = 知识 + 程序 + 数据 + 文档
2.软件危机与软件工程的关系
软件工程来源于软件危机,即现有软件危机,后有软件工程。
3.软件工程定义
软件工程师研究软件开发和软件管理的一门工程学科。
一强调开发,二强调管理或过程管理。
4.软件工程课程研究的内容
序号 | 研究方面 | 具体内容 |
---|---|---|
1 | 软件生命周期模型 | 瀑布模型、增量模型、原型模型、迭代模型、XP模型 |
2 | 软件开发方法 | 面向过程的方法、面向元数据的方法、面向对象的方法 |
3 | 软件支持过程 | CASE工具Rose、北大青鸟系统、PowerDesigner、ERWin |
4 | 软件管理过程 | CMMI、软件企业文化、敏捷(XP)文化现象 |
5 | 软件工程标准与规范 | 命名标准与规范、设计标准与规范、编程标准与规范 |
5.软件工程基本原理
1.用分阶段的生命周期计划严格管理软件开发。阶段划分为计划、分析、设计、编程、测试和运行维护。
2.坚持进行阶段评审。若上一阶段评审不通过,则不能进入向下一阶段开发。
3.实行严格的产品版本控制。
4.采用现代程序设计技术。
5.结果应能清除地审查。因此,对文档要有严格要求。
6.开发小组的成员要少而精。
7.要不断改进软件工程实践的经验和技术,要与时俱进。
8.二八定律。在软件工程中,所谓二八定律,就是一般人常常将20%的东西误以为是80%的东西,而将80%的东西误以为是20%的东西。
6.研究二八定律的现实意义
指导软件开发计划的指定与执行。如果实现掌握了二八定律,就能自觉地用二八定律去指定、跟踪与执行软件开发计划。只有这样,项目的开发计划与新项目的开发进度才能吻合。
7.软件工程在软件行业中的作用
从历史上讲,是为了克服20世纪60年代出现的软件危机。
从当前来讲,就是告诉人们怎样去开发软件和管理软件。具体低讲,它表现在与软件开发和管理有关的人员和过程上。为了说明这个问题,首先,分析软件行业的人才结构,看看这些人员的工作与软件工程有什么关系。
8.软件行业的专业人才层次组成
高层管理人员、中层项目经理和软件工程师、软件蓝领工人
软件营销人员、软件实施与维护人员、软件售前人员
9.软件生命周期模型概念
软件生命周期模型是指在整个软件生命周期中,软件开发过程应遵循的开发路线图。或者说,
软件生命周期模型是软件开发全部过程、活动和任务的结构框架。
10.软件开发方法概念
软件开发方法是指在软件开发路线图中,开发人员对软件需求、设计、实现、维护所采用的开发思想、开发技术、描述方法、支持工具等。
11.软件工程方法论
软件工程中软件开发方法的集合,成为软件工程方法论。
12.面向过程方法
优点:以处理流程为基础,简单实用。
缺点:只注重过程化写信息,忽略了信息的层面关系及相互关系。
它企图实用简单的时序过程方法(顺序、分支、循环三种结构),来描述关系复杂(随机)的信息世界。
13.面向对象方法
包括面向对象的需求分析、设计、编程、测试、维护、管理等。
面向对象方法是一种运用对象、类、消息传递、继承、封装、聚合、多态性等概念来构造软件系统的软件开发方法。
特点:将现实世界的事物(问题域)直接映射到对象。分析设计时由对象抽象出类(Class),程序运行时由类还原对象(Object)。
基本特点:将对象的属性和方法(即数据和操作)封装起来,形成信息系统的基本执行单位,再利用对象的继承特征,由基本执行单位派生出其他执行单位,从而产生许多新的对象。众多的离散对象通过事件或消息拦截起来,就形成了软件系统。
开发平台:.Net平台和 J2EE平台
优点:能描述无穷的信息世界,同时易于维护。
缺点:对于习惯于面向过程的人,比较难掌握。
14.面向元数据方法
元数据是关于数据的数据、组织数据的数据、管理数据的数据
如类的名称、属性和方法,实体的名称、属性和关联,数据库中的表名、字段名、主键、外键、索引、视图等信息。
就是在软件需求分析、设计、实现、测试、维护过程中,均以元数据为中心的软件工程方法。
优点:通俗易懂,特别适合信息系统中数据层上的设计与实现。
缺点:只能实现二维表格,不能实现窗口界面。
15.信息系统
利用计算机网络技术、数字通信技术与数据库技术实现信息采集和处理的系统,称为信息系统。
16.”五个面向”实践论
面向流程分析、面向元数据分析、面向对象实现、面向功能测试、面向过程管理
17.软件过程
指软件生命周期中的时间序列。
软件工程的支持过程,由支持软件声明周期各个阶段的生成工具组成。
第二章 软件生命周期与开发模型
1.瀑布模型
1.模型本意
在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前阶段的活动接受上一阶段活动的工作结果,实施完成所需的工作内容。需要对当前阶段活动的工作结果进行验证,如果验证通过,则该结果作为下一阶段活动的输入,继续进行下一阶段的活动,否则返回上一阶段修改。
项目经理或软件管理人员,只要控制好每级台阶的高度和宽度,在每级台阶处设立里程碑或极限,并组织好对基线的评审与审计,就可以控制好项目的开发成本、进度与质量。
2.特点
(1)里程碑或基线驱动,或者所文档驱动。
(2)过程逆转性很差或者说不可逆转,根据上游的错误会在下游发散性传播的原理,逆转将会延误工期,增加成本,造成重大损失。
优点:开发阶段界定清晰,便于评审、审计、跟踪、管理和控制。
缺点:在整个分析、设计和实现阶段隐藏下来的问题,会在项目后期堆积暴露出来。
2.增量模型
1.模型本意
要开发一个大的软件系统,先开发其中的一个核心模块(或子系统),然后再开发其他模块(或子系统),这样一个个模块(或子系统)地增加上去,直至整个系统开发完毕。在每增加一个模块前,先要对该模块进行模块测试,通过后再将此模块加入到系统中。然后还要进行系统集成测试,系统集成测试成功后,再增加新的模块。这样多次循环,直到系统搭建完毕。
2.特点
(1)任务或功能模块驱动,可以分阶段提交产品。
(2)有多个任务单,这些任务单的集合构成项目的一个总《任务书》或总《用户需求报告》/《需求规格说明书》
优点:相当于将一个大风险分解为多个小风险,从而降低了开发难度。人员分配灵活,刚开始不用投入大量人力资源。
缺点:如果软件系统的组装与拆卸性不强,或开发人员全局把握水平不高,或者客户不同意分阶段提交产品,或者开发人员过剩,都不宜采用这种模型。
3.原型模型
1.模型本意
在初步需求分析之后,马上向客户展示一个软件产品原型,对客户进行培训,让客户试用,在试用中收集客户意见,根据客户意见立刻修改原型,之后再让客户试用,反复循环几次,知道客户确认为止。
适用于企业资源规划ERP系统
2.模型的特点
原型驱动。开发中必须先有一个原型,至少有一个原型的核心。
优点:开发速度快,用户意见实时反馈,有利于开发商在短时间内推广并服务于多个客户。
缺点:因为事先有一个展示型的产品原型,所以在一定程度上,不利于开发人员的创新。
4.迭代模型
课本上讲的迭代模型是由RUP推出的一种“逐步求精”的面向对象的软件开发过程模型。
从宏观上看,它是一个大的迭代过程:横坐标表示软件产品所处的4个阶段状态:先启、精化、构建、产品化(移交),纵坐标表示软件产品在每个阶段的工作流程。
1.模型本意
多次执行各个开发工作流程,从而更好地理解需求,设计出更为强壮的软件构架,逐步提高开发组织能力,最终交付一系列逐步完善的实施成果。每次按顺序完成一些列工作流程就称为一次迭代,每次迭代均以次要里程碑结束,按照特定的迭代成功标准,对迭代的结果进行评估。通过一次又一次的迭代,实现递增成长,最后形成最终的软件系统或产品。
2.特点
迭代或迭代循环驱动,每一次迭代或迭代循环,均要走完初始、精化、构建、产品化这4个阶段。
(1)采用迭代的、增量式的开发过程。
(2)采用UML语言描述软件开发过程。
(3)有功能强大的软件工具Rational Rose支撑。
优点:在开发的早期或中期,用户需求可以变化;在迭代之初,不要求有一个相近的产品原型;模型的适用范围很广,几乎适用于所有项目的开发。
缺点:要求项目组成员具有很高的水平掌握先进的开发工具
第三章 软件立项与合同
1.立项
立项就是在市场调研的基础上,分析立项的必要性(是否有市场前景)和可能性(是否有能力实现),并具体列出系统的功能、性能、接口和运行环境等方面的需求,当前客户群和潜在客户群的情况,以及投入产出分析。然后再按照编写参考指南书写《立项建议书》,并对它进行评审,评审通过后才算正式立项。
第四章 软件需求分析
1.需求分析
需求分析的输入是软件《合同》或软件《立项建议书》,以及对用户现场的调研、分析和确认
输出是《用户需求报告》/《需求分析规格说明书》
2.定义
(1)用户解决问题或达到目标所需的条件或能力。
(2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需要具有的条件或能力。
(3)一种反应第(1)或(2)所描述的条件或能力的文档说明。
基本任务:准确地定义未来系统的目标,确定为了满足用户的需要系统必须做什么。
两个阶段:需求获取阶段和需求归约阶段。
两大类:功能性需求和非功能性需求。前者定义了系统做什么,后者定义了系统工作时的特性。
3.需求获取
就是开发者与用户共同提取并共同确认需求。
人们将“划分、抽象和投影”三要素作为需求获取的三原则。
(1)划分,就是捕获问题空间的“整体/部分”关系。
(2)抽象,就是捕获问题空间的“一般/特殊”或“一般/特例”关系。
(3)投影,就是捕获问题空间的多为“视图”。
4.需求规约
就是对获取并确认的需求进行定义与分析,并且解决需求中存在的二义性和不一致性问题,最后以一种系统化的文档新形势,准确地表达用户的需求,形成《需求分析规格说明书》。
5.名词解释
序号 | 名词 | 名词解释 |
---|---|---|
1 | 基线 | 基线是软件工作产品,它要经内部和外部都评审过的,是下一阶段工作的基础 |
2 | 检查点 | 检查点只是由时间、计划、事件驱动的检查工作进度和质量的一个标记。一个检查点不一定对应一条基线或一个里程碑 |
3 | 里程碑 | 里程碑是一个标记,只需要经过内部评审。一个里程碑是一个检查点,但不一定对应一条基线 |
4 | 评审 | 是对软件工作产品质量的一次开会(或汇签)活动 |
5 | 审计 | 是复查评审活动程序的合法性,是否按程序与规范进行等 |
6 | 客户 | 客户是软件企业合同的签约方,是软件产品的销售对象。客户是顾客的一部分 |
7 | 顾客 | “顾客”比“客户”的范围更广泛一些些,它包括潜在的客户 |
8 | 用户 | 用户是软件产品的最终使用者,用户是客户的一部分 |
9 | 软件工作产品 | 在CMMI中,“软件工作产品”是软件开发活动中的人工制品,如《用户需求报告》、《需求分析规格说明书》、《概要设计说明书》、《详细设计说明书》、源程序、《测试报告》、《用户手册》,也包括软件管理文档 |
10 | 软件产品 | 在CMMI中,“软件产品”是最终用户使用的软件,如操作系统Windows XP、财务系统、管理信息系统MIS。“软件产品”是“软件工作产品”的一部分。 |
11 | 现有系统 | 指用户当前正在使用的系统,它可能是网络管理系统,也可能是手工管理系统 |
12 | 目标系统 | 指将要实现的系统 |
6.需求分析的任务
1.画出目标系统的组织结构图,列出各部门的岗位角色表,即组织机构模型。
2.画出目标系统的业务操作流程图,即业务模型。
3.画出目标系统的数据流图(DFD),即单据和报表的流图,掌握业务规则,获得初步数据模型。
4.列出目标系统的功能点列表,即功能模型。
5.列出系统的性能点列表,即性能模型。
6.列出目标系统的接口列表,即接口模型。
7.确定目标系统的运行环境,即环境模型。
8.目标系统的界面约定。即界面模型。
9.对目标系统的开发工期、费用、开发进度、系统风险等问题进行分析与评估。
7.三中需求分析方法对比表
需求分析方法名称 | 目的 | 点评 | 适用范围 |
---|---|---|---|
面向功能分析 | 为了获得功能模型 | 简单明了 | 系统软件和应用软件 |
面向对象分析 | 为了获得对象模型 | 复杂抽象 | 系统软件和应用软件 |
面向数据分析 | 为了获得数据模型 | 抓住本质 | 以关系数据库为平台的信息系统 |
8.需求描述工具
面向元数据的X:实体关系图
面向过程的X:数据流图、数据字典
面向对象的X:用例图、类图、顺序图、活动图。
第五章 软件策划
1.软件策划和软件项目策划
输入是软件《合同》/《立项建议书》、《任务书》和《用户需求报告》
输出是《软件开发计划书》(包括《质量保证计划》、《配置管理计划》、《测试计划》、《里程碑及评审计划》
2.软件策划的目的及基础
目的:是为软件开发和软件管理制定合理的计划。
基础:是软件生命周期模型的选取。
3.软件策划的步骤
步骤 | 步骤名称 | 步骤内容 |
---|---|---|
1 | 估计软件工作产品的规模、工作量、费用及所需的资源 | 软件工作产品,包括需求规格说明书,概要设计说明书,详细设计说明书,源代码,测试计划和测试报告,质量保证计划,软件配置管理计划,里程碑及评审点计划。 |
2 | 制定时间表 | 包括看法进度时间表和管理进度时间表:软件开发计划、质量保证计划、软件配置管理计划、测试计划、评审计划 |
3 | 鉴别和评估风险 | 政策风险、资源风险、市场突变风险、技术风险和技能风险等 |
4 | 与相关的组或人协商策划中的有关约定 | 策划的结果是要实事求是,要得到各有关方面的同意和认可 |
4.软件估计
指对软件项目进行量化估计,并记录估计结果的过程。软件估计是软件度量的一部分,它既是软件策划的核心,又是软件策划的重点与难点。
5.Delphi法
基本步骤:
(1)协调人向各专家提供项目规格和估计表格
(2)协调人召集小组会,各专家讨论与规模相关的因素
(3)各专家匿名填写迭代表格
(4)协调人整理出一个估计总结,以迭代的形式返回专家。
(5)协调人召集小组会,讨论较大的估计差异
(6)专家复查估计,总结并在迭代基础上提交另一个匿名估计
(7)重复步骤(4)~(6),知道达到一个最低和最高估计的一致性为止,以完成此次估计
6.类比法
基本步骤:
(1)整理出项目功能列表和实现每个功能的代码行
(2)标识出每个功能列表与历史项目的相同点与不同点,特别要注意历史项目做得不够的地方
(3)通过步骤(1)和(2)得出各个功能的估计值
(4)产生规模估计
7.功能点估计法
基本不住:
(1)计算输入、输出、查询、主控文件和接口需求的数目。
(2)将这些数据进行加权相乘。
(3)估计者根据对复杂度的判断,总数可以用+25%、0或-25%调整。
第六章 软件建模
1.软件建模
软件建模的三个模型通常是指功能模型、业务模型和数据模型。
(1)功能模型实质上是用户需求模型,用来描述用户需求模型,用来描述系统能做什么,即对系统的功能、性能、接口和界面进行定义
(2)业务模型实质上是业务逻辑模型,用于描述系统在何时、何地、由何角色、按什么业务规则去做,以及做的步骤或流程,即对系统的操作流程进行定义。
(3)数据模型实质上是实体或类的状态关系模型,用于描述系统工作前的数据来自何处,工作中的数据暂存在什么地方,工作后的数据放到何处,以及这些数据的状态及互相之间的关联,即对系统的数据结构进行定义。
2.数据库设计的10个步骤
设计步骤 | 设计内容 |
---|---|
第1步 | 将原始单据分类整理,理清原始单据与输出报表之间的数据转换关系计算法,澄清一切不确定的问题 |
第2步 | 从原始单据出发,划分出各个实体,给实体命名,初步分配属性,表示出主键或外键,理清实体之间的关系 |
第3步 | 进行数据库概念模型CDM设计,画出实体关系图ERD,定义完整性约束 |
第4步 | 进行数据库物理数据模型PDM设计,将概念模型CDM转换为物理数据模型PDM |
第5步 | 在待定的数据库管理系统上定义表空间,实现物理建表与建索引 |
第6步 | 定义触发器与存储过程 |
第7步 | 定义视图,说明数据库与应用程序之间的关系 |
第8步 | 数据库加载与测试:向基表中追加记录,对数据库的功能、性能进行全面测试 |
第9步 | 数据库性能优化:从数据库系统的参数配置、数据库设计的反规范化过程的两个方面,对数据库的性能进行优化 |
第10步 | 数据库设计评审:从数据库的整体功能与性能两个方面,请同行专家评审评价 |
3.数据库设计与软件周期的关系
一个面向对象的系统,开发阶段:需求确认-概要设计-详细设计-编码-单元测试-集成测试-系统测试-维护。数据库设计步骤:需求分析-概念设计-逻辑设计-物理设计-数据库实施与维护。数据库设计的第一个阶段需求分析是在系统开发之前考虑的,也考虑用户需要知道什么数据,需要操作哪些数据。第二阶段概念设计到第四阶段都是围绕第一阶段设计考虑的。与系统开发阶段相关的是第一阶段需求分析和最后的实施维护,数据库设计和系统开发相辅相成,系统开发的需求是为了了解用户能看到哪些界面,拥有哪些操作。而界面中的信息,操作的数据结果是数据库设计的。
4.范式理论
第一范式:1NF是对属性的原子性约束,要求具有原子性,不可再分解。
2NF是对记录的唯一性约束,要求记录有唯一标识,即实体的唯一性。
3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。
第七章 软件设计
1.三层体系结构
表示层、中间层和数据层,各个层之间通过对外接口互相访问。分层结构的主要目的是,允许各层可以随着需求或技术的变化而独立地升级或替换,如当替换数据库时只需要变化数据层。
表示层也称浏览层,它通常采用图形化用户界面,在客户端PC或工作站上允许。
中间层也称业务层,有时又称应用层,它由许多构件或组件组成,他们完全体现了用户的业务逻辑或业务规则。
数据层是数据库服务器上的数据库层,它包括数据库管理系统DBMS和数据库DB两部分。
2.三层结构的优点
①三层之间的低耦合,互不干扰,哪一层出了问题就去哪一层解决。同时,由于同一层内的各个类之间,也是低耦合,所以不会出现Bug现象。
②三层结构减少了客户机的工作量,提高了网络系统的运行效率。
③三层结构有利于系统的维护和生意,各个层的维护,互不影响。
3.三层与多层的关系
若将中间层按照应用逻辑进一步划分,三层体系结构就变成了多层体系结构。
4.“设计“
“设计”在IEEE中的定义是:定义一个系统或部件的架构、组成、接口或其他特征的“过程”,或者是“该过程的结果“。
软件设计是一个过程,它是软件生命周期的一部分,是对软件需求分析后产生软件内部结构的一种描述。软件设计的结果,应能描述软件的架构,即软件中各个部件是如何分解并组合在一起的,这些描述将作为软件构建的基础。
5.软件设计原理
1.抽象,是将几个有区别的物体的共同性质或特性,形象地抽取出来,独立地进行考虑的过程。包括控制抽象、过程抽象、数据抽象。
2.模块化,就是解决一个复杂问题时,自顶向下、逐步求精地把软件系统划分成若干模块的过程。
3.信息隐藏,指在设计和确定模块时,使一个模块内包含的信息(过程或数据),对于不需要这些信息的其他模块来说是不能访问的。
4.模块独立性,模块独立性指每个模块只完成系统要求的独立的子功能,并且与其他模块的联系最少且接口简单
5.封装,是将信息隐藏在一个实体中,使其内部细节对外部不可见.封装是实现“低耦合,高内聚”的技术手段之一。
6.接口和实现分离,将接口和实现分离开来,对外只提供接口,隐藏具体实现。接口与实现的分离,保证了实现的独立性,降低了模块间的耦合。
6.软件设计和软件需求的区别
需求分析阶段的主要任务时确定系统必须“做什么“,形成软件的《需求分析规格说明书》,软件设计阶段的主要任务时确定系统”怎么做“,从软件《需求规格分析说明书》触发,形成软件的具体设计方案。软件设计可以采用多种方法,如面向程序设计、面向元数据设计、面向对象设计。
7.面向过程设计
详细设计的工具分为图形、表格、语言三种,包括程序流程图、盒图(N-S图)、程序设计语言PDL、PAD图。
8.面向对象设计
统一建模语言UML是一种图形化语言,提供了描述软件系统的图形和语法。UML既是面向对象需求分析的描述工具,又是面向对象架构设计的描述工具,更是面向对象详细设计的描述工具,它使软件开发三个重要阶段的描述工具统一起来,而且实现了平滑过渡与无缝连接,形成了一个从需求到设计的提花流程,使这三个阶段之间没有明显的界限。
UML主要包括7种图形,用例图、类图、顺序图、状态图、活动图、部件图和部署图。
9.面向对象设计步骤
1.需求分析,建立系统初步的功能模型、业务模型和数据模型
2.架构设计,建立系统完整的功能模型、业务模型和数据模型
3.详细设计,将功能模型、业务模型和界面模型中的各个部件加以实现
4.编程实现,将模型中的各个部件实现文档转换为相应代码
10.三种设计方法关系
面向过程、面向对象和面向元数据这三种设计方法,在多层网络结构的应用系统中找到了共同点,发挥了各自的优势,实现了互相依存,达到了和平共处。面向元数据方法用在数据库服务器层次上系统的设计与实现,面向对象方法用在除数据库服务器层次之外的其他层次上系统的设计与实现,面向过程方法用在其他两种方法本身内部函数的设计与实现。
第八章 软件实现
第九章 软件测试
1.什么是软件测试
软件测试是测试中的特例,因为其测试对形象是软件产品,它是人的智力产品,表现异常复杂,所以软件测试有自身的特点与难度,并具有挑战性。
软件测试是按照规定的测试规程发现软件缺陷的过程。
2.什么是软件缺陷
(1)软件未实现产品说明书要求的功能。
(2)软件出现产品说明书指明不应该出现的错误。
(3)软件实现了产品说明书未说明的功能。
(4)软件未实现产品说明书虽未明确提及但应该实现的目标。
(5)软件难以理解,不易使用,运行速度慢,或者软件测试员、最终用户认为软件不好。
3.软件测试模型
V模型、X模型
4.黑盒测试
黑盒测试是面向功能模型的测试。不考虑(主观上屏蔽)或者不需要(客观条件限制)知道被测对象的内部实现细节,只关心输入和输出。在运用黑盒测试方法进行软件测试时,它不关心软件的内部逻辑结构和实现方法,而是站在使用者的角度,主要测试软件的功能指标,即测试系统的功能模型。
黑盒测试方法:等价类划分法、边界值分析法、错误推测法、因果图分析法、场景分析法。
5.白盒测试
白盒测试是面向程序执行路径进行穷举代码测试,直至覆盖所有路径,才算完成了白盒测试。侧重于软件单元、模块和构件等小规模对象,绝对不适合软件项目或产品等大规模测试对象。
(1)语句覆盖是最基本的覆盖,它要求设计足够多的测试用例,使程序中每条语句至少被执行一次。
(2)判定覆盖又称分支覆盖,它要求设计足够多的测试用例,使程序中每个判定至少取一次真值和一次假值。
(3)条件覆盖要求设计足够多的测试用例,使得判定中的每个条件语句取一次真值和一次假值。
(4)判定/条件覆盖,是将判定覆盖和条件覆盖结合起来,设计足够多的测试用例,使判定语句被取一次真值和假值的同时,每个条件语句也同时被取一次真值和假值。
第十章 软件实施与维护
1.软件产品的分类
类别 | 产品特点 | 举例 |
---|---|---|
1 | 不需要客户化的软件产品 | 系统软件 |
2 | 只需要少量客户化工作的产品 | 专业性特强的应用软件产品 |
3 | 需要重新做业务流程规范和需求规格定义的软件产品 | 分行业的ERP |
2.项目与产品的区别与联系
软件产品是指不局限于特定业务领域、能被广大用户直接使用的软件系统。软件项目是指针对特定专业领域、需要提供业务流程充足与优化的软件系统。软件项目的特点是,业务领域知识所占的比重大,工程性强.
项目和产品既有显著的不同,又有紧密的关系。做软件项目是手段,做软件产品是目的,软件项目做多了,软件项目就慢慢地百年成了软件产品。
3.三分软件七分实施
第十一章 软件管理
软件管理是面向过程的,其主要模型时CMMI模型,ISO9001模型,软件企业文化模型。
CMMI是由美国卡内基-梅隆大学软件工程研究所CMU/SEI推出的评估软件能力与成熟度等级的一套标准。
1.CMMI的应用领域具体表现在三个方面
(1)软件组织,用它来不断改进自身的软件过程管理能力。
(2)评估机构,用它来评估某软件组织当前软件能力成熟度级别。
(3)客户,用它来评价某承包商的软件能力。
2.CMMI阶段模型的成熟度等级
CMMI的等级 | PA数目 | 管理特点 |
---|---|---|
ML1:Initial(初始级) | 0 | 过程不可预测且缺乏控制 |
ML2:Managed(已管理级) | 7 | 过程为项目服务,即项目级管理 |
ML3:Defined(已定义级) | 11 | 过程为组织服务,即组织级管理 |
ML4:Quantitatively Managed(定量管理级) | 2 | 过程已度量和控制,即定量级管理 |
ML5:Optimizing(优化级) | 2 | 集中于过程改进,即优化级管理 |
3.ISO 9001与 CMMI 的联系与区别
相同点:CMMI和 ISO 9001标准都致力于质量和过程管理,都是为了解决同样的问题。
不同点:CMMI 是动态的、开放的和持续改进的,它强调“没有最好,只有更好”,强调不断改进,强调人在软件开发方面的主动性,非常适用于软件过程的改进;ISO 9001是静态的质量控制,只要达到20个关键指标或过程,就能完成质量控制,它更适用于硬件制造行业和第三产业的质量控制
CMMI是“专用”,ISO 9001是“通用”,ISO 9001不覆盖CMMI,CMMI也不完全覆盖ISO 9001。
4.项目经理对程序员的八项要求
(1)团队协作精神的训练和要求
(2)数据库和数据结构分析与设计能力的训练和要求
(3)书写文档习惯的训练和要求
(4)规范化代码编写能力的训练和要求
(5)复用性能力和构件技术的训练和要求
(6)测试习惯的训练和要求
(7)学习和总结能力的训练和要求
(8)引导程序员由”丑小鸭”变成”白天鹅”