軟件工程Chapter 02 software process

1、軟件工程軟件工程Chapter 02 software Chapter 02 software processprocessFour activities of software process modelThere are many different software processes but all must include four activities that are fundamental to software engineering:1. Software specification The functionality of the software and constra

2、ints on its operation must be defined.2. Software design and implementation The software to meet the specification must be produced.3. Software validation The software must be validated to ensure that it does what the customer wants.4. Software evolution The software must evolve to meet changing cus

3、tomer needs.Software process modelsA software process model is a simplified representation of a software process. Each process model represents a process from a particular perspective, and thus provides only partial information about that process.In this section, a number of very general process mod

4、els is introduced (sometimes called process paradigms) and are presented from an architectural perspective. That is, we see the framework of the process but not the details of specific activities.The water fall modelThe water fall modelThe waterfall model is an example of a plan-driven processin pri

5、nciple, you must plan and schedule all of the process activities before starting work on them.In principle, the waterfall model should only be used when the requirements are well understood and unlikely to change radically during system development.An important variant of the waterfall model is form

6、al system development. Formal development processes, such as that based on the B method are particularly suited to the development of systems that have stringent safety, reliability, or security requirements.Cleanroom software engineeringp Originally developed by IBMp In the Cleanroom process each s

7、oftware increment is formally specified and this specification is transformed into an implementation. p Software correctness is demonstrated using a formal approach. p There is no unit testing for defects in the process and the system testing is focused on assessing the systems reliability.p The obj

8、ective of the Cleanroom process is zero-defects software so that delivered systems have a high level of reliability.Incremental developmentThe system is developed as a series of versions (increments), with each version adding functionality to the previous version.Incremental developmentIncremental d

9、evelopment 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

10、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.Incremental development: benefitsIncremental development has three important benefits, compared to the waterfal

11、l model:1. The 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.2. It is easier to get customer feedback on the development work that has been done. Customers can com

12、ment on demonstrations of the software and see how much has been implemented. 3. More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and gain value from the software earlier than is possi

13、ble with a waterfall processProblems with Incremental developmentFrom a management perspective, the incremental approach has two problems:The process is not visible. Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce document

14、s that reflect every version of the system.1. 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

15、 costly.Reuse-oriented software engineeringThe system development process focuses on integrating existed components into a system rather than developing them from scratch.The intermediate stages in a reuse-oriented process are different. These stages are:1 Component analysis Given the requirements s

16、pecification, a search is made for components to implement that specification. 2 Requirements modification The requirements are analyzed using information about the components that have been discovered. 3 System design with reuse The framework of the system is designed or an existing framework is re

17、used.4 Development and integration Software that cannot be externally procured is developed, and the components and COTS(Commercial of-the-shelf systems) are integrated to create the new system.Reuse-oriented software engineeringThere are three types of software component that may be used in a reuse

18、-oriented process:1. Web services that are developed according to service standards and which are available for remote invocation.2. Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.3. Stand-alone software systems that are config

19、ured for use in a particular environment.Software componentsp Reuse-oriented software engineering has the obvious advantage of reducing the amount of software to be developed and so reducing cost and risks. p It usually also leads to faster delivery of the software. p Requirements compromises are in

20、evitable and this may lead to a system that does not meet the real needs of users.p 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.Pros and consThe four basic process activities of specification, deve

21、lopment, validation, and evolution are organized differently in different development processes.p In the waterfall model, they are organized in sequencep In incremental development they are interleaved. p These activities are carried out depends on the type of software, people, and organizational st

22、ructures involved.Process activitiesp Software specification or requirements engineering is the process of understanding and defining what services are required from the system and identifying the constraints on the systems operation and development.p Requirements engineering is a particularly criti

23、cal stage of the software process as errors at this stage inevitably lead to later problems in the system design and implementation.p The requirements engineering process aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements.p Requirements are us

24、ually 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.Software specificationRequirements engineering processThere are four main activities in the requirements engineering process:p

25、 Feasibility study An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies.p Requirements elicitation and analysis is the process of deriving the system requirements through observation of existing systems, discussions with potential

26、 users and procurers, task analysis, and so on.p Requirements specification is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. p Requirements validation This activity checks the requirements for realism, consistenc

27、y, and completeness.Requirements engineering processA 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.The implementation stage of softw

28、are development is the process of converting a system specification into an executable system.Software design and implementationA general model of the design processA general model of the design processThe diagram suggests that the stages of the design process are sequential. In fact, design process

29、 activities are interleaved. Four activities that may be part of the design process for information systems:p Architectural design, where you identify the overall structure of the system, the principal components (sub-systems or modules), their relationships, and how they are distributed.p Interface

30、 design, where you define the interfaces between system components.p Component design, where you take each system component and design how it will operate.p Database design, where you design the system data structures and how these are to be represented in a database.2.2.3 Software validationSoftwar

31、e validation or, more generally, verification and validation (V&V) is intended to show that a system both conforms to its specification and that it meets the expectations of the system customer. The stages in the testing process are:p Development testing The components making up the system are teste

