软件开发过程与管理 实验2

软件开发过程与管理实验报告
实验2 软件开发过程模型的设计
题目1 常见的软件开发模型有哪些？各有什么含义？
瀑布模型
表2.1瀑布模型的优缺点和适用情况
瀑布模型（Waterfall Model）是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

优点：定义清楚，应用广泛;强迫开发人员采用规范化的方法(如:结构化技术);严格规定每个阶段提交的文档；易于建模和理解;便于计划和管理;有支持生命周期模型的多种工具。

缺点：必须在开始时就知道大多数需求;不便于适应需求的变化;缺点在项目接近完成之前，产品不能投入使用;可运行的软件交付给用户之前，用户只能通过文档来了解产品。

适用情况：待开发项目与以前的成功项目类似;待开发项目的需求稳定且很好理解;适用情况使用的技术经过验证并且成熟;整个项目的开发周期较长(至少一年);用户不需要任何阶段性产品。

原型模型
表2.2原型模型的优缺点和适用情况
原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求。

同时，原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应。

相对瀑布模型而言，原型模型更符合人们开发软件的习惯，是目前较流行的一种实用软件生存期模型。

优点：直观形象，符合人们认识事务循序渐进的规律，容易被接受;有效地避免开发人员和用户对需求理解的不一致性;及时暴露问题、及时反馈，确保系统的正确性;开发周期短、成本低，软件尽早投入使用。

缺点：为了加快开发速度，常常导致软件质量的降低;没有严格的开发文档，维护困难;缺乏统一的规划和开发标准;难以对系统的开发过程进行控制。

适用情况：用户需求不确定或经常发生变化;开发人员的经验不丰富;适用情况开发规模不大、不太复杂的系统。

因为大型系统不经过整体的分析和设计是不行的。

V模型
V模型是一个著名的、以测试为驱动的开发模型，该模型强调开发过程中测试贯穿始终，是瀑布模型的一个变体。

V模型描述了质量保证活动和沟通、建模相关活动以及早期构键相关的活动之间的关系。

随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。

一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。

V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。

从水平方向看：垂直虚线左边是分析和设计，是软件设计实现的过程，同时伴随着质量保证活
动──审核的过程，也就是静态的测试过程；垂直虚线右边是对左边结果的验证，是动态测试的过程，即对分析和设计的结果进行测试，以确认是否满足用户需求。

从垂直方向看：水平虚线上部表明，需求分析、系统定义和验收测试等工作主要是面向用户，要和用户进行充分的沟通和交流，或者和用户一起完成。

水平虚线下部的大部分工作，相对来说，都是技术工作，在开发组织内部进行，主要是由工程师、技术人员完成。

螺旋模型：
优点: 设计上的灵活性,可以在项目的各个阶段进行变更。

以小的分段来构建大型系统,使成本计算变得简单容易。

客户始终参与每个阶段的开发,保证了项目的方向与可控性。

具有瀑布模型和原型模型两者的优点。

采用螺旋模型需要丰富的风险评估经验和专门知识,在风险较大的项目开发中。

缺点：如果未能够及时标识风险,势必造成重大损失。

过多的选代次数会增加开发成本,延迟提交时间。

降低进度拖延、需求变更及验收问题的风险。

提高项目开发的可管理性。

连续增量的方式,把用户反馈融入到细化的产品中。

适用情况：对于高风险,需求不确定的大型软件项目,螺旋模型是一个理想的开发过程模型。

增量模型：
优点：中间构件可以在最终版本完成之前交付,用户可以标识需求的变更。

“分而治之”的策略将一个时间周期较长的项目分解开发。

在产品开发时,允许用户确认产品。

用户能够从早期的增量中了解系统,可以更改后面增量中的需求。

对尚不清楚的需求,可将实现推迟到弄清需求后的发行中。

同瀑布模型一样,必须在早期就了解大部分需求。

对选择具体构件的开发方法敏感。

缺点：需要对每次发行进行回归测试,增加软件测试的工作量。

生命周期的早期就将产品置于配置控制之下,因而需要正式的更改控制过程,将增加系统开销。

