The themes emphasized in this book

The themes emphasized in this book

The nine general themes discussed below are emphasized through many of the chapters in this book. They represent general principles or unifying approaches that can be used in any software project.

understanding the customer and user

Interaction with customers and users should occur in virtually all of the software engineering activities discussed in the previous section. These two groups of stakeholders are most heavily involved in requirements analysis, user interface design and deployment, but also may play a role in design, quality assurance and project management.

If software engineers can learn how users and customers think and behave, then it will be easier to produce software that meets their needs. Ensuring that they feel involved in the software engineering process will result in fewer mistakes being made and greater acceptance of the finished product

basing development on solid principles and reusable technology

A fundamental tenet of engineering is that once techniques or technology become well established, their use should become routine. Civil engineers, for example, have a well-established set of principles, which they use to decide what kind of bridge to build. They also have standard bridge designs that they adapt for most routine bridge projects.

Even though software engineering is still a maturing discipline, many principles have become well established. We discuss these principles throughout the book.

As for technology, we base our designs on Java, a language with wide acceptance. Furthermore, in Chapter 3 we present a framework – a collection of classes that forms the basic structure upon which many different applications can be built. We demonstrate how this framework can be used to rapidly build several different applications.

Applying well-understood principles and reusing designs means that we are building on the experience and work of others, rather than ‘reinventing the wheel’. The creative task of the engineer is to put knowledge to use in innovative ways to solve problems. This contrasts with the role of the scientist, which is to seek out new knowledge.

object orientation

Object-oriented (OO) techniques are based on the use of classes that act as abstractions of data, and that contain a set of procedures which act on that data. It is now widely recognized that object orientation is an effective design approach to manage the complexity inherent in most large systems.

In this book we discuss three major areas of software engineering in an object- oriented context: analysis, design and programming. In , we review basic OO principles and OO programming; then, in the rest of the book, we approach analysis and design from a primarily OO perspective. We will ask you to implement your designs in the OO language Java, so that you can see the consequences of your design decisions.

visual modeling using UML

The Unified Modeling Language (UML) is a set of notations for representing software requirements and design. It is now widely accepted as the standard approach to representing many aspects of software.

We will teach you in some detail how to use several different aspects of UML, including class diagrams 

evaluation of alternatives in requirements and design

There is rarely a single straightforward answer to any problem in software engineering. Whether you are developing requirements or performing design,there are often several alternatives that must be assessed systematically to decide which is best.In both requirements analysis and design we will encourage you to list alternatives, and discuss their advantages and disadvantages before making a decision. We will also encourage you to document your reasoning, frequently called rationale, so that others can understand your decisions.

incorporating quantitative and logical thinking

It is becoming increasingly necessary to incorporate mathematical thinking into software development. We will present basic ways to measure aspects of software systems and software engineering processes. The objective of doing this measurement is to help make predictions of development time and quality in order to better control these factors. This topic, 

We will also show several ways to make use of logic in order to develop software: in  we will introduce OCL, a language for formally describing properties of designs; and in Chapter 9 we will show how logic can be used in a technique called defensive programming.

incorporating quantitative and logical thinking

It is becoming increasingly necessary to incorporate mathematical thinking into software development. We will present basic ways to measure aspects of software systems and software engineering processes. The objective of doing this measurement is to help make predictions of development time and quality in order to better control these factors. This topic, 

We will also show several ways to make use of logic in order to develop software:inwe will introduce OCL, a language for formally describing properties of designs; and in we will show how logic can be used in a technique called defensive programming.

: iterative and agile development

Traditionally, software engineering has been performed following what is called the waterfall model. In this approach you first develop requirements; once these are complete you move on to design, and then to programming, testing and deployment. An outdated view held that you should completely finish each of these steps before moving on to the next; then, when you complete deployment, you are finished. In contrast, the currently accepted view is that software engineering is, and should be, a highly iterative process. So-called agile techniques are the most highly iterative of all (see the sidebar ‘Agile versus conventional development’ earlier in this chapter).

It is typical to develop the first iteration of a system as a prototype, with only rough requirements and little functionality. Doing this serves to help establish the requirements for the next iteration. Several iterations of prototypes may be needed before the stakeholders are finally satisfied with the requirements, at which time you can proceed with a more rigorous process involving more complete specification and design.

Even after delivering software to customers, you typically continue to build a series of new releases, each one involving most of the activities discussed in terative development results in delivering smaller units of work (prototypes or releases) quite frequently. This means that the first release can be in the customers’ hands earlier than if you had tried to develop a fully fledged system. It also means that if the system turns out to be a disaster, less work has been wasted.

communicating effectively using documentation

Software engineers communicate with each other orally both in meetings and at each other’s desks; however, it would never be possible to run a large project if all information had to be conveyed in this manner.

<!--[if !mso]-->

<!--[endif]--> Agile documentation Agile developers prefer to write very little documentation. Some would prefer that anything that needs documenting be put in code comments and nowhere else. <!--[if !mso]-->

<!--[endif]--> Writing clear documentation is therefore an essential skill. Documentation should be written at all stages of development and includes requirements, designs, user manuals, instructions for testers and project plans. One of the keys to writing good documentation is to understand the audience. You must provide the information the readers will need, and organize it in such a way that the readers can find it easily. For example, the audience for design documentation includes other software engineers with whom you are currently working, as well as those who will need to make changes later. Both groups need to understand what you did and why you did it.

Unfortunately, unless it is managed appropriately, writing documentation can waste resources and can be a source of rigidity in software development. The waste of resources can occur if documentation is never read – this will be the case if it is excessively voluminous, poorly written or not made readily available. Excessive documentation means that the readers cannot find what they want easily, and ‘can’t find the forest for the trees’. It is therefore as bad as if you had not created enough documentation to start with.

Forcing software developers to write documents prematurely just to meet specific deadlines can mean that the overall objective becomes writing documents, instead of solving problems. Furthermore, such documents can entrench poorly made decisions that are hard to change.

In this book, we will encourage you to write documentation but we will emphasize that it should be as short and succinct as possible, and it should serve the purpose of documenting your decisions and communicating them to others. Furthermore, documentation should be written in the context of risk management, discussed below, which means that it is always subject to change. We will give you outlines of each type of document as well as several example documents. You will have the opportunity to practice writing the documents and also reviewing them in groups. When writing documentation you should also be aware that there are often standards that you should adhere to. It is important that documentation used within a company have a standard format so that people can more easily use it.

risk management in all software engineering activities

Whereas documentation allows future readers to keep an eye on the past, we must also constantly keep an eye on the future. Risk analysis is a key software engineering activity in which we constantly assess any new information to determine whether it will cause problems for the project. If you believe there is a significant risk that a certain type of problem will arise, then you can take steps to reduce the risk.

Software is an investment that should provide benefits; and risks are natural in any investment. The objective must be to reduce risks to acceptable levels, while still achieving the benefits. Taking action to reduce risks is like adjusting your investment portfolio. Sometimes you put more effort into certain tasks to ensure the project is completed successfully; at other times you must cut parts of the system to avoid losses.

The last numbered section of every chapter will discuss the difficulties and risks to be considered in the material covered by that chapter. In the next section we begin this process by reviewing the most important risks in software engineering.