CPT203 W2
This note is about the Lecture 2 of CPT203.
This week we will focus on three following spots.
- understand the concepts of software processes and software process models;
- introduced to three generic software process models and when they might be used;
- know about the fundamental process activities of software requirements engineering, software development, testing, and evolution;
Introduction
A software process is a set of related activities that leads to the production of a software product. These activites may involve the development
- of software from scratch 软件从零开始
- by extending and modifying existing systems 扩展和修改现有系统
- by configuring and integrating off-the-shelf software or system components 通过配置和集成现成的软件或系统组件
Software processes must include four activites that are fundamental to software engineering:
- software specification 软件规范
- software design and implementation 软件设计与实现
- software validation 软件验证
- software evolution 软件进化
They’re complex activities and include sub-activities.
There’re also supporting process activities such as documentation and software configuration management. 还有支持过程活动，如文档和软件配置管理。
- Software processes are categorized as either plan-driven or agile processes. 软件过程分为计划驱动过程和敏捷过程两种。
- Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. 计划驱动的过程是指所有过程活动都提前计划，并根据该计划衡量进度的过程。
- In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. 在敏捷过程中，计划是增量的，更容易改变过程以反映客户需求的变化。
Software Process Models
A software process model is a simplified representation of a software process.
软件过程模型是软件过程的简化表示。
The models in our discussion
The waterfall model 瀑布模型
This takes the fundamental process activites of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on. 它将基本的过程活动(如规格说明、开发、验证和演进)表示为独立的过程阶段，如需求规格说明、软件设计、实现、测试等等。
Incremental development 增量开发
This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
这种方法将规范、开发和验证活动交织在一起。系统被开发为一系列版本(增量版本)，每个版本向前一个版本添加功能。
Reuse-oriented software engineering 面向重用的软件工程
This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.
这种方法是基于大量可重用组件的存在。系统开发过程关注于将这些组件集成到系统中，而不是从头开始开发它们。
These models are not mutually exclusive and are often used together, especially for large systems development. 这些模型不是相互排斥的，而且在大型系统开发中经常一起使用。
The waterfall model
This model is known as the ‘waterfall model’ or software life cycle 生命循环. This is an example of a plan-driven process 计划驱动流程.
该模型直接反应了以下的活动
- Requirements analysis and definition 需求分析和定义
- System and software design 系统和软件设计
- Implementation and unit testing 实现和单元测试
- Integration and system testing 集成和系统测试
- Operation and maintenance 操作维护
In principle, the result of each phase is one or more documents that are approved (‘signed off’). The following phase should not start until the previous phase has finished. In practice, these stages overlap and feed information to each other. The software process is not a simple linear model but involves feedback from one phase to another. Documents produced in each phase may then have to be modified to reflect the changes made.
原则上，每个阶段的结果是一个或多个文件被批准。在下一阶段应该直到前一阶段结束后才开始。实际上，这些阶段相互重叠并提供信息。软件过程不是一个简单的线性模型，而是涉及从一个阶段到另一个阶段的反馈。每个阶段产生的文件可能需要修改以反映所做的更改。
Because of the costs of producing and approving documents, iterations can be costly and involve significant rework. Therefore, after a small number of iterations, it is normal to freeze parts of the development, such as the specification, and to continue with the later development stages. Problems are left for later resolution, ignored, or programmed around. This premature freezing of development tasks may mean that the system won’t deliver what the users are expecting.
由于生产和批准文件的成本，迭代可能是昂贵的，并涉及重大的返工。因此，在少量的迭代之后，冻结开发的某些部分(如规范)并继续进行后期的开发阶段是正常的。问题被留到以后解决，或者被忽略，或者被编程处理。开发任务的过早冻结可能意味着系统无法交付用户所期望的内容。
During the final life cycle phase (operation and maintenance) the software is put into use. Errors and omissions in the original software requirements are discovered. Program and design errors emerge and the need for new functionality is identified. The system must therefore evolve to remain useful. Making these changes (software maintenance) may involve repeating previous process stages.
在软件生命周期的最后阶段(操作和维护)，软件投入使用。发现原始软件需求中的错误和遗漏。出现程序和设计错误，识别新功能的需求。因此，系统必须不断发展才能保持有用。进行这些更改(软件维护)可能涉及重复前面的过程阶段。
In the Waterfall Model, documentation is produced at each phase. This makes the process visible so managers can monitor progress against the development plan. Its major problem is the inflexible partitioning of the project into distinct stages. Commitments must be made at an early stage in the process, which makes it difficult to respond to changing customer requirements. In principle, the waterfall model should only be used when the requirements are well understood and unlikely to change radically during system development.
在瀑布模型中，每个阶段都会生成文档。这使得过程可见，以便管理人员可以根据开发计划监控进度。它的主要问题是不灵活地将项目划分为不同的阶段。必须在流程的早期阶段做出承诺，这使得很难响应客户不断变化的需求。原则上，瀑布模型只应该在需求被很好地理解并且不太可能在系统开发过程中发生根本变化的情况下使用。
Incremental development
Incremental development is based on the idea of developing an initial implementation, exposing this to user comment and evolving it through several versions until an adequate system has been developed. Specification, development, and validation activities are interleaved rather than separate, with rapid feedback across activities. Incremental software development, which is a fundamental part of agile approaches, is better than a waterfall approach for most business, e-commerce, and personal systems.
增量开发基于这样的想法:开发一个初始实现，将其公开给用户评论，并通过几个版本对其进行改进，直到开发出一个合适的系统。规范、开发和验证活动是交错而不是分离的，活动之间有快速的反馈。增量软件开发是敏捷方法的基本部分，对于大多数业务、电子商务和个人系统来说，增量软件开发比瀑布方法要好。
By developing the software incrementally, it is cheaper and easier to make changes in the software as it is being developed. Each increment or version of the system incorporates some of the functionality that is needed by the customer. Generally, the early increments of the system include the most important or most urgently required functionality. This means that the customer can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments.
通过增量式开发软件，在开发过程中对软件进行更改更便宜也更容易。系统的每个增量或版本都包含了客户需要的一些功能。通常，系统的早期增量包括最重要或最迫切需要的功能。这意味着客户可以在开发的相对早期阶段评估系统，看看它是否交付了所需的内容。如果没有，那么只需要更改当前的增量，并且可能为以后的增量定义新的功能。
Incremental development has three important benefits, compared to the waterfall model: 相比于瀑布模型的优势
- The cost of accommodating changing customer requirements is reduced. 降低了适应客户需求变化的成本。
- It is easier to get customer feedback on the development work that has been done. 对于已经完成的开发工作，更容易获得客户的反馈。
- More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. 即使没有包含所有的功能，也可以更快速地向客户交付和部署有用的软件。
From a management perspective, the incremental approach has two problems:
- the process is not visible. 流程不可视
- system structure tends to degrade as new increments are added. 系统结构会随着增量的增加而降低
Other problems with incremental development includes:
- large organizations have bureaucratic procedures that have evolved over time and there may be a mismatch between these procedures and a more informal iterative or agile process. 大型组织的官僚程序随着时间的推移而演变，在这些程序和更非正式的迭代或敏捷过程之间可能存在不匹配。
- Formal procedures are required by external regulations (e.g., accounting regulations)
The problems of incremental development become particularly acute for large, complex, long-lifetime systems, where different teams develop different parts of the system. Large systems need a stable framework or architecture and the responsibilities of the different teams working on parts of the system need to be clearly defined with respect to that architecture. This has to be planned in advance rather than developed incrementally.
对于大型、复杂、长生命周期的系统，增量开发的问题变得特别尖锐，在这些系统中，不同的团队开发系统的不同部分。大型系统需要一个稳定的框架或体系结构，不同团队在系统部分的工作职责需要根据该体系结构明确定义。这必须提前计划，而不是渐进地开发。
Reuse-oriented software engineering
In the majority of software projects, there are some forms of informal software reuse. This informal reuse takes place irrespective of the development process that is used. In the 21st century, software development processes that focus on the reuse of existing software have become widely used. Reuse-oriented approaches rely on a large base of reusable software components and an integrating framework for the composition of these components.
在大多数软件项目中，有一些非正式的软件重用形式。这种非正式的重用与所使用的开发过程无关。在21世纪，注重现有软件重用的软件开发过程得到了广泛的应用。面向重用的方法依赖于大量的可重用软件组件和用于这些组件组合的集成框架。
Three types of software component that may be used in a reuse-oriented process:
- Web services that are developed according to service standards and which are available for remote invocation. 根据服务标准开发并可用于远程调用的Web服务。
- Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. 对象的集合被开发成一个包，与组件框架集成。
- Stand-alone software systems that are configured for use in a particular environment. 配置为在特定环境中使用的独立软件系统。
Advantages
- reducing the amount of software to be developed and so reducing cost and risks. 减少需要开发的软件数量，从而降低成本和风险。
- usually also leads to faster delivery of the software. 通常也会导致更快的软件交付。
However, requirements compromises are inevitable and this may lead to a system that does not meet the real needs of users. Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them.
然而，需求妥协是不可避免的，这可能导致系统不能满足用户的实际需求。此外，由于可重用组件的新版本不在使用它们的组织的控制之下，对系统演化的一些控制就会丢失。
Software process activities
There’re four types of software process activites.
- Software Specification
- Software Design and Implementation
- Software Validation
- Software Evolution
真实的软件过程是技术、协作和管理活动的交错序列，其总体目标是指定、设计、实现和测试一个软件系统。在不同的开发过程中，规范、开发、验证和演进这四个基本过程活动的组织方式不同。
- In the waterfall model, they are organized in sequence. 在瀑布模型中，它们是按顺序组织的。
- In incremental development they are interleaved. 在增量开发中，它们是交错的。
- How these activities are carried out depends on the type of software, people, and organizational structures involved. 这些活动如何进行取决于所涉及的软件、人员和组织结构的类型。
Software specification 软件规格说明
Software specification or requirements engineering is the process of understanding and defining 软件规格说明或需求工程是理解和定义的过程
- what services are required from the system 系统需要哪些服务
- identifying the constraints on the system’s operation and development. 识别系统运行和发展的制约因素
Requirements engineering is a particularly critical stage of the software process as errors at this stage inevitably lead to later problems in the system design and implementation. 需求工程是软件过程中一个特别关键的阶段，因为这一阶段的错误不可避免地会导致系统设计和实现中的后续问题。
The activities of analysis, definition, and specification are interleaved. 分析、定义和规范的活动是交错的。
The requirements engineering process aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements. 需求工程过程的目的是产生一个商定的需求文档，指定一个满足涉众需求的系统。
规格一般分为两层级细节。
Requirements are usually presented at two levels of detail.
- End-users and customers need a high-level statement of the requirements; 终端用户和客户需要高层次的需求说明;
- system developers need a more detailed system specification. 系统开发人员需要一个更详细的系统规范。
There are four main activities in the requirements engineering process: 在工程过程需求中一般有四种活动
- Feasibility study 可行性研究
- Requirements elicitation and analysis 需求提取和分析
- Requirements specification 需求规范
- Requirements validation 需求验证
Software design and implementation
The implementation stage of software development is the process of converting a system specification into an executable system. It always involves processes of software design and programming but, if an incremental approach to development is used, may also involve refinement of the software specification. A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used. 软件开发的实现阶段是将系统规范转换为可执行系统的过程。它总是涉及到软件设计和编程的过程，但是，如果使用增量开发方法，也可能涉及到软件规范的细化。软件设计是描述要实现的软件的结构、系统使用的数据模型和结构、系统组件之间的接口，有时还包括使用的算法。
设计师不会立即完成设计，而是反复开发设计。他们在开发设计的过程中添加了正式性和细节，不断回溯以纠正早期的设计。
Design activities
- Architectural design, where you 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, where you define the interfaces between system components. This interface specification must be unambiguous. 接口设计，定义系统组件之间的接口。这个接口规范必须是明确的。
- Component design, where you take each system component and design how it will operate. 组件设计，将每个系统组件设计成如何运行。
- a simple statement of the expected functionalities. 对预期功能的简单说明
- a list of changes to be made to a reusable component. 可重用组件的更改列表
- a detailed design model (model-driven approach). 详细的设计模型
- Database design, where you design the system data structures and how these are to be represented in a database. 数据库设计，即设计系统数据结构以及如何在数据库中表示这些结构。
The detail and representation of the design output vary considerably.
- For critical systems, detailed design documents setting out precise and accurate descriptions of the system must be produced. 对于关键系统，必须编制详细的设计文件，对系统进行精确的描述。
- If a model-driven approach is used, these outputs may mostly be diagrams. 如果使用模型驱动的方法，这些输出可能主要是图。
- Where agile methods of development are used, the outputs of the design process may not be separate specification documents but may be represented in the code of the program. 在使用敏捷开发方法的情况下，设计过程的输出可能不是单独的规格文件，而是在程序代码中表示。
Software validation
There’re three testing process: 三种test process
- Development testing 开发测试 - The components making up the system are tested by the people developing the system. Each component is tested independently, without other system components.
- System testing 系统测试 - System components are integrated to create a complete system. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems.
- Acceptance testing 验收测试 - This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system customer rather than with simulated test data.
Tutorial questions
Q: Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems.
- A system to control anti-lock braking in a car
- A virtual reality system to support software maintenance
- A university accounting system that replaces an existing system
- An interactive travel planning system that helps users plan journeys with the lowest environmental impact
A:
- Anti-lock braking system. This is a safety-critical system so requires a lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages.
- Virtual reality system. This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. An agile process may be used.
- University accounting system. This is a system whose requirements are fairly well-known and which will be used in an environment in conjunction with lots of other systems such as a research grant management system. Therefore, a reuse-based approach is likely to be appropriate for this.
- Interactive travel planning system. System with a complex user interface. An incremental development approach is the most appropriate as the system requirements will change as real user experience with the system is gained.
PS: To be honest, I am quite confused about this reference answer cus NEITHER OF THESE ANSWERS is in the slides. So just have a glance at the answer, it’s common to stuck on these questions.
Q: Explain why incremental development is the most effective approach for developing business software systems. Why is this model less appropriate for real-time systems engineering?
A: Business software systems usually complex, software intensive, and frequently being changes when business goals or processes are changed. So incremental development is better. 业务目标或过程发生变化时经常发生变化。所以增量开发更好。Real-time systems usually involve many hardware components which are not easy to change and cannot be incremental. Also real-time systems usually safety critical which needed be built based on well planned process. 实时系统通常包含许多硬件组件，这些硬件组件不容易更改，也不能增量。此外，实时系统通常是安全的关键，需要建立在良好的计划过程。
Q: Consider the reuse-based process model. Explain why it is essential to have two separate requirements engineering activities in the process.
A:
In a reuse based process, you need two requirements engineering activities because it is essential to adapt the system requirements according to the capabilities of the system/components to be reused. These activities are:
- An initial activity where you understand the function of the system and set out broad requirements for what the system should do. These should be expressed in sufficient detail that you can use them as a basis for deciding of a system/component satisfies some of the requirements and so can be reused. 一个初步的活动，在这个活动中，您了解系统的功能，并为系统应该做什么设定广泛的需求。这些应该以足够详细的方式表达，以便您可以将它们作为决定系统/组件是否满足某些需求的基础，从而可以重用。
- Once systems/components have been selected, you need a more detailed requirements engineering activity to check that the features of the reused software meet the business needs and to identify changes and additions that are required. 一旦选择了系统/组件，您需要一个更详细的需求工程活动来检查重用软件的特性是否满足业务需求，并确定所需的更改和添加。
Q: Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process.
A:
There is a fundamental difference between the user and the system requirements that mean they should be considered separately.
- The user requirements are intended to describe the system’s functions and features from a user perspective and it is essential that users understand these requirements. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The people involved in the process must be able to understand the user’s environment and application domain. 用户需求旨在从用户的角度描述系统的功能和特性，用户理解这些需求是至关重要的。总的来说就是用户没有方法表达的太清楚，需要开发人员理解用户的需求。
- The system requirements are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract. They may also be used in situations where development is outsourced and the development team need a complete specification of what should be developed. The system requirements are developed after user requirements have been established. 系统需求要比用户需求详细得多，并且要成为系统合同的一部分的系统的精确规范。当开发被外包，并且开发团队需要一个完整的关于应该开发什么的规范时，也可以使用它们。系统需求是在建立用户需求之后开发的。
References
- XJTLU MC PowerPoint Slides (CPT203 Week2 Lecture2)