Notes of Software Engineering Ninth Edition（软件工程第九版笔记）

Chapter 1 Introduction

OBJECTIVES

The objectives of this chapter are to introduce software engineering and to provide a framework for understanding the rest of the book. When you have read this chapter you will:

Understand what software engineering is and why it is important.Understand that the development of different types of software systems may require different software engineering techniques.
Understand some ethical and professional issues that are important for software engineers. Have been introduced to three systems, of different types, that will be used as examples throughout the book.

KEY POINTS

Software engineering is an engineering discipline that is concerned with all aspects of software production.
Software is not just a program or programs but also includes documentation. Essential software product attributes are maintainability, dependability, security, efficiency, and acceptability.
The software process includes all of the activities involved in software development. The high level activities of specification, development, validation, and evolution are part of all software processes.
The fundamental notions of software engineering are universally applicable to all types of system development. These fundamentals include software processes, dependability, security, requirements, and reuse.
There are many different types of systems and each each requires appropriate software engineering tools and techniques for their requirement. Three are few, if any, specific design and implementation techniques that are applicable to all kinds of systems.
Software engineers have responsibility to the engineering profession and society. They should not simply be covered with technical issues.
Professional societies publish codes of conduct that set out the standards of behavior expected of their members.

Chapter 2 Software Processes Objectives

OBJECTIVES

The objective of this chapter is to introduce you to the idea of a software process - a coherent set of activities for software production. When have read this chapter you will:

Understand the concepts of software processes and software process models.
Have been introduced to three generic software models and when they might be used.
Know about the fundamental process activities of software requirements engineering, software development, testing and evolution.
Understand why processes should be organized to cope with changes in the software requirements and design.
Understand how the Rational Unified Process integrates good software engineering practice to create adaptable software process.

KEY POINTS

Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.
General process models describe the organization of software processes. Examples of these general models include the waterfall model, incremental development, and reuse-oriented development.
Requirements engineering is the process of developing a software specification. Specifications are intended to communicate the system needs of the customer to the system developers.
Design and implementation processes are concerned with transforming a requirements specification into an executable software system. Systematic design methods may be used as part of this transformation.
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.
Software evolution takes place when you change existing software systems to meet new requirements. Changes are continuous and the software must evolve to remain useful.
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 so that changes may be made without disrupting the system as a whole.
The Rational Unified Process is a modern generic process model that is organized into phase (inception, elaboration, construction, and transition) but separated activities (requirements, analysis, and design, etc.) from these phases.

Chapter 3 Agile Software Development

OBJECTIVES

Understand the rationale for agile software development methods, the agile manifesto, and the differences between agile and plan-driven development.
Know the key practices in extreme programming and how these relate to the general principles of agile methods.
Understand the Scrum approach to agile project management.
Be aware of the issues and problems of scaling agile development methods to the development of large software systems.

KEY POINTS

Agile methods are incremental development methods that focus on rapid development, frequent releases of the software, reducing process overhead, and producing high-quality code. They involve the customer directly in the development process.
The decision on whether to use an agile or a plan-driven approach to development should depend on the type of software being developed, the capabilities of the development team, and the culture of the company developing the system.
Extreme programming is a well-know agile method that integrates a range of good programming practices such as frequent releases of the software, continuous software improvement, and customer participation in the development team.
A particular strength of extreme programming is the development of automated tests before a program feature is created. All tests must successfully execute when an increment is integrated into a system.
The Scrum method is an agile method that provides a project management framework. It is centered around a set of sprint, which are fixed time periods when a system increment is developed. Planning is based on prioritizing a backlog of work and selecting the highest priority tasks for a sprint.
Scaling agile methods for large systems is difficult. Large systems need up-front design and some documentation. Continuous integration is practically impossible when there are several separate development teams working on a project.

Chapter 4 Requirements Engineering

OBJECTIVES

Understand the concept of user and system requirements and why these requirements should be written in different way.
Understand the difference between functional and non-functional software requirements.
Understand how requirements may be organized in a software requirements document.
Understand the principal requirements engineering activities of elicitation, analysis and validation, and the relationship between these activities.
Understand why requirements management is necessary and how it supports other requirements engineering activities.

KEY POINTS

