构件集成模型.PPT

1.4.4 螺旋模型 (Spiral Model) 1.4.8 微软过程 图1.13微软软件生命周期阶段划分和主要里程碑 图1.14微软过程的生命周期模型 软件 =程序+数据+文档 软件危机: 原因,现象,办法 (软件工程学) 软件工程(学):开发、运行和维护软件的系统方法 软件工程3个要素：方法、工具和过程。 软件生命周期:定义,开发,运行维护 软件过程:瀑布模型+RUP 1.5 小结 软件定义时期的任务是：确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资金和成本，并制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成 开发时期具体设计和实现在前一时期定义的软件 运行维护的主要任务是使软件持久的满足用户的需要 过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。 软件开发模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。 软件过程模型的选择基于项目和应用的性质、采用的方法工具以及需要的控制和交付的产品。几种典型的模型： 瀑布模型也称为线性顺序模型 在20世纪80年代以前，瀑布模型一直是唯一被广泛采用的生命周期模型 1.阶段间具有顺序性和依赖性。 2.推迟实现的观点。 3.每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。 传统的瀑布模型过于理想化。事实上，人在工作过程中不可能不犯错误。 在设计阶段可能发生规格说明文档中的错误。 而设计上的缺陷或错误可能在实现过程中显现出来。 在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。 瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如，结构化技术）； 严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。 ? 适合于用户需求明确、完整、无重大变化的软件项目开发。 快速建立起来的可以在计算机上运行的程序，他所能完成的功能 往往是最终产品能完成的功能的 一个子集。 快速原型模型的工作过程 原型模型从需求收集开始。 开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。 然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。 原型由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解， 这个过程是迭代的。 按线性模型构建软件系统 原型模型适用情况用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求 开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式； ……原型模型可能是最好的选择 （1） 原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。 （渐增模型） 先完成一个系统子集的开发，再按同样的开发步骤增加功能 (系统子集),如此递增下去直至满足全部系统需求。 系统的总体设计在初始子集设计阶段就应作出设想。 特点： ? 反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个“增量”的发布或提交，该增量均是一个可运行的产品。 ? 早期的版本实现用户的基本需求，并提供给用户评估的平台。 如果项目在既定的商业要求之前不可能找到足够的开发人员，这种情况下增量模型显得特别有用 早期的增量可以由少量的人员实现。如果核心产品的口碑不错，可为下一个增量投入更多的人力 产品交付给用户后用户可能不满意； 到了预定的交付日期软件可能还未开发出来； 实际的开发成本可能超过预算； 产品完成前一些关键的开发人员 “跳槽”了； 产品投入市场之前竞争对手发布了一个功能相近、价格更低的软件等。 ? 适合于大型系统的软件开发，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险。 ? 需要相当丰富的风险评估经验和专门知识，使该模型的应用受到一定限制。 ? 随着迭代次数的增加，工作量加大，软件开发成本增加。 可重用部件组装模型 (构件集成模型) (Component Integration Model) 构件（component)也称为组件，是一段实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件组装起来协调工作。 该模