se question bank

7/29/2019 SE Question bank

1/29

ANNA UNIVERSITY OF TECHNOLOGY, COIMBATORE

B.E./B.TECH. DEGREE EXAMINATIONS: APRIL/ MAY2011 REGULATIONS: 2008

FOURTH SEMESTER - INFORMATION TECHNOLOGY

080250013 - SOFTWARE ENGINEERING AND QUALITY ASSURANCE

Batch: 2008

Date of Examination: 21.04.11 Regulation of Syllabus: 2008

PARTA

Answer ALL Questions

1. What does System engineering model accomplish?System Engineering is a modeling process. It accomplishes following things

1. The process that needs a view of consideration is defined2. Behaviour of the system is represented3. Exogenous and endogenous input are defined4. All linkages for understanding each view must be represented2. Differentiate between verification and validation

Verification Validation

Are we building the product right? Are we building the right product?The Software should conform to itsspecification

The software should do what the user reallyrequires

The inputs of verification are checklists, issues

list, walkthroughs and inspection meeting,

reviews and meetings

The input of validation is the actual testing of

an actual product

The output of verification is a nearly perfect set

of documents, plans, specification and

requirements document

The output of validation is a nearly perfect,

actual product

3. Define Software engineeringDefinition by Fritz BallerSoftware engineering is the establishment and use of sound engineering principles in order toobtain economically software that is reliable and works efficiently on real machines.

IEEE Definition

Software Engineering is the application of a systematic, disciplined, quantifiable approach tothe development, operation, and maintenance of software; that is, the application of

engineering to software.

Definition by Sommerville

Software engineering is concerned with software systems developed by teams rather thanindividual programmers, user engineering and is made up of both technical and non-technical

aspects.

4. How does project risk factor affect the spiral model of software development?The spiral model demands considerable risk assessment because if a major risk is notuncovered and managed, problem will occur in the project and then it will not be acceptable

by end user.

5. Compare the product engineering and process engineering


2/29

Product engineering Process engineering

The goal of product engineering is to translate

the customers desire for a set of defined

capabilities into a working product.

The goal of process engineering is to define

architectures that will enable a business to use

information effectively

The various views used here is Requirementsengineering, Component engineering, Analysis

and Design modeling and Construction and

Integration

The various view used here is InformationStrategy Planning, Business Area Analysis,

Business System Design and Construction and

Integration

6. Identify ambiguities and omissions in the functional requirements, What questionswould you ask to clarify these functional requirements

Following are the questions that must be asked to clarify the functional requirements

Is the reqiurement specification clear?Can it be misinterpreted? What are the sources of requirements? Is the final requirement specification as per the

original source?

Is there any requirements violation for domain constructs? What are the other related requirements of the current requirements? And are they cross

verified?

For tracing the requirements is there any system model? Is the requirements testable? Has an index specification created for the requirements? Is the requirement satisfying the system objective?7. How to select the appropriate prototyping approach?

There are two prototyping approaches namely throwaway and evolutionary. The selection

among these prototyping is based on certain questions namely as follows

Questions Evolutionary

prototyping

Throwaway

prototyping

Is Application domain understood? Yes Yes

Can the problem be modeled? Yes Yes

Are the requirements established and stable? Yes No

Is the customer knows the basic requirements? Yes/No Yes/No

Are there some ambiguous requirements? No Yes

Are there Contradictions in requirements? No Yes


3/29

8. What is data dictionary? Where it is used in software engineering?The data dictionary represents all of the names used in the system models. Thedescription of the entities, relationships and attributes are also included in data dictionary.

The data dictionary is used during the structured analysis for providing the detail

information of the data objects being used in DFD. Nowadays, the data dictionary is

implemented as a part of CASE.

9. What do you mean by horizontal and vertical partitioning?Horizontal partitioning defines separate branches of the modular hierarchy for each majorprogram function.

Vertical partitioning, often called factoring, suggests that control (decision making) and

work should be distributed top-down in the program structure.

10.Brief the importance of user interfaceAn experienced user can use the system easily with the user interface.