Requirements for a software system set out what the system should do and define constraints on its operation and implementation.
Functional requirements are statement of the services that the system must provide or are descriptions of how some computations must be carried out.
Non-functional requirements often constrain the system being developed and the development process being used. These might be product requirements, organizational requirements, or external requirements. They often relate to the emergent properties of the system and therefore apply to the system as a whole.
The software requirements document is an agreed statement of the system requirements. It should be organized so that both system customers and software developer can use it.
The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification, requirements validation, and requirements management.
Requirements elicitation and analysis is an iterative process that can be represented as a spiral of activities --- requirements discovery, requirements classification and organization, requirements negotiation, and requirements documentation.
Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism, and verifiability.
Business, organizational, and technical changes inevitably lead to changes to the requirements for a software system. Requirements management is the process managing and controlling these changes.

Chapter 5 System Modeling

OBJECTIVES

This aim of this chapter is to introduce some types of system model that may be developed as part of the requirements engineering and system design processes. When you have read the chapter, you will:

Understand how graphical models can be used to represent software systems.
Understand why different types of model are required and the fundamental system modeling perspectives of context, interaction, structure, and behavior.
Have been introduced to some of the diagram types in the Unified Modeling Language (UML) and how these diagrams may be used in system modeling.
Be aware of the ideas underlying model-driven engineering, where system is automatically generated from structural and behavioral models.

KEY POINTS

A model is an abstract view of a system that ignores some system detailed. Complementary models can be developed to show the systems' context, interactions, structure, and behavior.
Context models show how a system that is being modeled is positioned in an environment with other systems and processes. They help define the boundaries of the system to be developed.
Use case diagrams and sequence diagram are used to describe the interactions between user the system being designed and users/other systems. User cases describe interactions between system and external actors; sequence diagrams add more information to these by showing interactions between system objectives.
Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations.
Behavioral models are used to describe the dynamic behavior of an executing system. This can be modeled from the perspective of the data processed by the system or by the events that stimulate responses from a system.
Activity diagrams may be used to model the processing of data, where each activity represents one process step.
State diagrams are used to model a systems' behavior in response to internal or external events.
Model-driven engineering is an approach to software development in which a system is represented as a set of models that can be automatically transformed to executable code.

Chapter 6 Architectural Design

OBJECTIVES

The objective of this chapter is to introduce the concepts of software architecture and architectural design. When you have read the chapter, you will:

Understand why the architectural design is important.
Understand the decisions that have to be made about the system architecture during the architectural design process.
Have been introduced to the idea of architectural patterns, well-tried ways of organizing system architectures, which can be reused in system designs.
Know the architectural patterns that are often used in different types of application system, including transaction processing systems and language processing systems.

KEY POINTS

A software architecture is a description of how a software system is organized. Properties of a system such as performance, security, and availability are influenced by the architecture.
Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used, and the ways in which the architecture should be documented and evaluated.
Architectures may be documented from several different perspectives or views. Possible views include a conceptual view, a logical view, a process view, a development view, and a physical view.
Architectural patterns are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used, and discuss its advantages and disadvantages.
Commonly used architectural patterns include Model-View-Controller, Layer Architecture, Repository, Client-server, and Pipe and Filter.
Generic models of application systems architectures help us understand the operation of applications, compare applications of the same type, validate application system designs, and assess large-scale components for reuse.
Transaction processing systems are interactive systems that allow information in a database to be remotely accessed and modified by a number of users. Information systems and resource management systems are examples of transaction processing systems.
Language processing systems are used to translate texts from one language into another and to carry out the instructions specified in the input language. They include a translator and an abstract machine that executes the generated language.

Chapter 7 Design and Implementation

OBJECTIVES

The objectives of this chapter are to introduce object-oriented software design using the UML and highlight implementation concerns. When you have read this chapter, you will:

Understand the most important activities in a general, object-oriented design process.
Understand some of the different models that may be used in document an object-oriented design.
Know about the idea of design patterns and how these are a way of reusing design knowledge and experience.
Have been introduced to key issues that have to be considered when implementing software, including software reuse and open-source development.

KEY POINTS

Software design and implementation are interleaved activities. The level of detail in the design depends on the type of system being developed and whether you are using a plan-driven or agile approach.
The process of object-oriented design includes activities to design the system architecture, identify objects in the system, described the design using different object models, and document the component interfaces.
A range of different models may be produced during an object-oriented design process. These include static models (class models, generation models, association models) and dynamic models (sequence models, state machine models).
Component interface must be defined precisely so that other objects can use them. A UML interface stereotype may be used to define interfaces.
When developing software, you should always consider the possibility of reusing existing software, either as components, services, or complete systems.
Configuration management is the process of managing changes to an evolving software system. It is essential when a team of people are cooperating to develop software.
Most software development is host-target development. You use an IDE on a host machine to develop the software, which is transferred to a target machine of execution.
Open source development involves making the source code of a system public available. This means that many people can propose changes and improvements to the software.

