Schaum's Outline of Software Engineering

By David Gustafson

Tough Test Questions? Missed Lectures? Not Enough Time?

Fortunately for you, there's Schaum's Outlines. More than 40 million students have trusted Schaum's to help them succeed in the classroom and on exams. Schaum's is the key to faster learning and higher grades in every subject. Each Outline presents all the essential course information in an easy-to-follow, topic-by-topic format. You also get hundreds of examples, solved problems, and practice exercises to test your skills.

This Schaum's Outline gives you

• Practice problems with full explanations that reinforce knowledge
• Coverage of the most up-to-date developments in your course field
• In-depth review of practices and applications

Fully compatible with your classroom text, Schaum's highlights all the important facts you need to know. Use Schaum's to shorten your study time-and get your best test scores!

Schaum's Outlines-Problem Solved.

• Language: English
• Publisher: McGraw-Hill Education
• Release date: May 22, 2002
• ISBN: 9780071406208

Book preview

INDEX

CHAPTER 1

The Software Life Cycle

1.1 Introduction

The software life cycle is the sequence of different activities that take place during software development. There are also different deliverables produced. Although deliverables can be agreements or evaluations, normally deliverables are objects, such as source code or user manuals. Usually, the activities and deliverables are closely related. Milestones are events that can be used for telling the status of the project. For example, the event of completing the user manual could be a milestone. For management purposes, milestones are essential because completion of milestones allow, the manager to assess the progress of the software development.

1.1.1 TYPES OF SOFTWARE LIFE CYCLE ACTIVITIES

1.1.1.1 Feasibility—Determining if the proposed development is worth-while.

Market analysis—Determining if there is a potential market for this product.

1.1.1.2 Requirements—Determining what functionality the software should contain.

Requirement elicitation—Obtaining the requirements from the user.

Domain analysis—Determining what tasks and structures are common to this problem.

1.1.1.3 Project planning—Determining how to develop the software.

Cost analysis—Determining cost estimates.

Scheduling—Building a schedule for the development.

Software quality assurance—Determining activities that will helpensure quality of the product.

Work-breakdown structure—Determining the subtasks necessary to develop the product.

1.1.1.4 Design—Determining how the software should provide the functionality.

Architectural design—Designing the structure of the system.

Interface design—Specifying the interfaces between the parts of the system.

Detailed design—Designing the algorithms for the individual parts.

1.1.1.5 Implementation—Building the software.

1.1.1.6 Testing—Executing the software with data to help ensure that the software works correctly.

Unit testing—Testing by the original developer.

Integration testing—Testing during the integration of the software.

System testing—Testing the software in an environment that matches the operational environment.

Alpha testing—Testing by the customer at the developer’s site.

Beta testing—Testing by the customer at the customer’s site.

Acceptance testing—Testing to satisfy the purchaser.

Regression testing—Saving tests from the previous version to ensure that the new version retains the previous capabilities.

1.1.1.7 Delivery—Providing the customer with an effective software solution.

Installation—Making the software available at the customer’s operational site.

Training—Teaching the users to use the software.

Help desk—Answering questions of the user.

1.1.1.8 Maintenance—Updating and improving the software to ensure continued usefulness.

1.1.2 TYPICAL DOCUMENTS

1.1.2.1 Statement of work—Preliminary description of desired capabilities, often produced by the user.

1.1.2.2 Software requirements specification—Describes what the finished software will do.

Object model—Shows main objects/classes.

Use case scenarios—Show sequences of possible behaviors from the user’s viewpoint.

1.1.2.3 Project schedule—Describes the order of tasks and estimates of time and effort necessary.

1.1.2.4 Software test plan—Describes how the software will be tested to ensure proper behavior.

Acceptance tests—Tests designated by the customer to determine acceptability of the system.

1.1.2.5 Software design—Describes the structure of the software.

Architectural design—The high-level structure with the interconnections.

Detailed design—The design of low-level modules or objects.

1.1.2.6 Software quality assurance plan (SQA plan)—Describes the activities that will be done to ensure quality.

1.1.2.7 User manual—Describes how to use the finished software.

1.1.2.8 Source code—The actual product code.

1.1.2.9 Test report—Describes what tests were done and how the system behaved.

1.1.2.10 Defect report—Describes dissatisfaction of the customer with specific behavior of the system; usually, these are software failures or errors.

1.2 Software Life Cycle Models

The four different software life cycle models presented in the following sections are the most common software life cycle models.

1.2.1 THE LINEAR SEQUENTIAL MODEL

This model, shown in Fig. 1-1, is also called the waterfall model, since the typical diagram looks like a series of cascades. First described by Royce in 1970, it was the first realization of a standard sequence of tasks.

