計(jì)算機(jī)英語Unit 5 Software Process Models（課堂PPT）

1、1Unit 5 Software ProcessSection A: Software Process Models2Introduction A software process is a set of activities that leads to the production of a software product. These activities may involve the development of software from scratch in a standard programming language like Java or C. Increasingly,

2、 however, new software is developed by extending and modifying existing systems and by configuring and integrating off-the-shelf software or system components.3 A software process model is an abstract representation of a software process. Each process model represents a process from a particular per

3、spective, and thus provides only partial information about that process.This section introduces a number of very general process models (sometimes called process paradigms) and presents them from an architectural perspective. That is, we see the framework of the process but not the details of specif

4、ic activities.4 These generic models are not definitive descriptions of software process. Rather, they are abstractions of the process that can be used to explain different approaches to software development. You can think of them as process frameworks that may be extended and adapted to create more

5、 specific software engineering processes.5 The process models covered here are the waterfall model, evolutionary development and component-based software engineering. These three generic process models are widely used in current software engineering practice. They are not mutually exclusive and are

6、often used together, especially for large systems development. Sub-systems within a larger system may be developed using different approaches. Therefore, although it is convenient to discuss these models separately, you should understand that, in practice, they are often combined.6. The waterfall mo

7、del The first published model of the software development process was derived from more general system engineering processes. This is illustrated in Figure 5A-1. Because of the cascade from one phase to another, this model is known as the waterfall model or software life cycle. The principal stages

8、of the model map onto fundamental development activities:7RequirementdefinitionSystem andsoftware design Implementation and unit testingIntegration and system testingOperation andmaintenanceFigure 5A-1: The Software Life Cycle8Requirements analysis and definition. The systems services, constraints a

9、nd goals are established by consultation with system users. They are then defined in detail and serve as a system specification.System and software design. The systems design process partitions the requirements to either hardware or software systems. It establishes an overall system architecture. So

10、ftware design involves identifying and describing the fundamental software system abstractions and their relationships.93. Implementation and unit testing. During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets i

11、ts specification.4. Integration and system testing. The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer.105. Operation and maintenance. Normally

12、 (although not necessarily) this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the systems services

13、as new requirements are discovered.11 In principle, the result of each phase is one or more documents that are approved. The following phase should not start until the previous phase has finished. In practice, these stages overlap and feed information to each other. During design, problems with requ

14、irements are identified; during coding design problems are found and so on. The software process is not a simple linear model but involves a sequence of iterations of the development activities. 12 Because of the costs of producing and approving documents, iterations are costly and involve significa

15、nt 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 requirements may m

16、ean that the system wont do what the user wants. It may also leads to badly structured systems as design problems are circumvented by implementation tricks.13 During the final life-cycle phase (operation and maintenance), the software is put into use. Errors and omissions in the original software re

17、quirements 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.14 The advantages of the waterfall model are that

18、 documentation is produces at each phase and that is fits with other engineering process models. Its major problem is its inflexible partitioning of the project into distinct stages. Commitments must be made at an earlier stage in the process, which makes it difficult to respond to changing customer

19、 requirements.15 Therefore, the waterfall model should only be used when the requirements are well understood and unlikely to change radically during system development. However, the waterfall model reflects the type of process model used in other engineering projects. Consequently, software process

20、es based on this approach are still used for software development, particularly when the software project is part of a larger systems engineering project.16. Evolutionary Development Evolutionary development is based on the idea of developing an initial implementation, exposing this to user comment

21、and refining it through many versions until an adequate system has been developed (Figure 5A-2). Specification, development and validation activities are interleaved rather than separate, with rapid feedback across activities. 17OutlinedescriptionInitialversionIntermediateversionsFinalversionSpecifi

22、cationValidationDevelopmentConcurrentactivitiesFigure 5A-2: Evolutionary Development18 There are two fundamental types of evolutionary development: 1. Exploratory development where the objective of the process is to work with the customers to explore their requirements and deliver a final system. Th

23、e development starts with the parts of the system that are understood. The system evolves by adding new features proposed by customer.19 2. Throwaway prototyping where the objective of the evolutionary development process is to understand the customers requirements and hence develop a better require

24、ments definition for the system. The prototype concentrates on experimenting with the customer requirements that are poorly understood.20 An evolutionary approach to software development is often more effective than the waterfall approach in producing system that meet the immediate needs of customer

25、s. The advantage of a software process that is based on an evolutionary approach is that the specification can be developed incrementally. As users develop a better understanding of their problem, this can be reflected in the software system. However, from an engineering and management perspective,

26、the evolutionary approach has two problems:21The process is not visible. Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.Systems are often poorly structured. Continual cha

27、nge tends to corrupt the software structure. Incorporating software changes becomes increasingly difficult and costly.22 For a small and medium-sized systems(up to 500,000 lines of code), the evolutionary approach may be the best approach to development. The problems of evolutionary development beco

28、me particularly acute for large, complex, long-life-time systems, where different teams develop different parts of the system. It is difficult to establish a stable system architecture using this approach, which makes it hard to integrate contributions from the teams.23 For large systems, a mixed pr

29、ocess is recommended which incorporates the best features of the waterfall and the evolutionary development models. This may involve developing a throwaway prototype using an evolutionary approach to resolve uncertainties in the system specification. You can then re-implement the system using a more

30、 structured approach. Parts of the system that are well understood can be specified and developed using a waterfall-based process. Other parts of the system, such as the user interface, which are difficult to specify in advance, should always be developed using an exploratory programming approach.24

31、. Component-Based Software Engineering In the majority of software projects, there is some software reuse. This usually happens informally when people working on the project know of designs or code which is similar to that required. They look for these, modify then as needed and incorporate them int

32、o their system. In the evolutionary approach, reuse is often essential for rapid system development. 25 This informal reuse takes place irrespective of the development process that is used. However, in the last few years, an approach to software development called component-based software engineerin

33、g (CBSE), which relies on reuse, has emerged and is becoming increasingly used. 26 This reuse-oriented approach relies on a large base of reusable software components and some integrating framework for these components. Sometimes, these components are systems in their own right (COTS or commercial o

34、ff-the-shelf systems) that may provide specific functionality such as text formatting or numeric calculation. The generic process model for CBSE is shown in Figure 5A-3.27requirements specificationComponentanalysisRequirementsmodificationSystem designwith reuseDevelopmentand integrationSystemvalidat

35、ionFigure 5A-3: Component-Based Software Engineering28 While the initial requirements specification stage and the validation stage are comparable with other processes, the intermediate stages in a reuse-oriented process are different. These stages are:1. Component analysis. Given the requirement spe

36、cification, a search is made for components to implement that specification. Usually, there is no exact match, and the components that may be used only provide some of the functionality required.29 2. Requirements modification. During this stage, the requirements are analyzed using information about the components that have been discovered. They are then modified to reflect the available component