Chapter 8 Software Testing

OBJECTIVES

The objective of this chapter is to introduce software testing and software testing processes. When you have read this chapter, you will:

Understand the stages of testing, during development to acceptance testing by system customers;
Have been introduced to techniques that help you choose test cases that are geared to discovering program defects;
Understand test-first development, where you design tests before writing code and run these tests automatically;
Know the important difference between component, system, and release testing and be aware of user testing processes and techniques.

KEY POINTS

Testing can only show the presence of errors in a program. It can not demonstrate that there are no remaining faults.
Development testing is the responsibility of the software development team. A separate team should be responsible for testing a system before it is released to customers. In the user testing process, customers or system users provide test data and check that tests are successful.
Development testing includes unit testing, in which you test individual objects and methods; component testing, in which you test related groups of objects; and system testing, in which you test partial or complete systems.
When testing software, you should try to "break" the software by using experience and guidelines to choose types of test cases that have been effective in discovering defects in other system.
Wherever possible, you should write automated tests. The tests are embedded in a program that can be run every time a change is made to a system.
Test-first development is an approach to development where tests are written before the code to be tested. Small code changes are made and the code is refactored until all tests execute successfully.
Scenario testing is useful because it replicates that practical use of the system. It involves inventing a typical usage scenario and using this to derived test cases.
Acceptance testing is a user testing process where the aim is to decide if the software is good enough to be deployed and used in its operational environment.

Chapter 9 Software Evolution

OBJECTIVES

Understand that change is inevitable if software systems are to remain useful and that software development and evolution may be integrated in a spiral model.
Understand software evolution processes and influences on these processes.
Have learned about different types of software maintenance and the factors that affect maintenance costs.
Understand how legacy systems can be assessed to decide whether they should be scrapped, maintained, reengineered, or related.

KEY POINTS

Software development and evolution can be thought of as an integrated, iterative process that can be represented using a spiral model.
For custom systems, the costs of software maintenance usually exceed the software development costs.
The process of software evolution is driven by requests for changes and includes change impact analysis, release planning, and change implementation.
Lehman's law, such as the notion that change is continuous, describe a number of insights derived from long-term studies of system evolution.
There are three types of software maintenance, namely bug fixing, modifying the software to work in a new environment, and implementing new or changed requirements.
Software reengineering is concerned with restructuring and re-documenting software to make it easier to understand and change.
Refactoring, making small program changes that preserve functionality, can be thought of as preventative maintenance.
The business value of a legacy system and the quality of the application software and its environment should be assessed to determine whether the system should be replaced, transformed, or maintained.

Chapter 10 Socio-technical Systems

OBJECTIVES

Know what is meant by a socio-technical system and understand the difference between a technical, computer-based system and a socio-technical system.
Have been introduced to the concept of emergent system properties, such as reliability, performance, safety, and security.
Know about the procurement, development, and operational activities that are involved in the systems engineering process.
Understand why software dependability and security should not be considered in isolation and how they are affected by systems issues, such as operator errors.

KEY POINTS

Socio-technical system include computer hardware, software, and people, and are situated within an organization . They are designed to support organizational or business goals and objectives.
Human and organizational factors such as organizational structure and politics have a significant effect on the operation of socio-technical systems.
The emergent properties of a system are characteristics of the system as a whole rather than of its component parts. They include properties such as performance, reliability, usability, safety, and security. The success or failure of a system is often dependent on these emergent properties.
The fundamental systems engineering processes are system procurement, system development, and system operation.
System procurement covers all of the activities involved in deciding what a system to buy and who should supply that system. High-level requirements are developed as part of the procurement process.
System development includes requirements specification, design, construction, integration, and testing. System integration, where subsystems from more than one supplier must be made to work together, is particularly critical.
When a system is put into use, the operational processes and the system itself have to change to reflect changing business requirements.
Human errors are inevitable and systems should include barriers to detect these errors before they lead to system failure. Reason's Swiss cheese model explains how human error plus latent defects in the barriers can lead to system failure.

Chapter 11 Dependability and Security