There are many versions of the waterfall model. Although the specific development tasks will occur in almost every development, there are many ways to divide them into phases. Note that in this version of the waterfall, the project planning activities are included in the requirements phase. Similarly, the delivery and maintenance phases have been left off.

Fig. 1-1. Waterfall model.

1.2.2 THE PROTOTYPING MODEL

This software life cycle model builds a throwaway version (or prototype). This prototype is intended to test concepts and the requirements. The prototype will be used to demonstrate the proposed behavior to the customers. After agreement from the customer, then the software development usually follows the same phases as the linear sequential model. The effort spent on the prototype usually pays for itself by not developing unnecessary features.

1.2.3 INCREMENTAL MODEL

D. L. Parnas proposed the incremental model.¹ The goal was to design and deliver to the customer a minimal subset of the whole system that was still a useful system. The process will continue to iterate through the whole life cycle with additional minimal increments. The advantages include giving the customer a working system early and working increments.

1.2.4 BOEHM’S SPIRAL MODEL

B. Boehm introduced the spiral model.² The image of the model is a spiral that starts in the middle and continually revisits the basic tasks of customer communication, planning, risk analysis, engineering, construction and release, and customer evaluation.

Review Question

1. How does a phased life cycle model assist software management?

2. What are two required characteristics of a milestone?

3. For each of the following documents, indicate in which phase(s) of the software life cycle it is produced: final user manual, architectural design, SQA plan, module specification, source code, statement of work, test plan, preliminary user manual, detailed design, cost estimate, project plan, test report, documentation.

4. Order the following tasks in terms of the waterfall model: acceptance testing, project planning, unit testing, requirements review, cost estimating, high-level design, market analysis, low-level design, systems testing, design review, implementation, requirement specification.

5. Draw a diagram that represents an iterative life cycle model.

Answers to Review Questions

1. How does a phased life cycle model assist software management?

The phased life cycle improves the visibility of the project. The project can be managed by using the phases as milestones. More detailed phases will allow closer monitoring of progress.

2. What are the two required characteristics of a milestone?

A milestone (1) must be related to progress in the software development and (2) must be obvious when it has been accomplished.

3. Documents in the software life cycle:

4. Order of tasks:

Market analysis

Project planning, cost estimating, requirement specification (may be done concurrently)

Requirements review

High-level design

Low-level design

Design review

Implementation

Unit testing

Systems testing

Acceptance testing

5. Draw a diagram that represents an iterative life cycle model. See Fig. 1-2.

Fig. 1-2. Iterative life cycle model.

CHAPTER 2

Software Process and

Other Models

2.1 The Software Process Model

A software process model (SPM) describes the processes that are done to achieve software development. A software process model usually includes the following:

• Tasks

• Artifacts (files, data, etc.)

• Actors

• Decisions (optional)

The notations used can vary. The standard software process model uses ovals for tasks and processes. The artifacts are represented by rectangles and the actors by stick figures. Many software process models do not include decisions. We will use diamonds whenever we show decisions. The flow is shown by arcs and is usually left-to-right and top-down. Arcs are normally not labeled.

The following are rules and interpretations for correct process models:

• Two tasks cannot be connected by an arc. Tasks must be separated by artifacts.

• A task is not executable until its input artifacts exist.

• There are one or more start tasks and one or more terminal tasks.

• All tasks must be reachable from the start task.

• There is a path from every task to the terminal task.

Software process models can be descriptive; that is, they can describe what has happened in a development project. The descriptive model is often created as part of a postmortem analysis of a project. This can be useful in terms of identifying problems in the software development process. Or, software process models can be prescriptive; that is, the software process model can describe what is supposed to happen. Prescriptive software process models can be used to describe the standard software development process. These can be used as training tools for new hires, for reference for uncommon occurrences, and for documenting what is supposed to be happening.

EXAMPLE 2.1

Figure 2-1 is a process model for unit testing software. There are two actors: the tester and the team leader. The unit tester, of course, is responsible for the unit testing. The unit tester uses the source code and the test plan to accomplish the unit testing. The result of this activity is an artifact, the test results. The team leader reviews the test results, and the result of this activity should be the approval of the unit testing. This model does not explicitly show what happens when the process is not successful. It could be inferred that the unit tester keeps testing until he or she is happy. Similarly, if the team leader is not ready to give the approval, then the process may be backed up to redo the unit testing.

Fig. 2-1. Process diagram for unit testing.

EXAMPLE 2.2

Draw the process model showing decisions.

Adding decisions allows the process model to be more explicit about what happens in all circumstances, as shown in Fig. 2-2.

Fig. 2-2. Process model with decisions.

2.2 Data Flow Diagrams

