NAME: DEVANSHU.R.

THAKKAR

ENROLLMENT NO: 180820107055

SUBJECT: SOFTWARE ENGINEERING

SEM:5TH(CSE)

SUBJECT CODE:3150711
Q1. Explain Risk Management.
Risk Management:
A computer code project may be laid low with an outsized sort of risk. so
as to be ready to consistently establish the necessary risks which could
have an effect on a computer code project, it’s necessary to reason risks
into completely different categories. The project manager will then
examine the risks from every category square measure relevant to the
project.

There square measure 3 main classes of risks that may have an effect on
a computer code project:

Project Risks:
Project risks concern varies sorts of monetary fund, schedule, personnel,
resource, and customer-related issues. a vital project risk is schedule
slippage. Since computer code is intangible, it’s terribly tough to observe
and management a computer code project. it’s terribly tough to manage
one thing that can not be seen. For any producing project, like producing
cars, the project manager will see the merchandise taking form.

For example, see that the engine is fitted, at the moment the doors area
unit fitted, the automotive is obtaining painted, etc. so he will simply
assess the progress of the work and management it. The physical property
of the merchandise being developed is a vital reason why several
computer codes comes to suffer from the danger of schedule slippage.

Technical Risks:
Technical risks concern potential style,
implementation, interfacing, testing, and maintenance issues. Technical
risks conjointly embody ambiguous specifications, incomplete specification,
dynamic specification, technical uncertainty, and technical degeneration.
Most technical risks occur thanks to the event team’s lean information
concerning the project.

Business Risks:
This type of risk embodies the risks of building a superb product that
nobody needs, losing monetary fund or personal commitments, etc.
 Q2. List different agile process model and explain any one
with suitanle example.

Agile Model
The meaning of Agile is swift or versatile."Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into
smaller iterations, or parts do not directly involve long term planning. The project scope
and requirements are laid down at the beginning of the development process. Plans
regarding the number of
iterations, the duration and the scope of each iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller
parts helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software
development life cycle including planning, requirements analysis, design, coding, and
testing before a working product is demonstrated to the client.

Phases of Agile Model:

Following are the phases in the Agile model
are as follows:

Requirements gathering

Design the requirements

Construction/ iteration

Testing/ Quality assurance

Deployment

Feedback

1. Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build
the project. Based on this information, you can evaluate technical and economic
feasibility
 2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the high-
level UML diagram to show the work of new features and show how it will apply to your
existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a
working product. The product will undergo various stages of improvement, so it
includes simple, minimal functionality.

4. Testing: In this phase, the Quality

Assurance team examines the product's performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work
environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

Q3. Explain the various coding standard.

Some of the coding standards are given below:

Limited use of globals:

These rules tell about which types of data that can be declared global and the data that can’t
be.
Standard headers for different modules:
For better understanding and maintenance of the code, the header of different modules
should follow some standard format and information. The header format must contain
below things that is being used in various companies:

Name of the module

Date of module creation

Author of the module

Modification historyNaming conventions for local variables, global variables,

constants andfunctions:
Some of the naming conventions are given
below:
Meaningful and understandable variables name helps anyone to understand the
reason of using it.
Ÿ It is better to avoid the use of digits in variable names.

The names of the function should be written in camel case starting with small letters.

Indentation:
Proper indentation is very important to increase the readability of the code. For making
the code readable, programmers should use White spaces properly. Some of the
spacing conventions are given below:

There must be a space after giving a comma

between two function arguments.

Each nested block should be properly indented and spaced.

Error return values and exception handling conventions:

All functions that encountering an error condition should either return a 0 or 1 for
simplifying the debugging.

On the other hand, Coding guidelines give some general suggestions regarding the
coding style that to be followed for the betterment of understandability and readability
of the code.

Avoid using a coding style that is too difficult to understand:

Code should be easily understandable. The complex code makes maintenance
and
debugging difficult and expensive.

Avoid using an identifier for multiple purposes:

Each variable should be given a descriptive and meaningful name indicating the
reason behind using it. This is not possible if an identifier is used for multiple purposes
and thus it can lead to confusion to the reader. Moreover, it leads to more difficulty
during future enhancements.

Code should be well documented:

The code should be properly commented for understanding easily. Comments
regarding the statements increase the understandability of the code.

Length of functions should not be very large:

Lengthy functions are very difficult to
understand. That’s why functions should be small enough to carry out small work and
lengthy functions should be broken into small ones for completing small tasks.

Try not to use GOTO statement:

GOTO statement makes the program unstructured, thus it reduces the
understandability of the program and also debugging becomes difficult.
 Q4.What is the importance of SQA? Explain the SQA
activities.
Software Quality Assurance (SQA) is simply a way to assure quality in the software. It is the
set of activities which ensure processes, procedures as well as standards suitable for the
project and implemented correctly.

Software Quality Assurance is a process which works parallel to development of a software. It

focuses on improving the process of development of software so that problems can be
prevented before they become a major issue. Software Quality Assurance is a kind of an
Umbrella activity that is applied throughout the software process.

Software Quality Assurance have:

A quality management approach

Formal technical reviews

Multi testing strategy

Effective software engineering technology

Measurement and reporting mechanism

Software Quality Assurance Activities:

SQA Management Plan:

Make a plan how you will carry out the sqa through out the project. Think which set of software
engineering activities are the best for project.check level of sqa team skills.

Set The Check Points:

SQA team should set checkpoints. Evaluate the performance of the project on the basis of
collected data on different check points.

Multi testing Strategy:

Do not depend on single testing approach. When you have lot of testing approaches available
use them.

Measure Change Impact:

The changes for making the correction of an error sometimes re introduces more errors keep
the measure of impact of change on project. Reset the new change to change check the
compatibility of this fix with whole project.

Manage Good Relations:

In the working environment managing the good relation with other teams involved in the project
development is mandatory. Bad relation of sqa team with programmers team will impact
directly and badly on project. Don’t play politics.
 Q5. Explain software engineering as a layered technology.

Software engineering can be viewed as a layered technology. Various layers are listed below.

The process layer allows the development of software on time. It defines an outline for a

set of key process areas that must be acclaimed for effective delivery of software engineering
technology.

This layer covers a broad array of tasks that include requirements analysis, design, coding,
testing, and maintenance phase of the software development. The tools layer provides
computerized or semi-computerized support for the process and the method layer.

Q6. Explain the merits and demerits of SCRUM.

Advantages of Scrum

The main advantage of Scrum is that the whole development process happens in short
iterations. Therefore, when it comes to project changes, you can adapt smoothly and in time.
Stakeholders can provide you with feedback immediately after a Sprint ends and before the next
one starts. So, the team can implement all the requirements immediately.

Through continuous feedback and regular testing, we increase the quality of the development
process.

Often, communication within the team ensures a common understanding of the project and its
solutions.

 Disadvantages of Scrum

There are no deadlines for delivering products. Very often, this leads to long discussions
between the Product Owner/Scrum Master and the Project Manager as PMs keep demanding
new functionality.

Scrum is mostly suited for smaller teams (up to

12 team members is best). If you have a bigger team, you need to scale Scrum, which is always
difficult.

Q7. Write a shortnote on requirement engineering .

Requirement Engineering

Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process. Requirement engineering
provides the appropriate mechanism to understand what the customer desires, analyzing the
need, and assessing feasibility, negotiating a reasonable solution, specifying the solution
clearly, validating the specifications and managing the requirements as they are transformed
into a working system. Thus, requirement engineering is the disciplined
application of proven principles, methods, tools, and notation to describe a proposed system's
intended behavior and its associated constraints.
 Requirement Engineering Process

It is a four-step process, which includes -

Ÿ Feasibility Study

Ÿ Requirement Elicitation and Analysis

Ÿ Software Requirement Specification

Ÿ Software Requirement Validation

Ÿ Software Requirement Management.

Q8. Write shortnote on COCOMO model.

Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines
of Code. It is a procedural cost estimate model for software projects and often used as a
process of reliably predicting the various parameters associated with making a project such as
size, effort, cost, time and quality. It was proposed by Barry Boehm in 1970 and is based on the
study of 63 projects, which make it one of the best-documented models.

The key parameters which define the quality of any software products, which are also an
outcome of the Cocomo are primarily Effort & Schedule:

Effort: Amount of labor that will be required to complete a task. It is measured in person-

months units.

Schedule: Simply means the amount of time required for the completion of the job, which is,
of course, proportional to the effort put. It is measured in the units of time such as weeks,
months.

In COCOMO, projects are categorized into three types:

Organic

Semidetached
1.Organic: A development project can be treated of the organic type, if the project deals with
developing a well-understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar methods of
projects. Examples of this type of projects are simple business systems, simple
inventory management systems, and data processing systems

2. Semidetached: A development project can be

treated with semidetached type if the development consists of a mixture of experienced and
inexperienced staff. Team members may have finite experience in related systems but may be
unfamiliar with some aspects of the order being developed. Example of Semidetached system
includes developing a new operating system (OS), a Database Management System
(DBMS), and complex inventory management system.
 Q9. Compare and contrast alpha and beta testing.

