Chapter 1

Download full Solution Manual for Object Oriented Software Engineering An Agile Unified

Methodology 1st Edition by Kung

https://getbooksolutions.com/download/solution-manual- for-object-oriented-software-

engineering-an-agile-unified-methodology-1st-edition-by-kung

Introduction

1.1 Search the literature and ̄ nd four other de¯nitions of software engineering in addition to the one

given in this chapter. Discuss the similarities and di®erences between these de¯nitions.

Solution. Below are ¯ve de¯nitions of software engineering including the one in the text -book,

listed chronologically. The similarities and di®erences are shown in Figure 1.1. A better solution

should also provide a convincing explanation of the di®erences, and signi¯cant im-plications of

the di®erences. For example, software engineering education, and signi¯cant improvement of

software PQCT are important considerations of software engineering.

1. IEEE. The IEEE Computer Society de¯nes software engineering as: \(1) The applica-

tion of a systematic, disciplined, quanti¯able approach to the development, operation,

and maintenance of software; that is, the application of engineering to software. (2)

The study of approaches as in (1)." (\IEEE Standard Glossary of Software Engineering

Terminology," IEEE std 610.12-1990, 1990.)

2. Ghezzi. \Software engineering is the ¯eld of computer science that deals with the

building of software systems that are so large or so complex that they are built by a

2

3

IEEE Ghezzi Brugge Sommerville Kung

(1) Application of engineering to software √ √ √ √

(2) Study of approaches as in (1) √ √

(3) Modeling, problem-solving, knowledge acquisition, √ √ √ √ √ and rationale driven activity

(4) Education of engineering processes and √ methodologies

(5) Significantly improve software PQCT (that is, √ engineering and business aspects)

Figure 1.1: Similarities and di®erences between SE de¯nitions

team or teams of engineers." It is \the application of engineering to software." (Carlo

Ghezzi, Mehdi Jazayeri, and Dino Mandrioli, \Fundamentals of Software Engineering,"

2nd Edition, Prentice Hall, 2003.)

3. Brugge and Dutoit. Software engineering is a modeling, problem-solving, knowledge

acquisition, and rationale-driven activity. (Bernd Brugge and Allen H. Dutoit, \Object-

Oriented Software Engineering Using UML, Patterns, and Java," 3rd Edition, Prentice

Hall, 2010.)

4. Sommerville. \Software engineering is an engineering discipline that is concerned with

all aspects of software production from the early stages of system speci¯cation through

to maintaining the system after it has gone into use." (Ian Sommerville, \Software

Engineering," 9th Edition, Addison-Wesley, 2011.)

5. Kung. \Software engineering as a discipline is focused on the research, education, and

application of engineering processes and methods to signi¯cantly increase software

productivity and software quality while reducing software costs and time to market."

(David Kung, \Object-Oriented Software Engineering: An Agile Uni¯ed Methodology,"

McGraw-Hill Higher Education, 2013.)

1.2 Describe in a brief article the functions of software development process, software quality

4 CHAPTER 1. INTRODUCTION

assurance, software project management, and software con¯guration management.

Discuss how these work together during the software development life cycle. Discuss how

they improve software PQCT.

Solution. This sample solution includes the main points. A student's solution may expand

on issues discussed here.

\A software development process transforms an initial system concept into an operational sys -

tem running in the target environment. Its functions include identi¯cation of business needs,

conducting feasibility study, formulating capabilities that the system must deliver as well as

design, implementation, testing and deployment of the system to the target environment. The

functions of software quality assurance (SQA) include de¯nition of quality assurance standards

and procedures, and veri¯cation, validation and testing activities to ensure that the development

process is carried out properly, and the software artifacts produced by the development activities

meet the software requirements and desired quality standards. Soft -ware project management

oversees the control and administration of the development and SQA activities. Its functions

include e®ort estimation, project planning and scheduling, risk management, and project

administration. These activities ensure that the software system is delivered on time and within

budget. During the development process, numerous software artifacts are produced including

software requirements speci¯cation (SRS), software design, code, test cases, user's manual,

etc. These are the software, or part of it, under di®erent stages of the development process.

