Q1.

Entity: It is most elementary thing of an organisation about which data is to be maintained. Every
entity has unique identity. It is represented by rectangular box with the name of entity written inside
(generally in capital letters).

Relationship: Entities are connected to each other by relationships. It indicates how two entities are
associated. A diamond notation with name of relationship represents as written inside. Entity types
that participate in relationship is called degree of relationship. It can be one to one (or unary), one to
many or many to many.

Cardinality & Optionally: The cardinality represents the relationship between two entities. Consider
the one to many relationship between two entities – class and student. Here, cardinality of a
relationship is the number of instances of entity student that can be associated with each instance of
entity class.

Q2 A

Problems in SRS There are various features that make requirements analysis difficult. These are
discussed below:

1. Complete requirements are difficult to uncover. In recent trends in engineering, the processes are
automated and it is practically impossible to understand the complete set of requirements during
the commencement of the project itself.

2. Requirements are continuously generated. Defining the complete set of requirements in the
starting is difficult. When the system is put under run, the new requirements are obtained and need
to be added to the system. But, the project schedules are seldom adjusted to reflect these
modifications. Otherwise, the development of software will never commence.

3. The general trends among software developer shows that they have over dependence on CASE
tools. Though these tools are good helping agents, over reliance on these Requirements Engineering
Tools may create false requirements. Thus, the requirements corresponding to real system should
be understood and only a realistic dependence on tools should be made.

4. The software projects are generally given tight project schedules. Pressure is created from
customer side to hurriedly complete the project. This normally cuts down the time of requirements
analysis phase, which frequently lead to disaster(s).

5. Requirements Engineering is communication intensive. Users and developers have different

vocabularies, professional backgrounds and psychology. User writes specifications in natural
language and developer usually demands precise and well-specified requirement.

6. In present time, the software development is market driven having high commercial aspect. The
software developed should be a general purpose one to satisfy anonymous customer, and then, it is
customised to suit a particular application.

7. The resources may not be enough to build software that fulfils all the customer‟s requirements. It
is left to the customer to prioritise the requirements and develop software fulfilling important
requirements
Q2 B;

Broadly, the prototypes are developed using the following two techniques:

Throw away prototype: In this technique, the prototype is discarded once its purpose is fulfilled and
the final system is built from scratch. The prototype is built quickly to enable the user to rapidly
interact with a working system. As the prototype has to be ultimately discarded, the attention on its
speed, implementation aspects, maintainability and fault tolerance is not paid. In requirements
defining phase, a less refined set of requirements are hurriedly defined and throw away prototype is
constructed to determine the feasibility of requirement, validate the utility of function, uncover
missing requirements, and establish utility of user interface. The duration of prototype building
should be as less as possible because its advantage exists only if results from its use are available in
timely fashion.

Evolutionary Prototype: In this, the prototype is constructed to learn about the software problems
and their solutions in successive steps. The prototype is initially developed to satisfy few
requirements. Then, gradually, the requirements are added in the same prototype leading to the
better understanding of software system. The prototype once developed is used again and again.
This process is repeated

Q2 D

Mutation Testing

Mutation Testing is a powerful method for finding errors in software programs. In this technique,
multiple copies of programs are made, and each copy is altered; this altered copy is called a mutant.
Mutants are executed with test data to determine whether the test data are capable of detecting
the change between the original program and the mutated program. The mutant that is detected by
a test case is termed “killed” and the goal of the mutation procedure is to find a set of test cases that
are able to kill groups of mutant programs. Mutants are produced by applying mutant operators. An
operator is essentially a grammatical rule that changes a single expression to another expression. It
is essential that all mutants must be killed by the test cases or shown to be equivalent to the original
expression. If we run a mutated program, there are two possibilities:

1. The results of the program were affected by the code change and the test suite detects it. We
assumed that the test suite is perfect, which means that it must detect the change. If this happens,
the mutant is called a killed mutant.

2. The results of the program are not changed and the test suite does not detect the mutation. The
mutant is called an equivalent mutant.

If we take the ratio of killed mutants to all the mutants that were created, we get a number that is
smalleC r than 1. This number gives an indication of the sensitivity of program to the changes in
code. In real life, we may not have a perfect program and we may not have a perfect test suite.
Hence, we can have one more scenario:

3. The results of the program are different, but the test suite does not detect it because it does not
have the right test case.
Q3 B

Auditing and Reporting helps change management process to ensure whether the changes have
been properly implemented or not, whether it has any undesired impact on other components. A
formal technical review and software configuration audit helps in ensuring that the changes have
been implemented properly during the change process. A Formal Technical Review generally
concentrates on technical correctness of the changes to the configuration item whereas software
configuration audit complements it by checking the parameters which are not checked in a Formal
Technical Review.

 Whether a formal technical review is carried out to check the technical accuracy of the changes
made?

 Whether the changes as identified and reported in the change order have been incorporated?

 Have the changes been properly documented in the configuration items?

 Whether standards have been followed.

 Whether the procedure for identifying, recording and reporting changes has been followed

Reporting: Status reporting is also called status accounting. It records all changes that lead to each
new version of the item. Status reporting is the bookkeeping of each release. The process involves
tracking the change in each version that leads the latest(new) version.