OBJECTIVES

Understand why dependability and security are usually more important than the functional characteristics of a software system.

Understand the four principles dimensions of dependability, namely availability, reliability, safety, and security.
Be aware of the specialized terminology that is used when discussing security and dependability.
Understand that to achieve secure, dependable software, you need to avoid mistakes during the development of a system, to detect and remove errors when the system is in use, and to limit the damage caused by operational failures.

KEY POINTS

Failure of critical computer systems can lead to large economic losses, serious information loss, physical damage, or threats to human life.
The dependability of a computer system is a system property that reflects the user's degree of trust in the system. The most important dimensions of dependability are availability, reliability, safety, and security.
The availability of a system is the probability that the system will be able to deliver services to its users when requested to do so. Reliability is the probability that system services will be delivered as specified.
Perceived reliability is related to the probability of an error occurring in operational use. A program may contain known faults but may still be experienced as reliable by its users. They may never use features of the system that are affected by the faults.
The safety of a system is a system attribute that reflects the system's ability to operate, normally or abnormally, without injury to people or damage to the environment.
Security reflects the ability of a system to protect itself against external attacks. Security failures may lead to loss of availability, damage to the system or its data, or the leakage of information to unauthorized people.
Without a reasonable level of security, the availability, reliability, and safety of the system may be compromised if external attacks damage the system. If a system is unreliable, it is difficult to ensure system safety or security, as they may be compromised by system failures.

Chapter 12 Dependability and Security Specification

OBJECTIVES

Understand how a risk-driven approach can be used for identifying and analyzing safety, reliability, and security requirements.
Understand how fault trees can be used to help analyze risks and derive safety requirements.
Have been introduced to metrics for reliability specification and how these are used to specify measurable reliability requirements.
Know the different types of security requirements that may be required in a complex system.
Be aware of the advantages and disadvantages of using informal, mathematical specifications of a system.

KEY POINTS

Risk analysis is an important activity in the specification of security and dependability requirements. It involves identifying risks that can result in accidents or incidents. System requirements are then generated to ensure that these risks do not occur and, if they do, that they do not lead to an incident or accident.
A hazard-driven approach may be used to understand the safety requirements for a system. You identify potential hazards and decompose these to discover their root causes. You then specify requirements to avoid or recover from these problems.
Reliability requirements can be defined quantitatively in the system requirements specification. Reliability metrics include probability of failure on demand, rate of occurrence of failure, and availability.
It is important not to over-specify the required system reliability as this leads to unnecessary additional costs in the development and validation processes.
Security requirements are more difficult to identify than safety requirements because a system attacker can use knowledge of system vulnerability to plan a system attack, and can learn about vulnerabilities from unsuccessful attacks.
To specify security requirements, you should identify the assets that are to be protected and define how security techniques and technology should be used to protect these assets.
Formal methods of software development rely on a system specification that is expressed as a mathematical model. Developing a formal specification has the key benefit of simulating a detailed examination and analysis of the system requirements.

Chapter 13 Dependability Engineering

OBJECTIVES

Understand how system dependability can be achieved by using redundant and diverse components.
Know how dependable software processes contribute to the development of dependable software.
Understand how different architectural styles may be used to implement software redundancy and diversity.
Be aware of good programming practice that should be used in dependable systems engineering.

KEY POINTS

Dependability in a program can be achieved by avoiding the introduction of faults, by detecting and removing faults before system deployment, and by including fault-tolerance facilities that allow the system to remain operational after a fault has caused a system failure.
The use of redundancy and diversity in hardware, software processes, and software systems is essential to the development of dependable systems.
The use of well-defined, repeatable process is essential if faults in a system are to be minimized. The process should include verification and validation activities at all stages, from requirements definition through to system implementation.
Dependable system architectures are system architectures that are designed for fault to tolerance. There are a number of architectural styles that support fault tolerance including protection systems, self-monitoring architectures, and N-version programming.
Software diversity is difficult to achieve because it is practically impossible to ensure that each version of the software is truly independent.
Dependable programming relies on the inclusion of redundancy in a program to check the validity of inputs and the values of program variables.
Some programming constructs and techniques, such as go-to statements, recursion, inheritance, and floating-point numbers, are inherently error prone. You should try to avoid these constructs when developing dependable systems.

Chapter 14 Security Engineering

OBJECTIVES

