《软件工程》笔记

来源:互联网 发布:csgo国服 mac 编辑:程序博客网 时间:2024/06/05 12:07

——软件工程

是一门研究应用工程化方法构建和维护有效的、实用的和高质量的软件的学科。

工程包括了管理、过程和技术三个方面,过程指软件的开发、维护过程及管理过程。涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等。

目标:

达到要求的软件功能。

取得较好的软件性能。

付出较低的开发成本。

开发的软件易于移植。

开发的软件易于维护,需要较低的维护费用。

能按时完成开发任务,并交付使用。

注意:

软件设计时,充分考虑软件的可修改性、可扩展性。

软件开发文档齐备。

加强团队合作精神。

——软件工程过程

是指软件生命周期所涉及的一系列相关过程,是产生一个最终能满足需求且达到工程目标的软件产品所需要的步骤。

包括开发过程、运作过程和维护过程。覆盖了分析、设计、编码、测试及支持。

分析包括问题分析和需求分析,需求分析生成功能规约。

设计包括概要设计和详细设计。

概要设计建立整个软件系统结构,包括子系统、模块及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块或类说明。

基本原则:

选取适宜的软件开发模型

采用合适的软件开发方法

提供高效的开发支撑环境

重视软件开发过程的管理

建设高素质的软件开发团队

软件生命周期:制定计划、需求分析和定义、设计、编码、测试、运行和维护。

通常要考虑软件的模块化、抽象与信息隐藏、可移植性、局部化、可适用性。

——UML统一建模语言

它使开发人员专注于建立系统的模型和结构,而不是选用具体的程序设计语言和算法来实现,当模型建立以后,模型可被UML工具转化为指定的程序设计语言代码和数据库结构。

用例图:用于业务建模、需求捕获,作为测试的依据

类图:描述类以及类之间的相互关系

对象图:描述对象以及对象之间的关系

构件图:描述构件及其相互依赖关系

部署图:描述构件在各个节点上的部署情况

顺序图:强调时间顺序的交互图

协作图:强调对象协作的交互图

状态图:描述类所经历的各种状态以及状态之间的转换关系

活动图:用于对工作流程建模

——Rational Rose

提供了一个集成环境,用来创建、查看和修改UML模型、视图、图和模型元素。

客户服务系统:面对的是客户,强调的是服务,注重的是管理。

性能指标:

满足多人同时使用系统

保存半年历史数据供查询

10s内完成数据交互性操作

页面访问平均响应时间<=3s,峰值<=10s,并具备扩展功能

支持传统的网络传输协议

能够抵御常见的Hacker攻击手段

本系统为平台化的应用系统,支持各种标准化数据接口

提供全部的数据库表结构、数据字典和二次开发详细参考文档

——项目管理

利用系统的管理方法将职能人员(垂直体系)安排到特定的项目中(水平体系)

项目管理是面向成果的

项目管理是基于团队的

项目管理借助外部的资源提供跨职能部门的解决方案

项目管理是可变化的

项目划分四个阶段:

识别需求、提出解决方案、执行项目、结束项目

项目的质量因素:时间、费用、范围

项目管理主要任务:项目计划、项目组织、质量管理、费用控制、进度控制

知识领域:范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理、集成管理

工期 = 工时 / 资源投入

成本 = 固定成本 + 资源成本

资源成本 = 工时资源成本 + 资料资源成本

——WBS任务分解结构

使项目各参与方从整体上了解项目的各项工作便于进行整体的协调管理或从整体上了解自己承担的工作与全局的关系。

关键路径:指一系列必须按时完成的任务

项目监控管理:

跟踪项目的实际运行状态,包括设置比较基准,更新进度,查看项目进度

——软件开发生命周期

制定计划:分析人员、领域专家及用户

需求分析和定义:分析人员、测试人员、领域专家及用户

软件设计:架构设计人员、软件设计人员、数据库设计员、用户界面设计员、封装体设计员、集成人员、测试人员

编码:编程人员、测试人员

软件测试:测试人员、开发人员、用户

运行维护:系统支持人员

——软件测试

首先单元测试:查找各模块或类在功能和结构上存在的问题并加以修改,这个过程会反复进行。

其次集成测试:验证软件单元集成后形成的模块能否达到概要设计规格说明中各模块的设计目标。

然后系统测试:对系统全面测试,确保满足产品需求并遵循系统设计。

最后确认测试:检查已实现的软件是否满足了需求规格说明书中确定的各种需求,包括功能需求和性能需求。

——瀑布模型

制定开发计划、需求分析和定义、软件设计、程序编写、软件测试、运行维护

自上而下,相互衔接。

核心思想是按工序将问题简化,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。

优点:

为软件项目提供了按阶段划分的检查点,强调开发的阶段性

强调早期计划及需求调查