32、d by the people developing the system.p System testing System components are integrated to create a complete system.p Acceptance testing This is the final stage in the testing process before the system is accepted for operational use.2.2.4 Software evolutionThe flexibility of software systems is one

33、 of the main reasons why more and more software is being incorporated in large, complex systems.Historically, there has always been a split between the process of software development and the process of software evolutionNow it is more realistic to think of software engineering as an evolutionary pr

34、ocess where software is continually changed over its lifetime in response to changing requirements and customer needs.2.3 Coping with changep Change is inevitable in all large software projects. p The system requirements change as the business procuring the system responds to external pressures and

35、management priorities change. p As new technologies become available, new design and implementation possibilities emerge. Therefore whatever software process model is used, it is essential that it can accommodate changes to the software being developed.2.3 Coping with changeThere are two ways of cop

36、ing with change and changing system requirements:p System prototyping, where a version of the system or part of the system is developed quickly to check the customers requirements and the feasibility of some design decisions.p Incremental delivery, where system increments are delivered to the custom

37、er for comment and experimentation.The process of prototype developmentIncremental deliveryAdvantages of incremental delivery1. Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments. 2. Customers do not have to wait until

38、 the entire system is delivered before they can gain value from it.3. The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system.4. As the highest-priority services are delivered first and increments then integrated, the

39、most important system services receive the most testing. Problems with incremental deliveryp Most systems require a set of basic facilities that are used by different parts of the system. It can be hard to identify common facilities that are needed by all increments.p Iterative development can also

40、be difficult when a replacement system is being developed. Getting useful customer feedback is difficult.p The essence of iterative processes is that the specification is developed in conjunction with the software. However, this conflicts with the procurement model of many organizations, where the c

41、omplete system specification is part of the system development contract.2.3.3 Boehms spiral modelA risk-driven software process framework (the spiral model) was proposed by Boehm (1988).Boehms spiral modelEach loop in the spiral is split into four sectors：Objective setting Specific objectives for th

42、at phase of the project are defined.Risk assessment and reduction For each of the identified project risks, a detailed analysis is carried out.Development and validation After risk evaluation, a development model for the system is chosen.1. Planning The project is reviewed and a decision made whethe

43、r to continue with a further loop of the spiral.2.4 The rational unified processThe Rational Unified Process (RUP) is an example of a modern process model that has been derived from work on the UML and the associated Unified Software Development ProcessThe RUP recognizes that conventional process mo

44、dels present a single view of the process. In contrast, the RUP is normally described from three perspectives:A dynamic perspective, which shows the phases of the model over time.A static perspective, which shows the process activities that are enacted.1. A practice perspective, which suggests good

45、practices to be used during the process.Phases in RUPInception: Establish a business case for the system.Elaboration: Develop an understanding of the problem domain, establish an architectural framework for the system, develop the project plan, and identify key project risks.Construction: Involves s

46、ystem design, programming, and testing.Transition: Moving the system from the development community to the user community and making it work in a real environment.Static workflows in the RUPWorkflowDescriptionBusiness modellingThe business processes are modelled using business use cases.Requirements

47、Actors who interact with the system are identified and use cases are developed to model the system requirements.Analysis and designA design model is created and documented using architectural models, component models, object models and sequence models.ImplementationThe components in the system are i

48、mplemented and structured into implementation sub-systems. Automatic code generation from design models helps accelerate this process.TestingTesting is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation.DeploymentA

49、 product release is created, distributed to users and installed in their workplace.Configuration and change managementThis supporting workflow managed changes to the systemProject managementThis supporting workflow manages the system development.EnvironmentThis workflow is concerned with making appr

50、opriate software tools available to the software development team.Six fundamental best practices1 Develop software iteratively Plan increments of the system based on customer priorities and develop the highest-priority system features early in the development process.2. Manage requirements Explicitl

51、y document the customers requirements and keep track of changes to these requirements. 3. Use component-based architectures Structure the system architecture into components.4. Visually model software Use graphical UML models to present static and dynamic views of the software.5. Verify software qua

52、lity Ensure that the software meets the organizational quality Standards6 Control changes to software Manage changes to the software using a change management system and configuration management procedures and tools.Key points(1)p Software processes are the activities involved in producing a softwar

53、e system. Software process models are abstract representations of these processes.p General process models describe the organization of software processes. Examples models include the waterfall model, incremental development, and reuse-oriented development.p Requirements engineering is the process o

54、f developing software specifications which are intended to communicate the system needs of the customer to the system developers.p Design and implementation processes are concerned with transforming a requirements specification into an executable software system. Systematic design methods may be use

55、d as part of this transformation.Key points(2)p Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.p Software evolution takes place when you change existing software systems to meet new requirements

56、. Changes are continuous and the software must evolve to remain useful.p Processes should include activities to cope with change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design. Processes may be structured for iterative development and delivery.p The

57、Rational Unified Process is a modern generic process model that is organized into phases (inception, elaboration, construction, and transition) but separates activities (requirements, analysis, and design, etc.) from these phases.Exercises (1)1. 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:A system to control anti-lock braking in a carA virtual reality syste