1.1 Classic examples include the use of digital automobile dashboards to impart a high

Copyright 2020 © McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.Solutions: 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.

(Software Engineering, 9e Roger Pressman) (Solution Manual, For Complete File, Download link at the end of this File) 1 / 4

Copyright 2020 © McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.

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 2 / 4

Copyright 2020 © McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.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.

• / 4

Copyright 2020 © McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.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.

d) Parallel process flow has the potential to allow self-contained work products to

be developed simultaneously for systems that are composed of subsystems.

• / 4