The users can switch from one task to another very easily. He can also interact with manyapplications simultaneously. The application information remains visible in its own

window.

Fast and full screen interaction is possible with user.

11.Justify the term: design is not coding and coding is not designThis is one of the design principles that are to be applied while designing the software

systems. This means that level of abstraction o design model should be higher than the

source code. At the time of coding, whatever design decisions are made can beimplemented. Hence design should be such that it can be transformed into source code.

Similarly, during coding it is not desired to do design to fulfill the requirements.

12.State the guidelines for modular designThe Guidelines for modular design can be given as

Achieve the functional independence

High level of cohesion should be achieved

There should be minimum number of coupling

13.Why testing is important with respect to software?The software testing is an important activity carried out in order to improve the quality ofthe software. A testing process focuses on logical internals of software ensuring that all

statements have been tested and all are functional externals. While testing, we execute the

entire program before it gets to the customer with specific indent of finding and removingall errors. In order to find the highest number of errors, test must be conducted

systematically and test cases must be designed using disciplined techniques.

14.How regression and stress tests are performed?


4/29

Regression testing is used to check for defects propagated to other modules by changesmade to existing program. Thus regression testing is used to reduce the side effects of the

changes.

Stress testing determines breakpoints of a system to establish maximum service level. In

stress testing the system is executed in a manner that demands resources in abnormal

quantity, frequency or volume.

15.What is cyclomatic complexity? How to calculate this?Cyclomatic complexity is software metric that provides a quantitative measure of thelogical complexity of a program. Cyclomatic complexity can be calculated using the

formula

V(G)=E-N+2Where E= Number of egdes in a graph

N=Number of nodes in a graph

16.When do you stop testing? Justify your answer with two illustrationsSome factors which decide when to stop testing is as follows:

When the testing cost is increasing and if it is more than the project cost then it isenough to test

If the project deadline and testing deadline is already crossed After completion of critical or key test cases one can stop testing If the project is meeting functional coverage, code coverage or satisfying the

client requirements at some point

When high priority bugs are resolved and defect rates fall below certain specifiedlevel.

Examples

1. For sorting a list of elements typical test cases can be like testing unsorted list, testingwhen equal elements are present, testing empty list and testing with negative

numbers. This much testing is sufficient because it satisfies the major requirements of

the function.

2. In the development of Windows OS the IE is a famous web browser that we use.There are many security patches that need to be applied. Some patches are already

introduced with newer versions of OS. But still this product specially shows how

testing is an endless process

17.Define SQASoftware Quality Assurance (SQA) is the process of defining how software quality can

be achieved and how the development organisation knows that the software has the

required level of quality


5/29

18.What are the parameters used for software configuration?The various parameters used for software configuration are

identification, version control, change control, configuration auditing, and reporting

19.What is the need for SCM?The SCM is concerned with managing the changes in the evolving software. If the

changes are not controlled at all then this stream of uncontrolled changes can cause the

well running project into chaos. Hence it is essential to identify, control, implement and

report these changes.

20.Define the term product qualityThe Conformance to explicitly stated functional and performance requirements, explicitly

documented development standards, and implicit characteristics that are expected of all

professionally developed software is known as Software Quality. The quality of a

developed product is influenced by the quality of the production process. This means

Product quality is related to the development process.

PART B

ANSWER ANY FIVE QUESTIONS

21.a) Explain about system engineering concepts and briefly describe on Productengineering

System Engineering is the activity of Specifying, designing, implementing, validating,

deploying and maintaining socio-technical systems.

System engineers are not just concerned with the services provided by the system, but

they must think about the constraints on its construction and operation and the ways in

which it is used.

The Various activities in system engineering are

System Requirement analysis

System Design

Sub-System Deveoplment

System integration

System Installation

System Evolution


6/29

System Decomissiong

System Requirement analysis

Three types of requirement defined at this stage Abstract functional requirements. System functions are defined in an abstract way System properties. Non-functional requirements for the system in general are

defined

Undesirable characteristics. Unacceptable system behaviour is specified Should also define overall organisational objectives for the systemSystem Design Process

System design is concerned with how the system functionality is to be provided by the