The report includes the following:

 The changes incorporated

 The person responsible for the change

 The date and time of changes

 The effect of the change

 The reason for such changes (if it is a bug fixing)

Every time a change is incorporated it is assigned a unique number to identify it from the previous
version. Status reporting is of vital importance in a scenario where a large number of developers
work on the same product at the same time and have little idea about the work of other developers

Q3 A

Software Review is systematic inspection of a software by one or more individuals who work
together to find and resolve errors and defects in the software during the early stages of Software
Development Life Cycle (SDLC). Software review is an essential part of Software Development Life
Cycle (SDLC) that helps software engineers in validating the quality, functionality and other vital
features and components of the software. It is a whole process that includes testing the software
product and it makes sure that it meets the requirements stated by the client.  
Usually performed manually, software review is used to verify various documents like
requirements, system designs, codes, test plans and test cases. 

1. Software Peer Review: 

Peer review is the process of assessing the technical content and quality of the product and it
is usually conducted by the author of the work product along with some other developers.  
Peer review is performed in order to examine or resolve the defects in the software, whose
quality is also checked by other members of the team. 
Peer Review has following types: 
 (i) Code Review: 
Computer source code is examined in a systematic way. 
 
 (ii) Pair Programming: 
It is a code review where two developers develop code together at the same platform.  
 
 (iii) Walkthrough: 
Members of the development team is guided by author and other interested parties and
the participants ask questions and make comments about defects. 
 
 (iv)Technical Review: 
A team of highly qualified individuals examines the software product for its client’s use
and identifies technical defects from specifications and standards. 
 
 (v) Inspection: 
In inspection the reviewers follow a well-defined process to find defects. 
 
2. Software Management Review: 
Software Management Review evaluates the work status. In this section decisions regarding
downstream activities are taken. 
 
3. Software Audit Review: 
Software Audit Review is a type of external review in which one or more critics, who are not a
part of the development team, organize an independent inspection of the software product
and its processes to assess their compliance with stated specifications and standards. This is
done by managerial level people. 
 

Advantages of Software Review: 

 Defects can be identified earlier stage of development (especially in formal review).  

 
 Earlier inspection also reduces the maintenance cost of software. 
 
 It can be used to train technical authors. 
 
 It can be used to remove process inadequacies that encourage defects. 

Q4 B
Hardware and environmental requirements:
In most cases, it’s the prevailing hardware that might place constraints upon the  CASE tool choice.
Thus, rather than process hardware necessities for a CASE tool, the task at hand becomes to suit in
associate degree optimum configuration of the CASE tool within the existing hardware capabilities.
Therefore, it is often emphasized on choosing the foremost optimum CASE tool configuration for a
given hardware configuration.

Documentation support:
The deliverable documents should be organized diagrammatically and may be able to incorporate
text and diagrams from the central repository. This helps in manufacturing up-to-date
documentation. The CASE tool ought to integrate with one or a lot of the commercially obtainable
publication packages. It ought to be doable to export text, graphics, tables, knowledge wordbook
reports to the DTP package in commonplace forms like PostScript

Project management support:

The CASE tool ought to support assembling, storing, and analyzing data on the computer code
project’s progress like the calculable task length, regular and actual task begin, completion date,
dates, and results of the reviews, etc.

External interface:
The CASE tool ought to permit the exchange of data for the reusability of style. the data that is to
be exported by the CASE tool ought to be ideally in American Standard Code for Information
Interchange format and support open design. Similarly, {the data|the info|the data} wordbook
ought to give a programming interface to access information. it’s needed for integration of custom
utilities, building new techniques, or populating the info wordbook.

Reverse engineering:
The CASE tool ought to support the generation of structure charts and knowledge dictionaries
from the prevailing supply codes. It ought to populate the info wordbook from the ASCII text file. If
the tool is employed for re-engineering data systems, it ought to contain conversion tool from
indexed consecutive file structure, graded and network database to computer database systems.

Data dictionary interface:

The data wordbook interface ought to give read and update access to the entities and relations
hold on in it. It ought to have the print facility to get the textual matter of the viewed screens. It
ought to give analysis reports like cross-referencing, impact analysis, etc. Ideally, it ought to
support a question language to look at its contents.

Q4 E
Software reuse is the use of software components in more than one software system. Software
components include software specifications, code, manuals, tests, plans, design rational, and other
items that are a product of software development. In many cases, reusable components consist of
only parts of the items listed above. For example, a programmer may copy a small portion of source
code to a new software system under construction, versus copying the entire source code. In other
cases, the developer may reuse the entire software system. Commercial off-the-shelf(COTS)
software is an example where the entire software is reused. Software reuse offers two benefits to
developers. One benefit is the reduced development time and resources. In one report, it is
estimated that less than 15% of all software is unique to the application. However, only 5% of all
code is being reused. Through reuse, developers take advantage of previously developed solutions
and focus on the problems for which no solution is available. Not only does software reuse save
development time and effort, but it can also raise software quality. If a software system has proven
reliability, there is some potential for quality assurance through the reuse of its components.