适用情况：待开发项日类似于以前的成功项目。

大多数需求是稳定的和易于理解的。

整个项目开发时间大于一年,或者软件需要中期发行。

增量开发必须注意的问题：
良好的可扩展性架构设计，是增量开发成功的基础；由于一些模块必须在另一个模块之前完成，所以必须定义良好的接口；与完整系统相比，增量方式正式评审更难于实现，所以必须定义可行的过程；要避免把难题往后推，首先完成的应该是高风险和重要的部分；客户必须认识到总体成本不会更低；分析阶段采用总体目标而不是完整的需求定义，可能不适应管理；需要良好的计划和设计，管理必须注意动态分配工作，技术人员必须注意相关因素的变化。

RAD模型
rad模型是线性顺序模型的一个高速变种，通过使用基于构件的建造方法获得了快速开发。

快速应用开发(RAD)是一个线性顺序的软件开发模型，强调极短的开发周期。

RAD 模型是线性顺序模型的一个“高速”变种，通过使用基于构件的建造方法获得了快速开发。

如果需求理解得很好，且约束了项目范围①， RAD过程使得一个开发组能够在很短时间内(如60 到90 天)创建出“功能完善的系统”[MAR91]。

RAD 方法主要用于信息系统应用软件的开发，它包含如下几个开发阶段[KER94]：
业务建模：业务活动中的信息流被模型化，以回答如下问题：什么信息驱动业务流程？生成什么信息？谁生成该信息？该信息流往何处？谁处理它？
数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需的数据对象。

标识出每个对象的特征(称为属性)，并定义这些对象间的关系。

处理建模：数据建模阶段定义的数据对象变换成为要完成一个业务功能所需的信息流。

创建处理描述以便增加、修改、删除或获取某个数据对象。

应用生成：RAD 假设使用第四代技术。

RAD 过程不是采用传统的第三代程序设计语言来创建软件，而是复用已有的程序构件(如果可能的话)或是创建可复用的构件(如果需要的话)。

在所有情况下，均使用自动化工具辅助软件建造。

测试及反复：因为RAD 过程强调复用，许多程序构件已经是测试过的，这减少了测试时间。

但新构件必须测试，所有接口也必须测到。

RAD模型的不足之处：
1 对大型项目而言，RAD需要足够的人力资源。

2 开发者和客户都要实现承诺，否则将导致失败。

3 并非所有系统都适合：不能合理模块化的系统、高性能需求并且要调整构件接口的系统均不适合。

软件包模型
软件包模型主要用于开发依赖于外购软件产品和可重用软件包的系统。

遗留系统维护模型
主要用于纠错性维护或者稍加改进一个运行系统。

如果需要改变软件结构，应使用瀑布模型或者增量模型。

在维护期间，也可以执行某些在软件开发程序中经过选择的活动。

遗留系统维护模型在本质上类似于瀑布模型，主要差别是该模型已经建立了结构设计。

软件开发过程模型选择
目前，大多数软件开发项目都采用瀑布模型作为规范化开发的基础，主要原因如下：
软件开发单位的软件工程工作尚处于初级阶段，软件开发人员和管理人员既缺乏经验，又无历史数据可供借鉴，因此，需要一种简单易行的组织方式；结构化方法学是系统工程中最成熟的方法学，目前大多数软件开发都以结构化开发方法学为基础。

在与结构化方法学相适应的软件开发过程模型中，瀑布模型最为简单实用，行之有效；有关软件开发的现行国家标准和国家军用标准都是以瀑布模型为基础制定的。

题目2 你准备设计的软件是什么？准备采用什么样的开发模型？
我想设计的软件是网上外卖订餐系统软件，准备使用瀑布模型。

题目3 敏捷开发模型的特点是什么？它有什么适用场合？
1. 工作在小的团队中
2. 团队是跨功能的-包括测试人员，开发人员，文档开发人员等等
3. 短迭代-利用短迭代方法来交付软件
4. 相较于文档，敏捷开发更注重面对面的交流
5. 敏捷不是一个过程，而是一个软件开发的形式或者方法
6. 敏捷可以与软件过程如CMMI等一起实施。