软考-系统分析-专题-开发方法
2024-12-20 14:30:09 0 举报AI智能生成
软考-系统分析-专题-开发方法
作者其他创作
大纲/内容
结构化开发方法
结构化方法将大问题分化成多个小问题，然后逐一解决。每个问题对应一个模块来进行解决，且每个模块包括抽象步骤和具体步骤。
结构化方法特点：1、开发目标清晰化，每个阶段工作目标明确并输出相应的文档，阶段结束进行评审通过后才进入下一阶段，保持与用户沟通，让用户了解工作进展，校准工作方向；2、开发工作阶段化，每个阶段完成后，要进行评审，便于项目管理与控制；3、开发阶段文档化，每个阶段完成后，按照要求完成相应文档，保证系统维护工作的便利；4、设计方法结构化，自顶向下分解，进行分析与设计。根据设计要求编写各个功能模块，自底向上实现。该方法缺点也很明显：1、开发周期长；2、很少考虑数据结构；3、难以适应变化，由于用户只有在交付阶段才能看到最终产品，因此是否能够满足用户要求或者用户提出变更对系统影响非常大，可能无法变更，测试阶段发现问题，可能不是开发阶段产生的，可能是设计阶段或者需求阶段产生，此时如果修改会对整个开发进行变更，成本高。
结构化开发方法使用模型：瀑布模型
瀑布模型
是一种严格定义方法，将软件开发过程分为计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段，形如瀑布流水，最终得到软件产品。
瀑布模型是一种线性顺序模型，支持直线开发。它假设当线性顺序完成之后就能交付一个完善的系统，并没有考虑软件的演化特征。尤其是强调开发的阶段性、早期计划及需求调查和产品测试，以这样严格的方式构造软件，开发人员很清楚每一步应该做的事情，有利于项目管理。然而，在瀑布模型中，依赖早期的需求调查，不能适应需求的变化；由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；风险往往推迟至后期的开发阶段才显露出来，从而失去了及早纠正的机会。在瀑布模型中需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目的风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。
阶段
计划->需求分析->设计->编码->测试->运维
瀑布模型是结构化开发方法所使用的一种模型。结构化开发方法的优缺点和瀑布模型的优缺点一样。
优缺点
优点
方便管理
具有严格的阶段划分，每个阶段目标清晰。
缺点
无法适应变化
风险控制能力较弱
在设计或者需求阶段产生的问题可能只有到了测试阶段段才能发现，此时纠正的成本较高。
阶段：计划-->需求分析-->设计-->编码-->测试-->运维
着重需求分析、设计阶段
面向对象开发方法
面向对象方法强调从现实世界中客观存在的事物(对象)出发来认识问题，使系统开发者大大减少了对问题域的理解难度，从而使系统能更准确地反映问题域;改善了人员之间的交流和协作，对软件复用提供了强有力的支持。
特点：
封装性：面向对象的开发方法可以通过类的封装将数据和操作封装在一起，提高代码的安全性和可维护性。
继承性：通过继承可以实现代码的重用，减少重复编码，提高开发效率。
多态性：多态性使得可以通过统一的接口处理不同的对象，提高代码的灵活性和可扩展性。
抽象性：面向对象的开发方法可以通过抽象类和接口实现抽象，使代码更易于理解和维护。
模块化：面向对象的开发方法可以将代码模块化，降低代码的耦合度，提高系统的可维护性和可扩展性。
封装性：面向对象的开发方法可以通过类的封装将数据和操作封装在一起，提高代码的安全性和可维护性。
继承性：通过继承可以实现代码的重用，减少重复编码，提高开发效率。
多态性：多态性使得可以通过统一的接口处理不同的对象，提高代码的灵活性和可扩展性。
抽象性：面向对象的开发方法可以通过抽象类和接口实现抽象，使代码更易于理解和维护。
模块化：面向对象的开发方法可以将代码模块化，降低代码的耦合度，提高系统的可维护性和可扩展性。
面向对象开发方法使用模型：喷泉模型
阶段：分析-->设计-->实现-->维护-->演化
喷泉模型
概述
是一种以用户需求为动力，以对象为驱动的模型，主要用于面向对象的软件开发过程。
是一种自底向上的实现过程。是从实现的角度来看系统开发，所有的功能最终都是落到具体的某个类上，因此设计类所具有的方法就可以完成系统所具有的功能。
该模型认为软件开发过程自下而上的各阶段是相互重叠和多次反复的，就像水喷上去又落下来，类似一个喷泉。
各个开发阶段没有特定的次序要求，并且可以相互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。
分支主题
特点
各个活动之间没有明显的边界。例如分析和设计之间没有明显的边界。这种特性称为无间隙性。面向对象的分析，分析的是系统的具有哪些对象，设计的时候 针对的也是分析是的类。
是一个迭代过程
由于对象概念的引入，只用类和关系来表达分析、设计和实现等活动，从而可以比较容易的实现活动的迭代和无间隙，提高软件开发项目效率，节省开发时间。
着重分析设计阶段
构件化开发
基于构件/组件化开发的软件是解决复杂环境下软件规模与复杂性的一种手段。只要是系统的部分都可以当成构件，是基于面向对象的思想所产生的。
构件的获取方法：
从现有构件中获取复合要求的构件，直接使用或做适应性修改，得到可重复利用的构件。
通过遗留工程（Legacy Engineering），将具有潜在复用价值的构件提取出来，得到可复用的构件。
从市场上购买现成的商业构件
开发符合要求的新的构件
从开源市场寻找免费的开源构件
构件分类法
关键字分类法：将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构，每个概念用一个描述性的关键字表示。
刻面分类法：定义若干用于刻画构件特征的”刻面”，每个面包含若干概念，这些概念描述构件在刻面上的特征。刻面可以描述构件执行的功能、被操作的数据、构件应用的语境或其他特征。
超文本方法：所有构件必须辅以详尽的功能或行为说明文档，说明中出现的重要概念或者构件以网状链接方式相互连接；检索者在阅读文档的过程中可按照人类的联想思维方式任意跳转到包含相关概念或构件的文档；全文检索系统将用户给出的关键字与说明文档中的文字进行匹配，实现构件的浏览式检索。
构件开发使用模型：RAD快速应用开发
快速应用开发（Rapid Application develop，RAD）是一种比传统生命周期法快得多的开发方法，他强调极短的开发周期。
RAD模型是瀑布模型的一种高速变种，通过使用基于构件的开发方法进行快速开发。
阶段：规划-->设计（包括分析）-->实现-->运行
基本思想
1、让用户更主动的参与到系统分析、设计和构造活动中来。
2、将项目开发组织成一系列重点突出的研讨会，研讨会要让项目投资方、用户、系统分析师、系统设计人员和开发人员一起参与。
3、通过一种迭代的构造方法，加速需求分析和设计阶段。
4、让用户提前看到一个可工作的系统。
RAD开发过程
RAD流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试与交付。
1、业务建模
确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向以及处理等，可以使用数据流图来帮助建立业务模型。
2、数据建模
为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可以使用ER图来帮会组建立数据模型。
3、过程建模
将数据对象变换为要完成一个业务功能所需的信息流，创建处理以描述增加、修改、删除或获取某个数据对象，即细化数据流图中的加工。
4、应用生成
利用第四代语言，写出处理程序，复用已有构件或者创建新的可复用的构件，利用环境提供的工具自动生成并构造出整个应用系统。
5、测试与交付
RAD强调复用，许多构件已经是测试过的，这就减少了测试的时间，由于大量复用，所以一般只做整体测试，但新创建的构件还需要测试。
RAD局限性
RAD通过大量使用可复用的构件，加快了开发速度过程，但也有局限性
1、并非所有应用都适合RAD。
RAD对模块要求比较高，如果有哪一项功能不能被模块化，那么RAD所需要的构件就会有问题；
如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得（需要对构件进行修改才能满足要），则RAD可能也不能有效
2、开发者和客户必须在短时间完成一系列的需求分析，任何一方配合不当，都会导致RAD失败
3、RAD只能用于管理信息系统的开发，不适合技术风险很高的情况。
当一个新系统采用很多新技术，或当新系统要与现有系统较高的互操作时，就不合适使用RAD
构件开发使用模型：RUP统一过程模型
统一过程（Unified Process，UP）是一个通用过程框架，可以用于广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。
重型模型，主要体现在大项目（周期长，例如两年以上的项目）使用；在瀑布模型的基础上增加了一些内容，主要是增加了项目管理的内容。
UP是基于构件的，在为软件系统建模时，UP使用UML。
与其他软件过程相比，UP具有三个显著特点，即：用例驱动（需求分析可以使用用例图来完成），以架构为中心（系统由哪些构件组成，针对系统的不同的组成部分都用UML展示，4+1视图来展示），迭代和增量。
RUP中的软件过程在时间上被分解为4个顺序的阶段，分别是初始阶段、细化阶段、构件阶段和移交阶段。每个阶段结束时都要进行进行技术评审，以确定这个阶段的目标是否已经达成，如果评审结果满意就进入下一阶段。
RUP 9大核心工作流
业务建模
业务建模（Business Modeling）工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在业务用例模型和商业对象模型中定义组织的过程，角色和责任。
需求
需求（Requirement）工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。
分析和设计
分析和设计（Analysis & Design）工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用例的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。
实现
实现（Implementation）工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
测试
测试（Test）工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。
部署
部署（Deployment）工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
配置和变更管理
配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录
项目管理
软件项目管理（Project Management）平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
环境
环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
1、初始阶段
初始阶段的任务是为了建立业务模型并确定项目的边界
在初始阶段必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。
在这个阶段中，所关注的是整个项目的业务和需求方面的主要风险。
对于建立在原有系统基础上的开发项目来说，初始阶段可能很短
初始阶段实现过程如下
明确项目规模：建立项目的软件规模和边界条件，包括验收标准；了解环境以及重要的需求和约束，识别系统的关键用例；
评估项目风险：了解项目所面临的风险，并对如何降低或处理风险有明确的策略；
制定项目计划：估计整个项目总体成本、进度和人员配备。综合考虑备选架构，评估设计和自制/外购/复用方面的方案，从而估算出成本、进度和资源。
阶段技术评审：初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定继续进行项目还是取消项目。
2、细化阶段
这个阶段的任务是分析问题领域，建立完善的架构，淘汰项目中最高风险的元素。
在细化阶段，必须在理解整个系统的基础上，对架构做出决策，包括其范围、主要功能注入性能等非功能需求，同时为项目监理支持环境。
细化阶段主要工作
确定架构：通过处理架构方面重要的场景，建立一个已确定极限的架构，并验证其将在适当时间，以合理的成本支持系统需求；
制定构建阶段计划：为构建阶段制定详细的过程计划并为其建立基线；
建立支持环境：包括开发环境、开发流程、支持构件团队所需的工具和自动化/半自动化支持。
选择构件：集成所选构件，并按主要场景进行评估；
阶段技术评审：检验详细的项目目标和范围、架构的选择，以及主要的风险解决方案。
3、构建阶段
对系统进行详细设计，并进行编码，测试、集成
4、移交阶段
对系统全面测试，补充各种文档，并发产品移交给用户等。
面向服务开发方法
思想是来源于构件化开发，将接口进一步封装形成服务，并将服务挂接到服务总线上（服务总线可以实现服务动态部署，调用，发现等等）
三个主要的抽象级别
操作级别
位于最底层的操作代表单个逻辑单元的事物，执行操作通常会导致读、写或修改一个或多个持久性数据。服务的操作类似于对对象的方法，他们都有特定的结构化接口，并且返回结构化的响应。
就是简单的读写操作，无具体的业务逻辑。
服务级别
位于第二层的服务代表操作的逻辑分组。
业务流程
最高层的业务流程则是为了实现特定业务目标而执行的一组长期运行的动作或活动，包括依据一组业务规则按照有序序列执行的一系列操作。其中操作的排序、选择和执行称为服务或流程的编排，典型的情况是调用已编排的服务来响应业务事件。
面相服务的分析与设计
面向服务的分析与设计（SOAD，Service-Oriented Analysis and Design），综合了OOA、OOD、企业架构（Enterprise Architecture，EA）和业务流程建模（BPM)中的适当原理，将这些规则中的原理与许多独特的新原理组合起来基础设计层。采用OOA和OOD的思想，其主要目标是能够进行快速而有效的设计、开发，以及执行灵活且可扩展的底层服务构件。
三个层次
业务组织
业务流程建模理论（BPM理论）
采用业务流程管理，既BPM理论，现在广泛使用的是uml图建模，其中最常用的是UML的活动图。SOAD以现有的BPM方法为起点，以服务流程编排模型为补充。此外，SOAD中的流程建模必须与用例设计保持同步。
应用架构
采用企业架构理论
采用EA的理论框架。企业信息系统建设是一个庞大的工程，其中可能会涉及到众多的业务流水线和组织单元（部门）。因此，需要应用EA，以努力实现蛤蚧酒方案之间架构的一致性。在SOAD中，应用结构层以表示业务服务的逻辑构件为中心，并且集中于定义服务之间的接口和服务级协定。
基础设计
用面向对象的分析与设计的理论。
采用OOA和OOD的思想，主要目标是能够进行快速而有效的设计，开发，以及执行灵活且可扩展的底层服务构件。
分支主题
原型开发方法
概述
结构化方法和面向对象方法有一个共同点，既在系统开发初期必须明确系统的功能要求，确定系统边界。从工程学角度来看，这是十分自然的：解决问题之前必须要明确解决的问题是什么。但是对于信息系统而言，明确问题本身就非常困难。
原型化方法也称为快速原型法，或者简称为原型法。
原型法是一种根据需求，利用系统开发工具，快速地建立一个系统模型展示给用户，在此基础上与用户进行交流，最终实现用户需求的信息系统快速开发方法。原型法可以根据用户初步需求利用系统工具快速建立一个系统模型，与用户交流。
原型法特点
从原型法的开发过程可以看出，原型法从原理到流程都十分简单，并无高深的理论和技术，所以应用广泛。
特点
优点
可以使系统开发的周期缩短、成本和风险降低、快速开发，获得较高的综合开发效益。
是以用户为中心来开发的系统，用户参与度高，开发的系统符合用户需求，因此增加了用户满意度，提高了系统开发成功率。
由于用户参与了系统开发的全过程，对系统的功能和结构容易理解和接受，有利于系统的移交，有利于系统的运行与维护。
缺点
开发的环境要求较高，例如对于开发人员的和用户的素质，系统开发工具、软硬件设备等，特别是原型法需要的快速开发工具的支持，开发工具的水平是原型法能否顺利实施的第一要素。原型法成败的关键以及效率的高低在于构建原型的速度。
管理水平要求高，系统的开发缺乏统一的规划和开发标准，难以对系统的开发过程进行控制。例如，如何确定用户的满意度，如何控制对系统原型的修改次数（原型迭代次数）等，都是比较难以协调的问题。
原型方法的分类
按照功能划分
水平原型
行为原型，用户解决，系统需求但并未实现功能。
垂直原型
结构化原型，用于复杂算法的实现，实现了部分功能。
按照最终结果划分
抛弃式
探索式原型，解决需求不确定性、二义性、不完整性、含糊不清等
演化式
逐步演化为最终系统，用于易于升级和优化的场合，适用于WEB项目。
原型法的开发过程
步骤
1、确定用户基本需求
2、设计系统初始原型
3、适用和评价原型
4、评审判断是否达到要求
5、达到要求则整理原型，提供文档；否则修改和完善原型并重新评价（转移到3）
分支主题
原型开发方法使用原型模型
原型模型
概述
原型模型是快速构建一个系统，让用户尽早了解最终系统所具有的特性。
对应的是原型开发方法，优点和缺点与原型模型一样
模型图：交流-->快速计划-->快速设计方式建模-->构建原型-->部署和反馈-->交流
构造过程
1、建造一个快速原型，实现客户或未来用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发的需求，确定客户的需求。
2、在第一步的基础上开发客户满意的软件产品。
优缺点
优点
能够减少由于软件需求不明确带来的开发风险。
缺点
所选用的开发技术和工具不一定符合主流的发展
快速建立的系统架构上连续的修改可能会导致产品质量低下。
建立多少原型才适合是难以控制的
敏捷开发方法
概述
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各子项目都经过测试，具备集成可运行的特征。
从开发者角度来看，主要有短平快的会议、小版本的发布、较少的文档、合作为主、客户直接参与、自动化测试、适应性计划调整和结对编程；
从管理者角度来看，主要的关注点有测试驱动开发（先编写测试代码，然后在开发具体的功能）、持续集成和重构。
特点
适应性
敏捷开发方法是"适应性”而非"预设性”。传统的开放方法，比如结构化开发方法，试图对一个软件开发项目在很长的时间跨度
内做出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷开发方法则拥抱变化。
内做出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷开发方法则拥抱变化。
以人为本
敏捷开发方法是“面向人的”而非“面向过程的”。
适用场景
项目团队的人数不多，适合于规模较小的项目。
项目经常发生变更。敏捷方法适用于需求萌动并且快速变化的情况，如果系统有比较高的关键性、可靠性、安全性等方面的要求则可能不适合敏捷开发。
高风险项目的实施
从组织结构的角度来看，组织结构的文化、人员、沟通性决定了敏捷方法是否适用。与这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但精干、开发人员所做的决定必须得到认可、环境设施满足团队成员之间快速沟通的需求。
敏捷宣言
个体和交互胜过过程和工具
可工作的软件胜过大量的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
敏捷方法强调让客户满意和软件尽早增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。
敏捷开发类型
XP极限编程：高效、低风险、测试先行（先写测试代码，在开发具体功能）
四大价值观
沟通
团队成员之间要保持良好的沟通，及时交流信息和想法。
简单性
尽量保持系统设计和代码的简单性，避免过度设计和复杂性。
反馈
通过持续的反馈机制，及时了解系统的状态和用户需求，以便快速作出调整。
勇气
鼓励团队成员勇敢面对挑战和困难，不断改进和学习。
水晶方法Cockburn：不同项目具有不同的策略
探索阶段
在这个阶段，团队明确项目的愿景和目标，确定项目的范围和关键特性，制定初步的计划和时间表，进行初步的风险评估
计划阶段
在这个阶段，团队制定详细的计划，包括任务分配、时间安排、资源调配等，明确迭代的目标和计划，确保团队对项目的整体方向有清晰的认识。
迭代阶段
项目被分解为多个迭代周期，每个迭代周期包括需求分析、设计、开发、测试和交付等环节，以快速迭代的方式不断完善产品。
评审阶段
每个迭代周期结束后，团队进行评审，总结经验教训，发现问题和改进空间，以提高团队的工作效率和产品质量
发布阶段
当所有迭代周期完成后，团队将产品交付给客户，并根据客户的反馈进行调整和改进，以确保产品符合客户需求。
收尾阶段
项目完成后，团队进行总结和评估，总结项目经验，记录成功和失败的教训，为下一个项目的开展做好准备。
SCRUM并列争求法：迭代，30天为一个迭代周期，按照需求优先级实现。
具体过程
确定工作项：团队首先确定需要完成的工作项，通常以用户故事或任务的形式呈现。
估算工作量：团队成员对每个工作项的工作量进行估算，通常使用相对估算方法，如故事点或理想天数。
优先级排序：团队成员共同讨论并确定工作项的优先级顺序，以确保最重要的工作首先被完成。
并列争求：团队成员一起讨论和协商，确定每个人在当前迭代中能够承担的工作量，并达成一致意见。
制定计划：根据讨论结果，团队制定具体的计划，确定每个人在迭代中的工作任务和时间分配。
执行工作：团队按照制定的计划执行工作，定期进行站会和检查进度，确保工作按计划进行。
FDD功用驱动方法：开发人员分类。分为指挥官（首席程序员），类程序员（具体干活的人员）。
开放式源码：虚拟团队，并发成员分布各地。
ASD自适应方法：预测--协作--学习
SCRUM并列争求法
SCRUM的基本原理是通过迭代开发、自组织团队、透明度、反馈和改进以及产品导向等方式，帮助团队快速响应变化、高效交付软件产品，并不断提升团队的能力和效率。这些原理使得SCRUM成为一种灵活、高效的软件开发方法，被广泛应用于各种软件开发项目中。
将需求设置为一个一个的用户故事，并对用户故事进行排序，然后设置一个冲刺周期（通常是4周为一个周期），冲刺周期结束之后进行评审，以确定是否发布或进行下一轮冲刺。在整个的开发过程中，需要开每日站会和使用使用一些工具（例如，燃尽图来了解当前任务的执行情况）
SCRUM是一种敏捷软件开发方法，其中包括多种角色、工件和活动。以下是SCRUM中常见的角色、工件和活动：
角色
产品负责人（Product Owner）：负责定义产品需求和优先级，与开发团队协作确保产品的成功交付。
SCRUM团队（SCRUM Team）：由开发人员组成的自组织团队，负责实现产品需求并交付可用的软件。
SCRUM主管（SCRUM Master）：负责促进SCRUM流程的执行，解决团队遇到的问题，并确保团队遵循SCRUM的最佳实践。
工件
产品积压（Product Backlog）：产品需求的列表，包含了所有待实现的功能和任务，由产品负责人管理。
冲刺积压（Sprint Backlog）：每个冲刺期间需要完成的任务列表，由开发团队自行确定并承诺完成。
冲刺成果（Sprint Increment）：每个冲刺结束后交付的可用软件产品，必须符合定义的完成标准。
活动
产品Backlog列表梳理
通过对前期需求的基本分析,我们对系统的关键核心模块的需求进行了细化,明确了具体的需求，对这些功能模块，我们根据其重要性、需求明确程度、实现难易程度、模块大小等进行了优先级排序。
冲刺计划会议（Sprint Planning）：产品负责人与开发团队协作确定下一个冲刺要完成的任务和目标。
前期确定每个Sprint的迭代周期为4周，在产品 Backlog 完成后，召开了全体团队成员参加的Sprint 计划会议，大家一起过了一遍产品 Backlog 中的工作项，选择了当前Sprint 要完成的功能项,然后对选择的功能进行了分解,生成了任务 Backiog,以让大家进行认领。
每日SCRUM（Daily SCRUM）：每日15分钟的会议，团队成员分享进度、问题和计划，以确保团队协作和透明度。
冲刺评审会议（Sprint Review）：每个冲刺结束后，团队演示完成的功能，产品负责人和利益相关者提供反馈。
冲刺回顾会议（Sprint Retrospective）：每个冲刺结束后，团队回顾过去的工作，识别改进点并制定行动计划。
0 条评论
下一页
