1. 1. What is meant by Risk?
The problem that could cause some loss or threaten the success of the
project, but which has not happened yet. The potential problems might have an adverse
impact on cost, schedule, or technical success of the project, the quality of our software
products, or project morale. Risk management is the process of identifying addressing
and eliminating these problems before they can damage the project.
2. Brief HIPO diagram
HIPO diagram were developed at IBM as design representation schemes
Top down software development and as external documentation aids for released
products. HIPO diagram contains a
 visual table of contents
 a set of overview diagrams, and
 a set of detail diagrams.
o The visual table of contents is a directory to the set of diagrams in the
package. It consists of tree-structured directory, a summary of the
contents of each overview diagram, and a legend
3. Brief s/w maintenance
S/W maintenance is the very broad activity that includes error corrections,
enhancements of capabilities, deletion of obsolete capabilities, and optimization. Change
is inevitable, mechanisms must be developed for evaluating, controlling and making
modifications. So any work done to change the software after it is in operation is
considered to be maintenance. The purpose is to preserve the value of the s/w overtime.
The value can be enhanced by expanding the customer base, meeting additional
requirements, becoming easier to use, more efficient and employing newer technology.
Maintenance may span for 50 years, whereas development may be 1-2 years.
4. What are all the solutions to Maintenance Problems
A number of possible solutions to maintenance problems have been suggested.
They include: budget & effort reallocation; complete replacement of existing systems;
and enhancement of existing systems.
Budget & effort Reallocation
It is now-a-days suggested that more time and resources should be invested in the
development-specification & design of more maintainable systems rather than allocating
resources to develop unmentionable or difficult to maintain systems
Complete replacement of the system

2. If maintaining an existing system costs as much as developing a new one, why not
develop a new system from scratch. This point of view is understandable, but in practice
it is not simple. The risk and costs associated with complete system replacement are
very high. Corrective & preventive maintenance take place periodically at relatively
small but incremental costs. Some organization can afford to pay for these comparatively
small maintenance charges while at the same time supporting more ambitious and
financially demanding project may not be possible.
Maintenance of Existing System
Complete replacement of the system is not usually a viable option. An
operational system in itself can be asset to an organization in terms of the investment in
technical knowledge and the working culture engendered. The current system may need
to have the potential to evolve to a higher state.
5. Software Reengineering
Software reengineering is concerned with taking existing legacy systems and re
implementing them to make them more maintainable. As a part of this reengineering
process, the system may be redocumented or restructured. It may be translated to a more
modern programming language, implemented on existing hardware technology. Software
re-engineering allows us to translate source code to a new language, restructure our old
code, migrate to a new platform capture and then graphically display design information,
and redocument documented systems.
New S/W Development
System
Specification
Design &
Implementation
New
System
Re-engineering
Existing
Software
System
Understanding
and
Transformation
Reengineer
ed System

3. The costs of re-engineering depend on the extent of the work that is carried out.
Other factors affecting costs are the quality of the software. The following suggestions
may be useful for the modification of the legacy code:
Study code well before attempting changes
Concentrate on overall control flow not coding
Heavily comment internal code
Create Cross references
Build Symbol tables
Use own variables, constants and declaration to localize the effect of change
Keep detailed maintenance document
Use modern design techniques
6. Define Modularity
Modularity is the way of defining the system as a collection of well defined,
manageable units with well defined interfaces among the units. Desirable properties of a
modular system include:
Each module is a well defined subsystem that is potentially useful in other
applications
Each module has a single, well defined purpose.
Modules can be separately compiled and stored in a library
Modules can use other modules.
Modules should be easier to use than to build
Modules should be simpler from the outside than from the inside.
Modularity is the single attribute from the outside than from the inside be
intellectually manageable. It enhances the design clarity , which in turn eases
implementations, debugging, documenting and maintenance of the s/w product.
7. What do you mean by Abstraction?
Abstraction is the intellectual tool that allows us to deal with concepts apart from
particular instances of those concepts. During requirements definition an design,
abstraction permits separation of the conceptual aspects of a system from the
implementation details. We can specify the FIFO property of a queue or the LIFO
property of a stack without concern for the representation scheme to be used in
implementing the stack or queue.
Three widely used abstraction mechanism in s/w design are
 functional abstraction