These documents depend on each other. This implies that changes to one document may a®ect

other documents, which may need changes as well. Software con¯guration management (SCM)

is a mechanism to coordinate changes to ensure that changes are made consistently and cost -

e®ectively.

All of software development process, SQA, project management and SCM contribute to

5

PQCT. In particular, good software development practices would apply well -established soft-ware

development methodologies, software design principles, software design patterns, coding standards,

test-driven development. These could lead to improvement of software productiv-ity and software

quality while at the same time reduce software costs and time to market. SQA ensures that the

software meets the requirements and quality standards. It contributes to improvement of software

quality. This in turn reduces rework and ¯eld-detected bugs; and hence, it also improves software

productivity, reduces costs associated with rework and ¯xing ¯eld-detected bugs. Software project

management ensures proper planning and administra-tion of the software project. In particular, it

should request the needed resources to develop the software system, properly schedule the

development activities and SQA activities, man-age budget and risks. These indirectly contribute to

improvement of software productivity and software quality. Proper planning and administration of

development and SQA activ-ities directly contribute to reducing software development costs and time

to market. This is because these activities could be performed smoothly, e.g., the needed

components and resources are in place. SCM supports project management, SQA and software

development process. It ensures that components of the software system are constructed and

modi¯ed consistently and cost-e®ectively. Consistent modi¯cation implies product ivity and quality,

and cost-e®ectiveness implies reduction in cost and time to market.

A student's answer to this question may also include a discussion of the balance between

PQCT. See Exercise 1.5."

1.3 Should optimization be a focus of software engineering? Brie°y explain, and justify your

answer with a practical example.

Solution. The answer to this question may depend on the interpretation of \optimization."

6 CHAPTER 1. INTRODUCTION

If it is about \optimization of software PQCT," then it is the focus of software engineering. If

it is about performance optimization, then it should not be a focus, although SE also

considers performance issues such as testing for performance. The database access

example discussed in Section 1.5 is a practical example.

Optimization could be a focus for a given project. For example, the construction of a compiler

for multicore computers. In this case, it depends on whether the project is classi¯ed as a

software engineering, or a computer science project. It might be an SE project. For example,

it is constructed for a certain application. (See solution to Exercise 1.6 for more on

optimization and SE.)

1.4 Identify three computer science courses of your choice. Show the usefulness of these

courses in the software life-cycle activities.

Solution. An Algorithms and Data Structures course is useful in the implementation phase for

the design and implementation of algorithms and data structures to implement business

processes. In particular, the course lets the student know the available algorithms and related

data structures. The computational complexity lets the student select appropriate algorithms and

data structures according to the nature of the computation.

A Database Systems course is useful in the analysis, design, and implementation phases.

In the analysis phase, it helps the student understand database related requirements such

as the need to support multiple databases for some applications. In the design phase, the

course enables the student to design the database to ful¯ll the requirements and constraints.

In the implementation phase, the course provides the student abilities to store and retrieve

information with a database.

A Discrete Mathematical Structures course is useful in many phases of the life cycle. In

7

particular, mathematical logic lets the student design and implement logically consistent and logicall y

complete algorithms, and check for such properties during design review and code review. Graph

theory helps the student understand design diagrams such as UML diagrams because UML diagrams

are directed graphs. Thus, concepts and algorithms of graph theory can be applied. Examples include

fan-in and fan-out of a class, transitive closure for computing the change impact of a class, traversal

algorithms for calculating reachability in a state diagram.

Courses on programming languages are useful for implementation, testing, and SQA

activities. Network courses are helpful in SE project that must communicate with a remote

computer, such as accessing a remote database. Arti¯cial intelligence courses are useful

for SE projects that involve heuristic, and/or learning algorithms.

1.5 There are interdependencies between software productivity, quality, cost, and time to market.

For example, more time and e®ort spent in coding could increase productivity. This may

result in less time and e®ort in software quality assurance because the total time and e®ort

are constants. Poor quality could cost productivity due to rework. Identify three pairs of such

interdependencies of your choice. Discuss their short-term and long-term impacts on the

software development organization. How should software engineering solve the \dilemmas"

induced by the interdependencies?