components of the system. The activities involved in this process are

1. Partition requirements Organise requirements into related groups.

2. Identify sub-systems Identify a set of sub-systems which collectively can meet the system

requirements.

3. Assign requirements to sub-systems Causes particular problems when COTS are integrated.

4. Specify sub-system functionality.5. Define sub-system interfaces

System Modeling

An architectural model presents an abstract view of the sub-systems making up a system.

They may include major information flows between sub-systems. The system architecture

may be presented as a block diagram. They may identify different types of functional

component in the model.

Sub-system development

Partition

Re uirement

Identify Sub

s stems

Define sub system

interface

Specify Sub sytem

Functionalit

Assign Requirements to

sub s stem


7/29

During sub-system development, the sub-systems identified during system design areimplemented. This may involve starting another system engineering process for individual

sub-systems.

System integration

During system integration process, you take the independently developed sub-systems and

put them together to make up a complete system

System Evolution

Large systems have a long lifetime. They must evolve to meet changing requirements

Evolution is inherently costly because

Changes must be analysed from a technical and business perspective Sub-systems interact so unanticipated problems can arise The reason for original design decisions are often unrecorded. System structure is corrupted as changes are made to it

System decommissioning

System decommissioning means taking the system out of service after the end of its useful

operational lifetime.

Product engineering

The goal of product engineering is to translate the customers desire for a set of defined

capabilities into a working product.

To achieve this goal, product engineeringlike business process engineeringmust derive

architecture and infrastructure.

In case of product engineering , the views used are discussed below

Requirements engineeringworld view Component engineeringdomain view Analysis and Design modelingelement view (software engineers) Construction and Integrationdetailed view (software engineer)


8/29

b) Compare and contrast the Waterfall model with spiral model

Waterfall Model Spiral Model

It requires well understanding of

requirements and familiar Technology

It is developed in iterations. Hence therequirements can be identified at new

iterations

Difficult to accommodate changes after theprocess has started.

The required changes can be made at everystage of new version

Can accommodate iteration but indirectly It is iterative model

Risks can be identified at the end which

may cause failure to the product

Risks can be identified and reduced before

they get problematic

The customer can see the working model of

the project only at the end. After reviewingof the working model, if the customer gets

The customer can see the working product

at certain stages of iterations


9/29

dissatisfied then it causes serious problem

Customers prefer this model Developers prefer this model

This model is good for small systems This model is good for large systems

It has sequential nature It has evolutionary nature

22.a) What are the necessities of life cycle model? Elaborate on the various issues ofsoftware life cycle

The process model is chosen based on the nature of software project and application and

then to obtain deliverable product method and tools are applied.

Using problem solving loop the software development can be done. The problem solving

loop includes

The existing status that represents current state of affairs

In the problem identification phase particular problem is identified

The technical development stage is for solving the identified problem using anappropriate technology

Finally solution integration is responsible for delivering the result.But applying such problem solving loop in software development process is very difficult

because we cannot strictly categorize the development in these phases. There may be arequirement of cross talk within and across stages. Hence some software process models

are suggested depending upon the nature of software. Such models are called generic

software models.

b) write short note on data modeling

Data modeling answers What are the primary data objects to be processed by the system? What is the composition of each data object and what attributes describe the object? Where do the the objects currently reside? What are the relationships between each object and other objects? What are the relationships between the objects and the processes that transform them?

The ERD, enables a software engineer to identify data objects and their relationships using a graphical

notation. In the context of structured analysis, the ERD defines all data that are entered, stored,

transformed, and produced within an application.

Data objects

A data object is a representation of almost any composite information that must be understood by

software. By composite information, we mean something that has a number of different properties or

attributes.


10/29

Attributes.

Attributes define the properties of a data object and take one of three differentcharacteristics. They can be used to

(1) name an instance of the data object,

(2) describe the instance, or

(3) make reference to another instance in another table.

In addition, one or more of the attributes must be defined as an identifierthat is, the identifierattribute becomes a "key" when we want to find an instance of the data object.

Relationships

Data objects are connected to one another in different ways. Consider two data objects, book and

