软件工程笔记:软件过程
该部分为本科期间软件工程课程笔记备份。
Software Processes 软件过程
3.1 Software process models 3.1 软件过程模型
3.2 Process activities 3.2 过程活动
3.3 Coping with change 3.3 应对变化
3.4 The Rational Unified Process 3.4 合理的统一过程
- An example of a modern software process. 现代软件过程的一个例子
Software Processes definition:
A structured set of activities required to develop a software system. 开发软件系统所需的一组结构化活动。
Note: no right or wrong software processes 没有正确或错误的软件流程
different software processes but all involve: 许多不同的软件流程, 但都涉及
- Specification 规范
- defining what the system should do 定义系统应执行的操作
- Design and implementation 设计实施
- defining the organization of the system and implementing the system 确定系统的组织和实施系统
- Validation 验证
- checking that it does what the customer wants 检查它是否执行了客户想要的操作;
- Evolution(进展,进化)
- changing the system in response to changing customer needs 根据不断变化的客户需求改变系统
A software process model:an abstract representation of a process 软件过程模型是过程的抽象表示。
presents a description of a process from some particular perspective 它从某种特定的角度描述了一个过程。
Software process descriptions
**Usually talk: 通常会讨论
activities in these processes and the ordering of these activities. 这些过程中的活动, 如指定数据模型、设计用户界面等, 以及这些活动的顺序。
may also include: 流程说明还可能包括
-
Products: outcomes of a process activity 产品, 是过程活动的结果
-
Roles: reflect the responsibilities of the people involved in the process 作用, 反映参与这一进程的人员的责任;
-
Pre- and post-conditions: are statements that are true before and after a process activity has been enacted or a product produced 前和后条件, 即在颁布加工活动或生产产品之前和之后真实的陈述
Plan-driven and agile processes
processes where all of the process activities are planned in advance and progress is measured against this plan. 计划驱动的流程是所有流程活动提前规划并根据该计划衡量进展情况的流程
-
In agile(敏捷) processes: planning is incremental andeasier to change the process to reflect changing customer requirements. 在敏捷流程中, 规划是渐进的, 更容易改变流程以反映不断变化的客户需求。
-
In practice: most practical processes include elements of both plan-driven and agile approaches 实际上, 大多数实际流程都包括计划驱动和敏捷方法的要素。
Software process models
Three types
waterfall model 瀑布模型
-
Plan-driven model: Separate(分离) and distinct(区别) phases of specification and development. 平面驱动模型。规范和开发的单独和独特的阶段。
Incremental development 增量开发
- Specification, development and validation are interleaved(交错) 规范、开发和验证是交织在一起的。
- May be plan-driven or agile.可以是计划驱动的, 也可以是敏捷的。
Reuse-oriented software engineering 面向复用的软件工程
- system is assembled(集合) from existing components. May be plan-driven or agile 该系统是由现有组件组装而成的。可以是计划驱动的, 也可以是敏捷的。
In practice: 实际上
most large systems are developed using a process that incorporates(合并) elements from all of these models. , 大多数大型系统都是使用一个包含所有这些模型元素的过程来开发的
The waterfall model
separate identified(认定的) phases
瀑布模型中有单独确定的阶段:
- Requirements analysis and definition 需求分析和定义
- System and software design 系统和软件设计
- Implementation and unit testing 实施和单元测试
- Integration(集成) and system testing 集成和系统测试
- Operation and maintenance(维护) 操作和维护
main drawback:
-
the difficulty of accommodating(调节) change after the process is underway(进行中) 瀑布模型的主要缺点是难以适应过程开始后的变化。
-
In principle: a phase has to be complete before moving onto the next phase 原则上, 一个阶段必须完成, 然后才能进入下一个阶段。
problems:
- Inflexible partitioning(僵化的区分) of the project into distinct stages(阶段) make it difficult to respond to changing customer requirements 将项目划分为不同阶段的不灵活会使其难以响应不断变化的客户需求。
- model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. 只有在很好地理解需求并在设计过程中对更改进行相当有限的情况下, 此模型才是合适的。
- model is mostly used for large systems engineering projects where a system is developed at several sites. 对于发展了多个地点的大型项目,模型大概被使用
- In those circumstances(情况), plan-driven nature of the waterfall model helps coordinate the work 在这种情况下, 瀑布模型的平面驱动性质有助于协调工作。
Incremental development
advantage
- cost of accommodating changing customer requirements is reduced 降低了满足不断变化的客户需求的成本
- The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model 必须重做的分析和文档量远远低于瀑布模型所需的数量
- easier to get customer feedback on the development work that has been done 更容易获得客户对已完成的开发工作的反馈。
- Customers can comment on demonstrations of the software and see how much has been implemented 客户可以对软件演示进行评论, 并查看已实施了多少软件。
- More rapid(快速的) delivery and deployment of useful software to the customer is possible 可以更快速地向客户交付和部署有用的软件。
- Customers are able to use and gain value from the software earlier than is possible with a waterfall process 客户能够比瀑布过程更早地使用软件并从软件中获得价值。
Problem
process is not visible 该进程不可见。
- Managers need regular deliverables(定期交付) to measure progress. 管理人员需要定期交付成果来衡量进展情况。
- not cost-effective to produce documents that reflect every version of the system when systems are developed quickly. 如果系统开发得很快, 那么生成反映系统每个版本的文档并不符合成本效益。
System structure tends to degrade(降级) as new increments are added 随着新增量的增加, 系统结构往往会降低。
- Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt(恶化) its structure. 除非花时间和金钱进行重构以改进软件, 定期的更改往往会破坏软件的结构。
- Incorporating further software changes becomes increasingly difficult and costly 合并进一步的软件更改变得越来越困难和昂贵。
Reuse-oriented software engineering
Basis
Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems 基于系统重用, 即从现有组件或商用现成系统集成系统。
Process stages 工艺阶段
- Component analysis; 成分分析
- Requirements modification; 需求修改
- System design with reuse; 具有重用的系统设计
- Development and integration. 开发和集成
Note:Reuse is now the standard approach for building many types of business system 重用现在是构建多种类型业务系统的标准方法
Types of software component
Web services:
developed according to service standards and which are available for remote invocation
根据服务标准开发的 web 服务, 这些服务可用于远程调用
Collections of objects:
developed as a package to be integrated with a component framework(框架)
.NET or J2EE.作为包开发的对象的集合, 这些对象将与组件框架 (如. net 或 J2EE) 集成。
Stand-alone software systems:
configured for use in a particular environment
配置为在特定环境中使用的独立软件系统 (COTS)。
Process activities
Real software processes:
inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system. 真正的软件流程是技术、协作和管理活动的交错序列, 其总体目标是指定、设计、实施和测试软件系统。
four basic process activities(specification, development, validation and evolution): 规范、开发、验证和进化这四个基本过程活动
organized differently in different development processes. 在不同的开发过程中进行了不同的组织。
In the waterfall model, they are organized in sequence, whereas in incremental development they are inter-leaved 瀑布模型中, 它们按顺序组织, 而在增量开发中, 它们是交错的。
Software specification
establishing what services are required and constraints(约束) on the system’s operation and development. 确定所需服务的过程以及对系统运行和开发的限制。
Requirements engineering process 需求工程流程
- Feasibility(可行性) study 可行性研究
- Is it technically and financially feasible to build the system?建立该系统在技术上和财政上是否可行?
- Requirements elicitation(抽取) and analysis 需求激发和分析
- Requirements specification 需求规格
- Defining the requirements in detail详细定义需求
- Requirements specification 需求验证
- Requirements validation 检查需求的有效性
Software design and implementation
converting the system specification into an executable system 将系统规范转换为可执行系统的过程。
-
Software design 软件设计
Design a software structure that realises(明白) the specification 设计实现规范的软件结构;
-
Implementation 实现
Translate this structure into an executable program 将此结构转换为可执行程序;
Note: activities of design and implementation are closely related and may be inter-leaved.设计和实施的活动密切相关, 可能是交织在一起的。
Design activities
Architectural design 架构设计
- identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed 在这里您可以确定系统的总体结构、主要组件 (有时称为子系统或模块)、它们之间的关系以及它们的分布方式。
Interface design 接口设计
- define the interfaces between system components 在其中定义系统组件之间的接口
Component design 组件设计
- take each system component and design how it will operate 在其中获取每个系统组件并设计其操作方式。
Database design 数据库设计
- design the system data structures and how these are to be represented in a database 其中您可以设计系统数据结构以及如何在数据库中表示这些结构。
Software validation
Verification and **validation(V&V):
intended to show that a system conforms to its specification and meets the requirements of the system customer 表明系统符合其规格, 并符合系统客户的需求,
involves
checkingand review processes and system testing 涉及检查和审查流程和系统测试。
System testing
involves executing the system with test cases that are derived(来源) from the specification of the real data to be processed by the system 系统测试包括使用从系统要处理的真实数据的规范中派生的测试用例来执行系统。
- Testing:most commonly used V & V activity 测试是最常用的 V & v 活动。
Stages of testing
Development or component testing 开发或组件测试
Individual(个别) components are tested independently 独立测试各个组件
Components may be functions or objects or coherent groupings of these entities. 组件可以是这些实体的功能或对象, 也可以是一致的分组。
System testing 系统测试
Testing of the system as a whole. Testing of emergent properties(突变(发)性质) is particularly important. 对整个系统进行测试。紧急特性的测试尤其重要。
Acceptance testing 验收测试
Testing with customer data to check that the system meets the customer’s needs. 使用客户数据进行测试, 以检查系统是否满足客户的需求。
Testing phases in a plan-driven software process 使用客户数据进行测试, 以检查系统是否满足客户的需求。
Testing phases in a plan-driven software process
Software evolution
- Software is inherently flexible(灵活的) and can change 软件本质上是灵活的, 可以改变。
- As requirements change through changing business circumstances(商业情况), the software that supports the business must also evolve and change. 随着需求随业务环境的变化而变化, 支持业务的软件也必须不断发展和变化。
- Although there has been a demarcation(划界) between development and evolution (maintenance) this is increasingly irrelevant(不相干的) as fewer and fewer systems are completely new. 虽然在发展和演变 (维护) 之间进行了划分, 但由于系统越来越少, 完全是新的, 这一点越来越不重要
Coping with change
Change is inevitable(必然的) in all large software projects 在所有大型软件项目中, 变化是不可避免的。
- Business changes lead to new and changed system requirements 业务变化导致新的和更改的系统需求
- New technologies open up new possibilities for improving implementations 业务变化导致新的和更改的系统需求
- Changing platforms require application changes更改平台需要更改应用程序
Change leads to rework so the costs of change include both rework (e.g. re-analyzing requirements) as well as the costs of implementing new functionality 更改导致返工, 因此更改的成本既包括返工 (例如重新分析需求), 也包括实现新功能的成本
Reducing the costs of rework
Change avoidance 避免更改,
the software process includes activities that can anticipate possible changes before significant rework is required. 其中软件过程包括在需要进行重大返工之前可以预测可能的更改的活动
eg: a prototype(标准) system may be developed to show some key features of the system to customers, and redefine requirements. 可以开发一个原型系统, 向客户显示系统的一些关键功能, 并重新定义需求。
Change tolerance 改变容忍度
the process is designed so that changes can be accommodated at relatively low cost 在这种情况下, 过程的设计是为了以相对较低的成本适应变化。
- normally involves some form of incremental development. 这通常涉及某种形式的增量开发。拟议的修改可以以尚未制定的增量实施。
- Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have to be altered to incorporate the change.如果这是不可能的, 那么可能只需更改单个增量 (系统的一小部分) 就可以合并更改。
Software prototyping
prototype
an initial version of a system used to demonstrate(展示) concepts and try out design options 原型是一个系统的初始版本, 用于演示概念和尝试设计选项。
used in
In requirements engineering process 需求工程流程
- help with requirements elicitation and validation 帮助需求激发和验证;
In design processes 在设计过程中
- explore options and develop a UI design 探索选项并开发 UI 设计
In the testing process 在测试过程
- to run back-to-back tests 连续运行测试。
Benefits of prototyping
-
Improved system usability 提高了系统的可用性。
-
A closer match to users’ real needs 更符合用户的实际需求
-
Improved design quality.提高设计质量。
-
Improved maintainability.改进的可维护性
-
Reduced development effort 减少开发工作
The process of prototype development
Prototype development
May be based on rapid prototyping languages or tools 可能基于快速原型语言或工具
May involve leaving out functionality 可能涉及省略功能
-
Prototype should focus on areas of the product that are not well-understood;原型应侧重于产品中不被很好理解的领域;
-
Error checking and recovery may not be included in the prototype;错误检查和恢复可能不包括在原型中;
-
Focus on functional rather than non-functional requirements such as reliability and security 专注于功能性需求, 而不是非功能性需求, 如可靠性和安全性
Throw-away prototypes
Prototypes should be discarded after development as they are not a good basis for a production system: :原型在开发后应该被丢弃, 因为它们不是生产系统的良好基础:
-
It may be impossible to tune(调整) the system to meet non-functional requirements Prototypes are normally undocumented;可能不可能调整系统以满足非功能性需求;
-
The prototype structure is usually degraded(降级) through rapid change;原型通常没有记录;
-
The prototype probably will not meet normal organizational quality standards.原型结构通常通过快速变化而退化;
Incremental delivery
Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.开发和交付不是作为单个交付交付交付, 而是通过每个增量提供所需功能的一部分而细分为增量。
User requirements are prioritised(被给予优先权) and the highest priority requirements are included in early increments.对用户需求进行优先排序, 并以早期增量的方式包括最高优先级需求。
Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve(发展)..一旦增量的开发开始, 需求就会被冻结, 尽管以后增量的需求可能会继续变化。
Incremental development and delivery
Incremental development:增量开发
-
Develop the system in increments and evaluate each increment before proceeding to the development of the next increment;以增量方式开发系统, 并在继续开发下一个增量之前评估每个增量;
-
Normal approach used in agile methods;敏捷方法中使用的常用方法;
-
Evaluation done by user/customer proxy(代理)..由用户/客户代理进行评估。
Incremental delivery: 增量交付
- Deploy an increment for use by end-users;部署增量供最终用户使用
- More realistic evaluation about practical use of software;更真实的软件实际使用评估;
- Difficult to implement for replacement systems as increments have less functionality than the system being replaced.对于增量的替换系统, 很难实现, 因此与被替换的系统相比, 功能较少。
advantage
- Customer value can be delivered with each increment 客户价值可以通过每个增量交付
- system functionality is available earlier 因此系统功能可以更早地提供。
- Early increments act as a prototype 早期增量作为一个原型
- help elicit requirements for later increments 以帮助获得以后的增量需求。
- Lower risk of overall project failure 降低整体项目失败的风险。
- The highest priority system services tend to receive the most testing 最优先级的系统服务往往接受的测试最多
problems
Most systems require a set of basic facilities that are used by different parts of the system 大多数系统都需要一组由系统不同部分使用的基本设施。
- As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments. 由于在实现增量之前没有详细定义需求, 因此很难确定所有增量所需的公共设施。
The essence of iterative processes is that the specification is developed in conjunction(结合) with the software itself 迭代过程的本质是规范是与软件本身一起开发的。
- this conflicts with the procurement(获得) model of many organizations, where the complete system specification is part of the system development contract(合同) 然而, 这与许多组织的采购模式相抵触, 在这些组织中, 完整的系统规范是系统开发合同的一部分。
Boehm’s spiral(螺旋的) model
-
Process is represented as a **spiral **rather than as a sequence of activities with backtracking(回溯). 过程被表示为一个螺旋, 而不是一个有回溯的活动序列。
-
Each loop in the spiral represents a phase in the process 螺旋中的每个循环都表示过程中的一个阶段。
-
No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required 没有固定的阶段, 如规格或设计-循环中的循环被选择, 这取决于什么是需要
-
Risks are explicitly(明确地) assessed and resolved throughout the process. 在整个过程中明确评估和解决风险
Spiral model sectors
Objective setting 目标设定
Specific objectives for the phase are identified. 确定了该阶段的具体目标
Risk assessment and reduction 风险评估和减少
Risks are assessed and activities put in place to reduce the key risks. 对风险进行评估, 并开展活动, 以减少关键风险。
Development and validation 开发和验证
A development model for the system is chosen which can be any of the generic(一般的) models. 选择了系统的开发模型, 该模型可以是任何通用模型。
Planning 规划
The project is reviewed and the next phase of the spiral is planned. 对该项目进行了审查, 并计划下一阶段的螺旋
Spiral model usage
Spiral model has been very influential(有影响) in helping people think about iteration in software processes and introducing the risk-driven approach to development. 螺旋模型在帮助人们思考软件过程中的迭代和引入风险驱动的开发方法方面发挥了非常重要的作用。
In practice, however, the model is rarely used as published for practical software development.然而, 在实践中, 该模型很少被用于实际软件开发的发布。
The Rational Unified Process
A modern generic process derived from the work on the UML and associated process. 从 UML 和关联流程的工作中派生出来的现代通用流程。
Brings together aspects of the 3 generic process models discussed previously. 将前面讨论的3个通用工艺模型的各个方面结合在一起。
Normally described from 3 perspectives: 通常从3个角度描述
-
A dynamic perspective that shows phases over time;显示随时间推移的阶段的动态透视
-
A static perspective that shows process activities;显示流程活动的静态透视;
-
A practive perspective that suggests good practice 一种实践观点, 表明良好的做法。
RUP phases
Inception(起初)
Establish the business case for the system. 建立系统的业务案例。
Elaboration(详细阐述)
Develop an understanding of the problem domain and the system architecture. 了解问题域和系统体系结构。
Construction 建设
System design, programming and testing. 系统设计、编程和测试
Transition 过渡
Deploy the system in its operating environment. 在其操作环境中部署系统。
RUP iteration 迭代
In-phase iteration 阶段迭代
Each phase is iterative with results developed incrementally.每个阶段都是迭代的, 结果是逐步开发的。
Cross-phase iteration 跨阶段迭代
As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally. 如 RUP 模型中的循环所示, 可以以增量方式制定整个阶段集。
Workflows in RUP
| Workflow | Description |
|---|---|
| usiness modelling 商业建模 | The business processes are modelled using business use cases.业务流程是使用业务用例建模的 |
| Requirements 要求 | Actors who interact with the system are identified and use cases are developed to model the system requirements.识别与系统交互的参与者, 并开发用例来建模系统要求。 |
| Analysis and design 分析和设计 | A design model is created and documented using architectural models, component models, object models and sequence models.使用体系结构模型、组件模型、对象模型和序列模型创建和记录设计模型。 |
| Implementation 实现 | The components in the system are implemented and structured into implementation sub-systems. Automatic code generation from design models helps accelerate this process.该系统中的组件被实现并结构成实施子系统。从设计模型自动生成代码有助于加快这一进程。 |
| Testing测试 | Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation.测试是一个迭代过程, 它是在实现的同时进行的。系统测试是在实现完成之后进行的 |
| Deployment部署 | A product release is created, distributed to users and installed in their workplace.产品版本被创建、分发给用户并安装在他们的工作场所。 |
| Configuration and change management配置和更改管理 | This supporting workflow managed changes to the system (see Chapter 25).此支持的工作流管理了对系统的更改 (请参阅第25章)。 |
| Project management项目管理 | This supporting workflow manages the system development (see Chapters 22 and 23).此支持的工作流管理系统开发 (请参见第22章和第23章)。 |
| Environment环境 | This workflow is concerned with making appropriate software tools available to the software development team.此工作流涉及向软件开发团队提供适当的软件工具。 |
RUP good practice
Develop software iteratively 以迭代方式开发软件
Plan increments based on customer priorities and deliver highest priority increments first. 根据客户优先级规划增量, 并首先交付最高优先级增量。
Manage requirements 管理需求
Explicitly(明确地) document customer requirements and keep track of changes to these requirements. 明确记录客户需求并跟踪这些需求的更改
Use component-based architectures 使用基于组件的体系结构
Organize the system architecture as a set of reusable components.使用基于组件的体系结构
Visually model software 直观的软件模型
Use graphical UML models to present static and dynamic views of the software. 使用图形 UML 模型显示软件的静态和动态视图。
Verify software quality 验证软件质量
Ensure that the software meet’s organizational quality standards.确保软件符合组织质量标准。.
Control changes to software 控制对软件的更改
Manage software changes using a change management system and configuration management tools. 使用更改管理系统和配置管理工具管理软件更改。

浙公网安备 33010602011771号