Solution. Barry Boehm in his papers on software engineering economics pointed out that the

cost to ¯x a requirements error increases exponentially with time. That is, removing errors as

early as possible is a cost-saving e®ort. This also coincides with the philosophy advocated by

agile methods | that is, test early and often. Thus, if SQA is carried out as a life -cycle activity and

follows a good SQA process, then it should detect requirements, design and

8 CHAPTER 1. INTRODUCTION

implementation errors early. This reduces bug ¯xing costs exponentially. Moreover, since

SQA is a cooperate-wide practice, developers are conscious of developing quality software.

This should signi¯cantly reduce the error rate; and hence, it reduces the cost that would

otherwise have to be spent to ¯x the bugs.

In the short term, implementing and executing an SQA framework may reduce productivity,

increase costs and time to market. However, in the long term, quality software brings many

bene¯ts to the organization. These include signi¯cant reduction in error rate and error cor-

rection costs, customer satisfaction, and increase in software capability maturity level.

These should positively impact productivity, cost and time to market.

One should be aware that quality is not the more the better. To a certain point, there is the

so-called \diminishing returns." Thus, how much SQA is appropriate remains a research

problem in general and for a software organization in particular.

1.6 What are the di®erences and relationships between OO software engineering and

conventional software engineering? Discuss whether OO software engineering will replace

conventional software engineering.

Solution. The main di®erence between conventional software engineering and OO software

engineering is paradigm shift | that is, how they view the world and systems. Because of

this, they di®er in the basic concepts, basic building blocks, and starting point for the

conceptualization, design and implementation of software systems. These in turn a®ect

SQA, project management (for example, e®ort estimation and planning), and SCM.

Will OO replace the conventional paradigm? The answer should be no1. The reasons are:

1A student's solution may indicate \yes," and provide convincing arguments. Such a solution should also be

considered a good solution.

9

1. There are numerous systems that were developed using one or more of the

conventional paradigms. It is very costly and risky to replace these systems. Therefore,

the other paradigms will continue to exist because bug ¯xing, performance

improvements, and functional enhancements to these systems are required.

2. There are hundreds of thousand organizations and millions of software developers

using only the conventional paradigms. It is practically impossible and unjusti¯able to

require them to convert to the OO paradigm.

3. A conventional paradigm may be more suitable for some projects. For example,

scienti¯c computing typically involves series of transformations of input into output.

Therefore, the function-oriented paradigm is more suitable for such applications.

Moreover, scien-ti¯c computing emphasizes computing speed, the ability to solve

complex computation problems, and the accuracy of the result. OO programming

languages may not sat-isfy such requirements. These and the facts that scienti c̄

computing is there to stay and expand into computational sciences imply that the

function-oriented paradigm will continue to exist.

In addition to the above, one should know that di®erent parts of a system may be developed

using di®erent paradigms. For example, a subsystem that performs scienti¯c computing

may be developed using the function-oriented paradigm. A database subsystem may be

developed using the data-oriented paradigm. In practice, there are systems that are

modeled and designed using the OO paradigm but implemented in a non-OO language.

Similarly, there are projects that are modeled and designed using a conventional paradigm

but implemented in SmallTalk or C++.

Chapter 2

Software Process and Methodology

2.1 What are the similarities and di®erences between the conventional waterfall model and the

Uni¯ed Process model? Identify and explain three advantages and three disadvantages of

each of these two models.

Solution. The waterfall model and the Uni¯ed Process (UP) model are similar in the sense

that they are process models, they de¯ne phases, the activities and products of each of the

phases. The waterfall process is a sequential process although backtracking is possible.

The UP, on the other hand, is an iterative, incremental process.

Waterfall process advantages are: (1) it facilitates project management, scheduling and sta-

tus tracking, (2) its can be used for function-oriented team organzation, and (3) it is more

appropriate for some types of software project. Its disadvantages are: (1) it is di±cult to

respond to requirements change, (2) the long development duration is unacceptable, and

(3) users cannot experiment with the system until late in the development life cycle.

UP advantages are: (1) its iterative process can better accommodate requirements change

because changes can be made to remaining iterations, (2) it is use-case driven, allowing the

