Copyright © 2015 University of Alberta.
SOFTWARE PROCESSES AND AGILE PRACTICES
Glossary
Word | Definition |
---|---|
Acceptance | Test A test that verifies that a product requirement has been satisfied. It can be automated or a script for a human to conduct. |
Activity | A set of related tasks. |
Ad Hoc Development | Developing software reactively, without a plan. |
Adaptation | Responding to changes. |
Agile | A philosophy for developing software that is based on the values and principles of the Manifesto for Agile Software Development. |
Agile Manifesto | A declaration of the values and principles for software development that follows the Agile philosophy. |
Agile Practices | Techniques, rules, or guidelines that are based on the Agile Manifesto to make software development or management more effective. |
Agile Unified Process | A methodology that combines the Unified Process model and Agile practices. |
Analysis, Requirements | An activity to examine the requirements of a product to ensure, for example, that they are clear, complete, and consistent. |
Analyze | Examine methodically and in detail to discover insights or potential improvements. |
Architecture | The structure of a software system in terms of components, connections, and constraints. |
Backlog | In Scrum, a prioritized list of features and functionalities for a product, maintained by the product owner. |
Change-Friendly | A product that is easily adaptable to change. |
Client Satisfaction | That the client is happy with the product provided, so it solves their problem, addresses their needs, and meets their expectations. |
Coding Standard | A set of guidelines or conventions to be followed by software developers on the formatting, style, and usage for source code in a particular programming language. |
Collective Ownership | A practice to encourage anyone on the development team to contribute to any part of the product. The team, not individuals, own the product’s successes and failures. |
Construction | The phase in the Unified Process model in which the focus is on implementing the product. |
Continuous Delivery | A practice to produce valuable software in short iterations to ensure that the software can be reliably released at any time. |
Continuous Integration | A practice where developers combine their code frequently into a shared repository to detect build issues or incompatibilities early. |
Cross-Functional | The development team is self-contained, consisting of all the skills needed to complete the product. |
Cycle | A complete loop of the Unified Process model through its phases. |
Design and Implementation Phase | The phase of a software process where you design the organization of the product and implement that design. |
Documentation | Documents that describe the product for the developers or end users. |
Elaboration | The phase in the Unified Process model in which the focus is on an architectural model or prototype to later drive product implementation. |
Elicitation, Requirements | An activity to discover requirements, by interacting with users, clients, and other stakeholders, investigating their needs, and exploring the ideas and features of a potential product. |
Estimation | A rough calculation of something, for example, the anticipated effort needed for a requirement or the time needed for a task. |
Evolutionary Prototype | A working prototype from a sequence of prototypes, where the first begins with all features in basic form and subsequent prototypes further refine those features. |
Exploratory Prototype | A working prototype to learn about the feasibility of a product idea. |
Expression, Requirements | An activity to describe the needed product features from the client in a structured way. |
External Documentation | Documentation that is intended to be used by users of the product. |
Extreme Programming | An Agile methodology that focuses on practices for effective software development, including pair programming and test-driven development. |
Illustrative Prototype | A simple prototype to depict product ideas in a low-fidelity form, potentially on disposable media. |
Inception | The initial phase in the Unified Process model in which key requirements are outlined and the business case, scope, and risks are identified. |
Incremental | Prototype A working prototype from a sequence of prototypes, where the first begins with a core set of features and subsequent prototypes add more features as resources permit. Features are triaged into categories of “must do”, “should do”, and “could do” to determine the order of release. |
Input Work Product | A work product that is required for an activity to occur. |
Inspection | A procedure to review a work product for flaws. |
Integration | Combining software written by different developers into a coherent whole. |
Interface | A boundary across which two separate entities communicate, for example, the connection between two software components or the visual presentation that an end user interacts with to use the product. |
Internal Documentation | Documentation that is intended to be used by members of the development team for a product. |
Invariant | A property that remains unchanging. |
Iteration | One instance of a repetition. |
Iterative Process | A kind of process with repeated sequences of phases. |
Kanban | In software development, a visual way to organize and track required work through their stages of completion. |
Life Cycle | The life span of a product. |
Life Cycle Process | A process to develop and manage a software product from its initial conception to its retirement. |
Linear (Process) Model | A conceptual representation of a linear process. |
Linear Process | A kind of process that advances from one phase to another sequentially and only when the previous phase has completed. |
Managed | That processes and practices are followed to organize the work of everyone involved in the software project. |
Management, Requirements | An activity whereby requirements are organized for reference and reuse, for example, ensuring requirements are traceable to tests and source code. |
Methodology | A defined set of practices to perform software development. |
Metric | A way to measure that a product or process meets some quality or characteristic. |
Metric Data | Data acquired from calculating metrics on a product or process. |
Microsoft Daily Build | A practice from Microsoft in which all software must be integrated at the end of the day. |
Monitoring | The tracking of a project’s progress and the product’s quality. |
Output Work Product | A work product that is generated by an activity. |
Pair Programming | A practice where two developers work side-by-side on a task at the same computer. |
Parallel Process | A kind of process in which activities can happen across phases and concurrently with other activities. |
Phase | A distinct period or stage in a process. |
Planning | A procedure done to make plans that organize and schedule upcoming work. |
Practices | Techniques, rules, or guidelines to make software development or management more effective. |
Prioritization, Requirements | An activity to organize the list of requirements based upon what is of higher value and should be completed earlier. |
Process | An organization of the development of software into distinct phases or stages. |
Process Model | A conceptual representation of the phases of a process. |
Product Owner | In Scrum, the role responsible for the product backlog. |
Project | An endeavour to complete a product including its planning, development, operation, and evolution. |
Project Management Phase | Consists of parallel and ongoing activities to manage and plan work throughout development. |
Prototype | A preliminary form or version of the software product, from which other forms are developed. |
Refactoring | A practice to restructure the internal design of the code without changing its behaviour, to allow future changes to be easier. |
Requirement | A specific description of a need, such as a desired capability to be implemented in the product. |
Resource | Something that improves, advances, or funds a task. |
Retrospectives | A way to reflect and review the development of a product and its process to identify lessons learned to improve future work. |
Review | To reflect on something and determine what was good and what can be improved upon. |
Risk Management | Identifying and mitigating risks before they occur. |
Risk Plan | A course of action that outlines the solution if an issue should occur. Also known as an action plan. |
Role | A job-related activity that a person takes on. |
Sawtooth Model | A linear process model, with specific phases that involve the client. |
Scrum | An iterative and incremental Agile methodology for managing software development. |
Scrum Events | In Scrum, occurrences facilitated by the scrum master, including sprints, sprint planning, daily scrums, sprint review, and sprint retrospective. |
Scrum Master | In Scrum, the role responsible for organizing and facilitating Scrum practices by the product owner and the development team. |
Scrum Team | Consists of everyone responsible for making a software product using Scrum practices, including the product owner, the scrum master, and development team members. |
Self-Organizing | A development team that is empowered to decide how to implement the product and determine on their own who will take on each required task. |
Software Engineering Activity | See Activity. |
Specification | Phase The phase of a process when the idea for the product is conceived, including a definition of what the product does. |
Spiral Model | A risk-driven process model by Boehm that iterates through four phases. |
Sprint | In Scrum, an iteration over a short time period, whereby an increment of working software is delivered to the client at the end for feedback. |
Standardize | To adopt development practices that ensure consistency or compatibility. |
Sub-Process | A smaller process within a larger process. |
Sub-Teams | A smaller team within a larger team. |
System Metaphor | A practice to explain the product simply to someone else, through familiar concepts or by analogy. |
Task | A small, manageable unit of work to be completed. |
Task Dependency | A relationship that specifies the ordering of tasks. |
Test-Driven Development | A practice where tests are prepared for a required feature or functionality before its corresponding source code is written. |
Throwaway Prototype | A full version of a product, intended to be replaced by a subsequent version. |
Transition | The phase in the Unified Process model in which the software product is fully delivered and deployed. |
Transparency | That everyone can see every aspect of the project. |
Triage | A procedure to classify requirements or requests, for example, into “must do”, “should do”, “could do” priorities. |
Unified Process Model | A use-case-driven, architecture-focused, iterative and incremental software development process. |
Unit Test | A test written and run by developers to verify whether a low-level functionality works correctly. |
User Story | A short, structured description of a product requirement that outlines who wants the requirement, what the requirement is, and why the requirement has value. |
V-Model | A linear process model, which focuses on verifying the product at multiple levels. |
Validated | That the released software product satisfies the client. |
Validation | See Validated. |
Velocity | The number of units of work that can be completed over a given time interval. |
Verification | See Verified. |
Verification and Validation Phase | The phase of a software process when the product is tested for whether it meets the requirements and the product is reviewed for whether it satisfies the client. |
Verified | That the released software product meets all the specified requirements. |
Waterfall Model | A linear software development process, typified by phases where approved work products are passed from one phase to the next. |
Work Product | An output produced by completing a specific task. A work product can also be consumed as an input for another task. |
软件开发过程与敏捷开发实践
中文术语
以下内容为本人自译,若有纰漏,还请多多指正。
中文 | 释义 |
---|---|
验收 | 测试用来验证是否满足产品要求的测试。它可以是自动化的,也可以是脚本供人类操作。 |
活动 | 一组相关任务。 |
临时开发 | 无计划地被动开发软件。 |
适应 | 响应变化。 |
敏捷 | 基于敏捷软件开发宣言的价值观和原则的软件开发哲学。 |
敏捷宣言 | 遵循敏捷哲学的软件开发价值和原则声明。 |
敏捷实践 | 基于敏捷宣言的技术,规则或指南,可提高软件开发或管理的效率。 |
敏捷统一流程 | 结合了统一流程模型和敏捷实践的方法。 |
分析,要求 | 一项检查产品需求的活动,以确保例如它们是清晰,完整和一致的。 |
分析 | 有条不紊地进行详细检查,以发现见解或潜在的改进。 |
建筑 | 就组件,连接和约束而言,软件系统的结构。 |
积压 | 在Scrum中,由产品所有者维护的产品特征和功能的优先列表。 |
改变友善 | 易于适应变化的产品。 |
客户满意度 | 客户对所提供的产品感到满意,因此可以解决他们的问题,满足他们的需求并满足他们的期望。 |
编码标准 | 软件开发人员应遵循的一组准则或约定,以特定编程语言编写源代码的格式,样式和用法。 |
集体所有权 | 鼓励开发团队中的任何人对产品的任何部分做出贡献的一种做法。由团队而非个人来负责产品的成败。 |
施工 | 统一过程模型中的阶段,重点在于实现产品。 |
持续交付 | 在短时间内生产有价值的软件的实践,以确保可以随时可靠地发布该软件。 |
持续集成 | 开发人员经常将其代码合并到共享存储库中,以及早发现构建问题或不兼容的做法。 |
跨职能 | 开发团队是独立的,由完成产品所需的所有技能组成。 |
循环 | 统一过程模型的各个阶段的完整循环。 |
设计和实施阶段 | 在软件过程中,您设计产品的组织并实施该设计的阶段。 |
说明文档 | 为开发人员或最终用户描述产品的文档。 |
详细说明 | 统一过程模型中的阶段,其中重点放在体系结构模型或原型上,以稍后推动产品实现。 |
启发,要求 | 通过与用户,客户和其他利益相关者进行交互,调查他们的需求并探索潜在产品的想法和功能来发现需求的活动。 |
估算 | 粗略地计算某些内容,例如,需求所需的预期工作量或任务所需的时间。 |
进化原型 | 一系列原型中的一个可用原型,其中第一个原型以基本形式的所有特征开始,随后的原型进一步完善了这些特征。 |
探索性原型 | 一个有效的原型,用于了解产品创意的可行性。 |
表达,要求 | 一种以结构化方式描述客户所需的产品功能的活动。 |
外部文档 | 产品用户打算使用的文档。 |
极限编程 | 一种专注于有效软件开发实践的敏捷方法论,包括结对编程和测试驱动的开发。 |
说明性原型 | 一个简单的原型,可以以低保真度形式描述产品创意,并可能在一次性介质上。 |
启始 | 统一过程模型的初始阶段,其中概述了关键需求,并确定了业务案例,范围和风险。 |
增量式原型 | 一系列原型中的一个有效原型,第一个原型以一组核心功能开始,随后的原型在资源允许的情况下添加更多功能。将功能分为“必须做”,“应该做”和“可以做”类别,以确定发布的顺序。 |
输入工作产品 | 活动发生所需的工作产品。 |
检验 | 审查工作产品的缺陷的过程。 |
整合 | 将不同开发人员编写的软件组合成一个连贯的整体。 |
界面 | 一个边界,两个单独的实体在该边界上进行通信,例如,两个软件组件之间的连接或最终用户进行交互以使用该产品的视觉表示。 |
内部文件 | 开发人员使用的产品文档。 |
不变的 | 保持不变的属性。 |
迭代 | 重复的一个实例。 |
迭代过程 | 一种具有重复相序的过程。 |
看板 | 在软件开发中,一种可视化的方式来组织和跟踪完成工作所需的工作。 |
生命周期 | 产品的寿命。 |
生命周期过程 | 从最初的概念到退役的软件产品开发和管理过程。 |
线性(过程)模型 | 线性过程的概念表示。 |
线性工艺 | 一种过程,仅当上一阶段完成时才从一个阶段逐步进行到另一阶段。 |
托管 | 遵循该过程和实践来组织参与软件项目的每个人的工作。 |
管理,要求 | 组织需求以供参考和重用的活动,例如,确保需求可追溯到测试和源代码。 |
方法论 | 用于执行软件开发的一组定义的实践。 |
公制 | 一种衡量产品或过程是否符合某种质量或特征的方法。 |
指标数据 | 通过计算产品或过程的度量获取的数据。 |
Microsoft每日生成 | Microsoft的一项惯例,必须在一天结束时集成所有软件。 |
监控 | 跟踪项目的进度和产品的质量。 |
输出工作产品 | 活动产生的工作产品。 |
配对编程 | 一种实践,其中两个开发人员在同一台计算机上并行处理一项任务。 |
并行处理 | 一种过程,活动可以跨阶段进行,也可以与其他活动同时发生。 |
相 | 过程中的不同时期或阶段。 |
规划 | 为制定计划以组织和安排即将进行的工作的计划而执行的过程。 |
实践 | 使软件开发或管理更有效的技术,规则或准则。 |
优先顺序,要求 | 一项根据较高价值组织需求清单的活动,应尽早完成。 |
工艺流程 | 将软件开发分为不同阶段或阶段的组织。 |
工艺模型 | 过程阶段的概念性表示。 |
产品负责人 | 在Scrum中,负责产品积压的角色。 |
项目 | 努力完成产品,包括其计划,开发,运营和发展。 |
项目管理阶段 | 由并行和正在进行的活动组成,以管理和计划整个开发过程中的工作。 |
原型 | 软件产品的初步形式或版本,从中可以开发其他形式。 |
重构 | 一种在不更改其行为的情况下重组代码内部设计的做法,以使将来的更改更加容易。 |
要求 | 需求的具体描述,例如要在产品中实现的所需功能。 |
资源 | 可以改善,推进或资助任务的东西。 |
复盘 | 反映和审查产品开发及其过程的方法,以识别吸取的教训以改进未来的工作。 |
评论 | 反思某件事,确定什么是好的,哪些可以改进。 |
风险管理 | 在风险发生之前识别并减轻风险。 |
风险计划 | 如果发生问题,概述解决方案的操作过程。也称为行动计划。 |
角色 | 一个人从事的与工作相关的活动。 |
锯齿模型 | 线性过程模型,具有涉及客户的特定阶段。 |
Scrum | 用于管理软件开发的迭代和增量敏捷方法。 |
Scrum活动 | 在Scrum中,Scrum管理员协助进行的事件包括Sprint,Sprint计划,每日Scrum,Sprint审查和Sprint回顾。 |
Scrum大师 | 在Scrum中,由产品所有者和开发团队负责组织和促进Scrum实践的角色。 |
Scrum团队 | 由负责使用Scrum实践制作软件产品的每个人组成,包括产品所有者,Scrum管理员和开发团队成员。 |
自我组织 | 开发团队有权决定如何实施产品,并自行确定谁将承担每个必需的任务。 |
软件工程活动 | 请参阅活动。 |
规格书阶段 | 构想产品创意的过程的阶段,包括产品功能的定义。 |
螺旋模型 | Boehm的风险驱动流程模型迭代了四个阶段。 |
冲刺 | 在Scrum中,这是在短时间内进行的迭代,从而将大量的工作软件最终交付给客户端以进行反馈。 |
标准化 | 采用确保一致性或兼容性的开发实践。 |
子流程 | 较大的过程中较小的过程。 |
小组 | 大团队中的小团队。 |
系统隐喻 | 通过熟悉的概念或类推向他人简单地解释产品的一种做法。 |
任务 | 一个小的,易于管理的工作单元。 |
任务依赖性 | 指定任务顺序的关系。 |
测试驱动开发 | 在编写相应的源代码之前,针对所需的功能部件准备测试的实践。 |
一次性原型 | 产品的完整版本,打算由后续版本替换。 |
过渡 | 统一过程模型中的阶段,在该阶段中,软件产品已完全交付和部署。 |
透明度 | 每个人都可以看到项目的各个方面。 |
分流 | 一种将需求或请求分类为例如“必须”,“应该”,“可以”优先级的过程。 |
统一流程模型 | 一个用例驱动,以体系结构为中心的迭代和增量软件开发过程。 |
单元测试 | 由开发人员编写和运行的测试,用于验证低级功能是否正常工作。 |
用户故事 | 产品需求的简短结构化描述,概述了谁想要该需求,什么是需求以及为什么需求具有价值。 |
V型 | 线性过程模型,专注于在多个级别上验证产品。 |
已验证 | 发行的软件产品满足客户的要求。 |
验证 | 请参阅已验证。 |
速度 | 在给定的时间间隔内可以完成的工作单元数。 |
验证 | 参见已验证。 |
验证和确认阶段 | 测试产品是否满足要求并检查产品是否满足客户的软件过程阶段。 |
已验证 | 发行的软件产品符合所有指定要求。 |
瀑布模型 | 线性软件开发过程,以阶段为代表,其中已批准的工作产品从一个阶段传递到下一个阶段。 |
工作产品 | 通过完成特定任务产生的输出。工作产品也可以用作其他任务的输入。 |