SOFTWARE ENGINEERING: SUB CODE- 35272

QPCODE:-532

PART-A

(Each question carries 2 marks, Answer any FIVE (5) questions. Q.No. 8 - Compulsory)

1. Define software engineering.

Software engineering is the application of a systematic disciplined, quantitative approach to the
development, operation and maintenance of software, the application of engineering to software.

2. What is requirement process?

The Requirement process is the sequence of activities that need to be performed in the requirement
phase and that helps in producing a high – quality document containing the SRS. The requirements
process typically consists of three basic tasks - Problem or requirement analysis, requirement
specification and requirement validation.

3. Expand HCI.
Human Computer Interaction

4. How to estimate the size of project?

 The ways to estimate project size can be through past data from an earlier developed system. This
is called estimation by analogy.
 The other way of estimation is through product feature/functionality. The system is divided into
several subsystems depending on functionality, and size of each subsystem is calculated.

5. What is software configuration management?

Software configuration management (SCM) process is the best solution to handle changes in
software projects. It identifies the functional and physical attributes of software at various points in time,
and performs systematic control of changes to the identified attributes for the purpose of maintaining
software integrity and traceability throughout the software development life cycle.

6. What is monitoring of risks?

Monitoring of risk means to review it and update it continuously. Is a process of identifying,
analyzing, and planning for newly discovered risks and managing identified risks.

7. List any two software testing objectives.

(Any two)
• Testing is a process of executing a program with the intent of finding an error.
• A good test case is one that has a high probability of finding an as-yet-undiscovered error.
• A successful test is one that uncovers an as-yet-undiscovered error.

8. Define Software Reliability.

Software reliability is defined as the probability of failure – free software operation in a specified
environment for a specified period of time

PART – B

(Each question carries 3 mark Answer any FIVE (5) questions. Q.No 16 - Compulsory)

9. List out the types of software myth.

 Management Myth
1
  Customer Myth
 Developer Myth

10. Describe project scheduling.

It is the process of identifying and organizing the tasks of a project into sequence of events
ensuring a harmonious completion of the venture. These events are dependent on the results of their
preceding activities, thus interlinking all the activities of the project.

11. Define test cases.

A test case can be considered as comprising a set of test inputs and execution condition. Testing
comes down to selecting and executing test cases.

12. List any three types of static testing strategies.

(Any 3)
• Formal technical review
• Code walkthrough
• Code inspection
• Compliance with design and coding standards

13. List the levels of SEI-CMM.

The five levels are given below.
 Initial( chaotic, ad hoc)
 Repeatable Defined
 Managed
 Optimized

14. What is the difference between forward and reverse engineering?

 In Forward engineering we can modify the implicit design and source code and make
necessary changes. Reverse engineering is usually undertaken in order to redesign the
system for better maintainability.
 Forward engineering is the traditional process of moving high level abstractions nd
logical design. Reverse engineering is a process of duplicating an existing component,
subassembly or product.
 Forward engineering is not much cost effective. Reverse engineering is typically cost
effective

15. List out the six task regions of spiral life cycle model.
 Requirement Gathering
 Risk Analysis
 Prototyping
 Coding
 Testing
 Customer Evaluation

16. Define software metric.

Software metrics deals with the measurement of the software product and the process by
which it is developed. The two categories of software metric are product and project metrics.
Product metrics- measure the software product at any stage of its development. Project Metrics –
used by the project manager to control the project in terms of project cost, time and effort.

Part-C

2
17 a) i) Explain the need for software engineering - [5]
(List-1, explanation-4)
 Large software - It is easier to build a wall than to a house or building, likewise, as the size of
software become large engineering has to step to give it a scientific process.
 Scalability - If the software processes were not based on scientific and engineering concepts, it
would be easier to re-create new software than to scale an existing one.
 Cost - As hardware industry has shown its skills and huge manufacturing has lower down the