Understand the difference between application security and infrastructure security.
Know how life-cycle risk assessment and operational risk assessment are used to understand security issues that affect a system design.
Be aware of software architectures and design guidelines for secure systems development.
Understand the notion of system survivability analysis is important for complex software systems.

KEY POINTS

Security engineering focuses on how to develop and maintain software systems that can resist malicious attacks intended to damage a computer-based system or its data.
Security threats can be threats to the confidentiality, integrity, or availability of a system or its data.
Security risk management involves assessing the losses that might ensure from attacks on a system, and deriving security requirements that are aimed at eliminating or reducing these losses.
Design for security involves designing a secure system architecture, following good practice for secure systems design, and including functionality to minimize the possibility of introducing vulnerabilities when the system is deployed.
Key issues when designing a secure systems architecture include organizing the system structure to protect key assets and distributing the system assets to minimize the losses from a successful attack.
Security design guidelines sensitize system designers to security issues that they may not have considered. They provide a basis for creating security review checklists.
To support secure deployment you should provide a way of displaying and analyzing system configurations, localizing configuration settings so that important configurations are not forgotten, minimize default privileges assigned to system users, and provide ways to repair security vulnerabilities.
System survivability reflects the ability of a system to continue to deliver essential business or mission-critical services to legitimate users while it is under attack, or after part of the system has been damaged.

Chapter 15 Dependability and Security Assurance

OBJECTIVES

Understand how different approaches to static analysis may be used in the verification of critical software systems.
Understand the basics of reliability and security testing and the inherent problems of testing critical systems.
Know why process assurance is important, especially for software that has to be certified by a regulator.
Have been introduced to safety and dependability cases that present arguments and evidence of system safety and dependability.

KEY POINTS

Static analysis is an approach to V&V that examines the source code (or other representation) of a system, looking for errors and anomalies. It allows all part of a program to be checked, not just those parts that are exercised by system sets.
Model checking is a formal approach to static analysis that exhaustively checks all states in a system for potential errors.
Statistical testing is used to estimate software reliability. It relies on testing the system with a test data set that reflects the operational profile of the software. Test data may be generated automatically.
Security validation is difficult because security requirements state what should not happen in a system, rather than what should. Furthermore, system attackers are intelligent and may have more time to probe for weakness than is available for security testing.
Security validation may be carried out using experience-based analysis, tool-based analysis, or "tiger teams" that simulate attacks on a system.
It is important to have a well-defined, certified process for safety-critical systems development. The process must include the identification and monitoring of potential hazards.
Safety and dependability cases collect all of the evidence that demonstrates a system is safe and dependable. Safety cases are required when an external regulator much certify the system before it is used.
Safety cases are usually based on structured arguments. Structures safety arguments show that an identified hazardous condition can never occur by considering all program paths that lead to an unsafe condition, and showing that the condition cannot hold.

Chapter 16 Software Reuse

OBJECTIVES

Understand the benefits and problems of reusing software when developing new systems.
Understand the concept of an application framework as a set of reusable objects and how frameworks can be used in application development.
Have been introduced to software product lines, which are made up of a common core architecture and configurable, reusable components.
Have learned how systems can be developed by configuring and composing off-the-shelf application software systems.

KEY POINTS

Most new business software systems are now developed by reusing knowledge and code from previously implemented systems.
There are many different ways to reuse software. These range from the reuse of classes and methods in libraries to the reuse of complete application systems.
The advantages of software reuse of lower costs, faster software development, and lower risks. System dependability is increased. Specialists can be used more effectively by concentrating their expertise on the design of reusable components.
Application frameworks are collections of concrete and abstract objects that are designed for reuse through specialized and the addition of new objects. They usually incorporate good design practice through design patterns.
Software product lines are related applications that are developed from one or more base applications. A generic system is adapted and specialized to meet specific requirements for functionality, target platform, or operational configuration.
COTS product reuse is concerned with the reuse of large-scale, off-the-shelf systems. These provide a lot of functionality and their reuse can radically reduce costs and development time. Systems may be developed by configuring a single, generic COTS product or by integrating two or more COTS products.
Enterprise Resource Planning systems are examples of large-scale COTS reuse. You create an instance of an ERP system by configuring a generic system with information about the customer's business processes and rules.
Potential problems with COTS-based reuse include lack of control over functionality and performance, lack of control over system evolution, the need for support form external vendors, and difficulties in ensuring that systems can interoperate.

Chapter 17 Component-based Software Engineering