4. 

data abstraction
control abstraction.
Functional Abstraction
It involves the use of parameterized subprograms. The ability to parameterize a
subprogram and to bind different parameter values on different invocations of the
subprogram is a powerful abstraction mechanism.
Data Abstraction
It involves specifying a data type or a data object by specifying legal operations
on objects. Represention and manipulation details are suppressed. Abstract data type
is used to denote decleration of data type from which numerous instances can be
created. Abstract data types are abstract in the sense that representation details of the
data items and implementation details of the functions that manipulate the data items
are hidden within the group that implements the abstract type.
Control Abstraction
It is the third commonly used abstraction mechanism in software design. Control
abstraction is used to state a desired effect without stating the exact mechanism of
control. IF statements and WHILE statements in modern programming languages are
abstractions of machine code implementations that involve conditional jump
instructions. A statement of the form
“for all I in S sort files I”
leaves unspecified the sorting techniques, the nature of S, the nature of the files, and
how “for all I in S” is to be handled.
8. What is the Modularization Criteria?
1.
2.
3.
4.
5.
A s/w module to be a named entity has the following characteristics:
Modules contain instruction, processing logic, and data structures
Modules can be separately compiled and stored in a library
Modules can be included in a program
Module segments can be used by invoking a name and some parameters.
Modules can use other modules.
Modularization allows the designer to decompose a system into functional units to
impose hierarchical ordering on functional usage, to implement data abstractions, and
to develop independently useful subsystems.

5. 9. Define Coupling and Cohesion
Coupling is the measure of the degree of interdependence between modules. Two
modules with high coupling are strongly interconnected and thus, dependent on each
other. Two modules with low coupling are not dependent on one another. The strength
of coupling between two modules is influenced by the complexity of the interface, the
type of connection, and the type of communication . Modification of a common data
block or control block may require modification of all routines that coupled to that block.
If modules communicate only parameters, and if the interfaces between modules remain
fixed, the internal details of modules can be modified without having to modify the
routines that use the modified modules. Coupling between modules can be ranked on a
scale of strongest to weakest as follows:
1. Content coupling
2. Common coupling
3. Control coupling
4. Stamp coupling
5. Data coupling
10. Define Cohesion?
Cohesion is the measure of the degree to which the elements of a module are
functionally related. A strongly cohesive module implements functionality that is related
to one feature of the solution and requires little interaction with other modules. The
internal cohesion of a module is measured in terms of the strength of binding of elements
within the module. Cohesion of elements occurs on the scale of weakest to strongest as
follows:
1. Coincidental cohesion
2. Logical Cohesion
3. Temporal cohesion
4. Communication cohesion
5. sequential cohesion
6. Functional Cohesion
7. Informational cohesion
11. What is meant by specification principles?
A number of specification principles adapted from the work of Balzer and
Goldman is as follows:
1. Separate functionality from implementation
2. Develop a model of the described behaviour of a system that encompases the data
and the functional responses of a system to various stimuli from the environment
3. Establish the context in which software operates by specifying the manner in
which other system components interact with software.

6. 4. Define the environment in which the system operates and indicates how “a highly
intertwined collection of agents react to stimuli in the environment produced by
those agents.
5. Create a cognitive model rather than a design or implementation model. The
cognitive model describes a system as perceived by its user community.
12. Give the importance of Risk analysis
Risk always involves two characteristics:
Uncertainity- The event that characterizes the risk may or may not happen; i.e. there
are no 100% probable risk
Loss: If the risk becomes a reality, unwanted consequences or losses will occur.
It is important to quantify the level of uncertainty and the degree of loss associated
with the each risk. Different categories of risks are considered. Different categories
of risks are considered.
Project risk : If project risk become real, it is likely that the project schedule will slip
and that cost will increase.
Technical risks: It threaten the quality and timeliness of the s/w to be produced. If a
technical risk becomes a reality, implementation may become difficult or impossible.
Business risks: It threatens the viability of the s/w to be built.
Known risks: The risks are uncovered after careful evaluation of the project plan, the
business and technical environment in which the project is being developed.
13. Define s/w Reliability
S/W reliability is defined in statistical term as “The probability of failure free
operation of a computer program in a specified environment for a specified
time”
Eg. Program X is estimated to have a reliability of 0.96 over eight elapsed processing
hours. i.e. if a program X were to be executed 100 times and require eight hours of
elapsed processing time, it is likely to operate correctly 96 times out of 100.
According to s/w quality and realiability failure is nonconformance to s/w
requirements. For a computer based system a simple measure of reliability is mean
time between failure (MTBF) where
MTBF = MTTF + MTTR
MTTF - mean time to failure
MTTR – mean time to repair
14. Explain the various classifications of s/w metrics
Project Metrics
Size oriented metrics

