发布时间 : 星期六 文章软件需求分析重点 - 图文更新完毕开始阅读5cbfcb26caaedd3383c4d37b
什么是软件工程:
用来制造软件的工程 化的 方法
软件的特性:
软件是抽象的，而不是物理的—看不见摸不到 软件是极其复杂的
软件的手工开发方式、智力密集型 对计算机硬件依赖性
软件是被开发或设计的，而不是被制造的 软件不会磨损和老化，但维护困难 软件的高成本
软件危机的表现:
?对软件开发成本和进度的估算很不准确，甚至严重拖期和超出预算； ?无法满足用户需求，导致用户很不满意； ?质量很不可靠，经常失效； ?难以更改、调试和增强； ?没有适当的文档； ?软件成本比重上升；
?软件开发生产率跟不上计算机应用迅速深入的趋势。
什么是软件神话,它的危害:
软件神话(software myths)：关于软件及其开发过程的一些说法被人盲目相信 ? 影响到几乎所有的角色：管理者、顾客、其他非技术性的角色、具体的技术人员；
? 看起来是事实的合理描述(有时的确包含真实的成分)、符合直觉，并经常被拿来做宣传；
? 实际上误导了管理者和技术人员对软件开发的态度，从而引发了严重的问题；
软件工程面临的挑战有哪些:
? 遗留系统(Legacy system)
? 多年以前开发出来的软件，在长期使用过程中不断的被人修改； ? 日益增加的维护成本和修改困难已经成为令人头疼的问题； ? 例如：Y2K问题； ? 高可信软件开发
? 关注软件的正确性、可靠性、安全性、保密性； ? 以形式化方法为发展趋势，通过保证模型的可信度来保证系统的可信度； ? 异构系统的集成与互操作
? 采用不同技术开发出来的系统，运行在不同的硬件平台和操作系统上，它们之间需要进行自动的数据交换； ? 更快的交付时间
? 顾客要求快速响应需求，而软件开发的周期难以有效缩短； On demand (随需应变)
? 软件开发方式的变化
? Web 2.0、open source
? 基于Internet的协同开发模式
软件工程的范围和目标:
? 范围：
? 软件开发过程(设计、开发、运行、维护) ? 软件开发中应遵循的原则和管理技术 ? 软件开发中所采用的技术和工具 ? 目标： ? 高质量 ? 按时交付 ? 控制成本 ? 满足用户需求
软件工程的四大组成部分:
工具、方法、过程、质量
第二章 核心概念与思想
功能性需求和非功能性需求及其特性:
功能性需求(Functional Requirements)：系统能够完成所期望的工作的能力
? 完备性：软件能够支持用户所需求的全部功能的能力； ? 正确性：软件按照需求正确执行任务的能力；
? 健壮性：在异常情况下，软件能够正常运行的能力 容错能力； 恢复能力；
——正确性描述软件在需求范围之内的行为，而 健壮性描述软件在需求范围之外的行为。
? 可靠性：在一定的环境下，在给定的时间内，系统不发生故障的概率，或者是快速从错误状态恢复到正确状态的能力。
非功能性需求(Non-Functional Requirements)：系统能够完成所期望的工作的
性能与质量
? 性能：软件的“时间-空间”效率；
? 易用性：用户使用软件的容易程度，用户容易使用和学习；
? 清晰性：易读、易理解，可以提高团队开发效率，降低维护代价； ? 安全性：在对合法用户提供服务的同时，阻止未授权用户的使用；
? 可扩展性：软件适应“变化”的能力，系统很容易被修改从而适应新的需求或采用新的算法、数据结构的能力；
? 兼容性：不同产品相互交换信息的能力；
? 移植性：是软件不经修改或稍加修改就可以运行于不同软硬件环境(CPU、OS和编译器)的能力；
? 经济性：开发成本、开发时间和对市场的适应能力。
? 商业质量：上市时间、成本/受益、目标市场、与老系统的集成、生命周期长短等。
软件工程的7条原理:
? 用分阶段的生命周期计划严格管理 ? 坚持进行阶段评审 ? 实行严格的产品控制 ? 采用现代程序设计技术 ? 结果应能清楚地审查 ? 开发小组的人员应少而精
? 承认不断改进软件工程实践的必要性
软件工程的几个核心思想:
复用(Reuse):
? 在一个新系统中，大部分的内容是成熟的，只有小部分内容是全新的。 ? 构造新的软件系统可以不必每次从零做起； ? 直接使用已有的软构件，即可组装成新的系统； ? 复用已有的功能模块，既可以提高开发效率，也可以改善新开发过程中带来的质量问题；
分而治之(Divide and Conquer):
? 将复杂问题分解为若干可独立解决的简单子问题，并分别独立求解，以降低复杂性；
? 然后再将各子问题的解综合起来，形成最初复杂问题的解。 折中(Trade-off):
? 不同的需求之间往往存在矛盾与冲突，需要通过折中来作出的合理的取舍，找到使双方均满意的点。
第三章 软件过程模型
理解黑盒与白盒
各种模型的优缺点及英文缩写如RAD, RUP (瀑布模型、原型模型、RAD）
? 瀑布模型(waterfall model)
? 增量过程模型(incremental process model) ? 增量模型(incremental model)
? 快速应用程序开发(Rapid App. Dev., RAD) ? 演化过程模型(evolutionary model) ? 螺旋模型(spiral model ) ? 原型模型(iterative model) ? 开放源码过程(open source)
? 统一过程模型(Rational Unified Process, RUP) ? 其他过程模型(other models)
? 形式化过程(formal method model)
? 软件复用过程(component-based reuse)
瀑布模型(waterfall model)
? 优点：
? 简单、易懂、易用； ? 每个阶段必须提供文档，而且要求每个阶段的所有产品必须由SQA小组仔细验证。 ? 缺点：
? 在开发早期，用户难以清楚地确定所有需求，需求的错误很难在开发后期纠正，因此难以快速响应用户需求变更；
? 这种模型几乎完全依赖规格说明文档，而客户无法理解和阅读这些文档，容易导致不能满足客户需求。
? 客户必须在项目接近尾声的时候才能得到可执行的程序，对系统中存在的重大缺陷，如果在评审之前没有被发现，将可能会造成重大损失。
快速应用程序开发(Rapid App. Dev., RAD)
? 快速应用开发RAD (Rapid Application Development)
? 侧重于短开发周期(一般为60~90天)的增量过程模型，是瀑布模型的高速变体，通过基于构件的构建方法实现快速开发；
? 多个团队并行进行开发，但启动时间有先后，先启动团队的提交物将作为后启动团队的输入； ? 缺点：
? 需要大量的人力资源来创建多个相对独立的RAD团队；
? 如果没有在短时间内为急速完成整个系统做好准备，RAD项目将会失败； ? 如果系统不能被合理的模块化，RAD将会带来很多问题； ? 技术风险很高的情况下，不宜采用RAD。
原型模型(iterative model)
? 优点：
? 节省时间和成本；
? 提高和改善客户/用户的参与程度； ? 缺陷：
? 为了尽快完成原型，开发者没有考虑整体软件的质量和长期的可维护性； ? 用户可能混淆原型系统与最终系统，原型系统在完全满足用户需求之后可能会被直接交付给客户使用； ? 过长的开发时间； ? 额外的开发费用。
第四章 软件需求的作用
? “Requirement is the Basics of Quality”
? 充分理解现实中的业务问题，并作为软件设计的基础；