bookstore.

We can define a set of object/relationship pairs that define the relevant relationships. For example,

A bookstore orders books. A bookstore displays books. A bookstore stocks books.

A bookstore sells books.

A bookstore returns books.

Relationships. Data objects are connected to one another in different ways. Consider twodata objects, book and bookstore.

Cardinality: The data model must be capable of representing the number of occurrencesobjects in a

given relationship.

One-to-one (l:l) One-to-many (l:N). Many-to-many (M:N)

Modality. The modality of a relationship is 0 if there is no explicit need for the relationship to occur or

the relationship is optional. The modality is 1 if an occurrence of the relationship is mandatory.


11/29

23. a) Draw an ER diagram for the relationship of manufacturer and dealership. Also specifythe association, cardinality and modality

b) What is Requirement Engineering? State its process and explain requirement

elicitation problem?


12/29

Requirements engineering is the process of establishing the services that the customer

requires from a system and the constraints under which it operates and is developed.

The above diagram shows the requirements engineering process showing the various steps in it.

The processes used for RE vary widely depending on the application domain, the people

involved and the organisation developing the requirements.

However, there are a number of generic activities common to all processes

Requirements elicitation; Requirements analysis; Requirements validation; Requirements management.

Requirements elicitation problems

Stakeholders may have unrealistic expectations

Stakeholders dont know what they really want.

Stakeholders express requirements in their own terms or in their own language.

Different stakeholders may have conflicting requirements.

Organisational and political factors may influence the system requirements.


13/29

The requirements change during the analysis process. New stakeholders may emerge and the

business environment change.

24. a) Briefly explain the various design concepts considered during designA set of fundamental software design concepts has evolved over the past four decades. The various

design concepts are as follows:

Data abstractiondata, procedure, control Refinementelaboration of detail for all abstractions Modularitycompartmentalization of data and function Software architectureoverall structure of the software

Structural properties Extra-structural properties Styles and patterns

Control Hierarchy Structural Partitioning Data Structure Software procedurethe algorithms that achieve function Information hidingcontrolled interfaces

Data Abstraction

A procedural abstraction is a named sequence of instructions that has a specific and limited

function. An example of a procedural abstraction would be the word open for a door. Open implies a longsequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door,

step away from moving door, etc.).

A data abstraction is a named collection of data that describes a data object. The data abstraction

for door would encompass a set of attributes that describe the door (e.g., door type, swing direction,

opening mechanism, weight, dimensions).

Control abstraction is the third form of abstraction used in software design. Like procedural and

data abstraction, control abstraction implies a program control mechanism without specifying internal

details

Refinement

Refinement is actually a process of elaboration. We begin with a statement of function that is

defined at a high level of abstraction. That is, the statement describes function or informationconceptually but provides no information about the internal workings of the function or the internal

structure of the information. Refinement causes the designer to elaborate on the original statement,

providing more and more detail as each successive refinement occurs.Abstraction and refinement are complementary concepts. Abstraction enables a designer to

specify procedure and data and yet suppress low-level details. Refinement helps the designer to reveal

low-level details as design progresses. Both concepts aid the designer in creating a complete design model

as the design evolves.

Modular Design


14/29

Meyer defines five criteria that enable us to evaluate a design method with respect to its ability to

define an effective modular system:

Modular decomposability.

If a design method provides a systematic mechanism for decomposing the problem into subproblems, it will reduce the complexity of the overall problem, thereby achieving an effective

modular solution.

Modular composability.

If a design method enables existing (reusable) design components to be assembled into a newsystem, it will yield a modular solution that does not reinvent the wheel.

Modular understandability.

If a module can be understood as a standalone unit (without reference to other modules), itwill be easier to build and easier to change.

Modular continuity.

If small changes to the system requirements result in changes to individual modules, ratherthan system wide changes, the impact of change-induced side effects will be minimized.

Modular protection.

If an aberrant condition occurs within a module and its effects are constrained within thatmodule, the impact of error-induced side effects will be minimized.

Software Architecture

The overall structure of the software and the ways in which that structure provides conceptualintegrity for a system.