7. S/W metrics are derived by normalizing quality and/or productivity
measures by considering the “size “ of the s/w that has been produced . If a s/w
organization maintains simple records, a table of size-oriented measures.
Function oriented metrics
S/w metrics use a measure of the functionality delivered by the application as a
normalization value. Functionality can not be measured directly, it must be derived
indirectly using other direct measures. Measurement is done by function point. Function
points are derived using an empirical relationship based on countable measures of
software’s information domain and assessments of software complexity.
Extended Function Point metrics
The function point metric was originally designed to be applied to business
information systems applications. To accommodate these applications, the data
dimension was emphasized to the exclusion of the functional and behavioral dimensions.
15. Brief COCOMO model
The name COCOMO stands for COnstrutive COst MOdel. It is an hierarchy
model.
Basic COCOMO Model: It computes software development effort as function of
program size expressed in estimated lines of code
Italic COCOMO Model: It computes software development effort as a function of
program size and a set of cost drivers that include subject assessments of product,
hardware, personnel, and project attributes.
Advanced COCOMO Model: It incorporates all characteristics of the intermediate
version with an assessment of the cost driver’s impact on each step of the s/w
engineering process.
16. Give the various s/w testing strategies
White box testing
It is also called as glass box testing. It is a test case design method that uses the
control structure of the procedural design to derive test cases.
Basis path testing method
The basis path method enables the test case designer to derive a logical
complexity measure of a procedural design and use this measure for defining a basis set
of execution paths.
Control structure Testing

8. (i)
Condition Testing
A simple condition is a Boolean variable or a relational expression,
possibly preceded with one NOT operator
(ii)
Data Flow testing
Data flow testing method selects test paths of a program according
to the locations of definitions and uses of variables in the program.
(iii) Loop testing
Black box testing
Black box testing focuses on the functional requirements of the s/w. Black box
testing enables the s/w engineer to derive sets of input conditions that will fully exercise
all functional requirements for a program.
17. What is the need for baseline?
Change is a fact of life in s/w development Customers want to modify
requirements. Developers want to modify technical approach. Managers want to modify
project approach. A baseline is a software configuration management concept that helps
us to control change without seriously impeding justifiable change.
After an initial baseline is established and forzen, every subsequent change is
recorded as delta until the next baseline is set. It is desirable to establish a baseline at an
early point in every project. Establishing a baseline too early, will impose unnecessary
procedures and slow the programmers’ work.
Baseline Scope
For code control, the baseline contains all the project code. The items to be
included for the implementation phase are
o Current level of each module, including source and object code
o Current level of each test case, including source and object code
o The current level of any special test or operational data
o The current level of all macros, libraries, and files
18. Brief the need of SCM
Software configuration management is a set of activities that have been developed
to manage change throughout the the life cycle of computer software. SCM can be
viewed as a s/w quality assurance activity that is applied throughout the s/w process. The
output of the s/w process is information that may be divided into three broad categories
(i)
Computer programs
(ii)
Documents that describes the program
(iii)
Data
As the s/w process progresses , the number of software configuration items(SCIs)
grows rapidly. A system specification spawns a s/w project plan and s/w requirements
specification.