OBJECTIVES

Know that component-based software engineering is concerned with developing standardized components based on a component model, and composing these into application systems.
Understand what is meant by a component and a component model.
Know the principal activities in the CBSE process for reuse and the CBSE process with reuse.
Understand some of the difficulties and problems that arise during the process of component composition.

KEY POINTS

Component-based software engineering is a reuse-based approach to defining, implementing, and composing loosely coupled independent components into systems.
A component is a software unit whose functionality and dependencies are completely defined by a set of public interfaces. Components can be composed with other components without knowledge or their implementation and can be deployed as an executable unit.
Components may be implemented as program units that are included in a system or as external services that are referenced from within a system.
A component model defines a set of standards for components, including interface standards, usage standards, and deployment standards. The implementation of the component model provides a set of common services that may be used by all components.
During the CBSE process, you have to interleave the processes of requirements engineering and system design. You have to trade off desirable requirements against the services that are available from existing reusable components.
Component composition is the process of 'wiring' components together to create a system. Types of composition include sequential composing, hierarchical composition, and additive composition.
When composing reusable components that have not been written for you application, you may need to write adaptors or 'glue code' to reconcile the different component interfaces.
When choosing compositions, you have to consider the required functionality of the system, the non-functional requirements and the ease with which one component can be replaced when the system is changed.

Chapter 18 Distributed Software Engineering

OBJECTIVES

Know the key issue that have to be considered when designing and implementing distributed software systems.
Understand the client-server computing model and the layered architecture of client-server systems.
Have been introduced to commonly used patterns for distributed systems architectures and know the types of system for which each architecture is most applicable.
Understand the notion of software as a service, providing web-based access to remotely deployed application systems.

KEY POINTS

The benefits of distributed systems are that they can be scaled to cope with increasing demand, can continue to provide user services (even if some parts of the system fails), and they enable resources to be shared.
Issues to be considered in the design of distributed systems include transparency, openness, scalability, security, quality of service, and failure management.
Client-server systems are distributed systems in which the system is structured into layers, with the presentation layer implemented on a client computer. Servers provide data management, application, and database services.
Client-server systems may have several tiers, with different layers of the system distributed to different computers.
Architectural patterns for distributed systems include master-slave architectures, two-tier and multi-tier client-server architectures, distributed component architectures, and peer-to-peer architectures.
Distributed component systems require middleware to handle component communications and to allow components to be added to and removed from the system.
Peer-to-peer architectures are decentralized architectures in which there are no distinguished clients and servers. Computations can be distributed over many systems in different organizations.
Software as a service is a way of deploying applications as thin client-server systems, where the client is a web browser.

Chapter 19 Service-oriented Architecture

OBJECTIVES

Understand the basic notions of a web service, web service standards, and service-oriented architecture.
Understand the service engineering process that is intended to produce reusable web services.
Have been introduced to the notion of service composition as a means of service-oriented application development.
Understand how business process models may be used as a basis for the design of service-oriented systems.

KEY POINTS

Service-oriented architecture is an approach to software engineering where reusable, standardized services are the basic building blocks for application systems.
Service interfaces may be defined in an XML-based language called WSDL. A WSDL specification includes a definition of the interface types and operations, the building protocol used by the service and the service location.
Services may be classified as utility services that provide a general-purpose functionality, business services that implement part of a business process, or coordination services that coordinate the execution of other services.
The service engineering process involves identifying candidate services for implementation, defining the service interface and implementing, and testing and deploying the service.
Service interfaces may be defined for legacy software systems that continue to be useful for an organization. The functionality of the legacy system may then be reused in other applications.
The development of software using services is based around the idea that programs are created by composing and configuring services to create new composite services.
Business process models define the activities and information exchange that takes place in a business process. Activities in the business process may be implemented by services so that the business process model represents a service composition.

Chapter 20 Embedded System

OBJECTIVES

Understand the concept of embedded software, which is used to control systems that must react to external events in their environment.
Have been introduced to a design process for real-time systems, where the software systems are organized as a set of cooperating processes.
Understand three architectural patterns that are commonly used in embedded real-time systems design.
Understand the organization of real-time operating systems and the role that they play in an embedded, real-time system.

KEY POINTS

