1.1 Provide at Least Five Additional Examples of How The Law of Unintended Consequences Applies To Computer Software

PRESSMAN BOOKS QUESTION SOLUTION(Collected Form Google)
PRESSMAN BOOKS QUESTION SOLUTION

Chapter 1
1.1 Provide at least five additional examples of how the law of unintended
consequences applies to computer software.
The law of unintended consequences:
The law states that “while observing the problem in a deep way, it seems to be clear and a
solution also seems to
Sure-fire. But at the same time the solution also creates another problem”.
Examples of the law of unintended consequences:
1. Boy and girl internet friend ship:
Instant messengers were developed as a solution for fast, real time communication.
The problem that rose with this type of software is that - strangers can communicate
with each other.
2. Way of chatting in mobile phone:
Mobile phone communication technology helped in erasing communication barriers.
But the same technology showed a path to anti-social elements in creating havocs.
3. War (Web – apps span a wide array of applications):
Computers are used in the every field, which was a change the strategies of the user. One of the
examples is
Digital automobile dashboard that shows an image in high quality resolution.
• This type of image was harmful to create an impact on the social network users.
• It can be little more than a set of lined hypertext _les that present information using text and
limited graphics.
• However, as e –commerce and B2B applications grow in importance, web apps are evolving in
sophisticated computing environments.
4. Enjoying the videos in piracy DVD/media:
The advent of laser disc technology helped to store the data easily at low costs.
Due to the low cost, the audio and video material is getting pirated.
5. Missile tracking system:
It is a great achievement in embedded systems area. The Missile tracking system used to know
about the paths of a missile.
• Actually it is a software system developed with an intension of fisnding out the path or to track
the path generated or motion by a missile.
• But this has become curse. This technology is now being widely used for darker side rather
than for a right bpurpose.
Emmergency Contact:[email protected]
1.2 .Provide a number of examples (both positive and negative) that indicate the
impact of software on our society. Positive
Software is both product and a vehicle that delivers a product. Software delivers the most
important product of our
time information. If transforms personal data so that data can be more useful in a local context; it
manages
business information to enhance competitiveness ; it provides gateway to world wide information
networks and
provides the means for acquiring information in all of its forms.
Importance of software in our society:

Computer software belongs in the abstract domain, defining its role in modern society in
sometimes tricky. The computer and its peripherals are useless without a wide array of
programs to make them useful.
Considering the immense presence of software in our everyday lives, industry and
government, it can definitely be classed in an inexhaustible technological resource which
supports users as they manipulate data, gathering and saving it in databases or files. When
an organization uses software dedicated to its field of operations, it has the eventual tools to
perform in a constantly changing environment.
Software drawbacks:
Software engineering was spurred by the so called software crisis and which identified many
of the problems of software development. Many software projects ran over budget and
schedule. Some projects caused property damage. Some projects caused loss of life
software crisis was originally defined in terms of productivity but evolved to emphasize
quality.
1.3.Develop your own answers to the five questions asked at beginning of section 1.1.
Discuss them with fellow students.
Today, a huge software industry has become a dominant factor in the economies of the
industrialized world. But yet questions that were asked are e
(1) Why does it take so long to get software finished:
Ans: Software development is an iterative process. User requirements are collected, through
communication and the analysis is done on that and finally go for design. In between user can
specify some more requirements and may need some modifications. This takes development
process to starting point. User may not be satisfied with the
developed system, it has to undergo the refinement. There fore if take so long to get software
finished.
(2) Why are development costs so high?

Ans: Each and every software company has its own frame work. Any software is built on that
framework. The framework itself costs so high and the maintenance of legacy software,
people in the organization is not a smaller issue hence the development costs so high.
(3) Why can’t we find all errors before we give the software to our customers?
Ans: *Customer point of view may be different from that of developers.
• All the possible test cases may not be available to developer
• Customer usage may differ with time
• Lack of proper communication.
• Excessive care taken by developers during development
4) Why do we spend so much time and effort maintaining existing programs?
Ans: Developing a program is not alone a big issue but maintenance of the existing programs
takes much effort.
Because we should have an idea of all the existing programs and the contexts in which they
may be used. Rather than developing the program from the scratch, it is very much useful to
use the existing programs which will reduce the time and cost effectively. But we should have
a great knowledge to identify the various situations where a particular program can fit.
Therefore we spend so much time and effort maintaining existing programs
5) Why do we continue to have difficulty in measuring progress as software is being
developed and maintained?
Ans: Software is not a physical quantity to measure it. Its progress is calculated in terms of
complexity, time and efficiency. An efficient program developed for a time ‘x hrs’ may show
bug at the last minute, which is a difficult scenario. Efficient program developed by an efficient
developer may show an error during demonstration to the user.
Hence, still we have difficulty in measuring progress of software.
1.4. Many modern applications change frequently—before they are presented

to the end user and then after the first version has been put into use.
Suggest a few ways to build software to stop deterioration due to change.
Solution;
Build software to stop deterioration due to change
“Build the software is accommodating the changes rather than building it from the scratch”.
It is easy to extend but difficult to modify.
Many modern applications change frequently. Before they are presented to the end _user, the
first version is called as beta(B) version.
To prevent low quality (deter) in change of developed software, developers must care about
the following issues:

1. While changes are made in one part of the program, it has to be seen that no side-effect is
created in another part of the program.
2. Software must be adapted to meet the needs of new computing environments or
technology.
3. It also has to be kept in mind that the software should not depend on external devices or
systems that are likely to change with time.
4. While doing the testing in an application, test cases and results are archived and available.
So, software can be retested when changes are made.
5. First, time spending is needed to understand the requirements of the customer, what the
customer wants.
6. Even a single minor requirement must not be neglected..
1.5. Consider the seven software categories presented in Section 1.1.2. Do
you think that the same approach to software engineering can be applied for
each? Explain your answer.
Step-by-step solution:
Step 1 of 3
Software is engineered, not manufactured.
Nature of software:
The computer software is the product that is built by the software professionals, supported for a
long term.
• It defined with the various programs and approaches presented in the form of architecture.
• Nowadays, software plays a major role because it affects every aspect of the human life in all
the activities.
• In the world, it is placed as a most important technology to improve business, science,
engineering, etc.,
• The importance of software is increasing and growing as software community developing the
technologies
continue to make the life easier, less expensive, faster, and high-quality programs are
maintained.
• Software manages to play a dual role that, it acts as a product and as a vehicle (medium) to
deliver a product;
managing both personal and business information in any manner, also acts a medium for
software threats.
• The role of computer software deals with the signi_cant change over the years, to become a
dominant factor in
the industrialized world.
• Also, there are more concerns about the software being developed to examine the
characteristics of the
software’s that are built by the human world.
• Every software failure leads to an error that complexes the entire system pretends to give
challenges continuously
to the software engineers.
Seven broad categories of computer software present continuing challenges for software
engineers are shown
below:
1. System software
2. Application software
3. Engineering / scienti_c software
4. Embedded software
5. product – line software
6. Web – application
7. Arti_cial intelligence software.
Software Engineering approach:
Software engineering is an engineering discipline which involves all the aspects of software
production from the
starting stage to the _nal stage by maintaining the speci_cations of the system.
• It allows the professionals to build the high-quality computer software which encompasses
a process, a
collection of methods and the tools of the array.
• It completes the profession with a discipline of work to build a complex system in a timely
manner.
• It is the application of a systematic, quanti_able, disciplined approach to the development,
operation, and
maintenance of the software.
• This study approaches the application engineering of the software with a technology of
layers.
• It de_nes all the forms to its application software’s which should be engineered.
• It ultimately leads to the continuous process improvement to approach the effectiveness of
software applications
to software engineering.
• It provides the techniques how-to build the software that includes all the stages of the software
development
with the descriptive techniques.
• These tools provide the full support of the software development to go through all the stages
of the software to
be engineered.
If the same approach to the software engineering can be applicable?
The approach to software engineering may/may not be applied for each of the software
categories because,
• Computer science relates to the specializations of theory and fundamentals.
• Software engineering relates to the specializations of developing and delivering the
softwares in a practical way.
• Software engineering is not only writing programs, not only science but an art.
• To develop new programs, the same old programs can be extended by including the new
features to the existing approach.
• Software engineering providing tools for the software development.
• Millions of software engineers worldwide are hard at work on projects in one or more of
the above mentioned 7 categories.
• Nowadays, the software plays a major role in front of an economy in all the developed
countries and all the systems are controllable.
• In some cases, new systems are being built, but in others, existing applications are being
corrected, adapted and enhanced.
• So that, the expenditure is spent on the software development reflects the significant
fraction of GNP in all the developed countries.
• The legacy behind the generation will ease the burden of future software engineers.
The different approach is needed for software engineering because,
• It may be applied in a similar fashion that the “new challenges” faced by the engineers will
come down under each of the seven categories to deliver effects that cannot be predicted.
However, the software engineers will need to develop the processes that are adaptable
and agile with the corresponding changes in terms of technology and the business over the
next decades.
• Many of the software programs are getting old, outdated and the upgraded versions
needed.
• So, the software engineers must be well prepared by instantiating a process to
accommodate dramatic changes capable of handling all the situations concerned in the
future.
Therefore, it makes sense the same approach of the existing program cannot be used
to the new program.
Chapter 2
2.1. Figure 2.1 places the three software engineering layers on top of a layer
entitled “A quality focus.” This implies an organizational quality program
such as total quality management. Do a bit of research and develop an
outline of the key tenets of a total quality management program.
FIGURE 2.1 Software engineering layers
Step 1 of 2
Software engineering is the layered approach which contains process, methods, and tools. The
method contains a
variety of tasks which includes requirements phase, analysis phase, design and modelling phase,
program
construction phase, testing and support phase.
Software engineering methods depends on certain principals which includes modelling activates.
The process and methods are provided with automated or semi-automated support for the fourth
layer “tools”.
Step 2 of 2
Key tenets for total quality management program are given below:
• To have perfect vision, Mission and Values
o Create orientation program to educate employees about organizational goals and achievements.
• Identifying critical success factor (CSF)
o CSF is useful in identifying the objectives set by the organization and how to achieve them.
Some of the
examples of CSF are:
• Financial Performance
• Customer Satisfaction
• Market Share
• Employee Satisfaction
• Product Quality
• Metrics to track CSF data

• Identify key customer group
• Customer feedback
• Develop survey tool
• Quality improvement plan
• Resurvey after certain time period
• Technology
2.2 Is software engineering applicable when Web-Apps are built? If so, how
might it be modified to accommodate the unique characteristics of Web-
Apps?
Step 1 of 3
4633-1-7P SA: 4475
SR: 6376
Yes, software engineering is applicable, when WebApps are built because it is a layered
technology and consists of
Tools, Methods, Process, and A quality focus.
WebApps exhibit some unique attributes like, Network intensiveness, concurrency, availability,
security etc.
These unique characteristics of WebApps can be accommodated through a generic process
framework for
software engineering. It encompasses _ve activities and they are modi_ed to accommodate the
WebApps.
Modi_ed process framework activities for WebApps are:
1. Customer communication (analysis/formulation) - Setting the goals, objectives and scope of
the _rst increment.
2. Planning - _ne grained estimates and schedule for the _rst increment, coarser estimates for
subsequent
increments.
3. Modeling - Establishes requirements and identi_es content items, content design, architectural
design,
navigational design, and interface design.
4. Construction - page generation and testing, merging of content and technical designs to
produce executable
web pages that are exercised to uncover errors.
5. Deliver and evaluation - Increment is reviewed and changes required by customer are
integrated into the next increment.
The five generic framework activities can be used during the development of small, simple
programs, the creation of large Web applications, and for the engineering of large, complex
computer-based systems
2.3. As software becomes more pervasive, risks to the public (due to faulty
programs) become an increasingly significant concern. Develop a doomsday
but realistic scenario in which the failure of a computer program could do
great harm, either economic or human.
Failure is state of the system due to which a system stops functioning. It will be raised by the
fault in software application.
The three examples of loses by software applications (economic or human) are given below:
• Aeronautics software applications: Software used in aeronautics such as an airplane.
The system failure can lead to airplane crash risking several lives. It will also lead to great
economic lose.
• Medical software applications: Software is used for monitoring various medical
operations. Malfunctioning of such systems can lead to serious injury or death.
• Nuclear reactor control applications: The software used to control nuclear reactors in the
field of nuclear engineering can cause serious health issues if the system goes corrupt.
2.4. Describe a process framework in your own words. When we say that
framework activities are applicable to all projects, does this mean that the
same work tasks are applied for all projects, regardless of size and
complexity? Explain. Step-by-step solution:
Step 1 of 3
A process framework establishes foundation for a complete software process by identifying a
small number of
framework activities that are applicable to all software projects, regardless of their size or
complexity. The process
framework encompasses a set of umbrella activities that are applicable across the entire software
process.
The following generic process framework in applicable to the vast majority of software
projects:
- Communication.
- Planning
- Modeling
- Construction.
- Deployment.
These five generic framework activities can be used during the development of small
programs, the creating of large web applications, and for the engineering of large, complex
computer based system. The details of the software process will be quite different in each
case. But the framework activities remain the same. different projects demand different task
sets. The software team chooses the task set based on problem and project characteristics
2.5. Umbrella activities occur throughout the software process. Do you think
they are applied evenly across the process, or are some concentrated in one
or more framework activities?
Step 1 of 3
The activities that are used to keep the progress of the software development process in check are
known as
umbrella activities. They are included inside the frameworks.
Different framework activities may have different sets of umbrella activities based on the
functions that they perform.
For example:
There is no need of the technical reviews in the communication activity of the framework,
but it is essential to include the technical reviews in the construction activity of the
framework, where technical review is one of the umbrella activities
2.6. Add two additional myths to the list presented in Section 2.4. Also state
the reality that accompanies the myth.
Two additional software Myths are
1. Organizational Myth:
The cost of computers is lower than that of analog or electro mechanical devices.
Reality:
Hardware is cheap compared to other electro mechanical devices. However cost of software,
with reliability and maintenance, is enormous.
EX:
Space-Shuttle software has 400,000 words (relatively small) but costs NASA approximately
$100,000,000 a year to maintain. Software Costs can become exorbitant over time.
2. Technology Myth:
The most important factors determining the success of a software development project are its
1. Programming language and
2. Tools.
Reality:
All wrong, despite what language and tool designers would have you believe.
For one thing, the real influence of the listed items is in reverse order.
1. Tools and
2. Programming language.
A good tool can make even assembly language appear object oriented. So then the
important influences are certainly, more important than these is the competence of the team
members.
Recall the discussion on individual differences earlier and how they completely washed out
the technological difference in the programming environment.
2.16. it is possible o prove that a software component that even an entire