price of computer and electronic hardware. But the cost of software remains high if proper
process is not adapted.
 Dynamic Nature - Growing and adapting nature of software hugely depends upon the
environment in which user works. If the nature of software is always changing, new
enhancements need to be done in the existing one. This is where software engineering plays a
good role.
 Quality Management- Better process of software development provides better and quality
software product.

ii) Compare waterfall and prototype model- [5]

MODEL STRENGTHS WEAKNESSES

Water fall Model  Simple • Disallows changes

 Easy to execute • Cycle time too long.
 Intuitive and logical • User feed back not allowed

Prototyping • Reduce risk • Higher cost

• Leads to a better System • Disallows later changes
• Helps in requirements elicitation

(OR)
b i) Differentiate program and software products. - [5]
(Any 5)

S.No Programs Software Products

1 Programs are developed by individuals A software products is usually developed by
for their personal use. a group of engineers working in a team.
2 Usually small in size. Usually large in size.
3 Single user Large number of users.
4 Lacks proper documentation. Good documentation support.
5 Lack of user interface. Good user interface.
6 Have limited functionality. Exhibit more functionality.

ii) Explain the desirable characteristics of good SRS. - [5]

(List – 1, explanation – 4)
 CORRECTNESS: An SRS is correct if every requirement included in the SRS represents
something required in the final system.
 COMPLETENESS: An SRS is complete when it is documented after:
• Focusing on all problems, goals, and objectives, and not only on functions and features.
• Correct definition of scope and boundaries of the software and system.3.

3
  UNAMIGUOUS: An SRS is unambiguous if and only if every requirement stated has one and
only one interpretation. Requirements are often written in a natural language. The SRS writer has
to be especially careful to ensure that there are no ambiguities.
 VERIFIABLE: An SRS is verifiable if and only if there exists some cost-effective process that
can check whether the final product meets the requirements.
 MODIFIABLE: An SRS is modifiable if its structure and style are such that any necessary
change can be made easily while preserving completeness and consistency.
 TRACEABLE: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each requirement in future development or enhancement
documentation.
 CONSISTENCY: Consistency in the SRS is essential to achieve correct results across the
system.

18) a) i) Explain the objectives of software design? - [5]

(Any 5)
 Identify different types of software, based on the usage.
 Show difference between design and coding.
 Define concepts of structured programming.
 Illustrate some basic design concepts.
 See how to design for testability and maintainability.
 Introduce some formal design notations.

ii) Explain software project estimation. - [5]

[List -1, Explanation-4]
Software project estimation is the process of estimating various resources required for the
completion of a project. Effective software project estimation is an important activity in any software
development project. On the other hand, overstaffing a project without proper control will increase the
cost of the project and reduce the competitiveness of the company.
Step for estimation:
The four basic steps in software project estimation are:
 Estimate the size
 Estimate the effort
 Estimate the schedule
 Estimate the cost
Estimate the size
The other way of estimation is through product feature/functionality. The system is divided into
several subsystems depending on functionality, and size of each subsystem is calculated.
Estimate the effort
Once the size of software is estimated, the next step is to estimate the effort based on the size.
The estimation of effort can be made from the organizational specifics of software development life cycle.
The development of any application software system is more than just coding of the system.
Estimate the schedule
The next step in estimation process is estimating the project schedule from the effort estimated.
The schedule for a project will generally depend on human resources involved in a process. Efforts in
man-months are translated to calendar months.
Estimate the cost
There are many factors to consider when estimating the total cost of a project. These include
labor, hardware and software purchases or rentals , travel for meeting or testing purposes,
telecommunication (e.g., long- distance phone calls, video- conferences, dedicated lines for testing, etc..,)
training courses, office space, and so on.

(OR)
b i) Explain internal documentation - [5]
4
 Internal is the one which has to be closed to the program , program statement and program block