Alpha testing is a type of acceptance testing, which is performed to identify all possible
bugs/issues before releasing the product to the end-user. Alpha test is a preliminary software
field test carried out by a team of users to find out the bugs that were not found previously by
other tests. Alpha testing is to simulate a real
user environment by carrying out tasks and operations that actual user might perform. Alpha
testing implies a meeting with a software vendor and client to ensure that the developers
appropriately meet the client's requirements in terms of the performance, functionality, and
durability of the software.

Beta Testing is a type of acceptance testing; it is the final test before shipping a product to the
customers. Beta testing of a product is implemented by "real users "of the software application
in a "real environment." In this phase of testing, the software is released to a limited number of
end-users of the product to obtain feedback on the product quality. It allows the real customers
an opportunity to provide inputs into the design, functionality, and usability of the product.
These inputs are essential for the success of the product. Beta testing reduces product failure
risks and increases the quality of the product through
customer validation. Direct feedback from customers is a significant advantage of beta testing.
This testing helps to tests the software in a real environment.

Q10. Explain the process of code review .

Code Review is a systematic examination, which can find and remove the vulnerabilities in the
code such as memory leaks and buffer overflows.

Technical reviews are well documented and use a well-defined defect detection process that
includes peers and technical experts.

It is ideally led by a trained moderator, who is NOT the author.

This kind of review is usually performed as a peer review without management participation.

Reviewers prepare for the review meeting and prepare a review report with a list of findings.

Technical reviews may be quite informal or very formal and can have a number of purposes but
not limited to discussion, decision making, evaluation of alternatives, finding defects and
solving technical problems.

Q11. Explain integration testing.

Integration testing is the process of testing the interface between two software units or
module. It’s focus on determining the correctness of the interface. The purpose of the
integration testing is to expose faults in the
interaction between integrated units. Once all the modules have been unit tested, integration
testing is performed.

Integration test approaches –

There are four types of integration testing approaches. Those approaches are the following:
 1. Big-Bang Integration Testing –
It is the simplest integration testing approach, where all the modules are combining and
verifying the functionality after the completion of individual module testing. In simple words, all
the modules of the system are simply put together and tested. This approach is practicable
only for very small systems. If once an error is found during the integration testing, it is very
difficult to localize the error as the error may potentially belong to any of the modules being
integrated.

Advantages:
It is convenient for small systems.

Disadvantages:

There will be quite a lot of delay because you would have to wait for all the modules to be
integrated.

High risk critical modules are not isolated and tested on priority since all modules are tested at
once.

2. Bottom-Up Integration Testing –

In bottom-up testing, each module at lower levels is tested with higher modules until all
modules are tested. The primary purpose of this integration testing is, each subsystem is to
test the interfaces among various modules making up the subsystem. This integration testing
uses test drivers to drive and pass appropriate data to the lower level modules.

Advantages:

In bottom-up testing, no stubs are required.

A principle advantage of this integration testing is that several disjoint subsystems can be
tested simultaneously.

Disadvantages:

Driver modules must be produced.

In this testing, the complexity that occurs when the system is made up of a large number of
small subsystem.

3. Top-Down Integration Testing –

Top-down integration testing technique used in order to simulate the behaviour of the lower-
level modules that are not yet integrated.In this integration testing, testing takes place
from top to bottom. First high-level modules are tested and then low-level modules and finally
integrating the low-level modules to a high level to ensure the system is working as intended.

Advantages:

Separately debugged module.

Few or no drivers needed.

It is more stable and accurate at the aggregate level.

 Disadvantages:

Needs many Stubs.

Modules at lower level are tested inadequately.

Q12.Explain version and change control

management.

Version Control:-
Software Version Control is a system or tool that captures the changes to a source code
elements: files, folders, images or binaries.
A version control system (also known as a Revision Control System) is a repository of files,
often the files for the source code of computer programs, with monitored access. Every change
made to the source is tracked, along with who made the change, why they made it, and
references to problems fixed, or enhancements introduced, by the change.

• Combines procedures and tools to manage the different versions of configuration objects
created during the software process.

Change Control:-
Change control is a systematic approach to managing all changes made to a product or system.
The purpose is to ensure that no unnecessary changes are made, that all changes are
documented, that services are not unnecessarily disrupted and that resources are used
efficiently.

Version Control and change control system often implements an issue tracking (also called

bug tracking) capability that enables the team to record and track the status of all outstanding
issues associated with each configuration object.