BC0049- Software Engineering

Question.1- What is Software Maintenance? Explain its types. Also

explain the Maintenance Process.

Answer 1 - Software Maintenance
Maintenance refers to the support phase of software development.
Maintenance focuses on CHANGE associated with error correction,
adaptations required as the software environment evolves, and changes
due to enhancements brought about by changing customer
requirements or improved capability on the part of developers. Four
types of maintenance are typically encountered.
Correction
Even with the best quality assurance activities, it is likely that the
customer will uncover defects in the software. Corrective maintenance
changes the software to correct defects.
Adaption
Overtime, the original environment (e.g., CPU, operating system,
business rules, external product characteristics) for which the software
was developed is likely to change. Adaptive Maintenance results in
modification to the software to accommodate changes to its external
environment.
Enhancement
As software is used, the customer/user will recognize additional
functions that will provide benefit. Perfective Maintenance extends the
software beyond its original functional requirements. Developers can
also initiate enhancements by utilizing their experience on similar project
and replicating the same on earlier developed systems.

Question.2 What are the drawbacks of Rapid Application
Development (RAD)?

Answer 2 - Drawbacks of the RAD model:
For large but scalable projects, RAD requires sufficient human
resources to create the right number of RAD teams.
RAD requires developers and customers who are committed to
the rapid-fire acitivites necessary to get a system complete in a
much abbreviated time frame. If commitment is lacking from
either, RAD projects will fail.
Not all types of applications are appropriate for RAD. If a system
cannot be properly modularized, building the components
necessary for RAD will be problematic. If high performance is
an issue and performance is to be achieved through tuning the
interfaces to system components, the RAD approach may not
work.
RAD is not appropriate when technical risks are high. This
occurs when a new application makes a heavy use of new
technology or when the new software requires a high degree of
interoperability with existing computer programs.

Question.3- What is Verification and Validation? Explain the
Validation Test Criteria.

Answer 3- Software testing is one element of a broader topic that is
often referred to as verification and validation (V&V). Verification refers
to the set of activities that ensure that software correctly implements a
specific function. Validation refers to a different set of activities that
ensure that the software that has been built is traceable to customer
requirements. Boehm states this in another way:
Verification: "Are we building the product right?"
Validation: "Are we building the right product?"
The definition of V&V encompasses many of the activities that we
have referred to as software quality assurance (SQA). Testing does
provide the last bastion from which quality can be assessed and, more
pragmatically, errors can be uncovered. But testing should not be
viewed as a safety net. As they say, "You can't test in quality. If it's not
there before you begin testing, it won't be there when you're finished
testing." Quality is incorporated into software throughout the process of
software engineering. Proper application of methods and tools, effective
formal technical reviews, and solid management and measurement all
lead to quality that is confirmed during testing.
Miller relates software testing to quality assurance by stating that
"the underlying motivation of program testing is to affirm software
quality with methods that can be economically and effectively applied to
both large-scale and small-scale systems."

Validation Test Criteria
Software validation is achieved through a series of black box tests that
demonstrate conformity with requirements. A test plan outlines the
classes of tests to be conducted and a test procedure defines specific
test cases that will be used to demonstrate conformity with requirements.
Both the plan and the procedure are designed to ensure that all
functional requirements are satisfied, all performance requirements are
achieved, documentation is correct and human-engineered, and other
requirements are met (e.g., transportability, compatibility, error recovery,
maintainability).
After each validation test case has been conducted, one of the two
possible conditions exist:
1. The function or performance characteristics conform to specification
and are accepted, or
2. A deviation from specification is uncovered and a deficiency list is
created.
Deviation or error discovered at this stage in a project can rarely be
corrected prior to scheduled completion. It is often necessary to
negotiate with the customer to establish a method for resolving
deficiencies.

Question.4- Explain Data-flow design.

Answer 4- Data flow design
Data-flow design is concerned with designing a sequence of
functional transformations that convert system inputs into the required.
The design is represented as data-flow diagrams. These diagrams
illustrate how data flows through a system and how the output is derived
from the input through a sequence of functional transformations.
Data-flow diagrams are a useful and intuitive way of describing a
system. They are normally understandable without special training,
especially if control information is excluded. They show end-to-end
processing that is, the flow of processing from when data enters the
system to where it leaves the system can be traced.
Data-flow design is an integral part of a number of design methods
and most CASE tools support data-flow diagram creation. Different
methods may use different icons to represent data-flow diagram entities
but their meanings are similar. The notation which use is based on the
following symbols:
Rounded rectangles represent functions, which transform
inputs to outputs. The transformation name indicates its function.
Rectangles represent data stores. Again, they should be given
a descriptive name.
Circles represent user interactions with the system which
provide input or receive output.
Arrows show the direction of data flow. Their name describes
the data flowing along that path.
The keywords and and or. These have their usual meanings
as in Boolean expressions. They are used to link data flows
when more than one data flow may be input or output from a
transformation.
Question.5- Explain White-Box testing?

Answer 5- White-Box testing
White-box testing, sometimes called glass-box testing, is a test case
design method that uses the control structure of the procedural design to
derive test cases. Using white-box testing methods, the software
engineer can derive test cases that (1) guarantee that all independent
paths within a module have been exercised at least once, (2) exercise all
logical decisions on their true and false sides, (3) execute all loops at
their boundaries and within their operational bounds, and (4) exercise
internal data structures to ensure their validity.
A reasonable question might be posed at this juncture: "Why spend
time and energy worrying about (and testing) logical minutiae when we
might better expend effort ensuring that program requirements have
been met?' Stated another way, why don't we spend all of our energy on
black-box tests? The answer lies in the nature of software defects:
Logic errors and incorrect assumptions are inversely
proportional to the probability that a program path will be
executed. Errors tend to creep into our work when we design
and implement function, conditions, or control that are out of the
mainstream. Everyday processing tends to be well understood
(and well scrutinized), while 'special case' processing tends to
fall into the cracks.
We often believe that a logical path is not likely to be executed
when, in fact, it may be executed on a regular basis. The logical
flow of a program is sometimes counterintuitive, meaning that
our unconscious assumptions about flow of control and data
may lead us to make design errors that are uncovered only once
path testing commences.
Typographical errors are random. When a program is translated
into programming language source code, it is likely that some
typing errors will occur.
Many will be uncovered by syntax and type checking
mechanisms, but others may go undetected until testing begins.
it is as likely that a typo will exist on an obscure logical path as
on a mainstream path.
Each of these reasons provides an argument for conducting white-box
tests. Black-box testing, no matter how thorough, may miss the kinds of
errors noted here. White- box testing is far more likely to uncover them.




Question.6- What is Top-down integration and Bottom-up
integration?

Answer 6- Top-down Integration
Top-down integration testing is an incremental approach to
construction of program structure. Modules are integrated by moving
downward through the control hiearchy, beginning with the main control
module (main program). Modules subordinate (and ultimately
subordinate) to the main control module are incorporated into the
structure in either a depth-first or breadth first manner.


Top-down Integration


Bottom-up Integration
Bottom-up integration testing, as its name implies, begins construction
and testing with atomic modules (i.e., components at the lowest levels in
the program structure). Because components are integrated from the
bottom up, processing required for components subordinate to a given
level is always available and the need for stubs is eliminated.




Bottom-up Integration