development team to focus on customer value | that is, development and deployment of

10

11

high-priority use cases as early as possible, (3) it is incremental, this reduces the risk of requirements

misconception. It disadvantages are: (1) an iterative process is more di±cult to manage and schedule,

(2) the early versions of the UP emphasize too much on documentation and much of it is not used,

(3) the UP is a process, not a methodology, therefore, it is useful only for experienced software

developers.

2.2 Write an essay about how a good process and a good methodology help tackling the project

and product challenges. Limit the length of the essay to ¯ve pages, or according to the

instructions of the instructor.

Solution. There could be many di®erent answers to this exercise. It is di±cult to come up

with a standard solution and use it to grade the submissions. However, the answer should

show how a good process and methodology address each of the challenges. Figure 2.1 of

this manual highlights the main points and provides pointers to related chapters.

Grading of this exercise could be done by reading the solutions submitted by the students,

according to the writing, the grader classi¯es the solutions into 3-5 categories such as very

good, good, fair, below, and poor. Each of the categories is then reviewed and a score is

assigned to each of the solution.

2.3 Write a brief essay on the di®erences between a software process and a software methodology.

Solution. Figure 2.11 of the textbook shows the di®erences between a process and a

method-ology. Therefore, the student needs only to explain the di®erences in the essay.

Section 2.6.1 of the textbook presents the di®erences. A student's solution may reuse the

materials in the section, and/or augment with practical examples, or experience.

2.4 Write an essay that discusses the following two issues:

12 CHAPTER 2. SOFTWARE PROCESS AND METHODOLOGY

Description Process or Methodology Solutions

Project How do we plan, schedule and • Effort estimation, and project planning and scheduling (Chapte r Challenge manage a project without 23)

1 sufficie nt knowle dge about what • Agile planning (Chapter 23)

will happen in the next several • Agile manifesto, principles, practic es, and values (Chapter 2, and years? throughout the book)

• Agile develo pm ent , i.e., design for change, frequent deliver y of small increments in short intervals (various chapters)

• Risk management (Chapter 23)

Project How do we divide the work • System engineering (Chapter 2)

Challenge among differe nt departm ents and • Software archite ctural design, behavioral design, and derivation of

2 teams, and smoothly integrate design class diagram (Chapters 6-16)

the resulting components? • Peer review, inspection and walkthrough (Chapter 18)

• Integration testing (Chapter 19)

Project How do we ensure proper • Model ing, analysis, and design using a unified modeling language

Challenge communicatio n and coordinat ion such as UML (various chapters)

3 among the departments and • Applying design patterns during the design process (Chapters 11

teams? and 16)

• Software configuration management (Chapter 22)

Product How do we develop the system • Deriving use cases from requirements (Chapter 5)

Challenge to ensure that these requireme nts • Use case driven (various chapters)

1 and constraints are met? • Peer review, inspection and walkthrough (Chapter 18)

• Acceptance testing and system testing (Chapter 19)

Product How do we cope with changes? • Design for change (various design chapters)

Challenge • Applying design patterns to provide the needed flexibility

2 (Chapters 11 and 16)

Product How do we design the system so Same as product challenge 2

Challenge that

3 changes can be made relatively

easily and without much impact

to

the rest of the system?

Product How do we design the system to Same as product challenge 2 Challenge hide the hardw a re , platform and

4 implementation so that

changes to

these will not affect the rest of the system?

Figure 2.1: Dealing with project and product challenges

13

a. The pros and cons of plan-driven development and agile development processes,

respec-tively.

b. Whether and why agile development will, or will not, replace plan-driven approaches.

Solution. The solution to 2.4a is similar to the solution about the di®erences between the

waterfall and UP process models. The answer to 2.4b can be \yes" or \no," and the answer

is not that important. The importance is the understanding of the di®erences between the

two approaches, and the student's reasoning to justify the conclusion. This exercise should

be graded using the method described in the solution for Exercise 2.2.

2.5 Write a short article that answers the following questions:

a. What are the similarities and di®erences between the spiral process, the Uni¯ed

Process, and an agile process.

b. What are the pros and cons of each of these processes.

c. Which types of projects should apply which of these processes?