to explain it. Internal documentation of the program is done by using comments. Writing comments inside
the programs increase the readability and understanding capability of the user.
Comments should provide the following information for the users
 Functionality
 Parameter and their roles and usage
 Attributes of inputs
 Mention of global variables
 Author of program
 When it is modified last
The main objective of internal documentation is to provide on line help to the user and to get a quick
understanding of the program .External documentation, on the other hand, focuses on what the problem
to be solved is, and which approach is used in solving it. This can be a graph detailing the execution, a list
of algorithms, dependencies, as well as meta-data such as the author, the date, and so fort.

ii) Explain about architectural design of CASE environment - [5]

[List-1,Explanation-4]

The important components of a modern CASE environment are the user interface, the Tools
Management System (Tools set), the Object Management System(OMS) and the repository. These
various components are discussed as follows:

1. User Interface. It provides a consistent framework for accessing different tools. So it is easier for the
user to interact with different tools and reduces learning time of how the different tools are used.

2. Tools Management Services (Tools Set). The tools set section holds the different types of improved
quality tools. The tools layer incorporates a set of tools management services with the CASE tool
themselves. Tools Management Services (TMS) control the behavior of tools within the environment. If
multitasking is used during the execution of one or more tools, TMS performs multitask synchronization
and communication, coordinates the flow of information from the repository and object management
system into the tools, accomplishes security and auditing functions, and collects metrics on tool usage.

3. Object Management System (OMS). The object management system maps the (specification design,
text data, project plan etc.) logical entities into the underlying storage management system i.e., repository.
Working in conjunction with the CASE repository, the OML provides integration services a set of
standard modules that couple tools with the repository.

4. Repository. It is the CASE database and the access control functions that enable the OMS to interact
with the database. The word CASE repository is referred in different ways such as project database, IPSE
database, data dictionary, CASE database and so on.

19) a) i) Explain about the categories of maintenance - [5]

[List-1,Explanation-4]

Maintenances may be classified into four categories as follows:-

 Corrective Maintenance – This means the modifications done to correct the discovered
problems.
 Adaptive Maintenance- This means changing the program functions. This is done to adapt to
external

5
  Perfect Maintenance- This means improving the performance or modifying the programs to
respond to the user’s changing needs.
 Preventive Maintenance – This is a process by which we prevent our system from being
obsolete. These are the modifications done to detect and correct latent faults.

ii) Explain work breakdown structure - [5]

Work Breakdown Structure is the process of dividing the project into tasks and logically ordering
them in a sequence. It provides a framework for keeping track of the progress of the project and for
determining the cost planned for these tasks. By comparing the cost planned cost and the actual cost
(cost that has been expended), the additional cost required can be controlled.
1. Break the project into general tasks: The project can be divided into general tasks such as
analysis, design, testing, and so on.
2. Break the general tasks into smaller individual tasks: When the general tasks are determined,
they can further be divided into subtasks. For example, design can further be divided into interface
design, modular design, and so on.
The figure shows a high level WBS structure for a small to medium sized project. The box at the top
represents the total system and is referred to as WBS level 1.

Level-1 The Project

Level-2
Project Service Hardware Software
Component Component

Module A

Level-3
Module B

Module C

Lower levels which describe project component in increasing detail are numbered 2,3,4 and so on.The
concept of WBS level is important, as it allows designating the level of details at which report cost
estimates and project cost performance. The portioning of the project into major components occurs at
level 2. Components at this level fall into the following classes:
Project Service - It is used to discover what the components are.
Hardware Component-A bill of materials breakdown of computer hardware.
Software Component- A bill of materials breakdown of computer software.

(OR)

b. Explain risk management categories. - [10]

(List-2, Explanation-8)

6
 A priority is given to risk and the highest priority is handled first. Various factors of the risk include
who are the involved team members, what hardware and software items are needed, where, when and
why. Risk management can be further categorized as follows:-
1. Risk Avoidance
 Risk anticipation
 Risk tools