program is correct.so why doesn`t do this………/2018/2-c
Yes, it is possible to prove that a software component and even an entire program is correct, but
it takes move time.
Though the entire program is tested as we say that there is no 100% successful test, the program
may go out of
reach some times. In order to make the entire program correct, we need to test the each & every
possible test case
but generally all the test cases may not be tested because some of the test cases may be unknown
and the lock of
time factor and the lack of coordination between the developers and the customers
Chapter 3
3.1. In the introduction to this chapter Baetjer notes: “The process provides
interaction between users and designers, between users and evolving tools,
and between designers and evolving tools [technology].” List five questions
that (1) designers should ask users, (2) users should ask designers, (3) users
should ask themselves about the software product that is to be built, (4)
designers should ask themselves about the software product that is to be
built and the process that will be used to build it. Step-by-step solution:
Step 1 of 4
(a) Users should ask designers
1. Will you tell me a little bit about yourself ?
2. How long have you been in business?
3. What your specialty ? How much does it cost?
4. What if I’m not happy with the design?
5. Will you show me a few samples of your ideas for my project so I can get a feel for your
work?
Step 2 of 4
(b) Designers should ask users.
1. What are all of your needs for this project?

2. What is the timeline, deadline for this project?
3. Who will use this project?
4. What sites do you 􀅜nd similar?
5. Who will be your competitors>
Step 3 of 4
(c) Designers should ask themselves.
1. What kind of development tools he / she uses?
2. How many applications he / she previously designed?
3. Does your web designer publish a blog?
4. Does all requirements re􀅟ect in the software?
5. What’s the maintenance record?
Step 4 of 4
(d) Users ask themselves.
1. How quickly developer understand my requirements?
2. Do I have budget to build it correctly?
3. Do I have the human resources to effectively maintain this functionality?
4. Does adding this functionality help me achieve my goals?
3.2. Discuss the differences among the various process flows described in
Section 3.1.
Can you identify types of problems that might be applicable to each of the
generic flows described?
Step 1 of 3
The software engineering process basically de􀅜nes 5 framework activities. They are
communication, planning,
modeling, construction and deployment. They four types of process 􀅟ow begin with
communication activity.
Difference between the various process flows are described in section 3.1 are given in table
below:-
The problems that are faced by the generic flows described in section 3.1 are:-
• Linear process flow:
o Unpredicted integration issues can crop up.
o Defects can be traced to previous activities that is they are identified later.
o It is difficult for clients to state all requirements just initially.
• Iterative process flow:
o It can lead to a blocking state.
o More time is spent waiting than for production
• Evolutionary process flow:
o Project team waits for the earlier activity to finish.
o Developers can end up making compromises in implementation.
• Parallel process flow:

o It can cause confusion in the project team as it proceeds.
o It demands a good experts in risk assessment.
3.3. Try to develop a set of actions for the communication activity. Select one
action and define a task set for it.
A requirements gathering is an essential software engineering action for the
communication activity.
A task set defines the actual work to be done to accomplish the objectives of a software
engineering action.
The requirement gathering task set for communication activity follows:
• Create a list of stakeholders for the project.
• Interview each stakeholder individually to verify overall needs and requirements.
• Construct a preface list of features and functions based on stakeholder input.
• Schedule series of facilitated requirements gathering meetings.
• Conduct meetings.
• Generate informal user scenarios as part of each meeting.
• Improve user scenarios as a part of each meeting and the stake holder’s feedback.
• Construct adjust list of stakeholder requirements.
• Apply quality function deployment techniques to prioritize requirements.
• Package requirements so that they can be delivered incrementally
• Note constraints and restrictions that will be placed on the system.
• Discuss method for validating the system.
3.4. A common problem during communication occurs when you encounter
two stakeholders who have conflicting ideas about what the software should
be. That is, you have mutually conflicting requirements. Develop a process
pattern (this would be a stage pattern) using the template presented in
Section 3.4 that addresses this problem and suggest an effective approach to
it.
Step-by-step solution
When stakeholders have conflicting, the following process pattern describes an approach
about what the software should be
Pattern name: Conflicting Requirements
Intent: This pattern describes an approach for identifying and making a list of the
requirements specified by the stakeholders.
Type: Stage pattern.
Initial context:
The following conditions must be met prior to the initiation of this pattern.
1. Stake holders have been identified;
2. A mode of communication between stakeholders and the software team has been
established;
3. The overriding software problem to be solved has been identified by stakeholders;
Problem: Requirements of the two stakeholders are conflicting. There is a clear recognition
of the requirements but, the ideas of the stakeholders are not the same. No clear idea of what
the software should be.
Solution: Evolutionary process models are used to solve this problem. The evolutionary
process models recognize the iterative incremental nature of the project and are designed to
accommodate the changes. As the requirements are conflicting, a preliminary list of functions
and features based on stakeholder input is built. The pattern is built according to the basic
requirements. And then the changes are accommodated using the evolutionary models
Resulting context: A software prototype that identifies basic requirements is approved by
the stakeholders. The prototype is built and changes are made, if needed. Or the pattern will
be rejected and a new pattern with new features is developed.
Related patterns:
Customer Communication,
Customer Assessment,
Requirements Gathering,
Constraint Description.
Known uses and examples. This pattern is needed when the requirements are uncertain
and conflicting.;
Chapter 4
4.1. Provide three examples of software projects that would be amenable to
the waterfall model. Be specific.
Step 1 of 4
Waterfall model is a sequential approach to software development that begins with customer
speci_cation
requirements and progresses through planning, modeling, construction and deployment
The waterfall model is appropriate for projects with the following characteristics:
(1) The problem is well understood (requirements are well-de_ned);
(2) The delivery date is realistic;
(3) it's unlikely that major changes in requirements will be requested as the project proceeds
Step 2 of 4
Communication project initiation, requirements gathering
Planning Estimating, scheduling, tracking

Modeling Analysis and design
Construction code and test
Deployment delivery, support and feedback.
Example software project – (1) transaction Maintenance system (TMS)
(2) Us Department of defense
(3) NASA
Step 3 of 4
(1) Transaction Maintain once system
Phase 1. Preliminary investigation: Aim of this phase is not develop system but to
investigate the problem.
Phase 2. Requirement analysis: This phase is concerned abort the collection of
requirements. Out put of this phase is SRS document.
Phase 3. System design: (1) Algorithm
(2) Data structure
(3) software architecture
(4) Interface design
Phase 4. coding
Phase 5. Integration & Testing
Phase 6. Implementation & maintain once.
Step 4 of 4
In similar lines, us department of defense and NASA uses the waterfall model in an extensive
way. As waterfall
model is a sequential approach and many increments can be applied after the evolution of
software in this model,
it is well suited for large and long term projects.
Along with these software projects, many government projects follow waterfall model.
the prototyping model. Be specific.
Step 1 of 3
Software applications that are relatively easy to prototype almost always involve human-machine
interaction.
When the customer has a legitimate need but is clueless about the details then develop a
prototype as a _rst step.
A customer de_nes a set of general objectives. For these
applications that are amenable to prototyping are certain classes of mathematical algorithms,
subset of command
driven systems and other applications where results can be easily examined without real-time
interaction.
Example software projects for prototyping.
(1) Web based projects:
Like any other projects, web based projects also have users, requirements, schedules to be
met and quality goals. Aspects of project management, requirements management, change
control and quality management are applicable to web projects also.
The difficulty in fully specifying the requirements at the beginning of the project makes the
conventional waterfall model unsuitable for web application development. In the traditional
prototyping model, the prototype is essentially for capturing the requirements and is thrown
away as soon as purpose is served.
(2) Projects that need better human – computer interfaces will benefit a lot from the
prototyping
(3) Many engineering & scientific projects that involves large investments follow partying.
4.3. What process adaptations are required if the prototype will evolve into a
delivery system or product?
Ans Step-by-step solution:
Prototyping
Prototyping paradigm assists the developers and the stakeholders to better understand what
to build when the requirements are fuzzy. Refer to figure 4.4 from the text book.
Given below are the process adaptations techniques that are required when the
prototype will evolve into a deliverable system or a product:
• The process must apply rigorous design rules from the start.
• Software Quality Assessments procedures must be applied from the beginning.
• The prototype must be designed with extensibility in mind and then it becomes the
framework for extensions that will cause it to evolve into a production system.

the incremental model. Be specific.
Ans:
Step 1 of 3
Software projects for incremental model

Incremental model:
The incremental model delivers a series of releases, called increments that provide progressively
more functionality
for the customer as each increment is delivered.
The incremental model combines elements of waterfall model applied in an iterative fashion.
Incremental model
applies linear sequences in a staggered fashion as time progresses.
Incremental model is widely used to solve the problem of better integrating human factors into
the system
engineering and acquisition process.
Examples:
1. Word processing software developed using incremental paradigm might deliver basic file
management, editing and document production functions in the first increment; more
sophisticated editing and document production capabilities in the second increment; spelling
and grammar checking in third increment; and advance page layout capability in fourth
increment.
2. Projects of type “Explore concept” are the province of the future studies group in marketing
and strategic planning. Ex: Operating systems.
3. Projects of type “Proof of concept” are done by the engineering directorate
4.5. As you move outward along the spiral process flow, what can you say
about the software that is being developed or maintained?
Ans
Spiral model
A spiral model is combines the iterative nature of prototyping with the systematic control.
It uses the linear sequential model. It is defined by the software engineering team. The spiral
model can be adapted to apply throughout the entire lifecycle of an application, from concept
of development to the maintenance.
When an engineering team moves around the spiral, then the first circuit around the spiral
results in development of product specification. The subsequent passes around the spiral
might be used to develop prototype in more subsequent manner.
In each pass, through planning region, some adjustments to project plane are made. Cost
and schedule adjustments can also be made according to customer feedbac
4.6. Is it possible to combine process models? If so, provide an example.
Ans:
Step 1 of 3
Combine Process Models
Yes, it is possible to combine the software process models.
Some possibilities to combine of software process models are given below,
1) Evolutionary process model.
2) Incremental process model.
3) The spiral model
In the evolutionary process models create gradually more complete version of software
and a complete cycle of activities is repeated for each version.
In the Incremental process model produces a series of releases that provide more
functionality for customer needs and increments are individually designed tested and
delivered at successive points of time.
In the spiral model produces the potential for fast development of progressively more
complete versions of the software. It combines the features of the prototyping model and the
waterfall model.
Example projects:
Let us consider the case study of department of defense.
It follows waterfall model or an incremental model. But if we need to develop software based
on some other software features, go with component based model. If time is the major factor
apply rapid application model.
Hence we can combine evolutionary, incremental and spiral process models to develop
single software. In medical and research projects also we can combine these process
models.
4.7. The concurrent process model defines a set of “states.” Describe what
these states represent in your own words, and then indicate how they come
into play within the concurrent process model.
Concurrent process model
It can be defined as a series of major technical activities, tasks, and their associated states. It
is applicable to all types of software development process, and provides an accurate picture
of the current stat of a project.
In this model, different parts of a project will be different stages of completeness those
activities are all being performed concurrently. The activity for which initial communication
was completed is said to be in none state. The challenge is to handle the concurrency about
the project and be able to assess the status of it.
The stages included are as follows:
1) Under development
2) Awaiting changes
3) Under revision
4) Under review
5) Base lined
6) None
7) Done
These states represent the different stages of completion of the project, and are performed
concurrently. It provides an accurate situation of the present state.
4.8. What are the advantages and disadvantages of developing software in

which quality is “good enough”? That is, what happens when we emphasize
development speed over product quality?
Ans:Step-by-step solution:
The advantages of developing software in which quality is “good enough” are
• Completeness – All the requirements are reflected in the software
• Conciseness – Compactness
• Reliability – No faulty outputs
• Improved user satisfaction.
• Reduced cost of maintenance
• Efficiency – Amount of computing resources and cost required by a program to perform a
function.
• Consistency.
We have to compromise with the advantages of quality software, where speed is major
constraint but the speed has its own pros and cons
We have to compromise with the advantages of quality software, where speed is major constraint
but the speed has its own pros and cons.
• Developing in short intervals resulting in miniature software projects and releasing the
product in mini – increments but short iterations may not add enough functionally leading to
significant delays in final iteration.
• Speedy software promotes strong collaborative atmosphere and dynamic gathering of
requirements but dependency on strong cohesive teams and individual commitment to the project

the component-based model. Be specific.
Ans:
Step 1 of 3
Commercial off – the shelf software components, developed by vendors who offer them as
products , can be used
when software is to be built. These components provide targeted functionality with well de_ned
interfaces that
enable the component to be integrated into the software.
Regardless of the technology that is used to create the components, the component – based
development model
incorporates the following steps.
• Available component – based products are researched
• Component integration issuers are considered
• Comprehensive testing is conducted to ensure proper functionality.
Example projects:
(1) All business application projects
Ex: Banking – operations like withdraw, deposit are same for any bank. So these can be
developed into a component and can be reused.
(2) Airport traffic controllers
This project deals with traffic controlling in the airports.
Checking the flight arrival & departures.
(3) Many projects that use object – orientation paradigm are generally component
based.
4.10. It is possible to prove that a software component and even an entire
program is correct. So why doesn’t everyone do this?Ans:
Step 1 of 3
Yes, it is possible to prove that a software component and even an entire program is correct, but
it takes move time.
Though the entire program is tested as we say that there is no 100% successful test, the program
may go out of
reach some times. In order to make the entire program correct, we need to test the each & every
possible test case
but generally all the test cases may not be tested because some of the test cases may be unknown
and the lock of time factor and the lack of coordination between the developers and the
customers.
Generally, instead of testing all the test cases, only the frequent test cases that are being
used by the customer are tested. This may give better results and even may gain customer
satisfaction but the program may not be 100% correct. We cannot ensure that the software
component and even the entire program is correct
4.11. Are the Unified Process and UML the same thing? Explain your answer.
Ans:
Unified process and UML
No, Unified process and the UML is not the same thing.
Unified process:
The Unified process is a type of framework, which is used for UML in software engineering. It
is a popular iterative and incremental software development process which should be
customized for specific organization or project.
Unified Modeling Language (UML):
UML is a standardized general – purpose modeling language in the field of software engineering.
It is a modeling notation and language consists of a technology which supports the object-
oriented (and conventional) software engineering practice. And also, UML is a graphical
language for visualizing, specifying, and constructing the artifacts of software – intensive system
Explanation:
Both UML and unified process appears to be same thing on projects of all kinds. But there is
a slight difference.
1. UML is applied in the unified process.
2. UML does not provide the process framework to guide project teams in their application of
the technology.
3. Unified Process is a process framework in which UML may be applied as part of software
engineering activities.
A model is a complete description of a system from a particular perspective. But the UML
alone is not enough. A process defines Who is doing? What, When to do it and How to
reach a certain goal
Example:
Agile Development is the process, it should use UML notation for produced diagrams as well.
Chapter 5
5.1. Reread the “Manifesto for Agile Software Development” at the beginning
of this chapter.
Can you think of a situation in which one or more of the four “values” could
get a software team into trouble?
Ans:
Step 1 of 2
Manifesto for agile software development:
Better ways of developing software are as follows:
1. Individuals and Interactions over Processes and Tools:
It is the _rst value proposition of the manifesto. In this tool should be used for capturing
requirements, version
control, project planning, editing, _le transfer, etc. Here the process can get in the way, and it is
more important to
get to the point which is using the interaction over process and will get you much better results.
2. Working Software over Comprehensive Documentation:
This tells about the importance of documentation, which is often lacking in projects and can
cause problems.
It is not important, but, when it comes down to a choice between _nishing a project with a
working outcome. It is
really important to the client.
3. Customer Collaboration over Contract Negotiation:
The purpose of contract negotiation is to ensure that responsibilities and deliverables are clear, as
well as providing
a framework for resolving issues should they arise. Relationship with the client are able to
resolve things amicably,
a contract is more like an insurance policy should things go wrong.
4. Responding to Change over Following a Plan:
The purpose of the plan is to know what you are deviating from when you have to make a
change. Change is
inevitable, there's no point in _ghting it.
Creating the initial project plan is an important process to capture all the tasks required, the ideal
order in which
they should be done, and most importantly, to identify dependencies. However, the initial project
plan and how
things happen in reality are often quite different
Step 2 of 2
De_nitely one or more of the four “Values” could get a software team into trouble.
Example:
The customer, programmer interaction may not go well, the user may not specify all the
requirements that the
software must under go. There may be a misunderstanding in the interaction between customer
and the
developer. In such situations the software teams automatically creeps into troubles.
So, from the fourth value, the software team will get into trouble.
Agile process models have been designed to address the following issues:
1. Importance of self-organizing team that has control over work they perform.
2. Communication and collaboration between team members, practitioners and their customers.
3. An emphasis on rapid delivery of software that satis_es the customer.
5.2. Describe agility (for software projects) in your own words.
The word agility means “To do something very quickly”. Thus, agility in terms of software
development is to develop a software which meets all the requirement specified by the
customer, and always ready to accept the changes required by the customer even in later
phases.
The goals of agility are explained below:
• The development process should always be ready to accept new changes needed in the
development.
• Agility means to deliver the working software as soon as possible.
• Agile means to keep the software simple, the part only that is required.
• The agile software development is always growth oriented. That means, it should adapt to
new things, but incrementally. Adaptation to new changes should always move the progress
in forward direction.
• Agility in the software development keeps the change cost low as it is an incremental
process. thus, changes can be easily made in controlled environment
5.3. Why does an iterative process make it easier to manage change? Is

every agile process discussed in this chapter iterative? Is it possible to
complete a project in just one iteration and still be agile? Explain your
answers.
Ans:
The software team manages change by focusing on a defined increment and postponing any
changes until the next increment. All agile process models are iterative/incremental.
An iterative process make it easier to manage changes. Since each iteration is a mini –
project, the project team addresses, to some extent, all the risks associated with the project
as a whole each time it builds an increment of the system. As risks become greater, as
delays occur, and as the environment become more unstable. The team is able to make
necessary adjustments on a relatively small scale and propagate those adjustments across
the entire project. An iterative process has greater flexibility to change the plan. Hence it is
easier to manage the changes
Almost all the agile process models are iterative.

Yes, it is possible to complete a project in just one iterative and still be agile. Because if the
time is the major constraints and all the requirements are well known at the beginning of the
project. If there are well suited design patterns are available and the principles of agile
development are satisfied then it is possible to complete a project in one iteration that too
with agility.
5.4. Could each of the agile processes be described using the generic
framework activities noted in Chapter 3? Build a table that maps the generic
activities into the activities defined for each agile process.
Ans:
The generic process framework can be applied to each agile process described in this
chapter. The table should list all agile process models across the first row and all generic
framework activities
• Communication
• Planning
• Modeling
• Construction
• Deployment
Mapping from activates in agile process to generic activities.
• Extreme programming (XP)
o Planning – communication, planning
o Design – modeling
o Coding – modeling, construction
o Test – deployment.
• Adaptive software development (ASD)
o Speculation – communication, planning
o Collaboration – modeling, construction
o Leaning – Deployment
• Dynamic systems development method (DSDM)
o Feasibility, business study – communication, planning
o Functional model, design – Modeling, constructs
o Implementation – construction, deployment
5.5. Try to come up with one more “agility principle” that would help a
software engineering team become even more maneuverable.
Ans:
Step 1 of 3
One more additional agility principle –
Less is more:
Always model for a purpose, either to communicate, or to understand. Don’t create models for
other people unless
you know how and by whom they will be used
Travel light and update only when it hurts. Everything that is created, model, document, code,
test etc has a cost. If you decide to keep it, each will need to be maintained over time
increasing cost of change and what people must know and understand. The less you keep
and maintain, the more agile you are.
Minimize the complexity. Simplicity reduces amount of work to do. The simplest solution is
usually the best solution. More complex and detailed artifacts will be more difficult and
expensive to change. Plan for change realistically, but don’t overload your models or system
with features that your don’t need.
5.6. Select one agility principle noted in Section 5.3.1 and try to determine
whether each of the process models presented in this chapter exhibits the
principle. [Note: We have presented
an overview of these process models only, so it may not be possible to
determine whether a principle has been addressed by one or more of the
models, unless you do additional research (which is not required for this
problem).]
Ans:
Step 1 of 3
Agile processes embrace change as essential to the customer's competitive advantage. Each of
the process models
presented in this chapter exhibits this principle.
Selected one agility principle is: “Working software is the primary measure of progress”.
1. Extreme programming (XP):
Planning activity begins with the creation of a set of stories. A value is assigned to each story
and XP team will
assess each story & assign a cost. Finally the XP story will evolve as working software.
2. Adaptive software development (ASD):
Effective collaboration with the customer will only occur if we throw out any “us and them”
attributes. ASD teams with intent of learning & then improving its approach.
3. Dynamic system development method (DSDM):

It is an incremental method. The increment may not be 100% complete but there should be
some progress compared to last increments
4. Scrum:
Scrums allow us to build softer software. Scrum patterns enable a software development
team to work successfully in a world where elimination of uncertainty is impossible
5. Agile modeling (AM):
The problem can be partitioned effectively among the people who must solve it and quality
can be assessed at every step as system is being progressed, engineered and built.
5.7. Why do requirements change so much? After all, don’t people know what
they want?
Ans:
Requirements may change for various reasons even if people know their wants. The reasons
for the same can be:-
• Change in environment: Changes in legislation, organizational dynamics or competition
strategy may also lead to change in requirements.
• Missed requirement: A stakeholder working with a system might realize that it's missing a
feature.
• Identify a defect: A bug or defect in the system, creates new requirement.
• Actual requirement was not clearly understood: It is common for user to realize that what
they asked for is different from what is required.
It is a fact that requirements change a lot in software development life cycle. Changes in
requirement are hard to predict and so are the change in customer priorities.
It is often difficult for stakeholders to verbalize their software needs till they see a working
prototype, and it is then only that they might realize that they have forgotten to consider some
important points. This might happen because people may not know what they actually want
until they see something running. This explains importance of active stakeholder participation
and short iterations to a system’s success.
Very rarely, does it happen that stakeholders do not know what they want from the system. A
decent requirement specification can be designed by effective collaboration between all the
stakeholders, also their experience in the respective fields does make the task a little easier
5.8. Most agile process models recommend face-to-face communication. Yet

today, members of a software team and their customers may be
geographically separated from one another. Do you think this implies that
geographical separation is something to avoid? Can you think of ways to

overcome this problem?
Ans:
Face – to – force communication is a better way to collect the requirements from a customer,
but face – to – face communication leading to many interpersonal difficulties and
miscommunications in today’s workplace. Major problem in today’s software development is
that the members of software team and their customers may be geographically separated
from one other. The ways to overcome this problem is to use
E – mails, text messaging, PDA’s, cell phones, video conferencing, black berries, blueberries,
raspberries, and more.
It’s unbelievable how dependent we’ve become as a society on electronic communication
devices!
5.9. Write an XP user story that describes the “favorite places” or “favorites”
feature available on most Web browsers.
Ans:
Step 1 of 3
Internet bookmarks are stored webpage locations that can be retrieved. The main purpose is to
easily catalog and
access web pages that a user has visited and choose to save. Saved links are called “favorites”,
and by virtue of the
browser’s large market share, the term favorite has been synonymous with bookmark since the
early days of widely
– distributed browsers. Bookmark are normally visible in a browser menu and stored on the
user’s computer and
commonly a metaphor is be used for organization.
Book marks are a fundamental feature of web browsers, but some users have expressed
frustration with bookmark collections that become disorganized and have looked for other
tools to help manage their links. There tools include browser synchronizers and desktop
applications.
5.10. What is a spike solution in XP?
Ans:
Extreme Programming (XP):
• Extreme programming (XP) is a popular agile software development methodology used to
implement the software project.
• XP uses an object-oriented approach as its preferred development paradigm.
• XP encompasses a set of rules and practices that occur within the context of framework
activities..
Spike solution:
• It is a small technique to investigate the solution to a problem.
• To figure out tough problems or any other design problems, create a spike solution to
overcome it.
• When we encounter a tough problem that lack’s an immediately apparent solution, create a
spike solution.
• The goal of a spike solution is to keep the solution simple and away from the risk factors.
• That is where you try out different approaches in the code to make the correct solution more
apparent.
• This happens all the time in independent development, and it may not require the level of
formally those agile programming calls for
Spike solution in XP:

A spike solution in XP is a prototype that is intended to throw away.
• The prototype is implemented and evaluated. The intent is to lower risk when true
implementation.
• Starts and to validate the original estimates for the story containing the design pattern.
• To figure out the tough problems or any other design problems, create a spike solution to
overcome it.
• Also, the spike solution reduces the potential risk of the problem.
• The spike approach deals to an “end to end” approach to the problem.
• In XP, the spike solution implemented to keep away the risk and to prepare the quality
solutions to the tough problems when those agile programming calls for.
5.11. Describe the XP concepts of refactoring and pair programming in your

own words.
Ans:
Step 1 of 3
Refactoring:
It is a construction technique. Extreme programming (XP) encourages refactoring. Refactoring is
the process of
changing a software system in such a way that it does not alter the external behavior of the code
yet improves the
internal structure.. it is a disciplined way to clean up the code that minimizes the chance of
introducing bugs. The
intent of refactoring is to control the modi_cations by suggesting small design changes that can
radically improve
the design. The design occurs both before and after coding commences. Refactoring means that
design occurs
continuously as system is constructed.
Pair programming:
Pair programming recommends that two people or teams work together at one computer work
station to create code for a story. This provides a mechanism for real – time problem solving and
real – time quality assurance. In practice, each person takes on slightly different role. For
example, one might think about coding details of particular portion of design while the other
ensures that coding standards are being followed and code that is generated will fit to
requirement.
5.12. Using the process pattern template presented in Chapter 3, develop a
process pattern for any one of the Scrum patterns presented in Section 5.5.1.
Ans:
Process pattern template for scrum pattern “communicate Early”
Problem: What is the goal of a project and who are members of a team?
Context: Use of scrum in a distributed project (faster, cheaper and quality projects)
Solution: Arrange kick – off meeting for all relevant members present briefly scrum
methodology.
Describe the goal and contents of the project.
Describe a release plan with some sprints
Introduce briefly use of an ALM tool everybody presents his / her responsibilities & hobbies.
Consequences: common goal is known by every relevant member a common process and
tools for every site can be established by scrum and ALM tools efficient
communication channels can be created between team members when
they learn to know each other better.
5.13. Visit the Official Agile Modeling site and make a complete list of all core
and supplementary AM principles.
Core principles of agile modeling:
• Assume simplicity
• Embrace change
• Enabling the next effort is your secondary goal
• Incremental change
• Maximize stakeholder ROI
• Model with a purpose
• Multiple models
• Quality work
• Rapid feedback
• Working software is your primary goal
• Travel light
Supplementary principles of agile modeling:
• Content is more important than representation
• Open and honest communication
Assume simplicity:
• Develop the model as simple as possible. Avoid including additional features that are not
necessary.
Embrace change:
• Requirements of the user changes from time to time. Therefore, the agile model should be
willing to accept the change.
Enabling the next effort is your secondary goal:
• The primary goal of software development is develop software that is working efficiently and
meets all the requirements of the customer.
• Sometimes even though working software is delivered, it is still considered as a failure.
• The secondary goal is the next effort to develop a system with next major release.
Incremental change:
• A model can be developed with initial requirements and then can be modified by adding
features one by one.
• It is not mandatory that the model must be perfect the first time it is built.
Maximize stakeholder ROI:
• Consider the resources that are provided by the stakeholders while designing a model so
that stakeholder ROI is maximized.
Model with a purpose:
• A model should be developed so that it will give a better understanding of the product to be
designed and help in reducing the complexity of the product to be designed.
Multiple models:
• If the software requires multiple models, then develop models that are necessary for the
software.
• Not all products require multiple models.
Quality work:
• Develop the model that is of good quality.
Rapid feedback:
• Rapid feedback can be obtained when working closely with customers.

• It helps in understanding the requirements of the customer.
• The customer can give a feedback after the user interface has been developed.
Working software is your primary goal:
• The primary goal of software development is develop software that is working efficiently and
meets all the requirements of the customer.
Travel light:
• Develop the model as simple as possible so that when a change has to be made, it will be
done easily.
• If multiple models are maintained, then a change has to be reflected in all the models. So
maintain simple models that are necessary.
Content is more important than representation:
• The type of model or the representation of the model constructed is not important.
• The model should be developed so that it serves its purpose.
Open and honest communication:
• People should be open and honest to voice up their ideas or opinions or suggestions.
5.14. The tool set proposed in Section 5.6 supports many of the “soft”
aspects of agile methods.
Since communication is so important, recommend an actual tool set that
might be used to enhance communication among stakeholders on an agile
team.
Ans:
Chapter 8
8.1. Why is it that many software developers don’t pay enough attention to requirements
engineering? Are there ever
circumstances where you can skip it?
Step 1 of 2
Designing and building an elegant computer program that solves the wrong problem server no
one needs. That’s
why it is important to understand what the customer wants before beginning to design and build
a computer –
based system.
Step 2 of 2
But many software developers do not pay enough attention to requirements engineering, because
in developers
point of view –
• After all, doesn’t the customer know what is required ?
• Shouldn’t the end users have a good understanding of the features and functions that will
provide bene_t? The
view is not at all correct.
Requirement engineering helps software engineers to better understand the problem they will
work to solve. It
encompasses the set of tasks that lead to an understanding of what the business impact of the
software will be,
what the customer wants and how end – users will interact with software we cannot directly skip
requirement
engineering but v=can be given less importance if the software to be built is very familiar.
8.2 .You have been given the responsibility to elicit requirements from a customer who tells
you he is too busy to meet with
you. What should you do?
Just asking a stakeholder what their requirements are rarely works. It is said that the
customer is always right. In fact the customer may be busy and normally far more urgent
things to do rather than speaking to someone in a suit about requirements for a system that is
not even due to be delivered.
The first thing to be sure of when eliciting requirements is that we have to get the stakeholder
into a state in which they want to talk to us.
Prepare a set of questionnaire and ask him to respond in his free time.
Use the internet facility to overcome the problem of collecting requirements from a busy
customer.
Be straight forward, look for the main central idea rather than looking for unnecessary
defaults.
However, if the customer refuses to work with you, it's time to get both your management and
the customer's management involved. If they don't have the time to help define the software,
they probably won't have the inclination to use it.
8.3. Discuss some of the problems that occur when requirements must be elicited from
three or four different customers. Discuss some of the problems that occur when
requirements must be elicited from three or four different customers.
The following are the problems that occur when requirements must be elicited from three or
four different customers.
• The requirements of the customer cannot be understood easily. The customer’s

requirements will change over time such that a customer with a set of requirements at one
time can include another set of requirements afterward.
• It is very difficult to understand the requirements of the customers.
• The customers will have a wide range of expectations such that it may lead to
disappointments at most of the time.
• The customers will change their requirements rapidly
• Each and every customer will have some set of requirements such that their expectations
can be at different level. Therefore, their expectations may not get fulfilled at most of the time.
• The developmental team of a product will work according to the requirements. Hence, the
customers should be available at all time to answer the questions asked by the
developmental team of the product.
• The customers should have the knowledge to answer the questions to be asked by the
developmental team members. The customers should specify the required input and output
clearly.
• The customers may get satisfied or may not get satisfied. They are the decision makers to
review a product whether it matches their requirements or not.
To avoid these problems, the customer with some knowledge about the requirements should
be available to the developmental team of the product at any time and answerable to the
questions asked by them for the good performance and functionality of the product. Also, the
customer should be very clear about the input and output data
8.4. Why do we say that the requirements model represents a snapshot of a system in time?
The intent of the analysis model in to provide a description of the required informational,
functional and behavioral domains for a computer based system. The model changes
dynamically as software engineers learn more about the system to be built, and stakeholders
understand more about what they really require. For that reason, analysis model is a
snapshot of requirements at any given time. We expect it to change.
As the analysis model evolves, certain elements will become relatively stable, providing a
solid foundation for design. But some elements of model may be more volatile. Indicating the
customer doesn’t yet fully understand requirements for the system.
8.5. Let’s assume that you’ve convinced the customer (you’re a very good salesperson) to
agree to every demand that you
have as a developer. Does that make you a master negotiator? Why?
There should be no winner and no loser in an effective negotiation. Both sides win because a
“deal “that both can live with is solidified.

There is no question of master negotiator. A developer may try to convince the customer but
he should remember the “Win –Win” result. The customer wins by getting the system that
satisfies the majority of customer’s needs and the software tam wins by working to realistic
and achievable budgets and deadlines. Then is negotiation becomes master negotiation but
not by convincing the customer as a salesperson.
8.6. Develop at least three additional “context-free questions” that you might ask a
stakeholder during inception.
Step 1 of 3
Context-free questions are said to be the questions that are asked during the development of a
project or the
project which is under construction. These questions will be used to identify the positive and
negative sides of a
project. These questions will give the clarity for the development of the project.
The following are the context-free questions that would be used to ask during the inception of
a project.
• What are the barriers to the development of this project?
• What kind of benefits does the project will provide and who are going to get these benefits?
• Who is going to provide the payment for the work?
These questions will be asked at the inception phase of a project for the development of the
project.
8..7. Develop a requirements-gathering “kit.” The kit should include a set of guidelines for
conducting a requirements-gathering meeting and materials that can be used to facilitate
the creation of lists and any other items that might help in defining requirements.
Answer:
Facilitated Requirements gathering “kit”

A project manager’s tool kit includes different collaborative sessions. In that requirement
gathering is a major session. Ii consists of
1. Team building
2. Team communication
3. Change management
Requirements gathering meeting consists of
1. Gathering requirements using workshops or focus groups.
2. Prototyping and early, reiterative user testing of designs.
3. The re-use of software components.

4. A good schedule is necessary to design improvements to the next product version.
Requirements gathering session kit
This session is designed to aid in the gathering of requirements to support a project. This
session is of great value when there is a need to gain alignment & consensus between
stakeholders as to the requirements of a project.
Outcomes & deliverables of session kit
1. Accelerated requirement gathering
2. Consensus among user groups around project requirements.
3. Reduced rework.
4. Establishment of requirement priorities
5. Increased ownership for the project
6. Join contribution & alignment between business and IT stakeholders
8.8.Your instructor will divide the class into groups of four or six students. Half of the
group will play the role of the marketing department and half will take on the role of
software engineering. Your job is to de_ne requirements for the SafeHome security
function described in this chapter. Conduct a requirements-gathering meeting using the
guidelines presented in this chapter
Requirements gathering essentials:
• Fours and clarity

• Format for specifying requirements
• The author of requirements document
• The language of requirements
• Accuracy is critical
• Minimizing risk of errant interpretation
• Conclusion
Safe home security function.

• Access camera surveillance via the internet
• Security & secret cameras
• Configure sate home system parameters
• Set alarms
• Activate sensors
8.9.Develop a complete use case for one of the following activities:

a. Making a withdrawal at an ATM.
b. Using your charge card for a meal at a restaurant.
c. Buying a stock using an online brokerage account.
d. Searching for books (on a speci_c topic) using an online bookstore.
e. An activity speci_ed by your instructor.
Answer:
ATM System:–
8.10. What do use case “exceptions” represent?

The purpose of exceptions in use-case is to identify some of the situations that are not covered in
the preliminary use case.
• The situations that are identified in exceptions are covered while refining the preliminary use
case.
• The use case must be complete and must deliver proper meaning to the user.
In the process of redefining the preliminary use case, at each step, various questions should
be asked to get a clear picture of the purpose of that step.
Some of the questions to be asked are:
• Is there any alternative action that can be taken by the actor?
• Will there be any errors conditions to be handled that the user may encounter?
8..11. Write a user story for one of the activities listed in question 8.9.
User stories are used to manage requirements of a system. It is a short statement of required
function. Usually a user story’s structure is:-
As a ,
I want to ,
So that .
A user story for also contains acceptance criteria, which verifies the correctness of the
implementation of user story. An acceptance test are based on the acceptance criteria.
Usually it contains Given, When and Then clauses.
The advantages of user story for stating requirements are:-
• They are easy to understand by everyone
• They lay emphasis on verbal communication between stakeholders
• They are used for iterative development and as a result details can be deferred for next
iteration.
User story for making a withdrawal at an ATM can be stated as:-
As a Customer,
I want to withdraw cash from my account in an ATM,
So that I can withdraw money without going to the bank and stand in a line.
In this case, one user story acceptance criteria can be defined as:-
Given that
• Users account has that much of money,
• Customer’s ATM card is valid and
• ATM machine has cash.
When the customer makes a cash transaction
Then ensure that the
• Customer’s account is debited and
• ATM machine dispenses cash.
Many other acceptance criteria can be created based on the condition such as:-
• customer’s account does not have required balance,
• card not being valid or
• ATM machine does not have the required cash.
8.12. Consider the use case you created in question 8.9, write a nonfunctional requirement
for the application.
A software might not be useable if it does not satisfy its non-functional requirements (NFR).
They specify the criteria for checking the operational quality of the system. They can be
Performance, Usability, Reliability, Software Quality, Security and Safety Requirements.

For making a withdrawal at an ATM system application, the NFR can be:-
• A performance requirement can be that each bank should be able to process transactions
from several ATMs at the same time.
• A safety requirement is that the temperature of the ATM center should be controlled to
prevent the machines overheating.
• Security requirement are
o A security guards must be present at the ATM at all times.
o A camera should be installed inside the ATM to capture and stores the videos in the ATM.
• A Quality requirement can be that the relevant communication with the ATM machine should
have a readable font size.
For using a charge card for a meal at the restaurant application, the NFR can be:-
• Card number or pin, if entered, should be hidden from others.
• The system should display a transaction successful or failure message within 30 seconds of
submitting information.
• The menu and ingredients at the restaurant are modified frequently, this should be done
without a new system release each time.
• If the card machine is down for some reason payment by cash should be an option
For buying a stock using an online brokerage account application, the NFR can be:-
• The online system should provide a functionality to recover transactions whenever the
system is down.
• The time it takes to buy or sell stock should be almost the same as when buying from a
company office.
• The system should work on desktops, laptops, tablets and mobile device platforms.
• A transaction failure or success message should be displayed to user within 30 seconds of
information submission.
For searching for books (on a specific topic) using an online bookstore application, the NFR
can be:-
• Result of the search should be displayed to user within 30 seconds of information
submission.
• The system should work on desktops, laptops, tablets and mobile device platforms.
• The site should be able to smoothly run on all operating system, with all types of browser.
• If books are out of stock a relevant message should be displayed along with a result.
For an activity specified by an instructor, the non-functional requirements can be:-

• The instructor should pass the directions for activity to be best at 90% of the time in easily
understandable language.
• The instructor can effectively instruct only 11 students at a time.
• The activity and its inherent steps should be explicitly specified by the instructor
unambiguously.
8.13.Describe what an analysis pattern is in your own words.

Analysis pattern:
We can notices that certain things reoccur across all projects with in a specific application
domain. These can be called as analysis patterns and represent something within the
application domain that can be reused when modeling many applications. Information about
an analysis pattern is presented in a standard template:
Pattern mane: A descriptor that captures essence of pattern.
Intent: Describes what the pattern accomplishes & represents.
Motivation: A scenario that illustrates how pattern can be used to address the problem.
Forces and context: A descriptor of external issues that can affect how the pattern is used
and also the external issues that will be resolved when pattern is
applied.
Solution: A description of how the pattern is applied to solve the problem with an
emphasis on structural and behavioral issues
Consequences: Addresses what happens when the pattern is applied.
Design: Discusses how the analysis pattern can be achieved through the use of known
design patterns.
Known uses: Examples of uses within actual system.
Related patterns: one or more patterns that are related to the named pattern.
8.14. Using the template presented in Section 8.5.2, suggest one or more analysis pattern for the
following application domains:
a. Accounting software.
b. E-mail software.
c. Internet browsers.
d. Word-processing software.
e. Website creation software.
f. An application domain speci_ed by your instructor.
8.15.What does win-win mean in the context of negotiation during the requirements
engineering activity?
The customer and the developer enter into a process of negotiation, where the customer may be
asked to balance functionality performance and other product or system characteristic against
cost and time to market. The intent of negotiation is to develop a project plan that meets the
needs of the customer while at the same time reflecting the real – world constraints that have
been placed on software team.
The best negotiations strive for a “Win – Win” result. ie……….. the customer wins by getting
the system that satisfies the majority of the customer’s needs and the software team wins by
working to realistic and achievable budgets and deadlines.
Win – win result can’ be achieved by successful completion of
1. Identification of system or subsystem’s key stakeholders
2. Determination of the stokeholds “Win conditions”.
3. Negotiate of stakeholders win conditions to reconcile them into a set of win – win condition
for all concerned.
8.16. What do you think happens when requirement validation uncovers an error? Who is
involved in correcting the error?
It is extremely desirable to detect errors in the requirements before the design and
development of the software begin. The basic objective of the requirements validation is to
ensure that the SRS reflects the actual requirements accurately and correctly.
Omission, inconsistency, incorrect fact and ambiguity are the common errors in requirements.
As requirements are generally textual documents that cannot be executed, inspections are
eminently suitable for requirement validation. Requirement validation reviews are conducted
to uncover the errors that commonly occur during requirements gathering.
Because requirement specification formally specifies something that is originally existed
informally in people’s minds, requirements validation must involve the clients and the users.
8.17. What five tasks make up a comprehensive requirements monitoring program?
Requirement monitoring aims to trail a system’s runtime activities so as to detect aberrations
from its requirement speci◊cation specified earlier. Requirement monitoring program are used
when stakeholder choose to use incremental software development.
The five tasks that make up a comprehensive requirement monitoring program are:-
• Distributed debugging: is used to find out error and the reason for their occurrence.
• Run time verification: is used to check if software matches its earlier specified specification.
• Run time validation: is used to check if the evolving software meets earlier specified user
goals.
• Business activity monitoring: is used to check if the evolving software meets earlier
specified business goals.
• Evaluation and co-design: is used to provide information to various stakeholders as the
system progresses.
Chapter 9
9.1. Is it possible to begin coding immediately after a requirements model has been
created? Explain your answer and then
argue the counterpoint
Step 1 of 1
The analysis model will serve as a basis for the design and coding. It is possible to begin coding
after objects,
attributes; relationships are analyzed in analysis phase however the design will suffer as a result
of explicit
architecture design will not have been considered. Interfaces will have been developed in
haphazard manner and
global data structure will not have been explicitly designed.
9.2. An analysis rule of thumb is that the model “should focus on requirements that are
visible within the problem or business
domain.” What types of requirements are not visible in these domains? Provide a few
examples.
Thumb rule of Analysis
• The model should focus on requirements which are visible with in problem or business domain.
• Abstraction levels are high in thumb rule
• New elements added in the analysis model should help in better understanding of the software
requirements of the system.
• These elements provide better understanding of the functionality, behaviour and information
domain of the system.
• Coupling should be minimized throughout the system

• The model should be simple
The following are the requirements not visible in these domains:
• Infrastructure requirements
o Functions required to manage global data
o Functions required to implement network communications
o Functions required to implement user interface
9.3. What is the purpose of domain analysis? How is it related to the concept of
requirements patterns?
Domain analysis is an on-going software engineering activity that is not connected to any one
software project
Purpose of domain analysis:
The key to reusable software is captured in domain analysis in that it stresses the reusability of
analysis and design.
Domain analysis for requirement patterns
The requirement is to find analysis pattern that are widely used with in specific application
domain and to identify a set of objects and classes that characterize the domain..
9.4. Is it possible to develop an effective analysis model without developing all four elements
shown in Figure 9.3 ? Explain.
FIGURE 9.3 Elements of the analysis model
It is possible to develop an effective analysis model without developing all four elements shown
in Figure. The specific content of each element may differ from project to project.
However, each element presents a different view of the problem to be solved, and therefore
provides the ability to see potential problems, inconsistencies or omissions more clearly. In
addition, if all four elements of the analysis model are developed, the transition to design is
simplified.
9.5.The department of public works for a large city has decided to develop a Web-based
pothole tracking and repair system (PHTRS). A description follows:
Citizens can log onto a website and report the location and severity of potholes. As potholes
are reported they are logged within a “public works department repair system” and are
assigned an identifying number, stored by street address, size (on a scale of 1 to 10),
location (middle, curb, etc.), district (determined from street address), and repair priority
(determined from the size of the pothole). Work order data are associated with each
pothole and include pothole location and size, repair crew identifying number, number of
people on crew, equipment assigned, hours applied to repair, hole status (work in progress,
repaired, temporary repair, not repaired), amount of filler material used, and cost of
repair (computed from hours applied, number of people, material and equipment used).
Finally, a damage file is created to hold information about reported damage due to the
pothole and includes citizen’s
name, address, phone number, type of damage, and dollar amount of damage. PHTRS is
an online system; all queries are to be made interactively. Draw a UML use case diagram
PHTRS system. You’ll have to make a number of
assumptions about the manner in which a user interacts with this system.
The department of public works for a city has decided to develop a web-based Pot Hole Tracking
and Repair System (PHTRS). A UML use case diagram states the relationship between the actors
in the system with the use cases.
To construct a unified modelling language (UML) use case diagram first identify the actors for
the system. For PHTRS, actors can include:-
• Citizen
• PHTRS employees
• Contractor
• Repair Crew
Then, identify the functionalities to be identified as use case for the system. For PHTRS,
functionalities can include:-
• Citizen reports pothole information like its severity and location.
• Record pothole information like identification number, size, location, address, repair priority in
PHTRS.
• Issue work order with data like size, location, repair crew id number, crew size, equipment
assigned, hours worked, status, cost or repair etc.
• Create a PHTRS damaged file with information like citizen name, phone number, and address,
type of damage and cost of damage.
Now, construct a UML use case diagram for the PHTRS using above information
Figure 1: UML use case diagram for PHTRS
9.6. Write two or three use cases that describe the roles of various actors in the PHTRS
described in Problem 9.5.
and Repair System (PHTRS). To construct use case for the system first identify the actors in the
system. For PHTRS, actors can include:-
• Citizen
• PHTRS employees
• Contractor
• Repair Crew
Then, identify the functionalities to be identified as use case in the system. For PHTRS,
functionalities can include:-
• Citizen reports pothole information like its severity and location.
• Log pothole information like identification number, size, location, address, repair priority in
PHTRS.
• Issue work order with data like repair crew id number, repair crew size, equipment assigned,
hours worked, status, cost or repair etc.
• Create a PHTRS damaged file with information such as citizen name, phone number, and
address, type of damage and cost of damage.
Now, uses cases to describe the role of various actors can be:-
Use Case: Report Pothole
Primary Actor: Citizen
Goal in Context: To report a pothole along with any damage to citizen or property.
Precondition: Citizen is logged in a fully configured PHTRS.
Trigger: Citizen sees a pothole or faces loss due to the pothole, decides to report it.
Scenario:
1. The user clicks on 'Report Pothole' in the web site.
2. The web site displays a form to fill in following information: location on the street, severity,
and address of Pothole.
3. The user fills his/her information into the fields, and if s/he faced damages.
4. The user Clicks on ‘Next’ button.
5. Site asks user for information about Type of damage done and cost if s/he choose
damages in last section.
6. The user fills out all this information.
7. The user clicks on ‘Submit’ button.
8. The application stores all the information that Citizen entered in a database.
Open Issues:
1. Users can log bad data that would increase cost without any actual requirement.
2. Users can exaggerate damage.
3. No backup: In case the system goes down for any reason, records could be lost.
4. End-Users don't prefer to use the system.
Use Case: Create damage file

Primary Actor: PWD employee
Goal in Context: To create a damage file.
Precondition: The web based PHTRS is functional and a pothole has been repaired.
Trigger: Contractor informs PWD that the pothole has been repaired.
Scenario:
1. The PWD employee checks the quality and completeness of repair.
2. The PWD employee logs in the system with user id and password.
3. The application opens with an option to search an existing unrepaired pothole.
4. The PWD employee closes the status of just repaired pothole (repaired) and click on the
‘Create damage file’ button.
5. The application creates a damage file containing information of pothole and reporting
damage caused to a citizen due to the pothole.
Open Issues:
1. The PWD employee might misjudge the quality of repair.
2. The contractor can exaggerate the cost of repair for more profit.
3. A contractor can misinform about quality of repair, wasting resources.
4. No backup: In case the system goes down for any reason, records could be lost.
5. PWD employees are reluctant to use the new system.
9.7. Develop an activity diagram for one aspect of PHTRS.

and Repair System (PHTRS).
One of the use case scenario for the system is:-
Use Case: Report Pothole Primary Actor: Citizen
Goal in Context: To report a pothole with damage to citizen or property, if any.
Precondition: Citizen is logged in a fully configured web based PHTRS.
Scenario:
2. The web site displays a form to fill in following information: location, severity, and address of
Pothole.
3. The user fills his/her information into the fields, and if s/he needs to mention damages.
5. Site asks user for information about Type of damage done and cost if s/he choose damages in
last section.
The activity diagram in UML is a tool to provide a graphical representation of flow of interaction
within a use case. Activity diagram are procedurally oriented. They resemble flowcharts. The
activity diagram for the ‘Report pothole’ use case can be:-
.
Figure 1: Activity diagram for ‘Report Pothole’ use case of PHTRS
9.8. Develop a swimlane diagram for one or more aspects of PHTRS

The department of public works for a city has decided to develop a web-based Pot Hole
Tracking and Repair System (PHTRS).
One of the use case scenario for the system is:-
Use Case: Report Pothole
Primary Actor: Citizen
Goal in Context: To report a pothole with damage to citizen or property, if any.
Precondition: Citizen is logged in a fully configured web based PHTRS.
Scenario:
2. The web site displays a form to fill in following information: location on street, severity, and
address of Pothole.
3. The user fills his/her information into the fields, and if s/he needs to mention damages.
5. Site asks user for information about Type of damage done and cost if s/he choose
damages in last section.

The UML swimlane diagram is an extension to activity diagram, which states the actors or
analysis class responsible for an action. Swimlane diagram are procedure oriented.
In this use case, classes are Citizen and the web based application. So, the swimlane
diagram for the above use case can look like:-
Figure 1: Swimlane diagram for ‘Report Pothole’ use case of PHTRS

As can be seen from Figure 1 above, the activity diagram of the ‘Report Pothole’ use case is
spread out so that activities associated with an analysis class fall inside the swimlane for that
class.
Chapter 10
10.1. You have been asked to build one of the following systems:
a. A network-based course registration system for your university.
b. A Web-based order-processing system for a computer store.
c. A simple invoicing system for a small business.
d. An Internet-based cookbook that is built into an electric range or microwave. Select the
system that is of interest to you
and develop a processing narrative. Then use the grammatical parsing technique to
identify candidate objects and
classes.
10.2. Develop a set of operations that are used within the classes identi_ed in Problem 10.1.
Operations associated with each class for a network based course registration system in a
university are:-
1. Student Class
• printStudentInfo(): print the information details of a given student object.
• calcAvgMarks(): calculate the average marks of the student based on all the marks that
student has obtained in all the courses he had taken.
• register(): Register student in the university and call enrollInCourse() repeatedly for each
course the student prescribes to.
• enrollInCourse(): Enroll student in the specified course.
• calcBill(): Calculate the bill according to the fees of each course that student has prescribed
to.
2. Professor Class
• printProfessorInfo(): print the information details of a given Professor.
• register(): Register the Professor in the university and call teachesCourse() repeatedly to
assign courses to the Professor.
• teachesCourse(): Assigns a course to a professor, which he’ll teach.
3. Course Class
• printCourseInfo():print the information details of a given Course.
• teachesCourse(): Assigns a course to a professor, which he’ll teach.
4. CoursesTaken Class
• allCoursesWithStudent(): Print all courses information taken by a student.
• allStudentsInCourse (): Print all students in a course.
• courseTaughtbyProfessor(): Print all the courses taught by a given professor.
5. Section Class
• addStudent(): Add a student to a section for a course.
• dropStudent(): Drop a student from a section for a course.
10.3. Develop a class model for the PHTRS system present in Problem 9.5.
The department of public works for a city has decided to develop a web-based Pot Hole
Tracking and Repair System (PHTRS). The class model for PHTRS system could look like:-
10.4. Write a template-based use case for the SafeHome home management system
described informally in the sidebar
following Section 10.4.
A template based use case for the SafeHome home management system, described in section
10.4 of the book, can be:-
10.5. Develop a complete set of CRC model index cards on the product or system you chose
as part of Problem 10.1.
10.6. Conduct a review of the CRC index cards with your colleagues. How many additional
classes, responsibilities, and
collaborators were added as a consequence of the review?
10.7. What is an analysis package and how might it be used?

Analysis package:
In a software engineering, various elements of the analysis model such as use cases, analysis
classes are categorized in a manner that packages them as a grouping. This is called an analysis
package To build a software, lot of classes are there which fall in one category and other classes
fall in other categories. Thus, classes that come under a category are grouped under a name, that
is called an analysis package
An analysis package is represented shown in figure:
Analysis package
+, -, and # are access specifiers for public, private and protected respectively.is for
Uses:
The analysis packages are used to derive the requirements.
Chapter 11
11.1. There are two different types of “states” that behavioral models can represent. What
are they?
The two different types of “states” that behavioral models can represent are:
1. The state of each class as the system performs its function and
2. The state of the system as observed from the outside as the system performs its function.
11.2. How does a sequence diagram differ from a state diagram? How are they similar?
Difference: A sequence diagram differs from a state diagram in the way of representing the
behavior of the system.
• Unlike a state diagram that represents behavior without noting the classes involved, a
sequence diagram represents behavior, by describing how classes move from state to state.
• A state diagram represents how an individual class changes its state, based on external
events where as a sequence diagram shows the behavior of the software as a function of
time.
Similarity:
Both the sequence diagram and the state diagram are the notation used for behavioral
modeling. They are the two different behavioral representations.
11.3. Suggest three requirements patterns for a modern mobile phone and write a brief
description of each. Could these
patterns be used for other devices? Provide an example.
Modern mobile phones need various applications like camera, Bluetooth, Internet, Radio etc.
Some of the requirements patterns for such modern mobile phones are:
Cameracontroller
This pattern shows how to specify the sensors and actuators in a phone, used to perform
camera controlling functions. This pattern uses the sensors for the zoom-in and zoom-out
functions of a camera. A pull mechanism is used for passive sensors and a push mechanism
for the active sensors.
This pattern can be used in various devices that need a camera. For example, a computer
that needs a web camera can use this pattern for camera controlling operations.
MobileRadio
This pattern provides functioning of an in built mobile radio. It uses some technologies that
enable stations to communicate over wide areas.
This pattern can be used in cars to provide the facility of a radio system
WirelessInternet
This pattern provides the mobile phones the access to internet without any modems or wires.
This pattern can also be used in laptops, which are mobile. Due to their mobility, a wireless
Internet access is much useful for laptops. So this pattern can be used.
11.5. How much analysis modeling do you think would be required for
www.safehomeassured.com? Would each of the model
types described in Section 11.5.3 be required?
For a SafeHomeAssured.com application, the degree to which analysis modeling for an

application is emphasized depends on the following factors:
• Size and complexity of WebApp increment
• Number of stakeholders
• Size of the WebApp team
• Degree to which members of the WebApp team worked together before
• Degree to which the organization’s success is directly depends on the success of the WebApp
Smaller the project and lesser the number of stakeholders and if the application is less
critical, it is reasonable to apply a more lightweight analysis approach. In the case of
SafeHomeAssured.com, a more lightweight analysis approach can be applied because,
• We need to analyze only that part of the problem that is relevant to the design work for the
increment to be delivered.
• It does not need any stakeholders. Only the owner of the house will be concerned about the
project.
• Also the success of a home is not a direct dependent on this SafeHomeAssured.com
There are five main classes of models. They are:

• Content model
• Interaction model
• Functional model
• Navigation model
• Configuration model
Some specific models depend largely upon the nature of the WebApp. For
SafeHomeAssured.com not each of these model types are required. For this system, we
could validly design the overall website aesthetics (layouts, color schemes, etc.) without
having analyzed the functional requirements for e-commerce capabilities. So the functional
model is not required.
11.6. What is the purpose of the interaction model for a WebApp?

The interaction model describes the manner in which users interact with the WebApp. The
purpose of the interaction model for a WebApps is to enable a “conversation” between an
end user and application functionality, content, and behavior.
This conversation can be described using an interaction model that can be composed of one
or more of the following elements:
• Use cases
• Sequence diagrams
• State diagrams
• User interface prototypes
• Use cases: It is the main element of WebApp interaction models. A set of use cases is
sufficient to describe the interaction at analysis level.
• Sequence diagrams: It provide representation of manner in which user actions collaborate
with analysis classes.
• State diagrams: It indicates information required to move users between states and
represents behavioral information. It can also represent potential navigation pathways.
• User interface prototype: It provides the layout of the user interface, the content it
presents, and the interaction mechanisms it implements
11.7. It could be argued that a WebApp functional model should be delayed until design.
Present pros and cons for this
argument.
It could be argued that a WebApp functional model should be delayed until design. The pros
and cons for this argument are:
Pros:
• Some WebApps does not need functional requirements up to some phase. In such cases, it
reduces the effort of unnecessary gathering of functional requirements.
• It saves some time.
Cons:
• Some requirements may not be addressed due to this delay till the design phase.
• Some WebApps deliver a broad array of computational and manipulative functions that can
be associated directly with content and the major goal of the WebApp. So in some cases,
even a major goal of user-WebApp interaction may sometimes go unassigned
11.8. What is the purpose of a configuration model?

The purpose of the configuration model is to describe the environment and infrastructure in
which the WebApp resides. The configuration model in some cases is nothing more than a
list of server-side and client-side attributes for WebApps
11.9. How does the navigation model differ from the interaction model?
A navigation model differs from an interaction model in addressing the requirements.
• A navigation model is concerned about how each user category will navigate from one
WebApp element to another, where as an interaction model presents the conversation
between an end user and application functionality.
• The mechanics of navigation are defined as part of design, while the interaction model is
basically described at an analysis level and further introduced in detail during design.
Chapter 12
12.1. Do you design software when you “write” a program? What makes software design
different from coding?
Design software
No, writing a program is the different concept in design software. Design is the place where
software quality is established. Before starting of design software, first requirements should
be analyzed and specified.

In the software design process, design engineering is the one of the concept. While
beginning software, requirements have been analyzed and modeled. This model can be
accessed for quality and improved before code is generated.
In a software engineering context, first need to develop the models of program. Not the
program themselves.
Software design different from coding:
At first it is very clear that, design is not coding and coding is not design. It
is created from program components.
Design is the description of the logic, which is used in solving the problem. Coding is the
language specification which is implementation of the design. It runs on the computer and,
provides the expected result.
12.2. If a software design is not a program (and it isn’t), then what is it?
Yes, software design is not a program. Coding or programming is a language which is used
to represent the design. Programming is not good for representing details of architecture,
components or their collaborations.
Software design contains a set of principles, concepts, and practices which leads to
development of high quality product. Design plays an important role in the development of a
successful software product.
The main aim of design is to create a model that presents firmness, commodity, and delight
to customers those who use it. Software engineering continuously changes with new
methods for better analysis and to evolve broader understanding.
Software design is like a kernel of software engineering. Software design is an action with the
software engineering modelling activity, followed by code generation and testing.
The following are design methods which are implemented in software engineering:
• Object/Class design
• Architectural design
• Interface design
• Component design
12.3. How do we assess the quality of a software design?
The quality of software is assessed based on the design even before it is implemented. During
design, the quality is assessed by conducting a series of technical reviews. The following are the
guidelines to assess the quality of the software design:
• A design should be simple created by using recognizable patterns which are easier for
implementation and testing.
• A design should be modular that is, it can be broken down into smaller sub systems.
• A design should lead to data structures, components, and interfaces that are appropriate for
classes and in turn reduce the complexity of connection with the external environment.
• A design is derived using repeatable methods and should be represented using simple notations
which communicates its meaning
The following are the FURPS quality attributes which are like a benchmark for a quality
software design:
• Functionality
• Usability
• Reliability
• Performance
• Supportability
12.4. Examine the task set presented for design. Where is quality assessed within the task
set? How is this accomplished? How
are the quality attributes discussed in Section 12.2.1 achieved?
Generic task set for design:
1. Examine information domain model and design appropriate data structures for data objects
and their attributes
2. Select an architectural pattern appropriate to the software based on the analysis model
3. Partition the analysis model into design subsystems and allocate these subsystems within
the architecture
4. Create a set of design classes or components
5. Design any interface required with external systems or devices
6. Design the user interface
7. Conduct component level design
8. Develop a deployment model
Quality is assessed for each element of the design model--data design, architecture, user
interface, and component-level design
During design, assessing quality is accomplished by conducting a series of technical reviews
(TRs). A technical review is a meeting conducted by members of the software team
Quality Attributes :
Quality Attributes represent a target for all software design. Set of attributes are represented
as an acronym FURPS.
F – Functionality
U – Usability
R – Reliability
P – Performance
S – Supportability
These quality attributes can be achieved when these attributes are addressed before a
design commences, but not after the design is complete and construction has begun.
12.5. Provide examples of three data abstractions and the procedural abstractions that can
be used to manipulate them.
Data abstractions: It is the process of representing essential details not including internal
details.
Examples:
1) First example of data abstraction is to abstract “Doors” as a data structure with essential
properties:
Door: Properties
Type
Swing direction,
Manufacturer,
Insets,
Lights,
Weight,
Opening / Close mechanisms
2) Second example of data abstraction is “ College ”

College: Computer science,
Electrical Engineering
.
.
.
.
Mechanical Engineering
3) Third example of data abstraction is “ Software company:
Company: Software Architect
Software Manager
Sr. Developers
Jr. Developers
Tester
Procedural abstractions: The Procedural abstraction is to decompose problem to many
simple sub works.
Examples:
1) Credit Card: Validate(User name, Password)
Check limited (Withdrawal limit)
2) Website: Add page(linking new page to home page)
Access (setting access permissions)
3) Online Medical transitions : patient list
Cost (Medical Lab bill
12.6. Describe software architecture in your own words

The software architecture is the structures of program components / modules. And
Software architecture is:
• An overall view of the solution to a problem
• The high-level design of modular components and how they interact
• A foundation that one can build on to solve a problem (e.g., rules, policies, attributes, etc.)
• An efficient method to meet a fixed set of well-defined attributes
Architecture needs to include:

architecture: The architectural vision, style, principle, key communication and control
mechanisms and concepts that guide the team of architects in the creation of the
architecture.
Architectural patterns: Structural patterns such as layers and client/server and mechanisms
such as brokers and bridges
12.7. Suggest a design pattern that you encounter in a category of everyday things (e.g.,
consumer electronics, automobiles,
appliances). Briefly describe the pattern.
Consider a pattern named, IntermittentWindshieldWiper capability in an automobile
industry.
Pattern name: Intermittent Wind Shield Wiper
Intent: It allows the driver to cause the windshield wipers to operate intermittently, with
intermittent timing defined using a time-setting device such as a ring-dial on the wiper control
arm.
Motivation: There are many situations in which precipitation is significant enough to warrant
removal from the windshield, but not heavy enough to warrant continuous wiper operation.
Applicability: Integrated into all luxury automobiles and other automobiles that provide the
feature as an option
Structure: wiper control arm, timer, and wiper actuator.
Participant’s- wiper control arm: turn on; turn off, set wiper speed, set timing level
Collaborations: wiper control arm defines the attributes of the control that are used by the
driver; timer implements a clocking function that collaborates with timing control set using
wipercontrolarm;
Wiper actuator sends control signals to the servomechanism the controls the wiper motor.
Consequences: The primary design force is the number of wiper timing levels and /or
whether the timing level can be set on a continuous scale.
12.8. Describe separation of concerns in your own words. Is there a case when a “divide
and conquer” strategy may not be
appropriate? How might such a case affect the argument for modularity?
Separation of concerns:
Separation of Concerns is a design concept. It refers to the delineation and correlation of
software elements to achieve order within a system. That means a large and difficult problem
can be divided into small parts and can be done easily. By dividing the work into parts and
handling it, the effort decreases. By this we can handle complex problem more easily through
proper separation of concerns. So complexity becomes manageable.
Yes, there is a case when a divide-and-conquer strategy may not be appropriate. The
strategy may not be appropriate in the case where, the complexity when two problems are
combined is greater than the sum of perceived complexity when each is taken separately.
The argument for modularity is that, if you subdivide software indefinitely the effort required to
develop it will become negligibly small. But in these types of cases, as the number of
modules grows, the effort (cost) associated with integrating the modules grow. Hence the
argument for modularity will not be appropriate.
12.9. When should a modular design be implemented as monolithic software? How can this
be accomplished? Is performance
the only justi_cation for implementation of monolithic software?
To accomplish this, implement all the task performed by the software in a single module.
Maintenance cost is the other factor to implement it as a monolithic software. Maintenance cost
of a modular software is greater than monolithic software. Thus, when there are very large
number of modules of small size, then it should be implemented a monolithic software.
12.10. Discuss the relationship between the concept of information hiding as an attribute of
effective modularity and the concept of module independence.
Information hiding can be related to both coupling and cohesion. By limiting the availability
the information to only those modules that have absolute need, coupling between modules is
inherently reduced. Isolation of information predicates isolation of function, therefore
cohesion of individual modules can also be improved.
Software architecture and design patterns embody modularity; that is, software is divided into
separately named and addressable components, sometimes called modules that are
integrated to satisfy problem requirements.
Monolithic software (large program composed of a single module) cannot be easily grasped
by a software engineer. The number of control paths, span of reference, number of variables,
and overall complexity would make understanding close to impossible.
It is the compartmentalization of data and function. It is easier to solve a complex problem
when you break it into manageable pieces. “Divide-and-conquer”
Don’t over-modularize. The simplicity of each small module will be overshadowed by the
complexity of integration “Cost”.
Modules should be specified and design so that information (algorithm and data) contained
within a module is inaccessible to other modules that have no need for such information.
Hiding implies that effective modularity can be achieved by defining by a set of independent
modules that communicate with one another only that information necessary to achieve
software function.
The use of Information Hiding as a design criterion for modular systems provides the greatest
benefits when modifications are required during testing and later, during software
maintenance. Because most data and procedures are hidden from other parts of the
software, inadvertent errors introduced during modifications are less likely to propagate to
other location within the software.
12.11. How are the concepts of coupling and software portability related? Provide examples
to support your discussion.
The concept of coupling and software portability are interrelated like External world complier
and operating systems coupling. Coupling is the concept, which is together with the reliability
and strength among all relationships between functional units. As well as concept of software
portability is usability of same components in different environments.
In the concept of optimal software, coupling has to be minimized and portability has to be
maximized. Strong software, which contains low levels of coupling could easily and efficiently
is portable. As the same way, if the software is portable it is probably due to the low levels of
coupling which it has.
Example: Software portability adversely.

Consider a program that has been design to make use of special graphics features of an
intelligent display. If the software is moved to a system without this type of display, major
design and code modification may be required. For this external coupling occurs when a
component communicates or collaborates with infrastructure components like operation system
functions, database capability,
telecommunication functions. It should be limited to a small number of components or classes
within a system. Software must communicate internally and externally. Therefore, coupling is a
fact of life and the designer should work to reduce coupling whenever possible and understand
the ramifications of high coupling when it cannot be avoided.
12.12.Apply a “stepwise refinement approach” to develop three different levels of

procedural abstractions for one or more of the following programs:
(1) Develop a check writer that, given a numeric dollar amount, will print the amount in
words normally required on a check.
(2) Iteratively solve for the roots of a transcendental equation.
(3) Develop a simple taskscheduling algorithm for an operating system.
To create a functional hierarchy and as a result refine the problem. For example, considering
the check writer, we might write:
Refinement 1:
Write dollar amount in words
Refinement 2:
Procedure write amount;
Validate amount is within bounds;
Parse to determine each dollar unit;
Generate alpha representation;
End write_amount
Refinement 3:
Procedure write_amount;
do while checks remain to be printed
if dollar amount > upper amount bound
then print "amount too large error message;
else set process flag true;
endif;
Determine maximum significant digit;
do while (process flag true and significant digits remain)

set for corresponded alpha phrase;
Divide to determine whole number value;
Concatenate partial alpha string;
Reduce significant digit count by one;
enddo
print alpha string;
enddo
end write_amount
12.14. Does “refactoring” mean that you modify the entire design iteratively? If not, what
does it mean?
No, refactoring does not mean modifying the entire design iteratively. Refactoring is the
process of changing a software system in such a way that it does not modify the external
behavior of the code (design) yet improves its internal structure.
12.15. Discuss what the dependency inversion principle is in your own words.
12.16. Why is design for testing so important?

Design for test approach says the design will come first and the code is developed such that
seams or test hooks can be inserted. Seams are locations in the design where code can be
tested for the status of running software. It involves isolating the code to be tested from the
production environment and testing it in a controlled one.
Design for test is important because:-
• Since testing is done at various seams, defects can be found out earlier.
• Test cases interrogate and control the running system.
• Testing at hooks also results in rectification of errors in code before they snowball.
• It results in long term maintenance of the system.
• Test are accountable and designing them makes testing exhaustive and extensive.
12.17. Briefly describe each of the four elements of the design model
The design model has four major elements:
1. Data design elements

2. Architectural design elements
3. Interface design elements
4. Component level design elements
Data design elements:
The data design (sometimes referred to as data architecting) creates a model of data and /or
information that is represented at high level of abstraction (the customer/user’s view of data).
The structure of data has always been an important part of software design.
• At the program component level, the design of data structures and the associated
algorithms required to manipulate them is essential to the creation of high-quality
applications.
• At the application level, the translation of a data model into a database is crucial in
achieving the business objectives of a system.
• At the business level, the collection of information stored in different databases and
reorganized into a “data warehouse” enables data mining or knowledge discovery that can
have an impact on the success of the business itself.
In every case, data design plays an important role.
Architectural design elements:
The architectural design elements provide an overall view of the software product.
It’s derived from three sources:
1. Information about the application domain for the software to be built.
2. Specific requirements model elements such as data flow diagrams or analysis classes,
their relationships and collaborations for the problem at hand; and
3. The availability of architectural styles and patterns.
The architectural design element is usually represented as a set of interconnected
subsystems, often derived from analysis packages within the requirements model. Each
subsystem may have its own architecture
Interface design elements:
The interface design elements of software show information flows into and out of the system
and how it is communicated among the components defined as part of the architecture.
There are three important elements of interface design:
1. User interface (UI) – UI design is a major software engineering action. UI is a unique
subsystem within the overall application architecture.
2. External interfaces to other systems, devices, networks, or other producers or consumers
of information – the design of the external interfaces requires definitive information about the
entity to which information is sent or received. It should incorporate error checking and
appropriate security features.

3. Internal interfaces between various designs components – the design of internal interfaces
is closely aligned with component level design.
These interface design elements allow the software to communicate externally and enable
internal communication and collaboration among the components that populate the software
architecture.
Component-level design elements:
The component-level design elements describe the internal detail of each software component.
To accomplish this, the component-level design defines
• Data structures for all local data objects.
• Algorithmic detail for all processing that occurs within a component and
• An interface that allows access to all component operations.
The design details of a component can be modeled at many different levels of abstraction.
Chapter 19
19.1 Describe how you would assess the quality of a university before
applying to it. What factors would be important? Which would be critical?
The quality can be assessed by observing various aspects. The important factors to be observed
are:
1. Standards: The standards that the university is maintaining and whether it is following all the
applicable
standards or not.
2. Recognition: How good the university is certi_ed by the government and recognition it has.
3. Quality of teaching: How good the teaching is? And how the results are obtained?
4. Infrastructure: Check whether a good and supportive environment is present for students to
concentrate well on
studies or not.
5. Behavior and Discipline: Is the management well concerned about teaching well disciplined
activities and
behavior and also making the students to implement them.
Of all the factors the most critical are the standards and the quality of teaching and knowledge
being provided.
19.2 Garvin [Gar84] describes five different views of quality. Provide an
example of each using one or more well-known electronic products with
which you are familiar.
David Garvin describes eight dimensions of quality that were not developed specifically for
software. They can be applied when software quality is considered.
Automobile acceleration, power windows on a car and televisions can be considered as the
best examples of electronic products to define these quality dimensions.
Performance quality:
An electronic product’s major operating characteristics. Examples are a television set’s
picture clarity and an automobile acceleration.
Feature quality:
To an electronic product’s essential functioning characteristics, such as power windows on a
car.
Reliability:
A computer that is used in some applications like banks must be reliable. It must be error free
and should not generate errors while doing transactions.
Conformance:
The degree to which a product’s design and operating characteristics meet recognized
standards. For example, if we take a television though it may not have some extra features
like flat screen, it should have the minimum features like picture clarity, sound system etc.
Durability:
A television must long for a minimum time period. As it is an expensive item, it should have a
long life and should guarantee to work.
Serviceability:
There should be service centers like in the cases of automobiles, televisions etc.
Aesthetics:
A plasma television differs from regular and portable televisions. They look different from
others make a change in their outward look and appearance.
Perception:
We will be ready to buy a television produced by a popular company even for a high price.
And at the same time a television launched by an unknown company even at a low price will
not be encouraged.
19.3 Using the definition of software quality proposed in Section 19.2, do you
think it’s possible to create a useful product that provides measurable value
without using an effective process? Explain your answer.
No, it is not possible to create a useful product that provides measurable value without using
an effective process. Because,
• Software engineering practices allow the developer to analyze the problem and design a
solid solution to build high-quality software.

• Umbrella activities such as change management and technical reviews have as much to do
with quality as any other part of software engineering practice.
19.4 Add two additional questions to each of Garvin’s quality dimensions
presented in Section
19.2.1.
David Garvin describes eight dimensions of quality.
Performance quality:
1. Does the software contain main operating features such as power, clarity, speed etc.?
2. Does the software requirements are easy to assess by the user?
Feature quality:
1. Does the software contain the extras that supplement the main characteristics such as
stylish, sunroof etc.?
2. Does the software provide new special features
Reliability:
1. How often it breaks down?
2. Does the software continuously run well?
Conformance:
1. How close it is to the design specification?
2. Does it provide a minimum guaranteed quality?
Durability:
1. Does the software long for a large time?
2. Can it accommodate the changes?
Serviceability:
1. Does the software have the ease to be repaired?
2. Does the quality software be available at low-cost?
Aesthetics:
1. Is the software understandable?
2. Is it user-friendly software?
Perception:
1. Is it acceptable and likely?
2. How are the feel, finish and manner?
19.5 McCall’s quality factors were developed during the 1970s. Almost every
aspect of computing has changed dramatically since the time that they were
developed, and yet, McCall’s factors continue to apply to modern software.
Can you draw any conclusions based on this fact?
McCall’s quality factors are
• Correctness
• Reliability
• Efficiency
• Integrity
• Usability
• Maintainability
• Flexibility
• Portability
• Reusability
• Interoperability
The conclusions that can be drawn are:
• These factors are like a basement. They provide the basic rules for determining the quality
of software.
• Though the quality factors were developed during the 1970’s they are not designed for any
particular software or a product.
• For any software they are the common and general factors to be noted, to determine the
quality. So they remain unchanged.
• They are some generalized factors and can be applied to any product of any generation.
Hence they continue to apply even to the modern software.
19.6 Using the sub-attributes noted for the ISO 9126 quality factor
“maintainability” in Section 19.2.3, develop a set of questions that explore
whether or not these attributes are present.
Follow the example shown in Section 19.2.4.
The sub-attributes of the quality factor maintainability are:
• Analyzability
• Changeability
• Stability
• Testability
The questions that explore whether or not these attributes are present are as follows:
Analyzability – The ease with which the cause of a failure can be determined.
• Are the requirements gathered clearly?
• Are the requirements specifications converted properly into software?
• Are the modules open for extension?
Changeability – The ability to accommodate changes.
• Is the modification of the design more difficult?
• Is the design less understandable?

Stability – The risk of a modification.
• Does the software functions continuously well?
• Is the risk of a modification to the software low?\
Testability – Testing the quality and functionality of the product
• Does the product meet the requirements?
• Does it match the specification?
• Is the design complex?
• Does it work as expected?
19.7 Describe the software quality dilemma in your own words.

Software quality dilemma is the dilemma of deciding the quality that a software product
must contain. Every software organization is faced with the software quality dilemma.
If software provided low quality then no one will want to buy. So basically, everyone wants to
build high-quality systems. But it needs more time and more effort to produce “perfect”
software, which is simply unavailable in a market-driven world. It may happen that the
product may not have launched in time and it may not acquire recognition. Also the resources
and the effort applied will be wasted. This is the dilemma of deciding the quality that is
needed while developing a software.
19.8 What is “good enough” software? Name a specific company and specific
products that you believe were developed using the good enough philosophy.
Good enough software is the software that delivers high-quality functions and features for
user needs that has sufficient quality to satisfy the customer’s requirements. At the same time
it delivers other more obscure or specialized functions or features that contain known bugs.
Microsoft is the company that develops its products using good enough software. It develops
a basic version initially and releases it, satisfying the needs and the quality required by
customers. Later it develops the enhanced versions and releases.
The products it developed using good enough software include Microsoft Office PowerPoint,
Microsoft Office Word, and Microsoft Windows etc.
• Microsoft office 2010 is the recently released version and its previous versions are Microsoft
office 2003, Microsoft office 2007.
• Microsoft Office word was released in different versions as, Word 2003, 2007.
• Similarly Microsoft Windows was released in different versions. They include Windows 95,
Windows NT, Windows XP, Windows Vista, and Windows 7 etc. These all are produces using
the concept of good enough software.
19.9 Considering each of the four aspects of the cost of quality, which do you
think is the most expensive and why?
The four aspects involved in the cost of quality are:
• Prevention costs
• Appraisal costs
• Internal failure costs
• External failure costs
Prevention costs: The costs of all activities specifically designed to prevent poor quality in
products or services
Appraisal costs: The costs associated with measuring, evaluating or auditing products or
services to assure conformance to quality standards and performance requirements
Internal failure costs: These are incurred when an error is detected in a product prior to
shipment.
External failure costs: These are associated with defects found after the product has been
shipped to the customer.
Of all the four aspects of the cost of quality, the external failure costs can be considered
expensive. The prevention costs, appraisal costs, and internal failure costs are the costs that
occur during the product development. They will be paid by the customer. But external failure
costs are associated with defects found after the product has been shipped to the customer.
So these costs must be bared completely by the developing side management.
External failure costs include costs like, complaint resolution, product return and replacement,
labor costs associated with warranty work etc. A product replacement is not an easy issue. It
involves much work and investment. The product should be revised and sometimes, it should
be redesigned. Hence the external failure costs can be considered as the most expensive
costs.
19.10 Do a Web search and fi nd three other examples of “risks” to the public
that can be directly traced to poor software quality. Consider beginning your
search at http://catless
.ncl.ac.uk/risks .
Low-quality software increases risks for both the developer and the end user. The downside
of poorly designed and implemented applications does not always stop with dollars and time;
they incur a great loss to people.The examples of the risks to the public due to poor software
quality are:
Example 1:
call centers dealing with emergency ambulance calls use software to automate the
prioritization of calls. Once, a change was requested to downgrade the severity of incidents
involving a fall of 10ft or more. The change was literally implemented with the consequence
that all incidents involving a fall were downgraded, irrespective of the severity of other
symptoms. The error came into light when a woman who had fallen 12ft, was unconscious
and had breathing difficulties died after being left to wait because priority was given to a
drunk who had collapsed on the street
Example 2:
Due to an unforeseen side-effect of a software upgrade over the weekend in a bank, they had
a problem with their online banking service. It happened that customers were able to access
the details of other customers.
Example 3:
For a long time, metro train had no automatic door opening mechanism, so that anything
trapped in a closing door stayed trapped. Once, a person’s leg became trapped in a train
door as it left the station
19.11 Are quality and security the same thing? Explain.
No, quality and security are not the same things, but software security relates entirely and
completely to quality. Software that does not exhibit high quality is easier to hack, and as a
consequence, low-quality software can indirectly increase the security risk with all of its
attendant costs and problems. So, to build a secure system, you must focus on quality.
19.12 Explain why it is that many of us continue to live by Meskimen’s law.
What is it about the software business that causes this?
Meskimen’s Law: There’s never time to do it right, but always time to do it over.
Many of us continue to live by Meskimen’s law because of the high competition and demand for
a product in the market. As there are tough competitors in producing software product, taking
much time in developing high quality software will not work. If one spends infinite time,
extremely large effort, and huge sums of money to build the absolutely perfect piece of software,
then it will take so long time to complete and it will be soexpensive. And also, they will be out of
business. Either ignores the market window, or simply exhausts all the resources.
So, people in industry try to produce an initial product which is good enough and not to be
rejected anyway. Also in a way that it does not involve so much perfectionism, and so much
work that it would take too long or too much cost to complete. Hence these business
requirements make the people to follow the Meskimen’s law.
Chapter 21
21.1. Some people say that “variation control is the heart of quality control.” Since every
program that is created is different from
every other program, what are the variations that we look for and how do we control
them?
A program is equal to data structure plus algorithm. Generally, different programmers will
design a program in a different way. Logic of one person varies from the other as per their own
thinking. Coding of one programmer will be different from others in solving the same problem.
So, we can expect variations in the design and coding of the data structure and the algorithm of a
program by different individuals. Also the programming language chosen by each may vary.
Hence we can look for the variations also in the syntax, logic, complexity, readability. We can
control the variations by checking the types and levels of complexity that can be used in the
design of the data structures and the algorithms of a program.
21.2. Is it possible to assess the quality of software if the customer keeps changing what it is
supposed to do?
Yes, If we define quality as "conformance to requirements," and requirements are dynamic (keep
changing), it is possible to assess the quality of software. The definition of quality will be
dynamic and an assessment of quality will be difficult
21.3. Quality and reliability are related concepts but are fundamentally different in a
number of ways. Discuss the differences.
Quality and reliability both are related concepts. But fundamentally these both are different in
some scenarios.
1. Quality control is concerned with the performance of a product at one point in time.
2. Quality focuses on the software's conformance to explicit and implicit requirements.
3. Software quality assurance is the mapping of the managerial principles and design disciplines
of quality assurance onto the applicable managerial and technological space of software
engineering.
Where as
1. Reliability is concerned with the performance of a product over its entire life time.
2. Reliability focuses on the ability of software to function correctly as a function of time or
some other quantity.
3. Software reliability models extend measurements, enabling collected defect data to be
extrapolated into projected failure rates and reliability predictions
21.4. Can a program be correct and still not be reliable? Explain.

Reliability:-
Yes, it is possible for a program to conform all explicit functional and performance
requirements at a given instant. Because, reliability uses statistical analysis to determine the
software failure with likelihood occur. And, The probability of failure is free software operation
for a specified period of time in a specified environment.
21.5. Can a program be correct and still not exhibit good quality? Explain.
Yes, it is possible for a program to conform to all explicit functional and performance
requirements at a given instant, yet to not perform well during maintenance, integration on other
systems, or might have hardware dependencies.
Many programs have been patched together, so that they work yet these programs exhibit very
low quality if measured by McCall's quality factors.
21.6. Why is there often tension between a software engineering group and an independent
software quality assurance group?
Is this healthy?
Software Quality Assurance group vs. Software Engineering group:
Between these two groups, there is a common natural tension because, if the SQA group takes on
the role of the "observing the bugs of software code," flagging quality problems and high-
lighting shortcomings in the developed software, this is normal and this would not be embraced
with open arms by the software engineering group. This software quality assurance group helps
ensure that they fit the project’s needs and verifies that they will be usable for performing the
necessary reviews and audits throughout the software life cycle.
As long as the tension does not degenerate into hostility, there is no problem. It is important to
note, however, that a software engineering organization should work to eliminate this tension by
encouraging a team approach that has development and QA people working together toward
common goal of high quality software.
21.7. You have been given the responsibility for improving the quality of software across
your organization. What is the first thing that you should do? What’s next?
For improving the quality of software across the organization, First of all i evaluate the quality
Based on the formal technical reviews, I checkout the total working process of that software.
If it is working smoothly, then the number of SQA activities might be implemented. That is
Change control and SCM;
Comprehensive testing methodology;
SQA audits of documentation and related software.
In this process software metrics can help.
21.8. Besides counting errors and defects, are there other countable characteristics of
software that imply quality? What are
they and can they be measured directly?
Suppose maintainability measured by mean – time – to – change; portability as measured by an
index that indicates conformance to language standard, portability complexity, availability ,
reliability. Portability as measured by an index that indicates conformance to language standard;
complexity as measured by McCabe's metric, and so on
Here reliability focuses on the ability of software to function correctly as a function of time or
some other quantity. Safety considers the risks associated with failure of a computer based
system that is controlled by software. Quality focuses on the software’s conformance to explicit
and implicit requirements. In most of the cases an assessment of quality considers may factors
that are qualitative in nature.
21.9. The MTBF concept for software is open to criticism. Explain why.
MTBF (mean-time-between-failure) is a simple measure of reliability.

MTBF = MTTF + MTTR
Where,
MTTF stands for Mean-Time-To-Failure and
MTTR for Mean-Time-To-Repair
MTBF is related to the mean times. The concept of MTBF is open to criticism because of various
reasons. Its measures are based on CPU time, not wall clock time. One of the reasons is it can be
problematic for two reasons. They are
1. It projects a time span between failures, but does not provide us with a projected failure rate,
and
2. MTBF can be misinterpreted to mean average life span even though this is not what it implies.
21.10. Consider two safety-critical systems that are controlled by computer. List at least
three hazards for each that can be
directly linked to software failures
To build safety – critical systems, instead of simply trying to get software correct and assuming
that will ensure. System safety, attention is focused on eliminating or controlling the software
behaviors.
1. The software requirements are complete and specify only safe behaviors.
2. The entire software development and maintenance process eliminates (or) reduces the
possibility of the unsafe behavior.
Software hazard analysis is a form of subsystem hazard analysis used to identify safety –
critical software behavior. The system safety design constrains and information from the system
hazard analysis, is used to:
1. Develop software safety for design constraints.
2. Identify specific software safety requiems.
3. Device software and system safety test plans and testing requirements.
4. Trace safety related requirements
5. Develop safety – related information for operations, maintenance.
21.11. Acquire a copy of ISO 9001:2000 and ISO 9000-3. Prepare a presentation that
discusses three ISO 9001 requirements and
how they apply in a software context.
ISO 9001: 2000 is the generic source of requirements for quality assurance in design,
development, production; installation and servicing as well as the standard against which quality
management systems for software are assessed.
In ISO 9000:2000 quality management system – fundamentals and vocabulary.
ISO 9004: 2000 quality management systems
- Guidelines for performance imprisonment

ISO 9000: 2000 explains the principles underlying the change’s ISO 9001 and defines
vocabulary.
ISO 9001:2000 is the quality assurance standard the applies software engineering. The standard
contains 20 requirements that must be present for an effective quality assurance system.
Because the ISO 9001: 2000 standard is applicable to all engineering disciplines, a special set of
ISO 9000 -3 have been developed to help interpret standard for use in the software process

1.1 Provide at Least Five Additional Examples of How The Law of Unintended Consequences Applies To Computer Software

Uploaded by

Copyright:

Available Formats

1.1 Provide at Least Five Additional Examples of How The Law of Unintended Consequences Applies To Computer Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1.1 Provide at Least Five Additional Examples of How The Law of Unintended Consequences Applies To Computer Software

Uploaded by

Copyright:

Available Formats

PRESSMAN BOOKS QUESTION SOLUTION(Collected Form Google)

PRESSMAN BOOKS QUESTION SOLUTION

Importance of software in our society:

(2) Why are development costs so high?

1.4. Many modern applications change frequently—before they are presented

the following issues:

• Metrics to track CSF data

2.16. it is possible o prove that a software component that even an entire

1. What are all of your needs for this project?

• Parallel process flow:

Planning Estimating, scheduling, tracking

4.4. Provide three examples of software projects that would be amenable to

Software projects for incremental model

4.8. What are the advantages and disadvantages of developing software in

4.9. Provide three examples of software projects that would be amenable to

5.3. Why does an iterative process make it easier to manage change? Is

Almost all the agile process models are iterative.

3. Dynamic system development method (DSDM):

5.8. Most agile process models recommend face-to-face communication. Yet

geographical separation is something to avoid? Can you think of ways to

Spike solution in XP:

5.11. Describe the XP concepts of refactoring and pair programming in your

• Rapid feedback can be obtained when working closely with customers.

• The requirements of the customer cannot be understood easily. The customer’s

“deal “that both can live with is solidified.

Facilitated Requirements gathering “kit”

3. The re-use of software components.

Requirements gathering essentials:

• Fours and clarity

Safe home security function.

8.9.Develop a complete use case for one of the following activities:

8.10. What do use case “exceptions” represent?

Performance, Usability, Reliability, Software Quality, Security and Safety Requirements.

For an activity specified by an instructor, the non-functional requirements can be:-

8.13.Describe what an analysis pattern is in your own words.

8.17. What five tasks make up a comprehensive requirements monitoring program?

Requirement monitoring aims to trail a system’s runtime activities so as to detect aberrations

• Coupling should be minimized throughout the system

Figure 1: UML use case diagram for PHTRS

Use Case: Create damage file

9.7. Develop an activity diagram for one aspect of PHTRS.

9.8. Develop a swimlane diagram for one or more aspects of PHTRS

damages in last section.

Figure 1: Swimlane diagram for ‘Report Pothole’ use case of PHTRS

10.7. What is an analysis package and how might it be used?

For a SafeHomeAssured.com application, the degree to which analysis modeling for an

There are five main classes of models. They are:

11.6. What is the purpose of the interaction model for a WebApp?

11.8. What is the purpose of a configuration model?

be analyzed and specified.

2) Second example of data abstraction is “ College ”

12.6. Describe software architecture in your own words

Architecture needs to include:

Example: Software portability adversely.

12.12.Apply a “stepwise refinement approach” to develop three different levels of

do while (process flag true and significant digits remain)

12.16. Why is design for testing so important?

1. Data design elements

appropriate security features.