9. 19. List out the s/w configuration items
The following SCIs become the target for configuration management techniques
and form a set of baselines.
1. System specification
2. Software project plan
3. Software Requirements Specification
(a) Graphical analysis models
(b) Process specifications
(c) Prototype
(d) Mathematical specification
4. Preliminary User Manual
5. Design specification
a) Data Design Description
b) Architectural design specification
c) Module design description
d) Interface design descriptions
e) Object descriptions
6. Source code listing
7. Test spcification
a) Test plan and procedures
b) Test cases and recorded results
8. Operation and Installation Manuals
9. Executed Program
a) Module executable code
b) Linked Modules
10. Database Descriptions
a) Schema file structure
b) Initial content
11. As-built User manual
12. Maintenance Documents
a) Software problem reports
b) Maintenance requests
c) Engineering change orders
13. Standards and procedures for s/w engineering
20. Write about SCM standards
Over the past two decades a number of s/w configuration management standards
have been proposed. Many early SCM standards, such as MIL-STD-483, DOS-STD480A, and MIL-STD-1521A, focused on s/w developed for militry applications. More
recent ANSI / IEEE standards such as ANSI / IEEE Std. No. 1042-1987, and Std.No.
1028-1988, are applicable for commercial software and recommended for both large and
small software engineeringorganizations.

10. 21. What is the role of SQA
The people responsible for the s/w projects are the only ones who can be
responsible for quality. The role of SQA is to monitor the way these groups perform
their responsibilities.
1.
2.
3.
4.
5.
6.
Review all development and quality plans for completeness
Participate as inspection moderators in design and code inspections
Review all test plans for adherence to standards
Review a significant sample of all test results to determine adherence toplans
Periodically audit SCM performance to determine adherence to standards
Participat in all project quarterly and phase reviews and register ononconcurrence
if the appropriate standards and procedures have not been reasonably met.
22. Write about SQA plan













Each development and maintenance project should have Software Quality
Assurance Plan (SAQP) that specifies its goals, the SQA tasks to be performed
the standards against which the development work is to be measured, and the
procedures and organizational structure.
The IEEE standard for SQAP preparation contains the following outline
Purpose
Reference Documents
Management
Documentation
Standards, Practices, and Conventions
Reviews and audits
Software configuration Management
Problem reporting and Corrective Action
Tools, techniques, and methodologies
Code controls
Media control
Supplier control
Records collection, Maintenance, and Retention
The documentation section should describe the documentation to be produced and
how it is to be reviewed.
23. Define testing, verification, validation and debugging
Testing
The process of executing a program with the intention of finding errors
Verification
An attempt to find erros by executing program in a test or simulated environment
Validation

11. An attempt to find erros by executing a program in a real environment
Debugging
Diagnosing the precise nature of a known error and then correcting it.
24. What are all the types of testing
1. Unit or Module test
It verifies single programs or modules. These are typically conducted in
isolated or special test environments
2. Integration tests
It verifies the interfaces between system parts (modules, components, and
subsystems)
3. External function tests
It verifies the external system functions, as stated in the external
specifications
4. Regression tests
It runs a subset of previously executed integration and function tests to
ensure that program
5. System tests
It verifies and/or validate the system to its initial objectives
6. Acceptance tests
It validates the system or program to the user’s requirements
7. Installation test
It validate the installability and operability of the user’s system
25. What do you mean by Regression testing
Regression testing is particularly important in software maintenance,where
it is not uncommon for bug fixes to disrupt seemingly unrelated functions.
The basic regressing testing approach is to incorporate selected test cases
into a regression test bucket that is run periodically in an attemp to detect
Regression problems.
26. What are all the element of s/w plan
1. Goals and objectives: It describes what is to be done, for whom, and by when, as
well as the criteria for determining project success
2. Work Breakdown structure(WBS) The WBS subdivides the project into tasks that
are each defined, estimated and tracked.
3. Product size estimates: These are quantitative assessments fo the code required
for each product element. Contingencies are applied to yield reasonable estimates
of the resources required fro each WBS element.
4. Project Shedule: Based on the available project staffing and resource estimates, a
schedule for the key tasks and deliverable items is produced.