软件需求分析重点

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

什么是软件工程:

用来制造软件的工程化的方法

软件的特性:

软件是抽象的,而不是物理的—看不见摸不到

软件是极其复杂的

软件的手工开发方式、智力密集型

对计算机硬件依赖性

软件是被开发或设计的,而不是被制造的

软件不会磨损和老化,但维护困难

软件的高成本

软件危机的表现:

•对软件开发成本和进度的估算很不准确,甚至严重拖期和超出预算;

•无法满足用户需求,导致用户很不满意;

•质量很不可靠,经常失效;

•难以更改、调试和增强;

•没有适当的文档;

•软件成本比重上升;

•软件开发生产率跟不上计算机应用迅速深入的趋势。

什么是软件神话,它的危害:

软件神话(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小组仔细验证。

• 缺点:

• 在开发早期,用户难以清楚地确定所有需求,需求的错误很难在开发后期纠正,因此难以快速响应用户需求变更;

• 这种模型几乎完全依赖规格说明文档,而客户无法理解和阅读这些文档,容易

相关文档
最新文档