One of the most basic diagrams in software development is the data flow diagram. A data flow diagram shows the flow of the data among a set of components. The components may be tasks, software components, or even abstractions of the functionality that will be included in the software system. The actors are not included in the data flow diagram. The sequence of actions can often be inferred from the sequence of activity boxes.

The following are rules and interpretations for correct data flow diagrams:

1. Boxes are processes and must be verb phrases.

2. Arcs represent data and must be labeled with noun phrases.

3. Control is not shown. Some sequencing may be inferred from the ordering.

4. A process may be a one-time activity, or it may imply a continuous processing.

5. Two arcs coming out a box may indicate that both outputs are produced or that one or the other is produced.

EXAMPLE 2.3

The unit testing example from the previous section can be depicted as a data flow diagram, as shown in Fig. 2-3.

Fig. 2-3. Data flow for unit testing.

Figure 2-3 illustrates some of the rules. The phrases within the boxes are verb phrases. They represent actions. Each arrow/line is labeled with a noun phrase that represents some artifact.

The data flow diagram does not show decisions explicitly. The example shows that the results of testing can influence further testing and that the results of the test review action can also affect the testing (or retesting).

EXAMPLE 2.4

The calculation of the mathematical formula (x + y)* (w + z) can be shown as a sequence of operations, as shown in Fig. 2-4:

Fig. 2-4

2.3 Petri Net Models

The basic petri net model consists of condition nodes, arcs, event nodes, and tokens. If the input condition nodes for an event node all have tokens, then the event can fire, the tokens are removed from the input nodes, and tokens are placed on all of the output nodes of the firing position. The condition nodes are usually represented by circles and the event nodes by horizontal lines or rectangles.

In a petri net model, the condition nodes usually represent some required condition—for instance, the existence of a test plan. A token at the condition means that the condition is met. An event node (the horizontal line) represents an event that can happen (fire) when all the requirements are met (tokens in all the condition nodes). Tokens are then placed at all the condition nodes that follow the event.

EXAMPLE 2.5

A petri net model of testing is shown in Fig. 2-5.

Fig.2.5 petri net model

There are a number of different variations on the basic petri net model.

2.4 Object Models

In object-oriented development (Chapter 11), both the problem in the problem domain and the solution in the machine space are described in terms of objects. In the solution, these objects normally become classes. As the requirements and design phases of software development progress, the objects switch from being representations of the things in the problem domain to being programming structures in the software.

Object models represent entities and relationships between entities. Each box represents a type of object, and the name, attributes, and the methods of the object are listed inside the box. The top section of the box is for the name of the object, the second section is for the attributes, and the bottom section is for the methods. An arc between two objects represents a relationship between the objects. Arcs may be labeled in the center with a name of the association. The roles may be labeled at the opposite end. Also, at each end a multiplicity may be given indicating how many different associations of the same kind are allowed.

The three major types of relationships are (1) inheritance, (2) aggregation, and (3) association. An inheritance relationship implies that the object at the bottom of the arc is a special case of the object at the top of the arc. For example, the top object might be a vehicle and the bottom object a car, which is a kind of vehicle. This is often called an is-a relationship. An aggregation relationship implies that the object at the bottom of the arc is a component of the object at the top of the arc. For example, the top object might be a car and the bottom object might be the engine. This is often called a part-of relationship. The final type of relationship is an association, and this arc implies that somehow one of the objects is associated with the other object. For example, a father-son relationship is an association. This relationship may be two-way, or it might only be one-way.

Although there are many different notations, we will use a notation compatible with the Unified Modeling Language (UML) standard.¹

EXAMPLE 2.6

Construct an object model for a library. The objects in the simple library shown in Fig. 2.6 consist of the library, books, copies of books, and patrons.

None of the methods of the objects are shown. The library has an aggregation relationship with book and with patron. That is, the library is really made up of books and patrons. The relationship between book and copy is neither aggregation nor inheritance. The object book represents the abstraction of a book, while the copy is the physical item that is loaned out. The relationship between patron and copy is called loan. From the view of copy, the role is checked out by and from patron the role is check out. The multiplicities indicate that a copy can either not be checked out or can have this relationship with only one patron at a time (0.1). The other multiplicity, 0.*, indicates that a patron can have zero or one or many relationships of check out at a time.

Fig. 2-6. Object model of simple library.

EXAMPLE 2.7

Construct an object model for a family-tree system that stores genealogical information about family members.

Figure 2-7 indicates that everyone has a birthfamily. Every marriage has a father person and a mother person. Many attributes have been left off the diagram, and no functions are shown.

Fig. 2-7. Family-tree object model.

2.4.1 EXISTENCE DEPENDENCY²

One approach to clarifying the relationships is