Set of properties that should be specific as part of an architectural design

Structural properties:

The architecture design defines the system components and their interactions.

Extra-functional properties:

The architecture design should address how the design architecture achieves requirements for

performance, capacity, reliability, adaptability, security.

Families of related systems:

The architecture design should draw upon repeatable patterns in the design of families of similar

systems.

Control Hierarchy

Control hierarchy, also called program structure, represents the organization of programcomponents (modules) and implies a hierarchy of control.

It does not represent procedural aspects of software such as sequence of processes, occurrence ororder of decisions, or repetition of operations; nor is it necessarily applicable to all architectural

styles.


15/29

Different notations are used to represent control hierarchy for those architectural styles that areamenable to this representation.

The most common is the treelike diagram that represents hierarchical control for call and returnarchitectures

Two Characteristics of Software Architecture

Visibility indicates the set of program components that may be invoked or used as data by a givencomponent, even when this is accomplished indirectly

Connectivity indicates the set of components that are directly invoked or used as data by a givencomponent.

Structural Partitioning

If the architectural style of a system is hierarchical, the program structure can be partitioned bothhorizontally and vertically. H

Horizontal partitioning defines separate branches of the modular hierarchy for each majorprogram function. The below diagram shows the horizontal partitioning.

Partitioning the architecture horizontally provides a number of distinct benefits: software that is easier to test software that is easier to maintain propagation of fewer side effects software that is easier to extend


16/29

On the negative side, horizontal partitioning often causes more data to be passed across moduleinterfaces and can complicate the overall control of program flow

Vertical partitioning often called factoring, suggests that control and work should be distributedtop-down in the program structure.

Vertical Partitioning

Data Structure

Data structure is a representation of the logical relationship among individual elements of dataSoftware Procedure

Program structure defines control hierarchy without regard to the sequence of processing anddecisions.

Software procedure focuses on the processing details of each module individually. Procedure must provide a precise specification of processing, including sequence of events, exact

decision points, repetitive operations, and even data organization and structure.

Information Hiding

The principle ofinformation hiding suggests that modules be "characterized by design decisionsthat (each) hides from all others."

Why Information Hiding?

reduces the likelihood of side effects limits the global impact of local design decisions emphasizes communication through controlled interfaces leads to encapsulationan attribute of high quality design results in higher quality software

b) Write short notes on real time executives

Real-time executives are specialized operating systems which are used to manageprocesses in RTS

The Standard RTE kernel can be modified for particular application The real time executives does not support file management.


17/29

The Real Time Executive Components are Real-time clock - Information for process scheduling Interrupt handler - Manages aperiodic requests for service. Scheduler - Chooses next process to be run

Resource manager - Allocates memory and processor resources

Dispatcher - Starts process execution Non-Stop System Components

Configuration manager - Dynamic reconfiguration of system software, hardwarewithout stopping systems. In Dynamic reconfiguration the hardware can be

completely replaced and software can be upgraded without stopping the systems.

Fault managerIt Detects software and hardware faults. On detecting the faults itis responsible to take appropriate actions. E.g. switch to backup disks

Real-Time Executive Components process various types of stimuli. Processing sometypes of stimuli must sometimes take priority

Interrupt level priority - Highest priority allocated to processes requiring very fastresponse

Clock level priority - Allocated to periodic processes Further levels of priority may be assigned within these levels

Interrupt ServicingWhen a current process is interrupted for processing a high priorityprocess, first the control is transferred automatically to pre-determined memory location.

This contains instruction to jump to interrupt service routine. Hence the control is passed

to ISR. Further interrupts disabled, and interrupt is serviced. Finally the control returned

to interrupted process. The necessary thing is interrupt service routines MUST be short,

simple and fast

Periodic Process Servicing The periodic process are assigned with different periods(time between executions), Different execution times, Different deadlines (time by which

processing must be completed). The process manager schedules the periodic process

when an interrupt is caused by real-time clock tick. Each tick causes interrupt which

schedules process manager for periodic processes. Process manager selects process

among those ready for execution

RTE Process Management Process Switching Scheduler


18/29

