Solution Manual For
Software Engineering A Practitioner's Approach, 9th Edition Roger S. Pressman , Bruce R.
Maxim
Chapters 1-30
Chapter 1: Software and Software Engineering
1.1) Classic examples include the use of "digital automobile dashboards" to impart a
high tech, high quality images. Appliances that "think;" the broad array of
consumer electronics; personal computers (today, differentiated more by their
software function than the hardware), industrial instrumentation and machines. All
e-commerce applications are differentiated by software.
1.2) This is a good problem for classroom discussion (time permitting). Rather than
focusing on cliché' ridden (albeit important) issues of privacy, quality of life, etc.,
you might want to discuss "techno fright" and how software can help to exacerbate
or remedy it. Another interesting possibility is to use Neumann's "Risks" column in
SEN to key discussion. You might also consider new attempts at software-based
‗cash‘ economies, new modes of interactive entertainment, virtual reality, e-
commerce, etc.
1.3) It takes software so long to be finished, because of following reasons
a) Facilities are not available on line.
b) Development tools do not work as expected.
c) Customer insists on the new requirements, requiring redesign and
rework.
d) Product depends on the government regulations that change
unexpectedly.
e) Strict requirements for compatibility with existing system require more
testing, design, and implementation then expected.
f) Requirements to operate under multiple operating systems take longer to
satisfy than expected.
g) Software project risk management takes more time then expected.
h) Dependency on a technology that is still under development lengthens
the schedule.
Development costs are high:
a) Unacceptably low quality requires more testing, design and
implementation work to correct then expected.
b) Development of the wrong software functions requires redesign and
implementation.
c) Development of the wrong user interface results in redesign and
implementation.
d) Development of extra software functions that are not required extends
the schedule.
, We can‘t find errors before we give the software to our customer because of
the following reasons;
a) Product depends on government regulation, which changes
unexpectedly.
b) Product depends on draft technical standards, which change
unexpectedly.
c) New development personnel sometimes are added late in the project.
d) Conflicts within teams sometimes results in poor communication and
hence poor design
e) Sabotage by project management results in efficient scheduling and
ineffective planning.
f) Sometimes the furnished components are poor quality resulting in extra
testing, design and integration work and in extra customer –relationship
management.
We continue to have difficulty in measuring progress as software is
developed as;
a) Sometimes the purpose of the project is not clear.
b) There are a lot of business risks involved.
c) If the product built is not fitted well.
d) We need to review our work continuously.
e) A time check has to be maintained.
f) Project team has to be thorough and organized throughout the process.
1.4) Many modern applications change frequently before they are presented to the end
user and then after the first versions have been used. The few ways to build
software to stop deterioration due to change would be:
Gather the required information.
Designer and customer define the overall objectives for the software.
Identify the known requirements.
After building a prototype the developer uses an existing program fragment, this
will help the working program to complete quickly.
To maintain and improve our technical competence and to undertake technological
tasks for others only if qualified by training or experience, or after full disclosure of
pertinent limitations.
Documents should be developed in a timely manner, to do this documentation
standards are defined and mechanisms are established.
Review works done up to a particular stage.
There should be a backup person for every critical team member.
Check whether the risk aversion steps are being properly applied or not.
Check whether the necessary information for future risk analysis is necessary to
collect.
,1.5) The same approach to software engineering can be applied for each of the seven
categories. Each of these ―new challenges‖ will undoubtedly have effects (for
business people, software engineers, and end-users) that cannot be predicted today.
However, software engineers can prepare by instantiating a process that is agile and
adaptable enough to accommodate dramatic changes in technology and business
rules that are sure to come over the next decade.
1.6) There are literally dozens of real life circumstances to choose from. For example,
software errors that have caused major telephone networks to fail, failures in
avionics that have contributed to plane crashes, computer viruses (e.g.,
Michelangelo) that have caused significant economic losses and attacks on major e-
commerce sites.
1.7) Process framework is applicable to all the projects; hence the same work tasks are
applied for all projects, regardless of their size or complexity. A process framework
involves heavy communication with the customer to gather requirements; this
activity establishes a plan for the software engineering work that follows. It
involves creation of models that will assist the developer and the customer to
understand the requirements and design them; it thereby involves construction
(code generation and error testing). It finally provides feedback based on the
evaluation.
1.8) The umbrella activities occur throughout the software process they are applied
evenly across the process, the analysis encompass a set of work tasks (eg.
requirement gathering, elaboration, negotiation specification and validation). A
process framework has a set of umbrella activities that are applicable across the
entire software process. These activities include Software project tracking and
control, Risk management, Software quality assurance, and formal technical
reviews, measurement, Software configuration management, reusability
management and work product preparation and production.
, Solutions: Chapter 2: Process Models.
2.1)
a) Designers should ask users:
Is the product satisfactory, or does it require redesign or rework?
Was user input solicited, to avoid the product being unsatisfactory and requiring
rework?
Is there a need for new requirements?
Is the product larger than estimated?
Do the modules require more testing, design and implementation work to correct
than expected?
b) Users should ask as designers:
Is the scope clear?
Do we have the tools and people with skills required for the development?
Are the requirements properly defined, are additional requirements needed.
Are the specified areas of the product more time consuming than usual?
Does the module require more testing, design?
c) Users should ask themselves about the software product that is to be built:
What is the scope and purpose of the software product?
Is the product larger than estimated?
Are the best people available?
Is the staff committed and possess skills required?
Will the turnover among staff members be low enough to allow continuity?
d) Designers should ask themselves about software product that is to be built and the
process that will used to build it:
Scope and purpose of the document?
What tools are to be used?
What are the objectives and risk aversion priorities?
What will be the steps for risk analysis, identification, estimation, and evaluation
and management?
2.2)
a) Linear process flow does not accommodate change well, but can be good if a team
is building a routine product similar to something they have done before
b) Iterative process flow handles change better by building in opportunities to reviews
the intermediate work products as they are developed. Often used when building
systems involving technologies that are new to the development team.
c) Evolutionary process models are often adopted for projects (e.g. WebApps) that
need to be developed in a rapid, but controlled manner that avoids unnecessary
rework.
Software Engineering A Practitioner's Approach, 9th Edition Roger S. Pressman , Bruce R.
Maxim
Chapters 1-30
Chapter 1: Software and Software Engineering
1.1) Classic examples include the use of "digital automobile dashboards" to impart a
high tech, high quality images. Appliances that "think;" the broad array of
consumer electronics; personal computers (today, differentiated more by their
software function than the hardware), industrial instrumentation and machines. All
e-commerce applications are differentiated by software.
1.2) This is a good problem for classroom discussion (time permitting). Rather than
focusing on cliché' ridden (albeit important) issues of privacy, quality of life, etc.,
you might want to discuss "techno fright" and how software can help to exacerbate
or remedy it. Another interesting possibility is to use Neumann's "Risks" column in
SEN to key discussion. You might also consider new attempts at software-based
‗cash‘ economies, new modes of interactive entertainment, virtual reality, e-
commerce, etc.
1.3) It takes software so long to be finished, because of following reasons
a) Facilities are not available on line.
b) Development tools do not work as expected.
c) Customer insists on the new requirements, requiring redesign and
rework.
d) Product depends on the government regulations that change
unexpectedly.
e) Strict requirements for compatibility with existing system require more
testing, design, and implementation then expected.
f) Requirements to operate under multiple operating systems take longer to
satisfy than expected.
g) Software project risk management takes more time then expected.
h) Dependency on a technology that is still under development lengthens
the schedule.
Development costs are high:
a) Unacceptably low quality requires more testing, design and
implementation work to correct then expected.
b) Development of the wrong software functions requires redesign and
implementation.
c) Development of the wrong user interface results in redesign and
implementation.
d) Development of extra software functions that are not required extends
the schedule.
, We can‘t find errors before we give the software to our customer because of
the following reasons;
a) Product depends on government regulation, which changes
unexpectedly.
b) Product depends on draft technical standards, which change
unexpectedly.
c) New development personnel sometimes are added late in the project.
d) Conflicts within teams sometimes results in poor communication and
hence poor design
e) Sabotage by project management results in efficient scheduling and
ineffective planning.
f) Sometimes the furnished components are poor quality resulting in extra
testing, design and integration work and in extra customer –relationship
management.
We continue to have difficulty in measuring progress as software is
developed as;
a) Sometimes the purpose of the project is not clear.
b) There are a lot of business risks involved.
c) If the product built is not fitted well.
d) We need to review our work continuously.
e) A time check has to be maintained.
f) Project team has to be thorough and organized throughout the process.
1.4) Many modern applications change frequently before they are presented to the end
user and then after the first versions have been used. The few ways to build
software to stop deterioration due to change would be:
Gather the required information.
Designer and customer define the overall objectives for the software.
Identify the known requirements.
After building a prototype the developer uses an existing program fragment, this
will help the working program to complete quickly.
To maintain and improve our technical competence and to undertake technological
tasks for others only if qualified by training or experience, or after full disclosure of
pertinent limitations.
Documents should be developed in a timely manner, to do this documentation
standards are defined and mechanisms are established.
Review works done up to a particular stage.
There should be a backup person for every critical team member.
Check whether the risk aversion steps are being properly applied or not.
Check whether the necessary information for future risk analysis is necessary to
collect.
,1.5) The same approach to software engineering can be applied for each of the seven
categories. Each of these ―new challenges‖ will undoubtedly have effects (for
business people, software engineers, and end-users) that cannot be predicted today.
However, software engineers can prepare by instantiating a process that is agile and
adaptable enough to accommodate dramatic changes in technology and business
rules that are sure to come over the next decade.
1.6) There are literally dozens of real life circumstances to choose from. For example,
software errors that have caused major telephone networks to fail, failures in
avionics that have contributed to plane crashes, computer viruses (e.g.,
Michelangelo) that have caused significant economic losses and attacks on major e-
commerce sites.
1.7) Process framework is applicable to all the projects; hence the same work tasks are
applied for all projects, regardless of their size or complexity. A process framework
involves heavy communication with the customer to gather requirements; this
activity establishes a plan for the software engineering work that follows. It
involves creation of models that will assist the developer and the customer to
understand the requirements and design them; it thereby involves construction
(code generation and error testing). It finally provides feedback based on the
evaluation.
1.8) The umbrella activities occur throughout the software process they are applied
evenly across the process, the analysis encompass a set of work tasks (eg.
requirement gathering, elaboration, negotiation specification and validation). A
process framework has a set of umbrella activities that are applicable across the
entire software process. These activities include Software project tracking and
control, Risk management, Software quality assurance, and formal technical
reviews, measurement, Software configuration management, reusability
management and work product preparation and production.
, Solutions: Chapter 2: Process Models.
2.1)
a) Designers should ask users:
Is the product satisfactory, or does it require redesign or rework?
Was user input solicited, to avoid the product being unsatisfactory and requiring
rework?
Is there a need for new requirements?
Is the product larger than estimated?
Do the modules require more testing, design and implementation work to correct
than expected?
b) Users should ask as designers:
Is the scope clear?
Do we have the tools and people with skills required for the development?
Are the requirements properly defined, are additional requirements needed.
Are the specified areas of the product more time consuming than usual?
Does the module require more testing, design?
c) Users should ask themselves about the software product that is to be built:
What is the scope and purpose of the software product?
Is the product larger than estimated?
Are the best people available?
Is the staff committed and possess skills required?
Will the turnover among staff members be low enough to allow continuity?
d) Designers should ask themselves about software product that is to be built and the
process that will used to build it:
Scope and purpose of the document?
What tools are to be used?
What are the objectives and risk aversion priorities?
What will be the steps for risk analysis, identification, estimation, and evaluation
and management?
2.2)
a) Linear process flow does not accommodate change well, but can be good if a team
is building a routine product similar to something they have done before
b) Iterative process flow handles change better by building in opportunities to reviews
the intermediate work products as they are developed. Often used when building
systems involving technologies that are new to the development team.
c) Evolutionary process models are often adopted for projects (e.g. WebApps) that
need to be developed in a rapid, but controlled manner that avoids unnecessary
rework.
