ASSIGNMENT SEM -3

MI0033 SOFTWARE ENGINEERING

Q.1 Explain the concept of software project life cycle with a suitable example.

ANS

We can classify software development projects into various types based on their business
functional domain. In case a software company is interested in specialising in only one
product or service, it will need to understand that particular function or domain thoroughly.
Mere technical knowledge in how to develop the software by writing lines of codes may not
be sufficient.
As mentioned earlier, a software process can be defined as the step-by-step manner in which
software is developed. Each organisation tailors this into its own set of processes to develop
software development process. The use of software development processes within the project
life cycles ensures that developers follow a systematic approach in developing the software
and also incorporate the company guidelines to complete their project schedules. In todays
world, software companies are looking for better processes to enhance their quality and
predictability of software development along with maintenance of costs.
For example, Kolkata-based UshaComm that has gained expertise in telecommunicationsbilling solutions that are used all across the world. For such companies, it is a prudent
approach when they consider breaking down the project into a broad series of phases that
would enable them to manage the project efficiently. The phases could be requirements in
Engineering, analysis, design, coding, testing, implementation and maintenance.

Q.2 Describe the different software estimation techniques and models used for
estimating a software project.
ANS
After discussing about the estimation models, let us now discuss some techniques used for
estimating time and cost of a project. We use estimation techniques to solve problems in a
project. The common problems that a software project can face are the problems related to
cost and effort. Therefore, it becomes very necessary to incorporate the cost and the effort
estimation techniques. We can use the decomposition technique for project estimation. In the
decomposition technique, we divide a complicated problem in a project into several smaller
and manageable units. Appropriate estimation techniques are used on the basis of the scope of

the software to be built. In the previous unit, we have already discussed about the sizeoriented and function-oriented metrics. These metrics speak about the line of code and the
function-point in a software project. So, let us now have a better understanding about the way
in which the Line of code and the Function point estimations are done. The LOC and the FP
are the two decomposition techniques used for estimating the effort in a software project, as
given in the table.
Line of code

It is a decomposition

technique used on the basis of the size

of line of code in a software project.
The
line
of
code

decomposition technique uses all the

intricate details in a program.
A direct estimation is done in the line of
code method.

Function point
It is a decomposition technique
that uses the baseline metrics collected from the
previous projects.
It uses only the macroscopic
details in a program.
It is determined indirectly by estimating
the number of inputs, outputs, data files and
external interfaces.

Q. 3 Describe in detail the software reliability metrics and its types

ANS
Software metrics

We can define reliability as the capability of being depended on; and software reliability
as the reliability/dependability of a particular software product. When we speak about the
quality of a software product/system, software reliability comes into picture.
We can categorise software reliability metrics into certain distinct types as Shown below

1. Product metrics Product metrics involve instinctive method of measuring the size
of the software, on the basis of the lines of code (LOC), or more practically
thousand lines of code (KLOC).
2. Function point metrics We can use the function point for the measurement of the
functionality of a recommended software development system based on functions
such as count of inputs, outputs, master files, inquires and interfaces.

3. Complexity metrics We can use complexity metrics for determining the complexity
of a software programs control structure. We can simplify the complexity of the
software program code by graphical representation.
4. Test coverage metrics We can use test coverage metrics for estimating the fault and
reliability of a software program.
5. Project management metrics We know that good management can provide better
quality products.
6. Process metrics We can use process metrics for estimating, monitoring and
improving the reliability and quality of a software product.
7. Fault and failure metrics Fault and failure metrics are used for measuring the
number of faults found in the software system during the testing phase.
Software reliability models

We know that a particular model can work well on certain software, while it may not work at
all on another. Typically, a software model contains mathematical functions, assumptions and
factors. The mathematical functions contain exponential and logarithmic functions of higher
order. These modelling techniques are based on accumulating the failure data and analysing
them statistically by observance. Let us understand these techniques by differentiating the
two modelling techniques, as given in Table 7.1.
Table 7.1: Prediction Modelling and Estimation Modelling

Prediction model

In the prediction model, we can predict

software reliability very early in the
software development process, and thus
can be used to enhance reliability.
The prediction model uses
historical data.
The prediction model predicts
reliability at some future point of time.
The prediction models are used before
the development or test phase, and are
sometimes used in the concept phase.

Estimation model

Estimation models include exponential

distribution models that are known as the
fault count/fault rate estimation model.
The estimation model uses data from
the current software development
process.
The estimation model estimates reliability
at either the present or the future time.
The estimation models are not used in the
concept and developments phase of
software. They are used after data are
collected for estimation.

4. Briefly note on design fundamentals and explain the principles of design

ANS

Design Fundamentals
The fundamental concepts of software design provide guidelines to get the design right.
1. Abstraction In abstraction, the issues related to the design are described using the
levels of details/language.
2. Data abstraction The representation of the data objects is called data abstraction.
3. Procedural abstraction The representation of instructions or procedures is called
procedural abstraction.
4. Refinement - In refinement, we polish the design using top-down strategy called as
stepwise refinement
5. Modularity In modularity, we divide the software into separate components called
modules.
6. Software architecture Software architecture describes the hierarchical structure of
procedural components and the structure of data.
7. Control hierarchy We can refer to it as Program structure. In the control
hierarchy, we organise the elements, which implies that we describe a hierarchy of
control, the metrics depth, width, and so on, and provide visibility and connectivity.
8. Data structure In data structure, we illustrate the links between individual data
elements using logical representations.
9. Software procedure It specifies processing details of each element.
10. Information hiding In information hiding, the elements should be categorised by
design decisions.
Principles of design
First Principle: The reason of its presence.
One reason for a software system to be present is to give value to its users. We should keep
this in mind while making all judgements.
Second Principle: KISS Keep it simple, Stupid!