Chooses next process to be executed by processor Depends on scheduling strategy

May take process priority into account Resource manager

Allocates memory and processor

Dispatcher Takes process from ready list, Loads it onto processor Starts execution

Scheduling Strategies Non pre-emptive scheduling

Process runs to completion Or until blocked (e.g. pending I/O)

Pre-emptive scheduling Execution of executing processes may be stopped If higher-priority process requires service

Scheduling algorithms example Round-robin Rate monotonic Shortest deadline first

25. a) Explain the different integration testing approachesIntegration testing is a systematic technique for constructing the program structure while at the same time

conducting tests to uncover errors associated with interfacing. The objective is to take unit tested

components and build a program structure that has been dictated by design.

Big Bang" approach all the components are combined and then tested as a whole.

Incremental integration the program is constructed and tested as small increments.

Top-Down Integration


19/29

Beginning with main module, modules are integrated by moving downward through the control hierarchy.

Subordinate modules are added into the structure either depth-firstor breadth-first

Verifies major control or decision points early in testing

Problem when lower level processes needed to test upper levels

Top-Down Integration Process

Beginning at main module, stubs are replaced one at a time with actual modules

Tests are conducted as each module is integrated

On the completion of each set of tests, another stub is replaced with real module

Regression testing (conduct all or some of previous tests) may be done to ensure no new errors have been

introduced

Bottom-Up Integration

Begins construction and testing with atomic modules (lowest level in hierarchy)

No need for stubs, all subordinate modules tested and available

Test drivers required and can be shared as integration move towards the higher levels

Bottom-Up Integration Process

Low-level modules are combined into clusters

A driver is written to coordinate test case input and output

The cluster is tested


20/29

Drivers are removed and clusters are combined moving upward in the program structure

Smoke Testing

The smoke testing approach encompasses the following activities:

1. Software components that have been translated into code are integrated into a build. A build includes

all data files, libraries, reusable modules, and engineered components that are required to implement oneor more product functions.

2. A series of tests is designed to expose errors that will keep the build from properly performing itsfunction. The intent should be to uncover errors that have the highest likelihood of throwing the software

project behind schedule.

3. The build is integrated with other builds and the entire product (in its current form) is smoke tested

daily. The integration approach may be top down or bottom up.

Advantages of Smoke Testing

Integration risk is minimized. The quality of the end-product is improved Error diagnosis and correction are simplified. Progress is easier to assess

Validation Testing

Validation can be defined in many ways, but a simple (albeit harsh) definition is that validation succeeds

when software functions in a manner that can be reasonably expected by the customer.

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 casesthat will be used to demonstrate conformity with requirements.

Both the plan and procedure are designed to ensure that

all functional requirements are satisfied, all behavioral characteristics are achieved, all performance requirements are attained, documentation is correct, and other requirements are met (e.g., transportability, compatibility, maintainability).

Thealpha test is conducted at the developer's site by a customer. The software is used in a natural setting

with the developer "looking over the shoulder" of the user and recording errors and usage problems.

The beta test is conducted at one or more customer sites by the end-user of the software. Unlike alpha

testing, the developer is generally not present.

The customer records all problems (real or imagined) that are encountered during beta testing and reports

these to the developer at regular intervals.


21/29

As a result of problems reported during beta tests, software engineers make modifications and then

prepare for release of the software product to the entire customer base.

b) Distinguish between black box and white box testing

Black Box Testing White Box Testing

Black box testing is called behavioural testing White box testing is called glass box testing

Black box testing examines some fundamental

aspects of the system with little regard for

internal logical structure of the software

In white box testing the procedural details, all

logical paths, all the internal data structures are

closely examined.

During black box testing the program cannot

be tested 100 percent

White box testing lead to test the program

thoroughly.

This type of testing is suitable for large

projects.

This type of testing is suitable for small

projects.

26. a) Why unit testing is so important? Explain the concept of unit testing in detail. Unit Testing is the first level of testing and the most important one. Detecting and

fixing bugs early on in the Software Lifecycle helps reduce costly fixes later on. An

Effective Unit Testing Process can and should be developed to increase the Software