强调产品测试和阶段评审

强调文档的重要性

缺点:

缺乏灵活性,无法理清本来不够明确的需求,导致开发完成时才发现并非用户所需。

一般适用于功能、性能明确、完整、无重大变化的软件系统。

——演化模型

主要针对事先不能完整定义需求的软件开发。

第一次迭代(需求->设计->编码->测试->集成)—>反馈—>第二次迭代(...)—>反馈—>...

可以看作是重复执行的多个瀑布模型。

优点:

用户在开发过程中可以看到,对发现的问题能够提早解决

若在某次迭代中没有满足用户需求,开发人员可以根据用户反馈在下一次迭代中进行修正

将系统中难度较大、风险较高的部分安排在早期的迭代中,可增加项目的成功率

缺点:

由于项目需求在开发初期不明确,会给设计带来困难,影响系统的完整性

若开发过程中缺乏严格的过程管理,可能会退化为边写边改模式

若没有一定的约束条件,可能永远无法得到一个最终的软件产品

——螺旋模型

制定计划、风险分析、实施工程、用户评估

以风险分析为驱动,一旦风险过大就要停止开发。

适用于产品研发和机构内部大型的复杂系统,不适用于合同项目。

优点:

设计上灵活,在项目的各个阶段都可变更

以小的分段构件大的系统,使资源、成本、进度的估计变得容易

用户参与到每个阶段中,保证了项目的正确性与可控性

缺点:

需要具有丰富的风险评估经验和专门知识

过多的迭代次数会增加软件开发成本,延迟交付使用的时间

——增量模型

分批的逐步向用户提交可操作的产品,客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能。

优点:

人员分配灵活

重要功能被首先交付使用,可以获得最多的测试

早期发布的可操作产品可以作为原型为后期增量开发提供需求

可以将技术难度较大的部分作为早期的增量,能够有效的管理与控制技术风险

缺点:

若不能控制并管理好需求的变更,容易退化为边写边改模式

加入的增量部分不能破坏已构造好的系统部分,这需要软件具备开放式的体系结构

难以对所有增量进行有效的集成

——面向对象

方法特性:对象唯一性、封装型、继承性、多态性

封装:隐藏某一方法的具体执行步骤,保护或防止数据或程序代码被无意破坏,通过对象提供的公共消息接口来访问对象。

封装应具有的条件:

具有一个清晰的边界,对象所有的私有数据、成员方法或函数的实现细节都被固定在这个边界内。

具有一个接口,它描述了对象之间的交互作用,它就是消息。

对象内部的实现代码受到封装体的保护,其他对象不能直接修改本对象所拥有的数据和代码。

——继承

子类继承父类时,既可以重新定义子类的某些属性和方法,也可以重写某些方法,来覆盖父类原有的属性和方法,使其获得与父类不同的功能。

作用:避免代码冗余,提高可理解性和可维护性

代码重用机制,使系统具有灵活性和适应性,使多态性成为可能。

父类的成员若定义为受保护或公有访问域,子类是可以访问的,若是私有则不可以。

重载:一个类中的操作具有不同的参数和相同的名称。

签名:操作名、参数及其类型和操作的返回类型合在一起。一个类中的所有操作都必须具有唯一的签名。

——面向对象的软件生命周期

是一个迭代的增量式过程。

系统分析阶段:得出对象模型、动态模型、功能模型

系统设计阶段:划分子系统,确定整体框架结构

对象设计阶段:将分析模型的逻辑结构映射到一个程序的物理组织,得到设计模型

实现阶段:将类转化为代码或数据库

测试阶段:面向对象的分析测试、设计测试、编程测试、单元测试、集成测试、系统测试

——RUP(统一软件开发过程):

利用其开发的软件系统是由构件组成的,构件之间通过良好的接口相互联系。

它是用例驱动的过程:根据需求分析的用例来构建需要的系统行为。用例定义了系统功能的使用环境和上下文,每个用例描述的是一个完整的系统服务。

它是迭代和增量式的过程:每次迭代都产生一个可执行的版本。每次迭代时,都选用一组还没有实现的用例来作为增量进行开发,优先识别并着手实现风险较大的用例。

它是以基本架构为中心的过程:在开发之前首先根据平台而不考虑用例来设计系统架构,然后选用其中几个成熟的用例来修改或扩展先前的架构,用系统架构来概念化、建立管理和开发之中的系统。

RUP是一种软件开发过程,包括开发过程、管理过程和支撑过程。

四个阶段:每个阶段以一个主要里程碑结束。

先启阶段:任务是为系统建立业务模型并确定项目的软件范围和边界条件,识别出系统的关键用例,确定至少一个体系结构方案,评估整个的整体成本和进度安排、评估潜在风险,准备项目的支持环境。主要关注整个项目的业务和需求方面的主要风险。

0 0