An embedded software system is part of a hardware/software system that react to events in its environment. The software is 'embedded' in the hardware. Embedded systems are normally real-time systems.
A real-time system is a software system that must respond to events in real time. System correctness does not just depend on the results it produces, but also on the time when these results are produced.
Real-time systems are usually implemented as a set of communicating processing that react to stimuli to produce responses.
State models are an important design representation for embedded for embedded real-time systems. They are used to show the system reacts to its environment as events trigger changes of state in the system.
There are several standard patterns that can be observed in different types of embedded systems. These include a pattern for monitoring the system's environment for adverse events, a pattern for actuator control and a data-processing pattern.
Designers of real-time systems have to do a timing analysis, which is driven by the deadlines for processing and responding to stimuli. They have to decide how often each process in the system should run and the expected and worst-case execution time for processes.
A real-time operation system is responsible for process and resource management. It always includes a scheduler, which is the component responsible for deciding which process should be scheduled for execution.

Chapter 21 Aspect-oriented Software Engineering

OBJECTIVES

Understand why the separation of concerns is a good guiding principle for software development.
Have been introduced to the fundamental ideas underlying aspects and aspect-oriented software development.
Understand how an aspect-oriented approach may be used for requirements engineering, software design, and programming.
Be aware of the difficulties of testing aspect-oriented systems.

KEY POINTS

The main benefit of an aspect-oriented approach to software development is that it supports the separation of concerns. By representing cross-cutting concerns as aspects, individual concerns can be used, reused, and modified without changing other parts of the program.
Tangling occurs when a module in a system includes code that implements different system requirements. The related phenomenon of scattering occurs when the implementation of a single concerns is scattered across several components in a program.
Aspects include a point cut - a statement that defines where the aspect will be woven into the program, and advice - the code to implement the cross-cutting concern. Join points are the events that can be referenced in a point cut.
To ensure the separation of concerns, systems can be designed as a core system that implements the primary concerns of stakeholders, and a set of extensions that implement secondary concerns.
To identify concerns, you may use a viewpoint-oriented approach to requirements engineering to elicit stakeholder requirements and to identify cross-cutting quality of service and policy concerns.
The transition from requirements to design can be made by identifying use cases, where each use case represents a stakeholder concern. The design may be modeled using an extended version of the UML with aspect stereotypes.
The problems of inspecting and deriving tests for aspect-oriented programs are a significant barrier to the adoption of aspect-oriented software development in large software projects.

Chapter 22 Project Management

OBJECTIVES

Know the principle tasks of software project mangers.
Have been introduced to the notion of risk management and some of the risks of that can be arise in software projects.
Understand factors that influence personal motivation and what these might mean for software project managers.
Understand key issues that influence team working, such as team composition, organization, and communication.

KEY POINTS

Good software project management is essential if software engineering projects are to be developed on scheduled and within budget.
Software management is distinct from other engineering management. Software is intangible. Projects may be novel or innovative so there is no body of experience to guide their management. Software processes are not mature as traditional engineering processes.
Risk management involves identifying and assessing major project risks to establish the probability that they will occur and the consequences for the project if that risk does arise. You should make plans to avoid, manage, or deal with likely risks if or when they arise.
People are motivated by interaction with other people, the recognition of management and their peers, and by being given opportunities for personal development.
Software development groups should be fairly small and cohesive. The key factors that influence the effectiveness of a group are the people in that group, the way that it is organized, and the communication between group members.
Communications within a group are influenced by factors such as the status of group members, the size of the group, the gender composition of the group, personalities, and available communication channels.

Chapter 23 Project Planning

OBJECTIVES

Understand the fundamentals of software costing and reasons why the price of the software may not be directly related to its development cost.
Know what sections should be included in a project plan that is created within a plan-driven development process.
Understand what is involved in project scheduling and the use of bar charts to present a project schedule.
Have been introduced to the "planning game", which is used to support project planning in extreme programming.
Understand how the COCOMO II model can be used for algorithmic cost estimation.

KEY POINTS

The price charged for a system does not just depend on its estimated development costs and the profit required by the development company. Organizational factors may mean that the price is increased to compensate for increased or decreased to gain competitive advantage.
Software is often priced to gain a contract and the functionality of the system is then adjusted to meet the estimated price.
Plan-driven development is organized around a complete project plan that defines the project activities, the planned effort, the activity schedule, and who is responsible for each activity.
Project scheduling involves the creation of various graphical representations of part of the project plan. Bar charts, which show the activity duration and staffing timelines, are the most commonly used schedule representations.
A project milestone is a predictable outcome of an activity or set of activities. At each milestone, a formal report of progress should be presented to management. A deliverable is a work product that is delivered to the project customer.
The XP planning game involves the whole team in project planning. The plan is developed incrementally and, if problems arise, it is adjusted so that software functionality is reduced instead of delaying the delivery of an increment.
Estimation techniques for software may be experienced-based, where managers judge the effort required, or algorithmic, where the effort required is computed from other estimated project parameters.
The COCOMO II costing model is a mature algorithmic cost model that takes project, product, hardware, and personnel attributes into account when formulating a cost estimate.