Reliability and credibility of the developer.

Unit testing focuses verification effort on the smallest unit of software design thesoftware component or module.

Unit Test Considerations

The module interface is tested to ensure that information properly flows into and out ofthe program unit under test.

The local data structure is examined to ensure that data stored temporarily maintains itsintegrity during all steps in an algorithm's execution.

Boundary conditions are tested to ensure that the module operates properly atboundaries established to limit or restrict processing.

All independent paths (basis paths) through the control structure are exercised to ensurethat all statements in a module have been executed at least once.

And finally, all error handling paths are tested.


22/29

Because a component is not a stand-alone program, driver and/or stub software must bedeveloped for each unit test.

In most applications a driver is nothing more than a "main program" that accepts testcase data, passes such data to the component (to be tested), and prints relevant results.

Stubs serve to replace modules that are subordinate (called by) the component to betested.

A stub or "dummy subprogram" uses the subordinate module's interface, may do minimaldata manipulation, prints verification of entry, and returns control to the module

undergoing testing.

b) Explain the regression testing

Each time a new module is added as part of integration testing, the software changes.New data flow paths are established, new I/O may occur, and new control logic is

invoked. These changes may cause problems with functions that already tested.

In the context of an integration test strategy, regression testing is the re-execution ofsome subset of tests that have already been conducted to ensure that changes have not

propagated unintended side effects.

Regression testing is the activity that helps to ensure that changes do not introduceadditional errors.

Regression testing may be conducted manually, by re-executing a subset of all test cases . Regression testing is an important strategy for reducing side effects. Run regression

tests every time a major change is made to the software.

The regression test suite (the subset of tests to be executed) contains three different

classes of test cases:


23/29

A representative sample of tests that will exercise all software functions. Additional tests that focus on software functions that are likely to be affected by the

change.

Tests that focus on the software components that have been changed.27. a) How to derive the test case for the given project? Explain with exampleThe basis path testing method can be applied to a procedural design or to source code.

The following steps can be applied to derive the basis set:

1. Using the design or code as a foundation, draw a corresponding flow graph. A flow graph

is created using the symbols and construction rules. Referring to the PDL for average as shownbelow, a flow graph is created by numbering those PDL statements that will be mapped into

corresponding flow graph nodes. The corresponding flow graph is shown below after the

procedure


24/29

2. Determine the cyclomatic complexity of the resultant flow graph.The cyclomatic complexity, V(G), is determined by applying the algorithms. It should be noted

that V(G) can be determined without developing a flow graph by counting all conditionalstatements in the PDL (for the procedure average, compound conditions count as two) and

adding 1.V(G) = 6 regionsV(G) = 17 edges _ 13 nodes + 2 = 6

V(G) = 5 predicate nodes + 1 = 6

3. Determine a basis set of linearly independent paths.The value of V(G) provides the number of linearly independent paths through the programcontrol structure. In the case of procedure average, we expect to specify six paths:

path 1: 1-2-10-11-13

path 2: 1-2-10-12-13path 3: 1-2-3-10-11-13

path 4: 1-2-3-4-5-8-9-2-. . .

path 5: 1-2-3-4-5-6-8-9-2-. . .

path 6: 1-2-3-4-5-6-7-8-9-2-. . .The ellipsis (. . .) following paths 4, 5, and 6 indicates that any path through the remainder of the

control structure is acceptable. It is often worthwhile to identify predicate nodes as an aid in the

derivation of test cases. In this case, nodes 2, 3, 5, 6, and 10 are predicate nodes.

4. Prepare test cases that will force execution of each path in the basis set.Data should be chosen so that conditions at the predicate nodes are appropriately set as each path

is tested. Test cases that satisfy the basis set just described are

Path 1 test case:value(k) = valid input, where k< i for 2 i 100

value(i) = _999 where 2 i 100Expected results: Correct average based on kvalues and proper totals.


25/29

Note: Path 1 cannot be tested stand-alone but must be tested as part of path 4, 5, and 6 tests.

Path 2 test case:

value(1) = _999Expected results: Average = _999; other totals at initial values.