2. Risk Detection
 Risk analysis
 Risk category
 Risk prioritization
3. Risk Control
 Risk Pending
 Risk resolution
 Risk not solvable
4. Risk Recovery
 Full
 Partial
 Extra/alternate feature
Risk Avoidance:-
 Risk Anticipation- various risk anticipation rules are listed according to standards from
previous projects, experience, and also as mentioned by the project manager.
 Risk tools:-Risk tools are used to test whether the software is risk free. The tools have a
built- in databases of available risk areas and be updated depending upon the type of
project.

Risk Detection:-
 Risk analysis- Risk can be analyzed with various hardware and software parameters, the
maximum value of risk exposure indicates that the problem has to be solved as soon as
possible and be given higher priority
 Risk category- it can come from the various factors such as persons involved in the
team, customer specification, feedback etc.,
 Risk prioritization – Depending upon the entries of the risk- analysis table, the
maximum risk exposure is given higher priority and nhas to be solved first.

Risk Control- Risk control attempts to minimize the probability of risks occurring and minimizes its
effect on the project. The steps to control risks are:
 Identify the risks
 Determine the risk exposure
 Develop strategies to mitigate the risks
 Handle the risks
 Risk Pending- According to the priority , low priority risk are pushed to the end of the
queue with a view of various resources.
 Risk resolution- The risk manager decides how to solve the risk
 Risk not solvable – if a risk takes more time and more resources, then it is dealt with in
its totality on the business side of the organization and the customer is notified, and the
team member proposes an alternate solution.
 Risk transfer – If the risk is transferred to some part of the module, then the risk analysis
table entries get modified. And again, the risk manager will control high priority risks.

Risk Recovery:
Risk recovery may be either full or partial.

7
  Full- The risk analysis table is scanned and if the risk is fully solved, then the
corresponding entry is deleted from the table.
 Partial-The risk analysis table is scanned and due to partially solved risks.
 Extra/Alternate features- Sometimes it is difficult to remove risks, and its case ,we can
add a few extra features, that solve the problem.

20) a) i) Differentiate between black box and white box testing. - [5]

BASIS WHITE-BOX TESTING BLACK-BOX TESTING

 To test the internal structure of  To test the functionality of software

software
 Tests the software but does not  Concerned with testing the
Purpose ensure the complete specifications and does not ensure that
implementation of all the all the components of software that are
specifications mentioned in implemented are tested
user requirements.

Performed in the early stages of Performed in the later stages of testing

Stage testing

Knowledge of the internal structure No knowledge of the internal structure of a

Requirement of a program is required for program is required to generate test cases
generating test cases

Test cases are generated based on

Test Cases the internal structure or code of the Internal structure of modules or programs is
module to be tested not considered for selecting test cases

ii) Explain about the classification of tools - [5]

(List -1,Explanation-4)
Software testing tools can be categorized by the testing activity or the process they are utilized in, e.g.
test planning, test execution, data comparison, defect capture, etc. Software tools are classified as follows:

• Function/ Regression tools

• Performance / Load testing tools.
• Testing process Management Tools

Functional testing is a process used within software development in which software is tested to ensure
that it conforms with all requirements. Its focus is on validating features, database access, security and
functionality of the Application under Test. It uses external interfaces, including Application
programming interfaces (APIs), Graphical user interfaces (GUIs), and Command line interfaces (CLIs).
Functional Testing Tools includes JMeter, SoapUI, and Watir.
Regression Testing techniques include Retest all, Regression Test Selection and Prioritization of test
cases.
Performance testing tools are basically for system level testing, to see whether or not the system will
stand up to a high volume of usage. A load testing is to check that the system can handle its expected
number of transactions.
Test management tools are given below. Some tools will provide all of these features; others may
provide one or more of the features.