Chapter 24 Quality Management

OBJECTIVES

Have been introduce to the quality management process and know why quality planning is important.
Understand that software quality is affected by the software development process used.
Be aware of the importance of standards in the quality management process and how standards are used in quality assurance.
Understand how reviews and inspections are used as a mechanism for software quality assurance.
Understand how measurement may be helpful in assessing some software quality attributes and the current limitations of software measurement.

KEY POINTS

Software quality management is concerned with ensuring that software has a low number of defects and that it reaches the required standards of maintainability, reliability, portability, and so on. It includes defining standards for processes and products and establishing processes to check that these standards have been followed.
Software standards are important for quality assurance as they represent an identification of 'best practice'. When developing software, standards provides a solid foundation for building good quality software.
You should document a set of quality assurance procedures in an organizational quality manual. This may be based on the generic model for a quality manual suggested in the ISO 9001.
Reviews of the software process deliverables involve a team of people who check that quality standards are being followed. Reviewers are the most widely used technique for assessing quality.
In a program inspection or peer review, a small team systematically checks the code. They read the code in detail and look for possible errors and omissions. The problems detected are then discussed at a code review meeting.
Software measurement can be used to gather quantitive data about software and the software process. You may be able to use the values of the software metrics that are collected to make inferences about product and process quality.
Product quality metrics are particularly useful for highlighting anomalous components that may have quality problems. These components should then be analyzed in more detail.

Chapter 25 Configuration Management

OBJECTIVES

Understand the processes and procedures in software change management.
Know the essential functionality that must be provided by a version management system, and the relationships between version version management and system building.
Understand the differences between a system version and a system release, and know the stages in the release management process.

KEY POINTS

Configuration management is the management of an evolving software system. When maintaining a system, a CM team is put in place to ensure that changes are incorporated into the system in a controlled way and that records are maintained with details of the changes that have been implemented.
The main configuration management processes are concerned with change management, version management, system building, and release management. Software tools are available to support all of these processes.
Change management involves assessing proposals for changes from system customers and other stakeholders and deciding if it is cost-effective to implement these in a new version of a system.
Version management involves keeping track of the different versions of software components that are created as changes are made to them.
System building is the process of assembling system components into an executable program to run on a target computer system.
Software should be frequently rebuilt and tested immediately after a new version has been built. This makes it easier to detect bugs and problems that have been introduced since the last build.
System releases include executable code, data files, configuration files, and documentation. Release management involves making decisions on system release dates, preparing all information for distribution, and documenting each system release.

Chapter 26 Process Improvement

OBJECTIVES

Understand the rational for software process improvement as a means of improving both product quality and the efficiency and effectiveness of software processes.
Understand the principles of software process improvement and the cyclic process improvement process.
Know how the Goal-Question-Metric approach may be used to guide process measurement.
Have been introduced to the idea of process capability and process maturity, and the general form of the SEI's CMMI model for process improvement.

KEY POINTS

The goals of process improvement are higher product quality, reduced process costs, and faster delivery of software.
The principal approaches to process improvement are agile approaches, geared to reducing process overheads, and maturity-based approaches based on better process management and the use of good software engineering practice.
The process improvement cycle involves process measurement, process analysis and modeling, process change.
Process models, which show the activities in a process and their relationships with software products, are used for process description. In practice, however, engineers involved in software development always adapt models to their local circumstances.
Measurement should be used to answer specific questions about the software process used. These question should be based on organizational improvement goals.
Three types of process metrics used in the measurement process are time metrics, resource utilization metrics, and event metrics.
The CMMI process maturity model is an integrated process improvement model that supports both staged and continuous process improvement.
Process improvement in the CMMI model is based on reaching a set of goals related to good software engineering practice and describing, standardizing, and controlling the practices used to achieving these goals. The CMMI model includes recommended practices that may be used, but these are not obligatory.