Path 3 test case:Attempt to process 101 or more values.

First 100 values should be valid.Expected results: Same as test case 1.

Path 4 test case:value(i) = valid input where i < 100

value(k) < minimum where k< i

Expected results: Correct average based on kvalues and proper totals.

Path 5 test case:

value(i) = valid input where i < 100value(k) > maximum where k


26/29

a) Software Configuration ManagementSoftware configuration management is a set of activities that have been developed to

manage change throughout the life cycle of computer software.

The Software Configuration Management Process

SCM is responsible for the identification of individual SCIs and various versions of the

software, the auditing of the software configuration to ensure that it has been properlydeveloped, and the reporting of all changes applied to the configuration.

Activities of Software Configuration Management process

Identification, Version control, Change control,

Configuration auditing, and

ReportingIdentification of Objects

Two types of objects can be identified basic objects and aggregate objects.

A basic object is a "unit of text" that has been created by a software engineer during

analysis, design, code, or test.

An aggregate object is a collection of basic objects and other aggregate objects.

An object can be identified as an aggregate object.

The relationship defines a hierarchy of objects. For example, using the simple

notation

E-R diagram 1.4 data model;

data model design specification;

The interrelationships between configuration objects can be represented with a module

interconnection language (MIL)

The evolution graph describes the change history of an object

Version Control

Version control combines procedures and tools to manage different versions of configuration

objects that are created during the software process.

An entity is composed of a collection of objects at the same revision level.


27/29

A variant is a different collection of objects at the same revision level and therefore coexists

in parallel with other variants.

A new version is defined when major changes are made to one or more objects.

Change Control

Change control is vital. But the forces that make it necessary also make it annoying. We

worry about change because a tiny perturbation in the code can create a big failure in theproduct. But it can also fix a big failure or enable wonderful new capabilities.

Configuration Audit

A software configuration audit complements the formal technical review by assessing a

configuration object for characteristics that are generally not considered during review.

1. Has the change specified in the ECO been made? Have any additional modifications been

incorporated?

2. Has a formal technical review been conducted to assess technical correctness?

3. Has the software process been followed and have software engineering standards been

properly applied?


28/29

4. Has the change been "highlighted" in the SCI? Have the change date and change author

been specified? Do the attributes of the configuration object reflect the change?

5. Have SCM procedures for noting the change, recording it, and reporting it been followed?

6. Have all related SCIs been properly updated?

Status Reporting

Configuration status reporting (sometimes called status accounting) is an SCM task that

answers the following questions: (1) What happened? (2) Who did it? (3) When did it

happen? (4) What else will be affected?

b) Software Quality planning and controlQuality Planning

A quality plan sets out the desired product qualities and how these are assessed and defines the most

significant quality attributes.

The quality plan should define the quality assessment process.

It should set out which organisational standards should be applied and, where necessary, define new

standards to be used.

Quality plan structure

Product introduction; Product plans; Process descriptions; Quality goals; Risks and risk management.

Quality plans should be short, succinct documents

If they are too long, no-one will read them.Quality Control

This involves checking the software development process to ensure that procedures and standards are

being followed.

There are two approaches to quality control

Quality reviews; Automated software assessment and software measurement.

This is the principal method of validating the quality of a process or of a product.

A group examines part or all of a process or system and its documentation to find potential problems.

There are different types of review with different objectives

Inspections for defect removal (product);


29/29

Reviews for progress assessment (product and process); Quality reviews (product and standards).

Design or program inspections

To detect detailed errors in the requirements, design or code. A checklist of possible errors should drive

the review.

Progress reviews

To provide information for management about the overall progress of the project. This is both a process

and a product review and is concerned with costs, plans and schedules.

Quality reviews

To carry out a technical analysis of product components or documentation to find mismatches between

the specification and the component design, code or documentation and to ensure that defined quality

standards have been followed.

A group of people carefully examine part or all of a software system and its associated documentation.

Code, designs, specifications, test plans, standards, etc. can all be reviewed.

Software or documents may be 'signed off' at a review which signifies that progress to the next

development stage has been approved by management.

se question bank

Documents