《软件过程模型》PPT课件
合集下载
《软件过程模型》课件
瀑布模型：适 用于需求明确、 风险较低的项
目
敏捷模型：适 用于需求变化 频繁、风险较
高的项目
迭代模型：适 用于需求不明 确、风险较高
的项目
混合模型：适 用于需求不明 确、风险较低
的项目
实践经验：根 据项目特点和 团队能力选择 合适的软件过
程模型
实践经验：在 项目实施过程 中，根据实际 情况调整软件
特点：增量模型具 有可预测性、可管 理性和可维护性， 可以降低风险，提 高软件质量。
应用：增量模型适 用于需求不明确、 风险较高的项目， 如大型软件系统、 嵌入式系统等。
优点：增量模型可 以降低开发成本， 提高软件质量，缩 短开发周期，提高 客户满意度。
Part Four
概念：V模型是 一种软件过程模 型，它将软件开 发过程划分为多 个阶段，每个阶 段对应一个测试
,
汇报人：
01 02 03 04 05
06
Part One
Part Two
软件过程模型是一种描述软件 开发过程的框架或模型
包括需求分析、设计、编码、 测试、维护等阶段
旨在提高软件开发的效率和质 量
常见的软件过程模型有水晶模 型、瀑布模型、和步骤 提高软件开发效率：通过标准化和规范化提高开发效率 保证软件开发质量：通过模型化的方法保证软件开发的质量 降低软件开发风险：通过模型化的方法降低软件开发的风险
瀑布模型：线性开发，阶段划分明确，易于管理 迭代模型：重复开发，逐步完善，适应需求变化 增量模型：逐步增加功能，易于控制风险 敏捷模型：快速响应，持续改进，适应快速变化的需求 原型模型：快速构建原型，易于用户理解和反馈 螺旋模型：风险驱动，逐步增加风险，适应复杂项目
Part Three
软件工程-软件过程模型
软件工程-软件过程模型简介软件工程是研究如何以系统的、规范的、可靠的和经济合理的方式开发、维护和管理软件的学科。
而软件过程模型是软件工程中用来描述和管理软件开发过程的一种方法论，它指导着团队成员在软件开发过程中的活动和步骤，并且帮助团队进行有效的沟通和合作。
常见的软件过程模型瀑布模型瀑布模型是最早的软件过程模型之一，它按照线性顺序将软件开发过程划分为需求分析、系统设计、编码、测试和维护等阶段。
这种模型的优势在于每个阶段的任务清晰明确，工作量可控；也存在着刚性和不适应需求变更的问题。
增量模型增量模型强调通过多个增量的方式逐步完成软件开发，每个增量都包含了完整的软件功能。
这种模型能够及早地交付可用的软件功能，并且可以有效地应对需求变更。
但是增量模型的不足之处在于可能会出现功能之间的兼容性和交互问题。
喷泉模型喷泉模型是一种迭代的软件过程模型，它将软件开发过程分为多个不断迭代的阶段，并且每个阶段都包含了需求分析、系统设计、编码、测试和维护等活动。
喷泉模型能够更好地应对需求变更，并且能够更好地与用户进行交互和反馈。
螺旋模型螺旋模型结合了瀑布模型和增量模型的特点，它强调了风险管理和迭代开发。
螺旋模型通过风险评估和迭代开发来降低开发过程中的风险，并且能够及时地应对需求变更。
敏捷开发模型敏捷开发模型是一种迭代的、增量的软件开发方法论，它强调了快速响应需求变化和持续交付可用软件的能力。
敏捷开发模型的核心是团队的合作和反馈，以及持续迭代和改进。
敏捷开发模型可以提高团队的灵活性和适应性，并且能够更好地满足客户的需求。
软件过程模型是软件工程中描述和管理软件开发过程的一种方法论。
常见的软件过程模型包括瀑布模型、增量模型、喷泉模型、螺旋模型和敏捷开发模型等。
每种模型都有自己的优势和不足，团队可以根据具体的项目需求和团队特点选择合适的软件过程模型来进行开发。
2-1 软件过程模型
原型需求
系统需求
沟通 快速策划 建模 快速设计
提交系统
部署交付 及反馈
构建原型
2-1 软件过程模型
快速原型法的步骤
Step 1：双方通过沟通，明确已知的需求，并大致勾画出以后 再进一步定义的东西。 Step 2：迅速策划一个原型开发迭代并进行建模，主要集中于 那些最终用户所能够看到的方面，如人机接口布局或者输出
2-1 软件过程模型
瀑布模型
也叫做鲑鱼模型(Salmon model)：向前一阶段回溯，很难。
2-1 软件过程模型
瀑布模型
优点——追求效率 – 它提供了一个模板，这个模板使得分析、设计、编码、测试和 支持的方法可以在该摸板下有一个共同的指导；
– 简单、易懂、易用、快速；
– 为项目提供了按阶段划分的检查点，项目管理比较容易；每个
2-1 软件过程模型
增量模型
举例1：开发一个类似于Word的文字处理软件 – 增量1：提供基本的文件管理、编辑和文档生成功能； – 增量2：提供高级的文档编辑功能； – 增量3：实现拼写和语法检查功能；
– 增量4：完成高级的页面排版功能；
举例2：开发一个教务管理系统 – 增量1：提供基本的学籍管理和成绩管理功能； – 增量2：提供选课功能； – 增量3：提供查询教室使用情况的功能；
– 增量4：提供课表生成、上课名单生成、成绩录入等功能。
2-1 软件过程模型
增量模型
优点：
– 在时间要求较高的情况下交付产品：在各个阶段并不交付一 个可运行的完整产品，而是交付满足客户需求的一个子集的 可运行产品，对客户起到“镇静剂”的作用； – 人员分配灵活：如果找不到足够的开发人员，可采用增量模 型：早期的增量由少量人员实现，如果客户反响较好，则在 下一个增量中投入更多的人力； – 逐步增加产品功能可以使用户有较充裕的时间来学习和适应 新产品，避免全新软件可能带来的冲击；
软件过程模型
软件过程模型软件过程是指在软件工具的支持下，所进行的一系列软件开发和进化的活动。
软件过程模型是对软件开发实际过程的抽象和简化，是描述软件开发过程中各种活动如何执行的模型，因此又称为软件开发模型。
主要的软件过程模型有：瀑布模型、增量模型、螺旋模型、喷泉模型和基于知识的模型等。
⑴瀑布模型是经典的软件开发模型，将软件开发活动中的各项活动规定为依线性顺序连接的若干阶段，它简单易用，在消除非结构化软件、降低软件的复杂性、促进软件开发工程化方面起了很大的作用。
但在软件开发实践中也逐渐暴露出它的缺点。
它将一个充满回溯的软件开发过程硬性分割为几个阶段，无法解决软件需求不明确或者变动的问题。
⑵增量模型是一种非整体开发的模型。
根据增量的方式和形式的不同，分为基于瀑布模型的渐增模型和基于原型的快速原型模型。
该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
⑶螺旋模型将瀑布模型和增量模型结合起来，并加入了风险分析。
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期可分为4个工作步骤：制定计划、风险分析、实施工程、客户评估。
⑷喷泉模型用于采用对象技术的软件开发项目。
它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。
喷泉模型使开发过程具有迭代性和无间隙性。
软件开发过程有4个阶段，即分析、系统设计、软件设计和实现。
各阶段相互重叠，以分析为基础，资源消耗成塔形，从高层返回低层无资源消耗。
强调增量开发，是对象驱动的过程，反映了对象的开发和重用过程。
⑸基于知识的模型也称为智能模型。
通过领域的专家系统，可使需求说明更加完整、准确和无二义性。
通过软件工程知识和特定应用领域的知识和规则的应用来提供开发的帮助。
软件工程-软件过程模型
4 演化模型-螺旋模型
Evolutionary Model
螺旋模型的基本思想
每一个螺旋周期（Spiral model sectors）包 含四个部分： （1）确定目标，选择方案，设定约束条件， 选定完成本周期所定目标的策略。 （2）分析该策略可能存在的风险。 （3）在排除风险后，实现本螺旋周期的目标。 （4）评价前一步的结果，并且计划下一轮的 工作。
第二章 软件过程模型
软件生存周期 软件开发模型 瀑布模型 进化式模型 演化模型 形式化开发
第一节 软件生存周期
软件生存周期的概念： 一个软件从计划起，到废弃不用止。
软件生存周期包括：计划、开发、运行。
第二节 软件开发模型概念
软件开发模型的概念：
为整个软件生存期建立的模型。
交付客户
构件n
规格说明
设计
实现和集成
交付客户
增量模型的基本思想
每个增量提供系统功能的一个子集，一个增 量完成并交付，部分系统功能可以提前交付 使用。 对增量中服务的分配取决于服务优先次序。 最高优先权的服务首先被交付。 第一个增量往往是核心的产品。 开发者能通过对系统的经验帮助理解后面的 增量需求和目前增量后续版本的需求变更。
思考题
为以下各系统提出合适的软件过程模型，阐 述理由： （1） 汽车防锁死刹车控制系统 （2）一个支持软件维护的虚拟现实系统 （3）大学记账系统，准备替换一个已存在的 系统 （4）一个位于火车站的交互式火车车次查询 系统
建立原型系统的方法
原型系统仅包括未来系统的主要功能，以及 系统重要的接口。 开发原型系统尽可能使用能缩短开发周期的 语言和工具。
3 演化模型-增量模型
Evolutionary Model
软件工程-软件过程模型
软件工程-软件过程模型软件工程-软件过程模型1.引言在软件开发过程中，软件过程模型是一种指导开发团队进行软件项目管理、开发、测试和维护的方法。
选择合适的软件过程模型能够提高开发效率和质量。
本文将介绍几种常见的软件过程模型及其特点。
2.瀑布模型2.1 概述瀑布模型是最经典的软件过程模型，它将软件开发过程划分为需求分析、设计、编码、测试和维护等阶段，各阶段按序依次进行，并且每个阶段的输出作为下一个阶段的输入。
该模型适用于需求明确、变动较少的项目。
2.2 优点●易于理解和使用●各个阶段有明确的任务和输出●开发进度容易掌握2.3 缺点●特别注重文档，过程较为刻板●不适应需求较为灵活和易变的项目●需求变更较困难3.增量模型3.1 概述增量模型是一种迭代的软件过程模型，它将软件开发过程分解为多个增量部分，每个增量部分都是可执行的，具有独立的功能。
每个增量都经过开发、测试和维护等阶段，最终形成完整的软件系统。
3.2 优点●提高开发效率，快速交付可用的软件●适用于需求变更频繁的项目●早期发现和解决问题，降低风险3.3 缺点●需要多次集成和测试，增加了工作量和成本●每个增量都需要经过完整的开发流程，开发时间可能较长4.原型模型4.1 概述原型模型是一种以用户需求为中心的软件过程模型。
它将软件系统分为前端界面和后端逻辑实现，开发团队先为用户构建原型界面，根据用户反馈进行迭代修改，最终实现满足用户需求的系统。
4.2 优点●高度交互性，能够及时反馈用户需求●提高用户满意度，减少需求变更●可提前发现和解决问题4.3 缺点●需要与用户之间的密切合作●前期投入较大●需求不够明确时，开发团队容易走偏5.敏捷模型5.1 概述敏捷模型是一种以迭代和增量为特点的软件过程模型。
它注重团队合作、需求变更和持续交付的原则，以客户满意为最终目标。
5.2 优点●满足需求变更的灵活性●提高开发团队的工作效率和满意度●客户参与度高，减少需求风险5.3 缺点●依赖团队协作和沟通●需求变更较多时，可能影响开发进度和成本控制●关注点放在短期交付上，对长期计划较弱6.结论根据不同项目的需求和特点，选择合适的软件过程模型对项目的成功非常重要。
14 软件过程模型CMM的体系结构
4.6 KPA2.6 软件配置管理
• SCM(Software Configuration Management)保证软件项目生产的产品在 软件生命周期中的完整性。
• 软件配置：软件工作产品及技术文档。 • 通过在给定时间点上软件的配置，系统地 控制配置的更改，维护在整个软件生命周 期中配置的完整性和可跟踪性，得到具有 完整性的软件工作产品和软件产品。
1.1 软件项目成功的三要素－PPT
S D O TECHNOLOGY
不规范
SD O
TECHNOLOGY
S D O
低效率
覆盖成功开发的三要素： Technology – 强大的工具 Process – 协同和规范 People – 执行能力
S D O TECHNOLOGY
不专业
1.2 软件工程难题
5 CMM 3级的KPA
• 3级CMM在2级的基础上增加了七个KPA，既包 括项目管理问题，又包括组织问题和工程问题。 • 软件组织建立了一个基础设施，对项目中所有 有效的软件工程和管理过程的实施制度化。
5.1 KPA3.1 组织过程焦点OPF
• Organization Process Focus • 软件组织建立负责软件过程活动的责任和 机制 • 为改进软件组织的整体软件过程能力提供 组织上的保证。 • 如：设定职位，指定专人或小组负责软件 过程能力的监管。
第14讲 软件能力成熟度模型 CMM
本讲提纲
• • • • • • • • 1. 软件过程与过程改进概述 2. 软件过程的三个流派 3. CMM 概述/CMM的外部结构 4. CMM 2级的6个关键过程域 5. CMM 3级的7个关键过程域 6. CMM 4级的6个关键过程域 7. CMM 5级的6个关键过程域 8 CMM的内部结构与公共特性
16 软件过程模型CMMI
• CMMI 模型对工程活动进行了一定的强化。
– 在CMM中，只有3级中的软件产品工程和同行评审两个关键过程 域是与工程过程密切相关的， – 在CMMI中，则将需求开发，验证，确认，技术解决方案，产品集 成这些工程过程活动都作为单独的关键过程域进行了要求，从而 在实践上提出了对工程的更高要求和更具体的指导。
2.4 CMMI的 模型表述
• 一个组织可以从以下两种过程改进的方法 中选择其一:
– 组织成熟度 – 过程域能力
• CMMI 对不同过程改进方法采用不同表示 法
– 组织成熟度 – 分级(阶梯式)表示法 – 过程域能力 – 连续表示法
2.4分级表示法
规定了一系列已经证明的改进措施,每一级 都是其上一级的基础,服务于上一级.
量化管理
3 已定义
过程标准化
项目管理 2 已管理
风险 返工
1 初始级
4.3 CMMI 的新特性
• CMMI 模型中比CMM 进一步强化了对需求的重视。
– 在CMM 中，关于需求只有需求管理这一个关键过程域，也就是说， 强调对有质量的需求进行管理，而如何获取需求则没有提出明确 的要求。 – 在CMMI的阶段模要求和方法。
• CMMI中还强调了风险管理。
– 在CMM 中把风险的管理分散在项目计划和项目跟踪与监控中进行 要求， – CMMI3级里单独提出了一个独立的关键过程域叫做风险管理。
4.4 CMMI 的新特性
• 保留了CMM阶段式模式的基础 • 增加了连续式模型，
– 可以帮助组织其客户更加客观和全面的了解它的过程 成熟度。 – 可以给组织在进行过程改进的时候带来更大的自主性， – 不用再象CMM 中 一样，受到等级的严格限制。 – 这种改进的好处是灵活性和客观性强，弱点在于若缺 乏指导，一个组织可能缺乏对关键过程域之间依赖关 系的正确理解而片面的实施过程，造成一些过程成为 空中楼阁，缺少其他过程的支撑。 – 两种表现方式（连续的和阶段的）从他们所涵盖的过 程区域上来说并没有不同，不同的是过程区域的组织 方式以及对成熟度（能力）级别的判断方式。
软件工程ppt课件完整版
修改与测试
对软件进行修改，并进行测试以确保 修改的正确性。
版本管理与发布
对修改后的软件进行版本管理，并发 布新版本。
软件演化策略与方法
增量式演化
逐步增加新功能或修改现有功能。
迭代式演化
通过不断迭代改进软件质量。
软件演化策略与方法
组件化演化
将软件拆分为独立组件进行演化。
重构
改进软件内部结构而不改变其外部行为。
处理团队冲突，化解矛盾，促进团队合作
版本控制与文档管理
使用版本控制工具（如Git） 管理项目代码和文档
建立完善的文档管理体系， 包括需求文档、设计文档、 测试文档等
制定版本控制规范，包括 分支管理、代码提交和合 并流程等
定期评审和更新文档，确 保文档与项目实际进展保 持一致
07 软件维护与演化
软件维护类型及流程
版本迁移与数据迁移
将旧版本的数据迁移到新版本，确保数据的 完整性和一致性。
持续集成与持续交付
持续集成
频繁地将代码集成到主干， 并进行自动化测试以快速发 现问题。
持续交付
在持续集成的基础上，将软 件以可发布的状态交付给用 户，以便用户能够快速获得 新功能或修复问题。
自动化测试与部署
监控与反馈
利用自动化工具进行测试和 部署，提高开发效率和质量。
软件工程的发展
软件工程经历了从程序设计、软件 工程方法、软件工程过程到软件工 程学科的逐步成熟过程。
软件工程目标与原则
软件工程的目标
在给定成本、进度的前提下，开发出具有有效性、可靠性、可理解性、可维护 性、可重用性、可适应性、可移植性、可追踪性和可互操作性且满足用户需求 的软件产品。
软件工程的原则
过程PPT课件
12 2020/4/20
SX.NU-INC-YW
第12页，共47页
软件开发时期各阶段任务
软件开发时期的任务是设计和实现已定义的，并经过需
求分析的软件系统。
软件开发时期通常划分成软件设计、软件实现和软件测 试三个阶段。
软件测试也可以分解到软件实现的各个活动中，可重新 划分成编码和单元测试、集成测试、系统测试三个阶段。 甚至，还可以认为软件测试不是一个独立的阶段，因为
方法层提供了建造软件在技术上“如何做”。软件工程 方法涵盖在一系列开发过程的任务中。方法依赖于一组 基本原则得以实施。这些原则控制了每一个技术区域的 建模活动和其他描述技术。
工具层对过程和方法提供了自动化支持。
4 2020/4/20
SX.NU-INC-YW
第4页，共47页
2.1.2 软件生存周期
软件生存周期（Software Life Cycle）：一个软件项目从 问题提出开始，直到软件产品最终退役（废弃不用）为止。 软件生存周期方法学把整个生存周期划分为多个相对独立 的较小阶段，给每个阶段赋予确定而有限的任务，从而降 低了整个软件工程的难度，提高了软件开发生产率；对软 件生存周期的每个阶段采用科学的、规范的方法和管理， 使软件开发全过程以一种有条不紊的方式进行，保证了软 件质量，提高了软件的可维护性和软件开发的成功率。
③ 每个阶段有相对独立的任务，前一个阶段任务的完成
是后一个阶段任务开始的前提和基础，而后一阶段任务
的完成是前一阶段提出“解”的进一步具体化和实现细
6 节。 2020/4/20
SX.NU-INC-YW
第6页，共47页
软件过程开发标准的要点
④ 每一个阶段的开始和结束都有严格标准。对于任何两 个相邻的阶段而言，前一阶段的结束标准就是后一阶段的 开始标准。每一个阶段结束之前，都必须对这个阶段的成 果进行严格的技术复审和管理审查。审查的主要对象是每 个阶段都应该提交的、最新版本的、高质量的相关文档资 料。
《软件过程模型》PPT课件
❖一旦将个人的单元测试组织到一个“通用测试集”， 每天都可以进行系统的集成和确认测试。 ❖XP验收测试，也称为客户测试，则客户规定技术 条件，并且着眼于客户可见的、可评审的系统级的 特征和功能。
UP起源
UP历史
Rational统一过程
• 从3个视角描述软件开发过程
– 动态视角：随时间变化的各个阶段 – 静态视角：所进行的活动 – 实践视角：可采用的良好实践建议
Rational统一过程
静
初始：项目计
态ห้องสมุดไป่ตู้
划、评估风险；
视
精化：设计系
角
统的体系结构、
制定项目计划、 确定资源需求；
构建：开发出 所有组件和应 用程序，集成 并进行详尽测 试；
❖ 三剑客及其建模方法
– James Rumbaugh提出了OMT方法 – Grady Booch提出了Booch方法 – Ivar Jacobson提出了Objectory（Object Factory）方法
UP起源
❖UML
– 1994年James Rumbaugh和Grady Booch创建了统一方法（ Unified Method），即UML第一个草案 – 三人加入Rational公司（后被IBM收购），领导了OMG的建 模标准制定 – 1997年UML1.0发布，2004年UML2.0发布，成为OO建模标准
方面需求定义那些对整个软件体系结构产生影响的横 切关注点。 面向方面的软件开发（AOSD）通常称为面向方面编 程（AOP），为定义、说明、设计和构建方面提供过 程和方法，是对横切关注点局部表示的一种机制，超 越了子程序和继承的方法。
面向方面的构件工程(AOCE)
* AOCE对纵向分解的软件构件进行横向切片，称为“方面 ”， 以表示构件功能及非功能的横切属性。
UP起源
UP历史
Rational统一过程
• 从3个视角描述软件开发过程
– 动态视角：随时间变化的各个阶段 – 静态视角：所进行的活动 – 实践视角：可采用的良好实践建议
Rational统一过程
静
初始：项目计
态ห้องสมุดไป่ตู้
划、评估风险；
视
精化：设计系
角
统的体系结构、
制定项目计划、 确定资源需求；
构建：开发出 所有组件和应 用程序，集成 并进行详尽测 试；
❖ 三剑客及其建模方法
– James Rumbaugh提出了OMT方法 – Grady Booch提出了Booch方法 – Ivar Jacobson提出了Objectory（Object Factory）方法
UP起源
❖UML
– 1994年James Rumbaugh和Grady Booch创建了统一方法（ Unified Method），即UML第一个草案 – 三人加入Rational公司（后被IBM收购），领导了OMG的建 模标准制定 – 1997年UML1.0发布，2004年UML2.0发布，成为OO建模标准
方面需求定义那些对整个软件体系结构产生影响的横 切关注点。 面向方面的软件开发（AOSD）通常称为面向方面编 程（AOP），为定义、说明、设计和构建方面提供过 程和方法，是对横切关注点局部表示的一种机制，超 越了子程序和继承的方法。
面向方面的构件工程(AOCE)
* AOCE对纵向分解的软件构件进行横向切片，称为“方面 ”， 以表示构件功能及非功能的横切属性。
软件开发模型(最新总结ppt)
一、瀑布模型（Waterfall Model
）
定义：瀑布模型即生存周期模型，其核心思想是 按工序将问题化简，将功能的实现与设计分开， 便于分工协作，即采用结构化的分析与设计方 法将逻辑实现与物理实现分开。 结构：瀑布模型将软件生命周期划分为制定计划、 需求分析、软件设计、程序编写、软件测试和 运行维护等六个基本活动，并且规定了它们自 上而下、相互衔接的固定次序，如同瀑布流水， 逐级下落。
八、并发开发模型： 定义：也称为“并发工程”，它关注于多 个任务的并发执行，表示为一系列的主要 技术活动、任务及其相关状态。 构成：并发过程模型由客户要求、管理决 策和评审结果驱动，不是将软件工程活动 限定为一个顺序的事件序列，而是定义一 个活动网络，网络上的每一个活动均可与 其他活动同时发生。这种模型可以提供一 个项目的当前状态的准确视图。
瀑布模型图：
计划 需求分析 设计 需求变更
点：在瀑布模型中，软件开发的各项活动严 格按照线性方式进行，当前活动接受上一项活 动的工作结果影响，实施完成所需的工作内容 。 缺点： 1、 各个阶段的划分完全固定，阶段之间产生大 量的文档，极大地增加了工作量； 2、由于开发模型是线性的，用户只有等到整个 过程的末期才能见到开发成果，从而增加了开 发的风险； 3、早期的错误可能要等到开发后期的测试阶段 才能发现，进而带来严重的后果。
六、WINWIN模型 ：
定义：WINWIN模型融合了螺旋模型的基本成分 以及原型实现的迭代特性，夸大风险以及标识。 路程经过过程早期谈判使客户以及开发者之间达 成一致协议，它将变成进展成软件以及系统定义 的关键标准。 优点：WINWIN模型夸大风险阐发以及标识，使 得开发职员以及用户对每个演化层出现的风险有 所相识，继而做出应有的反应。采用WINWIN模 型的优点是客户以及开发者到达一种平衡，实现 共赢，可是需要额外的谈判内容。
第2讲软件过程模型ppt课件
严格执行突发事件上报制度、校外活 动报批 制度等 相关规 章制度 。做到 及时发 现、制 止、汇 报并处 理各类 违纪行 为或突 发事件 。
软件过程模型
软件过程模型：增量模型
构件1
分析 构件2
设计 分析
编码
测试
设计 编码 测试
非整体的、搭积 木的开发的思想：
1）把软件产品作为 系统的增量构件来设 计、编码、集成和测 试
严格执行突发事件上报制度、校外活 动报批 制度等 相关规 章制度 。做到 及时发 现、制 止、汇 报并处 理各类 违纪行 为或突 发事件 。
软件过程模型
软件过程模型：螺旋模型
优点：
1）将瀑布模型、原型模型和增 量模型结合起来，加入了风 险分析，弥补了不足之处
2）风险驱动，方便项目管理人 员及时调整管理决策，进而 可降低开发风险
优点： 提高效率，节省开发时间
缺点： 没有严格的阶段区分，不便于 管理
严格执行突发事件上报制度、校外活 动报批 制度等 相关规 章制度 。做到 及时发 现、制 止、汇 报并处 理各类 违纪行 为或突 发事件 。
软件过程模型
各个模型的比较：
严格执行突发事件上报制度、校外活 动报批 制度等 相关规 章制度 。做到 及时发 现、制 止、汇 报并处 理各类 违纪行 为或突 发事件 。
软件过程模型
软件过程模型：增量模型
✓ 缺点 1）构建集成问题 2）增量粒度选择很难把握
严格执行突发事件上报制度、校外活 动报批 制度等 相关规 章制度 。做到 及时发 现、制 止、汇 报并处 理各类 违纪行 为或突 发事件 。
软件过程模型
几种常见的软件过程模型
✓ 瀑布模型 ✓ 原型模型 ✓ 增量模型 ✓ 螺旋模型 ✓ 喷泉模型
软件过程框架与软件过程模型PPT课件
21
SRD
22
7.软件工程管理
项目管理是过程管理的主要体现： (1)建立与客户的沟通渠道； (2)制订计划，定义资源、时限、落实到开发组； (3)风险分析，评估所采用的技术和管理带来的风险； (4)技术过程监控； (5)客户评审，获得客户的反馈。
23
24
25
8.软件质量保证
软件质量保证SQA活动，贯穿于软件过程始终。开发单位 成立SQA小组负责全面质量管理。在开发项目计划时就要做出 SQA计划。其工作： - 各种测试：测试软件是否满足规格说明要求。 - 各种评审/审计：为多种人员参与的讨论会，以规格说明或各 种标准、规范为准评价各项软件工作。 - 报告和记录：所有测试、评审、审计都要详细记录并写出报 告，报告和记录均要整理、归档。
以上活动均应在软件质量保证计划中列出。
26
27
传统软件生命周期模型
1. 瀑布模型 Winston Royce在软件生命周期概念的基础上，于1970年提出了著名
的“瀑布模型”（waterfall model）。
28
瀑布模型中的每一个开发活动具有下列特征： - 本活动的工作对象来自于上一项活动的输出，这些输出一般是代表 本阶段活动结束的里程碑式的文档。 - 根据本阶段的活动规程执行相应的任务。 - 产生本阶段活动相关产出——软件产品，作为下一活动的输入。 - 对本阶段活动执行情况进行评审。
37
原型法的适用范围和局限性： - 对于一个大型系统，如果不经过系统分析得到系统的整体划分， 而直接用原型来模拟是很困难的。 - 对于原有应用的业务流程、信息流程混乱的情况，原型构造与 使用有一定的困难。 - 对于一个批处理系统，由于大部分活动是内部处理的，因此应 用原型方法会有一定的困难。
SRD
22
7.软件工程管理
项目管理是过程管理的主要体现： (1)建立与客户的沟通渠道； (2)制订计划，定义资源、时限、落实到开发组； (3)风险分析，评估所采用的技术和管理带来的风险； (4)技术过程监控； (5)客户评审，获得客户的反馈。
23
24
25
8.软件质量保证
软件质量保证SQA活动，贯穿于软件过程始终。开发单位 成立SQA小组负责全面质量管理。在开发项目计划时就要做出 SQA计划。其工作： - 各种测试：测试软件是否满足规格说明要求。 - 各种评审/审计：为多种人员参与的讨论会，以规格说明或各 种标准、规范为准评价各项软件工作。 - 报告和记录：所有测试、评审、审计都要详细记录并写出报 告，报告和记录均要整理、归档。
以上活动均应在软件质量保证计划中列出。
26
27
传统软件生命周期模型
1. 瀑布模型 Winston Royce在软件生命周期概念的基础上，于1970年提出了著名
的“瀑布模型”（waterfall model）。
28
瀑布模型中的每一个开发活动具有下列特征： - 本活动的工作对象来自于上一项活动的输出，这些输出一般是代表 本阶段活动结束的里程碑式的文档。 - 根据本阶段的活动规程执行相应的任务。 - 产生本阶段活动相关产出——软件产品，作为下一活动的输入。 - 对本阶段活动执行情况进行评审。
37
原型法的适用范围和局限性： - 对于一个大型系统，如果不经过系统分析得到系统的整体划分， 而直接用原型来模拟是很困难的。 - 对于原有应用的业务流程、信息流程混乱的情况，原型构造与 使用有一定的困难。 - 对于一个批处理系统，由于大部分活动是内部处理的，因此应 用原型方法会有一定的困难。
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
阶段及迭代 业务模型
如果需要 一个或多个原型
细化阶段
用例模型 补充需求
包括非功能需求 分析模型 软件体系结构描述 可执行的体系结构原型 初步的设计模型 修订的风险列表 项目计划，包括
迭代计划 调整的工作流 里程碑 技术工作产品 初始用户手册
构建阶段
设计模型 软件构件 集成的软件增量 测试计划及步骤 测试用例 支持文档
UP起源
UP历史
Rational统一过程
• 从3个视角描述软件开发过程
– 动态视角：随时间变化的各个阶段 – 静态视角：所进行的活动 – 实践视角：可采用的良好实践建议
Rational统一过程
静
初始：项目计
态
划、评估风险；
视
精化：设计系
角
统的体系结构、
制定项目计划、 确定资源需求；
构建：开发出 所有组件和应 用程序，集成 并进行详尽测 试；
统一过程的阶段
❖构建阶段(construction)：[部署]
✓与通用软件过程中的构建活动相同。该阶段采用体系结构模型作为输入，开发 或获取软件构件，使得最终用户能够操作用例。
❖转换阶段(transition): [构建、部署]
✓包括通用构建活动的后期阶段以及第一部分通用部署活动。软件被提交给最终 用户进行Beta测试，用户反馈缺陷及必要的变更。另外，软件开发团队创建系
统一过程的阶段
❖细化阶段(elaboration)[策划、建模]
✓包括用户沟通和通过过程模型的建模活动。该阶段扩展了起始阶段定义的用例， 并扩展体系结构以包括软件的五种视图——用例模型、分析模型、设计模型、 实现模型和部署模型。体系结构基线证明了体系结构的可实现性，但没有提供 系统使用所需的所有功能和特性。另外，在细化的最终阶段将评审项目计划以 确保项目的范围、风险和交付日期合理。同时对项目计划进行修订。
• 软件过程模型是不断发展的 • 各种软件过程模型各有优缺点和
适用场合 • 选用时不必拘泥于某种模型 • 可组合多种模型 • 也可根据实际创造新的模型
应用举例
❖开发一个类似于Word的字处理软件。
– 迭代1：提供基本的文件管理、编辑和文档生成功能。 – 迭代2：提供高级的文档编辑功能。 – 迭代3：实现拼写和语法检查功能。 – 迭代4：完成高级的页面排版功能。
① 个体和交互胜过过程和工具 ② 可以工作的软件胜过面面俱到的文档 ③ 客户合作胜过合同谈判 ④ 响应变化胜过遵循计划 虽然右边的项有价值，但我们更重视左边的项
敏捷 Agility
敏捷软件开发的基本原则
• 客户参与到开发团队中
• 实践中的困难
– 确定系统需求、对需求排序、 评估系统等
– 客户不一定愿意参与到
上次课的基本知识点回顾
软件生命周期 问题定义、可行性研究、需求分析、总体设 计、详细设计、编码、测试、维护
传统软件过程模型 瀑布模型 增量模型
上次课的基本知识点回顾
传统软件过程模型 原型模型 螺旋模型 喷泉模型
现代软件过程模型 – 基于构件的开发模型 – 形式化方法模型
如何选择软件过程模型
极限编程
课本图3-2 极限编程过程
极限编程的过程
❖策划：策划活动开始于建立一系列描述待开发软件 必要特征与功能的“故事”。
❖每个故事由客户书写并置于一张索引卡上，客户根据对应 特征或功能的全局业务价值度标明权值（故事优先级）； ❖评估每个故事给出开发周数为单位的成本； ❖客户和团队共同决定故事分组； ❖团队对待开发故事进行排序 ❖团队计算项目的速度 ❖在开发过程中，用户可增加、减少故事数，以及改变故事 的优先级。
• 软件以增量的方式进行开发和交付
开发团队中
• 开发团队的技术和开发团队的风格 应得到认可
• 接受变更，设计软件适应变更
• 保持所开发软件和开发过程的简单 性
– 团队成员的性格 – 需求和变更的优先级不
容易确定
– 维护简单性需要额外的
时间
– 企业文化很难改变
敏捷开发方法
• 极限编程：eXtreme Programming/XP • 自适应软件开发
极限编程的过程
❖编码：XP推荐的故事开发和基本设计完成之后， 团队不应直接开始编码，而是开发一系列用于检测 本次（软件增量）发布的包括所有故事的单元测试。 XP编码活动中的关键概念之一是结对编程。
❖XP建议两个人共同为一个故事开发代码，提供实时 解决问题和实时保证质量。
极限编程的过程
❖测试：在编码开始之前建立单元测试是XP方 法的关键因素。所建立的单元测试应当使用一 个可以自动实施的框架，这种方式支持代码修 改之后即时的回归测试策略。
面向方面的软件开发
随着现代计算机系统变得更加复杂，某些关注点—— 客户需要的属性或技术兴趣点——已经体现在整个架 构设计中。某些关注点是系统的高层属性（例如安全 性、容错能力），某些关注点影响了系统的功能等。 如果某个关注点涉及系统多个方面的功能、特性和 信息，这些关注点通常称为横切关注点。
面向方面的软件开发
方面需求定义那些对整个软件体系结构产生影响的横 切关注点。 面向方面的软件开发（AOSD）通常称为面向方面编 程（AOP），为定义、说明、设计和构建方面提供过 程和方法，是对横切关注点局部表示的一种机制，超 越了子程序和继承的方法。
面向方面的构件工程(AOCE)
* AOCE对纵向分解的软件构件进行横向切片，称为“方面 ”， 以表示构件功能及非功能的横切属性。
统一过程的三个特点
• 用例驱动
– 所有的软件开发都是用户需求驱动的。UP采用用 例来描述用户需求，同时提供一套方法把用例转化 为设计的类图，进一步变成最终的程序代码。在整 个软件开发过程中，要求用例是可跟踪的，即在设 计和实现阶段，都可以找到相应的需求。
• 以架构为核心
– 架构刻画了系统的整体设计，舍弃细节，突出重要 特征。UP提供了创建架构的方法和过程。
统一过程的三个特点
• UP采用迭代和增量的开发模式，把一个软件产品 划分成多个较小的部分，每次完成一个部分，每 次迭代都是产品的一个增量。
• 优点：把一个复杂系统分解成多个简单系统，提 供软件项目的可控性，降低软件开发的风险，有 效的应对需求变更。
UP起源
❖面向对象
– 60年代 Alan Kay发明OO语言 Smalltalk和面向对象编程（ObjectOrientedprogramming, OOP） – 1982年Grady Booch提出面向对象设计（Object-Oriented Design, OOD） – 80年代末，Peter Coad创建完整的OOA/D方法
Adaptive Software Development/ASD • 并列争球法：Scrum • 动态系统开发方法
Dynamic System Development Method/DSDM • 水晶法：Crystal • 特征驱动开发：Feature-Driven Development/FDD • 精益软件开发：Lean Software Development/LSD •…
* 系统的方面包括用户接口、协同工作、发布、持续性、存 储器管理、事务处理、安全、完整性等。
* 构件也许提供或需要某一方面的“方面细节信息”，如视 图机制、可扩展性和接口类型（用户接口方面）；事件生 成、传输和接收（分布式方面）；数据存取/查询和索引 （持久性方面）；认证、编码和访问权限（安全方面）； 原子事务、协同控制和登录策略（事务方面）等。
❖ 三剑客及其建模方法
– James Rumbaugh提出了OMT方法 – Grady Booch提出了Booch方法 – Ivar Jacobson提出了Objectory（Object Factory）方法
UP起源
❖UML
– 1994年James Rumbaugh和Grady Booch创建了统一方法（ Unified Method），即UML第一个草案 – 三人加入Rational公司（后被IBM收购），领导了OMG的建 模标准制定 – 1997年UML1.0发布，2004年UML2.0发布，成为OO建模标准
极限编程的过程
❖设计：XP设计严格遵循KIS原则，即使用简单而 不是复杂的表述。另外，设计为故事提供不多也不 少的实现原则，不鼓励额外功能性设计。
❖鼓励使用CRC卡（类-责任-协作者）确定和组织与 当前软件增量相关的类； ❖如果某个故事的设计中遇到困难，采用Spike方案； ❖鼓励重构 ❖XP的中心观念是设计与编码可以同时进行。
Rational统一过程
静
初始：项目计
态
划、评估风险；
视
精化：设计系
角
统的体系结构、
制定项目计划序，集成 并进行详尽测 试；
产品化：将产 品移交给用户。
动态视角
统一过程的阶段
❖起始阶段(inception)：[沟通、策划]
✓ 包括客户沟通和策划活动。该阶段识别基本的业务需求， 并初步用“用例”描述每一类用户所需要的主要特征和 功能。此时的架构仅是主要子系统及其功能、特性的试 探性概括。策划活动识别各种资源，评估主要风险，定 义进度计划，并为用于软件增量开发的各个阶段建立基 础。
扩展 内容
极限编程
• eXtreme Programming – XP • 把好的开发实践运用到极致
为当前版本选择 故事情节/需求 （Scenario）
评估系统
将故事情节分 解成任务
发布软件
规划版本
开发/集成/测试 软件
• 结对编程
• 先写测试用例再 编程
极限编程XP
❖XP使用面向对象方法作为推荐的开发范型。XP 包含了策划、设计、编码和测试4个框架活动的规 则和实践。如图3-2所示。
应用举例
❖应用举例：开发一个教务管理系统。 ✓ 第一次迭代：完成基本的学籍管理、选课和成绩管 理功能。（6周） ✓ 客户反馈：基本满意，但是对大数据量运行速度慢 效率，不需要学生自己维护学籍的功能等。 ✓ 第二次迭代：修改细节，提高成绩统计和报表执行 效率（2周）。 ✓ 客户反馈：需要严格的权限控制，报表打印格式不 符合要求。 ✓ 第三次迭代：完善打印和权限控制功能。（2周） ✓ 客户反馈：可以进行正式应用验证。
如果需要 一个或多个原型
细化阶段
用例模型 补充需求
包括非功能需求 分析模型 软件体系结构描述 可执行的体系结构原型 初步的设计模型 修订的风险列表 项目计划，包括
迭代计划 调整的工作流 里程碑 技术工作产品 初始用户手册
构建阶段
设计模型 软件构件 集成的软件增量 测试计划及步骤 测试用例 支持文档
UP起源
UP历史
Rational统一过程
• 从3个视角描述软件开发过程
– 动态视角：随时间变化的各个阶段 – 静态视角：所进行的活动 – 实践视角：可采用的良好实践建议
Rational统一过程
静
初始：项目计
态
划、评估风险；
视
精化：设计系
角
统的体系结构、
制定项目计划、 确定资源需求；
构建：开发出 所有组件和应 用程序，集成 并进行详尽测 试；
统一过程的阶段
❖构建阶段(construction)：[部署]
✓与通用软件过程中的构建活动相同。该阶段采用体系结构模型作为输入，开发 或获取软件构件，使得最终用户能够操作用例。
❖转换阶段(transition): [构建、部署]
✓包括通用构建活动的后期阶段以及第一部分通用部署活动。软件被提交给最终 用户进行Beta测试，用户反馈缺陷及必要的变更。另外，软件开发团队创建系
统一过程的阶段
❖细化阶段(elaboration)[策划、建模]
✓包括用户沟通和通过过程模型的建模活动。该阶段扩展了起始阶段定义的用例， 并扩展体系结构以包括软件的五种视图——用例模型、分析模型、设计模型、 实现模型和部署模型。体系结构基线证明了体系结构的可实现性，但没有提供 系统使用所需的所有功能和特性。另外，在细化的最终阶段将评审项目计划以 确保项目的范围、风险和交付日期合理。同时对项目计划进行修订。
• 软件过程模型是不断发展的 • 各种软件过程模型各有优缺点和
适用场合 • 选用时不必拘泥于某种模型 • 可组合多种模型 • 也可根据实际创造新的模型
应用举例
❖开发一个类似于Word的字处理软件。
– 迭代1：提供基本的文件管理、编辑和文档生成功能。 – 迭代2：提供高级的文档编辑功能。 – 迭代3：实现拼写和语法检查功能。 – 迭代4：完成高级的页面排版功能。
① 个体和交互胜过过程和工具 ② 可以工作的软件胜过面面俱到的文档 ③ 客户合作胜过合同谈判 ④ 响应变化胜过遵循计划 虽然右边的项有价值，但我们更重视左边的项
敏捷 Agility
敏捷软件开发的基本原则
• 客户参与到开发团队中
• 实践中的困难
– 确定系统需求、对需求排序、 评估系统等
– 客户不一定愿意参与到
上次课的基本知识点回顾
软件生命周期 问题定义、可行性研究、需求分析、总体设 计、详细设计、编码、测试、维护
传统软件过程模型 瀑布模型 增量模型
上次课的基本知识点回顾
传统软件过程模型 原型模型 螺旋模型 喷泉模型
现代软件过程模型 – 基于构件的开发模型 – 形式化方法模型
如何选择软件过程模型
极限编程
课本图3-2 极限编程过程
极限编程的过程
❖策划：策划活动开始于建立一系列描述待开发软件 必要特征与功能的“故事”。
❖每个故事由客户书写并置于一张索引卡上，客户根据对应 特征或功能的全局业务价值度标明权值（故事优先级）； ❖评估每个故事给出开发周数为单位的成本； ❖客户和团队共同决定故事分组； ❖团队对待开发故事进行排序 ❖团队计算项目的速度 ❖在开发过程中，用户可增加、减少故事数，以及改变故事 的优先级。
• 软件以增量的方式进行开发和交付
开发团队中
• 开发团队的技术和开发团队的风格 应得到认可
• 接受变更，设计软件适应变更
• 保持所开发软件和开发过程的简单 性
– 团队成员的性格 – 需求和变更的优先级不
容易确定
– 维护简单性需要额外的
时间
– 企业文化很难改变
敏捷开发方法
• 极限编程：eXtreme Programming/XP • 自适应软件开发
极限编程的过程
❖编码：XP推荐的故事开发和基本设计完成之后， 团队不应直接开始编码，而是开发一系列用于检测 本次（软件增量）发布的包括所有故事的单元测试。 XP编码活动中的关键概念之一是结对编程。
❖XP建议两个人共同为一个故事开发代码，提供实时 解决问题和实时保证质量。
极限编程的过程
❖测试：在编码开始之前建立单元测试是XP方 法的关键因素。所建立的单元测试应当使用一 个可以自动实施的框架，这种方式支持代码修 改之后即时的回归测试策略。
面向方面的软件开发
随着现代计算机系统变得更加复杂，某些关注点—— 客户需要的属性或技术兴趣点——已经体现在整个架 构设计中。某些关注点是系统的高层属性（例如安全 性、容错能力），某些关注点影响了系统的功能等。 如果某个关注点涉及系统多个方面的功能、特性和 信息，这些关注点通常称为横切关注点。
面向方面的软件开发
方面需求定义那些对整个软件体系结构产生影响的横 切关注点。 面向方面的软件开发（AOSD）通常称为面向方面编 程（AOP），为定义、说明、设计和构建方面提供过 程和方法，是对横切关注点局部表示的一种机制，超 越了子程序和继承的方法。
面向方面的构件工程(AOCE)
* AOCE对纵向分解的软件构件进行横向切片，称为“方面 ”， 以表示构件功能及非功能的横切属性。
统一过程的三个特点
• 用例驱动
– 所有的软件开发都是用户需求驱动的。UP采用用 例来描述用户需求，同时提供一套方法把用例转化 为设计的类图，进一步变成最终的程序代码。在整 个软件开发过程中，要求用例是可跟踪的，即在设 计和实现阶段，都可以找到相应的需求。
• 以架构为核心
– 架构刻画了系统的整体设计，舍弃细节，突出重要 特征。UP提供了创建架构的方法和过程。
统一过程的三个特点
• UP采用迭代和增量的开发模式，把一个软件产品 划分成多个较小的部分，每次完成一个部分，每 次迭代都是产品的一个增量。
• 优点：把一个复杂系统分解成多个简单系统，提 供软件项目的可控性，降低软件开发的风险，有 效的应对需求变更。
UP起源
❖面向对象
– 60年代 Alan Kay发明OO语言 Smalltalk和面向对象编程（ObjectOrientedprogramming, OOP） – 1982年Grady Booch提出面向对象设计（Object-Oriented Design, OOD） – 80年代末，Peter Coad创建完整的OOA/D方法
Adaptive Software Development/ASD • 并列争球法：Scrum • 动态系统开发方法
Dynamic System Development Method/DSDM • 水晶法：Crystal • 特征驱动开发：Feature-Driven Development/FDD • 精益软件开发：Lean Software Development/LSD •…
* 系统的方面包括用户接口、协同工作、发布、持续性、存 储器管理、事务处理、安全、完整性等。
* 构件也许提供或需要某一方面的“方面细节信息”，如视 图机制、可扩展性和接口类型（用户接口方面）；事件生 成、传输和接收（分布式方面）；数据存取/查询和索引 （持久性方面）；认证、编码和访问权限（安全方面）； 原子事务、协同控制和登录策略（事务方面）等。
❖ 三剑客及其建模方法
– James Rumbaugh提出了OMT方法 – Grady Booch提出了Booch方法 – Ivar Jacobson提出了Objectory（Object Factory）方法
UP起源
❖UML
– 1994年James Rumbaugh和Grady Booch创建了统一方法（ Unified Method），即UML第一个草案 – 三人加入Rational公司（后被IBM收购），领导了OMG的建 模标准制定 – 1997年UML1.0发布，2004年UML2.0发布，成为OO建模标准
极限编程的过程
❖设计：XP设计严格遵循KIS原则，即使用简单而 不是复杂的表述。另外，设计为故事提供不多也不 少的实现原则，不鼓励额外功能性设计。
❖鼓励使用CRC卡（类-责任-协作者）确定和组织与 当前软件增量相关的类； ❖如果某个故事的设计中遇到困难，采用Spike方案； ❖鼓励重构 ❖XP的中心观念是设计与编码可以同时进行。
Rational统一过程
静
初始：项目计
态
划、评估风险；
视
精化：设计系
角
统的体系结构、
制定项目计划序，集成 并进行详尽测 试；
产品化：将产 品移交给用户。
动态视角
统一过程的阶段
❖起始阶段(inception)：[沟通、策划]
✓ 包括客户沟通和策划活动。该阶段识别基本的业务需求， 并初步用“用例”描述每一类用户所需要的主要特征和 功能。此时的架构仅是主要子系统及其功能、特性的试 探性概括。策划活动识别各种资源，评估主要风险，定 义进度计划，并为用于软件增量开发的各个阶段建立基 础。
扩展 内容
极限编程
• eXtreme Programming – XP • 把好的开发实践运用到极致
为当前版本选择 故事情节/需求 （Scenario）
评估系统
将故事情节分 解成任务
发布软件
规划版本
开发/集成/测试 软件
• 结对编程
• 先写测试用例再 编程
极限编程XP
❖XP使用面向对象方法作为推荐的开发范型。XP 包含了策划、设计、编码和测试4个框架活动的规 则和实践。如图3-2所示。
应用举例
❖应用举例：开发一个教务管理系统。 ✓ 第一次迭代：完成基本的学籍管理、选课和成绩管 理功能。（6周） ✓ 客户反馈：基本满意，但是对大数据量运行速度慢 效率，不需要学生自己维护学籍的功能等。 ✓ 第二次迭代：修改细节，提高成绩统计和报表执行 效率（2周）。 ✓ 客户反馈：需要严格的权限控制，报表打印格式不 符合要求。 ✓ 第三次迭代：完善打印和权限控制功能。（2周） ✓ 客户反馈：可以进行正式应用验证。