1 软件与软件工程的概念
1.1软件的概念、特性及分类
1.1.1软件的概念及特性
软件的概念
1. 软件=程序+数据+相关文档。
2. 软件是计算机系统中与硬件相互依存的另一部分，包括 程序、数据、及其相关文档的集合。
- 形态特性
软件是无形的，不可见的逻辑实体
-
智能特性
软甲是复杂的智力产品，其开发凝聚力人们的大量脑力活动
-
开发特性
人工（目前并未实现现代化）
- 质量特性
软件产品的质量控制存在着一些难于克服的实际困难，表现在一下方面
- 软件的需求在开发之初往往是不确定的
- 软件测试技术存在不可克服的局限性
- 已经长期使用或多次反复使用的软件没有发现问题，但这并不意味着今后的使用也不会出现问题
- 生产特性
软件产品的成本主要是设计开发成本，同时也不能采用制造业生产的办法来解决软件开发的管理问题 - 管理特性
- 环境特性
软件对计算机系统的环境有着不可摆脱的依赖性 - 维护特性
- 软件的维护往往是为了修正开发时遗留下来的、隐蔽的、那些在特定运行条件才暴露的缺陷，也可能是为了扩展与提升软件的功能或性能以及为了适应运行环境的改变
- 废弃特性
当软件的运行环境变化过大时，或用户提出更大、更多的需求变更时，如果再对其实施适应性维护已不划算，那么软件走到其生存期终点而被废弃（或称退役） - 应用特性
软件的应用十分广发，如今已渗入国民经济和国防的各个领域，现已成为信息产业，先进制造业和现代服务业的核心，占据了无可替代的位置
软件的分类
1. 系统软件
- 能与计算机硬件紧密配合在一起，是计算机各个部件、相关的软件和数据协调、高效的工作的软件。
- 如操作系统、数据库管理系统、设备驱动程序、通讯和网络处理程序
2. 支撑软件
- 支撑软件亦称工具软件，是协助用户开发软件的工具性软件，其中包括帮助程序人员开发软件产品的工具，也包括帮助管理人员控制开发进程的工具
- 纵向支撑软件：需求分析工具、设计工具、编码工具、测试工具、维护工具
- 横向支撑软件：项目管理工具、配置管理工具
3.应用软件
- 在系统软件的支持下，在特定领域开发，为特定目的服务的一类软件
- 如：商业数据处理软件、工程与科学计算软件、CAD/CAM、
4.可复用软件
- 各种标准函数库
1.2软件危机与软件工程
1.2.1软件危机
软件在开发、运行、维护过程中出现的一系列问题
1.2.2软件工程
- 工程化思想：系统化、规范化、数量化
- 按工程化的原则和方法组织软件开发工作是有效的，是摆脱软件危机的一条主要出路
- IEEE给出的定义：软件工程是开发、运行、维护和修复软件的系统弄方法
1.3软件工程的目标
运用先进的软件开发技术和管理方法来提高软件的质量和生产效率，也就是要以较短的时间周期、较低的成本神产出高质量的软件产品，并最终实现软件的工业化生产
1.4软件生存期
-
软件生存期：由软件定义、软件开发、运行和维护三个时期组成
软件定义：解决“做什么”的问题。
通常分为三个阶段 ： 问题定义、可行性研究、需求分析
软件开发：解决“如何做”的问题。
通常由四个阶段组成：1 概要设计 、2详细设计 、3编码 、4测试
运行和维护：使软件持久的满足用户的需求。
通常有四类维护活动：改正性维护 、适应性维护、完善性维护、预防性维护
1.5软件工程方法概念
通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm) 。
软件工程方法学包括三个要素：方法、工具和过程。
方法是完成软件开发的各项任务的技术方法，回等“怎样做”的问题；工具是为运用方法而提供的自动的或半自动的软件工程支撑环境；过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。
1.5.1传统方法
也成为生命周期学或结构化范型。采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。把软件生命周期的全过程一次划分为若干个阶段，然后顺序地完成每个阶段的任务。对于问题的解决类似于队列的方法，只有队首出队才能完成后续人的出队操作，即只有阶段式完成目标并进行严格的技术审查和管理复审才能进行下一阶段的操作，并把前一阶段的结果作为下一阶段的标准。审查的一条主要标准是每个阶段完成时都应该交出“最新式”高质量文档资料，把当前阶段所完成的任务以文档形式详细说明，如果文档不完整，即可认为有某些工作忘记做了，在下一阶段开始前应将其补足。
将软件生命周期分为若干阶段，每个阶段任务相对独立，而且比较简单，便于不同人的分工合作，从而降低整体的工作难度
1.5.2面向对象方法
当软件比较庞大，或者对于软件的要求模糊或者对于要求会随时间变化时，传统方法学即不再适用，此外，维护起来仍然十分困难。其只要原因是，传统方法学是结构化的开发方法：要么面对数据，要么面对行为，其对于操作的割裂性使得在后期维护时对于软件本身的改动将会十分困难。
面向对象方法学把数据以及对于数据的操作进行合并，以数据为主线。
15.3面型服务方法
1.5.4面向数据方法
1.5.5形式化方法
1.6软件工具概述
1.6.1软件工具的概念
软件工具是指为支持计算机软件的开发、维护、模拟、移植或管理而研制的程序系统。它是为专门目的而开发的，在软件工程范围内也就是为实现软件生存期中的各种处理活动（包括管理、开发和维护）的自动化和半自动化而开发的程序系统。
1.6.2软件工具的发展
1.6.3软件工具的分类
- 支持软件开发过程的工具
- 支持软件维护过程的工具
- 支持软件管理过程和支持过程的工具
1.6.4常用软件工具介绍
1.6.4.1需求分析与设计工具
- IBM Rational Requirement Compose。（需求获取与分析工具）
- Enterprise Architect（支持软件开发的全过程）
- Microsoft Office Visio
- PowerDesigner
1.6.4.2编码工具与排错工具
- visual Basic
- visual C++
- Microsoft visual Studio
- JBuilder
- Eclipse、MyEclipse
1.6.4.3测试工具
-
（1）单元测试工具
1. 早起的单元测试有三类：程序静态分析工具、动态分析工具、自动测试支持工具 2. 目前流行的单元测试工具是xUnit系列框架 -
（2）组装测试工具
- WinRunner 企业级的功能测试工具
- IBM Ration Functional Tester 自动化功能测试工具
- Web 应用自动化测试框架
-
（3）系统测试工具
- IBM Rational Robot 功能及性能测试工具
- IBM Rational Quality Manager
- LoadRunner
2 软件生存期模型
迭代：是重复反馈过程的活动，其目的通常是为了逼近所需目标或结果。每一次对过程的重复称为一次“迭代”，而每一次迭代得到的结果会作为下一次迭代的初始值。
2.1 瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。
优点：
- 可强迫开发人员采用规范化的方法
- 严格的规定了每个阶段必须提交的文档
- 要求每个阶段交出的所有的产品都必须是经过验证的
缺点：
-
由于几乎完全依赖于书面的规格说明，很可能导致最终开发的产品不能真正的满足用户需求
-
只适用于项目开始时需求已确定的情况
2.2 快速原型模型
快速原型是快速建立起来的可以在计算机上运行的程序，他所完成的往往是最终产品功能的一个子集
优点：
缺点：
- 所选用的开发技术和工具不一定符合主流的发展；
- 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
- 使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
2.3 增量模型
增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件
- 优点
- 在较短的时间内可向用户提交可完成的部分工作产品
- 使用户有充足的的时间掌握新产品
- 项目失败的风险较低
- 缺点
- 系统必须具有开放结构，便于拆分组装
- 在组装新的构件时不破坏原有结构
2.4 螺旋模型
螺旋模型的基本思想：使用原型及其他尽量将低分险，理解这种模型的一个简单办法就是，把它看作在每个阶段之 前都增加了风险分析过程的快速原型模型
四个象限：
-
目 标 设 定 ——定义在该阶段的目标，弄清对过程和产品的限制条件，制定详细的管理计划，识别项目风险，可能 还要计划与这些风险有关的对策
-
风险估计与弱化——针对每个风险进行详细分析，设想弱化风险的步骤
-
开 发 与 验 证——评价风险之后选择系统开发模型
-
计 划——评价开发工作，确定是否进入螺旋的下一个循环
- 优点
- 对可选方案和约束条件的强调有利于已有软件的重用，也有利于把软件质量作为软件开发的一个重要目标
- 减少了过多测试，或测试不足带来的风险
- 在螺旋模型中维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别
- 缺点
- 风险驱动，要求开发人员具有丰富的经验
- 优点
2.5 喷泉模型
迭代是软件开发过程中普遍存在的一种内在属性。喷泉一词体现了迭代和无间隙特性
2.6 统一过程
由Booch、Jacobson、Rumbaugh 提出
统一过程的核心过程工作流
- 业务建模工作流——用业务用例为业务过程建立模型
- 需求工作流——描述系统应该做什么，确保开发人员构建正确的系统
- 分析与设计工作流——分析和细化需求，并建立分析模型和设计模型
- 实现工作流——用选择的实现语言实现目标系统
- 测试工作流——执行集成测试，验证对象之间的交互，是否所有的构件都集成了，是否正确实现了所有需求，差错并改正
- 部署工作流——制作软件的外部版本，软件打包、分发为用户提供帮助和支持
统一过程的阶段
- 初始阶段——主要关注项目计划和风险评估，其目的是确定是否值得开发目标系统。此阶段需要回答的问题包括
- 目标系统是否是经济的
- 目标系统是否能按期交付
- 开发系统所涉及的风险是什么
- 细化阶段——关心定义系统的总体框架，其目标是：细化初始需求，细化体系结构，监控风险并细化他们的优先级，细化业务用例制定项目管理计划
- 构造阶段——构造阶段是建立系统的第一个具有操作性的版本，以能够交付给用户测试的版本结束，有时称为测试版本
- 移交阶段——移交阶段以发布完整的系统而终止，其目标系统是确保系统正真满足用户的需求
2.7基于构件的开发模型
基于构件的的软件工程强调可复用的软件“构建”来设计和构造基于计算机的系统的过程
构建：可复用软件的组成成分，可被用来构造其他软件它可以是被封装的对象类、类树、一些功能模块、软件框架（framework）、软件构架（或体系结构Architectural）、文档、分析件、设计模式（Pattern）等
需求分析---->系统设计---->组装---->测试---->维护
开发步骤：
不考虑构件的开发技术，基于构件的的开发模型有以下步骤组成
- 对于该问题领域的基于构件的可用产品进行研究和评估
- 考录构件集成的问题
- 设计软件架构以容纳这些构件
- 将构建集成到架构中
- 进行充分的测试以保证功能正常
典型的构建模型：
2.8 敏捷过程
2001年，Kent Beck等17名编程大师发表“敏捷软件开发”宣言：我们正在通过亲身实践以及帮助他人实践的方式来揭示更好的软件开发之路，通过这项工作，我们认为：
- 个体和交互胜过过程和工具
- 可工作的软件胜过宽泛的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
敏捷原则
- 我们最优先要做的是通过尽早、持续交付有价值的软件来是客户满意
- 即使在开发后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势
- 经常交付可运行软件，交付的间隔可以从几星期到几个月，交付的时间间隔越短越好
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
- 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作
- 在团队内部，最富有成效和效率的信息传递方法是面对面交谈
- 可运行软件是进度的首要度量标准
- 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一种长期、稳定的开发速度
- 不断地关注优秀的技能和好的设计会增强敏捷能力
- 简单是必要的
- 好的架构、需求和设计出自于自组织团队
- 每隔一定时间，团队会反省如何才能更有效的工作，并相应调整自己的行为
极限编程
极限编程是最广泛的敏捷过程包含：策划、设计、编码、测试 4个框架活动的规则和实践
其他敏捷过程模型
1. 自适应软件开发（ASD）
ACD生命周期：
- 思考：思考过程中，开始项目规划并完成自适应循环策划
- 协作：受激励的人员已超越其聪明才智和独创成果的方式共同工作，协作方法是所有敏捷方法中不断重复的主旋律
- 学习：当ASD团队成员开始开发作为自适应循环一部分的构件时，其重点是在完成循环过程中学习尽可能多的东西
2. Scrum
强调使用一组“软件过程模式” 此模式被证实在时间紧张的、需求变化的、业务关键的项目中是有效的。
每一个过程模式定义一系列开发活动：
- 待定项
- 冲刺
- Scrum例会
- 演示
3. 敏捷建模
AM建模原则中独具特色的内容是：
- 有目的的模型
- 使用多个模型
- 轻装上阵
- 理解模型及工具
- 适应本地需要
4. 敏捷统一过程
采用“在全局连续”“在局部迭代”的原理来构建基于计算机的系统
- 建模
- 实现
- 测试
- 部署
- 配置及项目管理
- 环境管理
2315
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