Solution. The similarities are that they are iterative processes, and meant to be an improve -ment

over the existing processes. However, the iterations in the spiral process is situation dependent

| that is, what to perform next depends on the outcome of the current iteration. Moreover, risk

management is a unique feature of the spiral process. Unlike the spiral process, the UP repeats

the same four phases in each iteration. It does not require the spiral process like decision

making. It also does not indicate risk management. Agile processes are di®erent from the spiral

and UP in the agile manifesto, agile practices and values, and agile principles. In addition, agile

development tend to adopt short iterations and frequent delivery of small increments. There are

other di®erences but a solution should focus on these.

Among the three choices, projects that are research-oriented or exploratory may use the

14 CHAPTER 2. SOFTWARE PROCESS AND METHODOLOGY

spiral process. Projects that require adequate documentation should use the UP. Projects

that need to respond quickly to changing business environments, and hence software

require-ments, should use an agile process. There are subtle di®erences between

\research-oriented" and \changing requirements." Both need to tackle changing

requirements. Research-oriented requirements need to be discovered with research tasks

and experiments, which require con-siderable time and e®ort, and the costs are high.

2.6 Explain in an essay why the waterfall process is a process for solving tame problems.

Solution. The waterfall process requires that the requirements of the system must be identi -¯ed,

clearly and completely de¯ned before the design and implementation of the system. This is at

least true in theory, although many real-world projects do not happen like this. The ¯rst two

properties of wicked problems are: (1) a wicked problem does not have a de¯nite formu -lation,

and (2) the speci¯cation of the problem and the solution cannot be separated. Clearly, the

waterfall process cannot solve wicked problems because the problem-solving process does not

address these two wicked-problem properties. A student's solution may address other properties

as well. (See also solution to Exercise 2.7, especially Figure 2.2 of this manual. From the

discussion and the Figure 2.2, one may infer more on the inadequacy of waterfall in solving

software development as a wicked problem.)

2.7 Explain in an essay how agile development tackles application software development as a

wicked problem.

Solution. Software development as a wicked problem implies that the requirements for a

software system cannot be completely and de¯nitely formulated, and the speci¯cation and the

solution cannot be separated | the speci¯cation is the solution, and vice versa. Agile

development recognizes these and advocates responding to requirements change. The 20/80

15

Properties of a Wicked Problem Agile Development Solution

1) A wicked problem does not have a definite • Value working software over comprehensive

formulation. documentation.

2) For a wicked problem, the specification is the • Value responding to change over following a

solution and vice versa. plan.

• Capture requirements at a high level,

lightweight, and visual.

• User involvement is imperative.

• Good enough is enough.

3) There is no stopping rule for a wicked problem • Requirements evolve but the timescale is fixed.

--- you can always do it better. • Don’t work over 40 hours a week.

4) Solutions to wicked problems can only be • User involvement is imperative.

evaluated in terms of good or bad, and the • The team is empowered to make decisions.

judgment is subjective. • Users perform testing.

5) Each step of the problem-solving process has • Value individual and interaction over processes

an infinite number of choices ---everything goes and tools.

as a matter of principle. • The team is empowered to make decisions.

6) Cause-effect reason is premise-based, leading • User involvement, value individual and

to varying actions, but hard to tell which one is interaction, team decision making. the best. • A collaborative and cooperative approach

7) The solution cannot be tested immediately and between all stakeholders is essential.

is subject to life-long testing. • Value customer collaboration over contract

8) Every wicked problem is unique. negotiation.

9) The solution process is a political process.

10) The problem-solver has no right to be wrong

because the consequence is disastrous.

Figure 2.2: Wicked problems and agile development as a solution

rule indicates that it is good enough to identify 80% of the requirements that are of high customer

value. In additiion, it advocates capturing requirements at a high level, lightweight, and visual.

That is, low-level requirements are to be captured during the implementation phase. This is

because the speci¯cation and the solution cannot be separated. Agile devel -opment also

emphasizes on user involvement because the \correctness" of a software system cannot be

determined objectively and scienti¯cally. Figure 2.2 of this manual shows how agile manifesto

and principles solve wicked problems.