Software design is not a random process. In any design, we should consider many factors. All
the designs should be simple but not simpler. This helps to have a system that can be easily
understood and maintained.

 Third Principle: Maintain the vision.

A clear vision of the software is necessary to gain success in any software project. If the
vision towards the software is not clear then the project ends up with low quality.
Fourth Principle: What is produced will be consumed/used by others.

According to this principle, a product developed is used, maintained and documented by the
users/clients, to understand the system. A product should be developed such that the user
should understand the specifications, design and implementation.
Fifth Principle: Be open to the future.

As per this principle, the system has more value if it has extensive lifetime. In the present
generation computing environments, the specifications of hardware and software change
rapidly and become outdated very fast.
Sixth Principle: Plan in advance for reuse.

According to this principle, time and effort can be saved by reusing the developed software.
Seventh Principle: Think.

As per this principle, placing clear, complete thought before action produces better results.

Q. 5 Explain the different types of integration testing

ANS
Types of integration testing
Top-down integration

We can state an incremental approach to develop a program as top-down integration. In topdown integration, we first recognise the control hierarchy. This helps us to identify and
categorise the modules. The modules that are subordinate to the main control module are
integrated to the bigger structure. Depth-first or breadth-first approach is used for integrating.
Bottom-up integration

The bottom-up integration test commences at the atomic module level. The lowest levels in
the program structure are atomic modules. In this approach, stubs are not needed as modules
are integrated from bottom-up, and processing needed for modules which are subordinate to a
given level is always present. Let us have a look at the steps followed in bottom-up
integration:

1. Combine low-level modules forming clusters which execute particular software subfunction. Clusters are also called builds.
2. Write control program to co-ordinate test case input and output.
3. Test the build.
Regression testing

We conduct regression test to recognise the errors and ensure that new errors have not crept
into the units being tested. The number of regression tests can increase as integration testing
continues. Hence, regression test set should be designed to include tests that handle one or
more errors in every major program functions. Regression testing is done whenever an
implementation is modified within a program. It is conducted by rerunning available tests
against the altered code to verify the effects after modifications and new tests are written
wherever required
Smoke testing

Smoke testing is basically related to the concept of project control, where variations of the
actual project outputs are compared with required outputs.
Time, cost and performance are the factors used in project control. Smoke testing should be
done on high testing frequency basis whereby the
errors will show up on time. The mid-level integration of different modules
reduces the risk of inappropriateness at later levels.
Comments on integration testing

Integration strategies should be selected on the basis of software characters

and project agenda. It is better to use a combined approach which uses topdown tests for
upper levels and bottom-up tests for subordinate levels of the program structure. Regression
tests should take care on critical module function. Every strategy has its own advantages and
disadvantages. The disadvantage of top-down integration is that it requires stubs, which have
their own testing difficulties. The disadvantage of bottom-up integration is that the code
individually does not live till the last module is added.

Q.6 Briefly explain the SQA plan.

ANS
We will first understand the meaning of Software Quality Assurance (SQA). We often use the
word quality and we know that quality can be good or bad. Literally, quality assurance
refers to the assurance of quality. Thus, we can say that SQA means assurance of high
software quality. It is a combination of a means of monitoring the software engineering
processes and methods that are used to ensure quality. We can define SQA as a planned
and systematic approach to the evaluation of the quality and solidarity to software product
standards, processes and procedures. The main role of SQA is assuring that standards and

procedures are adhered to and are followed all the way throughout the software
development life cycle. Quality assurance approval points are incorporated in the software
development and control processes, whereas an SQA evaluation of the product may be
done in connection to the applicable standards. The two key principles that characterise
SQA are the following:

1. Fit for purpose, that is, the product should be suitable for the intended purpose.

2. Right first time, that is, mistakes should be eliminated.

You must note that SQA is a collection of activities like monitoring the quality of raw
materials, products and components, services linked to production, management and
inspection process. We can say that SQA is an activity that gets more priority than just
testing the quality aspects of a product, service or facility; it also analyses the quality to
ensure that it conforms to particular requirements and complies with established plan related
to the project.

Standards and procedures

In case of software development, establishment of standards and procedures is critical, since
a framework is provided by the standards through which the software evolves. These
standards are documentation standards (standards related to the documentation of the
project), design standards (standards that indicate the type and content of the design of the
product) and code standards (standards that specifies the coding language of the project). The
software products are compared with established standards. To develop software, procedures
and standards, we need to establish prescribed methods. The role of SQA is to make sure that
the existence and adequacy of these prescribed methods and standards are proper in place. We
know that a plan is important for every project. Standards and procedures are also significant
for every project as they add value to the software project. The two important bodies of
quality standards are the Malcolm Baldrige assessment and ISO 9000.