8
 • To manage the tests (like, keeping track of the same kind of data for a given set of tests,
knowing which tests need to run in a common environment, number of tests planned, written, run,
passed or failed);
• Scheduling of tests to be executed (manually or by a test execution tool);
• Managing the testing activities (time spent in test design, test execution, whether we are
on schedule or on budget);
• Interfaces to other tools, such as:
o test execution tools (test running tools);
o incident management tools;
o requirement management tools;
o configuration management tools;
o Traceability of tests, test results and defects to requirements or other sources

(OR)
b i) Explain the level of testing - [ 5]
((List-1, Explanation – 4)

Testing is an important step n software development life cycle. The process of testing takes place at
various stages of development in programming. This is a vital step in development life cycle because the
process of testing helps to identify the mistakes and sends the program for correction.
This process gets repeated at various stages until the final unit or program is found to be complete
thus gives a total quality to the development process. The various levels and types of testing found in a
software development life cycle are:
 Unit testing
 Integration testing
 System testing
 Acceptance testing

Unit Testing- Unit testing is a level of the software testing process where individual
units/components of a software/System are tested. The purpose is to validate that the software performs as
designed.

Integration Testing - Integration testing is the activity of software testing in which individual
software modules are combined and tested as a group. The purpose of integration testing is to verify
functional, performance , and reliability requirement placed on major design items.

System Testing - System testing of software or hardware is the testing conducted on a complete,
integrated system to evaluate the system’s compliance with its specified requirement.

Acceptance Testing- Acceptance testing is the testing of system with the intent of confirming
readiness of the product and customer acceptance.

Acceptance Testing

System Testing

Integration Testing

Unit Testing 9
ii) Explain the life cycle of a debugging task. -[5]

Debugging is not testing but always occurs as a consequence of testing. Referring to the figure below,
the debugging process begins with the execution of a test case. Results are assessed and a lack of
correspondence between expected and actual performance is encountered. The debugging process
attempts to match symptoms with cause, thereby leading to error correction.
The debugging process will always have one of two outcomes:
 The cause will be found and corrected or
 The cause will not be found.
The following are various steps involved in debugging:
a. Defect identification / confirmation
b. Defect analysis
c. Defects resolution
In the latter cause, the person performing debugging may suspect a cause , design a test case to
help validate that suspicious and work toward error correction in an iterative fashion.
During debugging, we encounter errors that range from mildly annoying to catastrophic. As the
consequences of an error increase, the amount of pressure to find the cause also increases. Often, pressure
sometimes forces a software developer to correct one error and at the same time introduce two more new
errors.

21) a) i) Explain the important qualities of software products. - [5]

(List- 1 mark, Explanation -4 marks)
 CORRECTNESS : A program is functionally correct if it behaves according to the specification
of the functions it should provide (called functional requirements specifications).
 RELIABILITY : Informally, software is reliable if the user can depend on it. The specialized
literature on software reliability defines reliability in terms of statistical behavior-the portability
that the software will operate as expected over a specified time interval.
 ROBUSTNESS: A program is robust if it behaves “reasonably,” even in circumstances that were
not anticipated in the requirements specification
 PERFORMANCE : Performance affects the usability of the system. If a software system is too
slow, it reduces the productivity of the users. If a software system uses too much disk space, it
may be too expensive to run. If a software system uses too much memory, it may affect the other
applications that are run on the same system, or it may run slowly while the operating system tries
to balance the memory usage of the different applications.
 VERIFIABILITY: A software system is verifiable if its properties can be verified easily. For
example, it is important to be able to verify the correctness or the performance of a software
system.
 REPARABILITY: A software system is repairable if it allows the correction of its defects with a
limited amount of work.
 EVOLVABILITY : Like other engineering products, software products are modified over time
to provide new functions or to change existing functions. Indeed, the fact that software is so
malleable makes modifications extremely easy to apply to an implementation.
 UNDERSTANDABILITY: Some software systems are easier to understand than others. Of
course, some tasks are inherently more complex than others.
 INTEROPERABILITY : “Interoperability” refers to the ability of a system to coexist and
cooperate with other systems. With interoperability, a vendor can produce different products and
allow the user to combine them if necessary.
 PRODUCTIVITY : Productivity is a quality of the software production process; it measures the
efficiency of the process.

10
  TIMELINESS : Timeliness is a process – related quality that refers to the ability to deliver a
product on time. Timeliness requires careful scheduling, accurate estimation of work, and clearly
specified and verifiable milestones.
 VISIBILITY : A software development process is visible if all of its steps and its current status
are documented clearly. Another term used to characterize this property is transparency. The idea
is that the steps and the status of the project are available and easily accessible for external
examination.

ii) Explain reliability growth modeling.[5]

(list -2, Explanation – 3)

Software Reliability growth Modeling

a) Jelinski-Morand de-eutrophication model
b) Goel-Okumoto Model
c) Musa basic execution time model
 Musa-Okumoto logarithmic model
 Block coverage model
 Hyper geometric model for systematic testing
Jelinski- Morand de-eutrophication model: - he failure intensity of the software at time t is
proportional to the expected number of faults remaining in the software. The hazard rate of an individual
fault is then constant of proportionality.
Goel-Okumoto Model:- the failure is the product of the constant hazard rate of an individual fault and
the number of expected faults remaining in the software.
Musa basic execution time model:- Musa’s basic execution time model developed in 1975 was the first
one to implicitly require that the time measurements are in actual CPU time in executing the application
under test, named as “execution time”.
λ(µ)= λo[1- µ/νo]
They are two types of:
a) Musa- Okumoto logarithmic model
b) Block coverage model
c) Hyper geometric model for systematic testing
Musa- Okumoto logarithmic model: Musa – Okumoto is based on failure data measured in execution
time.
λ(µ)= λoe-θµ
Block coverage model :- A model for block coverage model is independent of the number of test cases
executed during functional testing, which can be easily be extended to become a model of the number of
failures experienced in terms of time.
Hyper geometric model for systematic testing: Hype geometric model for the number of failures,
experienced at each stage of testing when the construct tested model for the number of failures,
experienced at each stage of testing when the constructs tested are removed from the population.
(OR)

b) i) Explain the need for ISO certification - [5]

(any 5)

 It is sign of customer confidence. This certification has become a standard for international
bidding.
 It is a motivating factor to the business organizations.
 It makes the processes more focused, efficient and cost effective.
 It helps in designing high quality repeatable software products.
 It highlights weaknesses and suggests corrective measures for improvements.
 It facilitates the development of optimal process and total quality measurement.

11
  It emphasizes the need of proper documentation.
 Registration can improve service performance and reduce uncertainty.
 Regular assessments ensure the organization continually uses monitors and improves their
processes.
 Worldwide Recognitions.

ii) Explain the characteristics of reverse engineering. - [5]

(List-1,Explanation-4)

 Completeness. The completeness of a reverse engineering process refers to the level of detail that
is provided at an abstraction level. In most cases, the completeness decreases as the abstraction
level increases.
 Interactivity. Interactivity refers to the degree to which the human is “integrated” with
automated tools to create an effective reverse engineering process. In most cases, as the
abstraction level increases, interactivity must increase.
 Directionality. If the directionality of the reverse engineering process is one-way, all information
extracted from the source code is provided to the software engineer who can then use it during
any maintenance activity. If directionality is two-way, the information is fed to a re-engineering
tool that attempts to restructure or regenerate the old program.
 Extract Abstractions. The core of reverse engineering is an activity called extract abstractions.
the engineer must evaluate the old program and from the (often un-documented) source code,
develop a meaningful specification of the processing that is performed, the user interface that is
applied, and the program data structures or database that is used.

Date : Prepared by
Location :
LEENA J [41205203]
Part Time / Guest Lecturer
120, Government Polytechnic College,
Purasaiwakkam, Chennai – 12.

12