Assignment PGD-2103: Software Engineering

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 20

Assignment PGD-2103

Software Engineering

USOL-PGDCA

GURPREET SINGH BEDI


ROLL NO-56463
PGDCA- 2nd SEMESTER (2019-2020)

GURPREET SINGH BEDI ROLL NO-56463


Q1. Define software and its various characteristics in detail.

Ans. In earlier times, software was simple in nature and hence, software development was a
simple activity. However, as technology improved, software became more complex and
software projects grew larger. Software development now necessitated the presence of a team,
which could prepare detailed plans and designs, carry out testing, develop intuitive user
interfaces, and integrate all these activities into a system. This new approach led to the
emergence of a discipline known as software engineering.
Software engineering provides methods to handle complexities in a software system and
enables the development of reliable software systems, which maximize productivity. In addition
to the technical aspects of the software development, it also covers management activities
which include guiding the team, budgeting, preparing schedules, etc. The notion of software
engineering was first proposed in 1968. Since then, software engineering has evolved as a
full-fledged engineering discipline, which is accepted as a field involving in-depth study and
research. Software engineering methods and tools have been successfully implemented in
various applications spread across different walks of life.
Software is defined as a collection of programs, documentation and operating procedures.
The Institute of Electrical and Electronic Engineers (IEEE) defines software as a 'collection
of computer programs, procedures, rules and associated documentation and data.'​ ​It possesses
no mass, no volume, and no colour, which makes it a non-degradable entity over a long period.
Software does not wear out or get tired.
Software controls, integrates, and manages the hardware components of a computer system. It
also instructs the computer what needs to be done to perform a specific task and how it is to be
done. For example, software instructs the hardware how to print a document, take input from
the user, and display the output.
Computer works only in response to instructions provided externally. Usually, the instructions
to perform some intended tasks are organized into a program using a programming language
like C, C++, Java, etc., and submitted to computer. Computer interprets and executes these
instructions and provides response to the user accordingly. A set of programs intended to
provide users with a set of interrelated functionalities is known as a software package​. ​For
example, an accounting software package such as Tally provides users the functionality to
perform accounting-related activities.
Software Characteristics
Different individuals judge software on different basis. This is because they are involved with
the software in different ways. For example, users want the software to perform according to
their requirements. Similarly, developers involved in designing, coding, and maintenance of the
software evaluate the software by looking at its internal characteristics, before delivering it to
the user. Software characteristics are classified into six major components.

GURPREET SINGH BEDI ROLL NO-56463


• Functionality: ​Refers to the degree of performance of the software against its intended
purpose.
• Reliability: ​Refers to the ability of the software to provide desired functionality under the
given conditions.
• Usability: ​Refers to the extent to which the software can be used with ease.
• Efficiency: ​Refers to the ability of the software to use system resources in the most effective
and efficient manner.
• Maintainability: ​Refers to the ease with which the modifications can be made in a software
system to extend its functionality, improve its performance, or correct errors.
• Portability: ​Refers to the ease with which software developers can transfer software from
one platform to another, without (or with minimum) changes. In simple terms, it refers to the
ability of software to function properly on different hardware and software platforms without
making any changes in it.
In addition to the above mentioned characteristics, robustness and integrity are also
important. ​Robustness ​refers to the degree to which the software can keep on functioning in
spite of being provided with invalid data while ​integrity refers to the degree to which
unauthorized access to the software or data can be prevented.

Q2. Explain various software engineering principles.

Ans. ​A set of fundamental principles can act as an enabler in the establishment of a discipline;
however, software engineering still lacks a set of universally recognized fundamental principles.
A fundamental principle is less specific and more enduring than methodologies and techniques.
It should be phrased to withstand the test of time. It should not contradict a more general
engineering principle and should have some correspondence with “best practice”. It should be
precise enough to be capable of support and contradiction and should not conceal a trade off.
It should also relate to one or more computer science or engineering concepts. [1]

Principles are common and conceptual statements describing desirable properties of software
products and processes. Principles become practice through methods and techniques, often
methods and techniques are packaged in a methodology. Methodologies can be enforced by
tools.

Principles of Software Engineering have a good impact on the process of software engineering
and also on the final product. These principles facilitate to develop software in such a manner
that it posses all the qualities like: efficiency, functionality, adaptability, maintainability, and
usability. Principles are general, abstract statements describing desirable properties of software
processes and products. The principles are applicable throughout the lifecycle of the software.
Principles are the set of statements which describe the advantageous features of the product
and process. Focus on both process and product is needed to deliver software systems. These
principles help in controlling process which in turn helps to control the quality of the product.

GURPREET SINGH BEDI ROLL NO-56463


Only the control of process will not guarantee a quality product therefore it is important to
concentrate on both process and quality.

As said earlier there are no fundamentally recognized principles of Software Engineering but we
can list down few that may be used in all phases of software development.

● Rigor and formality


● Separation of concerns
● Modularity and decomposition
● Abstraction
● Anticipation of change
● Generality
● Incremental Development
● Reliability

Q3: Explain the various activities of Software Project management Plan in detail.

Ans: ​Software project management comprises of a number of activities, which contains


planning of project, deciding scope of software product, estimation of cost in various terms,
scheduling of tasks and events, and resource management. Project management activities may
include:

● Project Planning
● Scope Management
● Project Estimation
Project Planning
Software project planning is task, which is performed before the production of software
actually starts. It is there for the software production but involves no concrete activity that has
any direction connection with software production; rather it is a set of multiple processes,
which facilitates software production. Project planning may include the following:
Scope Management
It defines the scope of project; this includes all the activities, process need to be done in order
to make a deliverable software product. Scope management is essential because it creates
boundaries of the project by clearly defining what would be done in the project and what
would not be done. This makes project to contain limited and quantifiable tasks, which can
easily be documented and in turn avoids cost and time overrun.
During Project Scope management, it is necessary to -

● Define the scope

GURPREET SINGH BEDI ROLL NO-56463


● Decide its verification and control
● Divide the project into various smaller parts for ease of management.
● Verify the scope
● Control the scope by incorporating changes to the scope
Project Estimation
For an effective management accurate estimation of various measures is a must. With correct
estimation managers can manage and control the project more efficiently and effectively.
Project estimation may involve the following:

● Software size estimation


Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software. Lines of code depend upon
coding practices and Function points vary according to the user or software
requirement.

● Effort estimation
The managers estimate efforts in terms of personnel requirement and man-hour
required to produce the software. For effort estimation software size should be known.
This can either be derived by managers’ experience, organization’s historical data or
software size can be converted into efforts by using some standard formulae.

● Time estimation
Once size and efforts are estimated, the time required to produce the software can be
estimated. Efforts required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks
are divided into smaller tasks, activities or events by Work Breakthrough Structure
(WBS). The tasks are scheduled on day-to-day basis or in calendar months.
The sum of time required to complete all tasks in hours or days is the total time
invested to complete the project.

● Cost estimation
This might be considered as the most difficult of all because it depends on more
elements than any of the previous ones. For estimating project cost, it is required to
consider -

o Size of software
o Software quality
o Hardware

GURPREET SINGH BEDI ROLL NO-56463


o Additional software or tools, licenses etc.
o Skilled personnel with task-specific skills
o Travel involved
o Communication
o Training and support

Q4: Explain SDLC in detail.

Ans: ​Software Development Life Cycle (SDLC) is a process used by the software industry to
design, develop and test high quality softwares. The SDLC aims to produce a high-quality
software that meets or exceeds customer expectations, reaches completion within times and
cost estimates.
● SDLC is the acronym of Software Development Life Cycle.
● It is also called as Software Development Process.
● SDLC is a framework defining tasks performed at each step in the software
development process.
● ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to
be the standard that defines all the tasks required for developing and maintaining
software.
SDLC is a process followed for a software project, within a software organization. It consists of
a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.

GURPREET SINGH BEDI ROLL NO-56463


A typical Software Development Life Cycle consists of the following stages −
Stage 1: Planning and Requirement Analysis
Requirement analysis is the most important and fundamental stage in SDLC. It is performed by
the senior members of the team with inputs from the customer, the sales department, market
surveys and domain experts in the industry. This information is then used to plan the basic
project approach and to conduct product feasibility study in the economical, operational and
technical areas.
Planning for the quality assurance requirements and identification of the risks associated with
the project is also done in the planning stage. The outcome of the technical feasibility study is
to define the various technical approaches that can be followed to implement the project
successfully with minimum risks.
Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define and document the
product requirements and get them approved from the customer or the market analysts. This
is done through an ​SRS (Software Requirement Specification)​ document which consists of all
the product requirements to be designed and developed during the project life cycle.
Stage 3: Designing the Product Architecture

GURPREET SINGH BEDI ROLL NO-56463


SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and documented in a DDS - Design
Document Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as
risk assessment, product robustness, design modularity, budget and time constraints, the best
design approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if
any). The internal design of all the modules of the proposed architecture should be clearly
defined with the minutest of the details in DDS.
Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the product is built. The programming
code is generated as per DDS during this stage. If the design is performed in a detailed and
organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and programming
tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high
level programming languages such as C, C++, Pascal, Java and PHP are used for coding. The
programming language is chosen with respect to the type of software being developed.
Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing
only stage of the product where product defects are reported, tracked, fixed and retested,
until the product reaches the quality standards defined in the SRS.
Stage 6: Deployment in the Market and Maintenance
Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometimes product deployment happens in stages as per the business strategy of that
organization. The product may first be released in a limited segment and tested in the real
business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the market, its
maintenance is done for the existing customer base.
SDLC Models
There are various software development life cycle models defined and designed which are
followed during the software development process. These models are also referred as
Software Development Process Models". Each process model follows a Series of steps unique
to its type to ensure success in the process of software development.
Following are the most important and popular SDLC models followed in the industry −

GURPREET SINGH BEDI ROLL NO-56463


● Waterfall Model
● Iterative Model
● Spiral Model
● V-Model
● Big Bang Model
Other related methodologies are Agile Model, RAD Model, Rapid Application Development
and Prototyping Models.

Q5: Explain COCOMO cost estimation model with example.

Ans: ​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.
Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of constant to be
used in subsequent calculations. These characteristics pertaining to different system types are
mentioned below.
Boehm’s definition of organic, semidetached, and embedded systems:
Organic – A software project is said to be an organic type if the team size required is adequately
small, the problem is well understood and has been solved in the past and also the team
members have a nominal experience regarding the problem.
Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team-size, experience, knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as
Semi-Detached are comparatively less familiar and difficult to develop compared to the organic

GURPREET SINGH BEDI ROLL NO-56463


ones and require more experience and better guidance and creativity. Eg: Compilers or
different Embedded Systems can be considered of Semi-Detached type.
Embedded – A software project with requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size than
the other two models and also the developers need to be sufficiently experienced and creative
to develop such complex models.
All the above system types utilize different values of the constants used in Effort Calculations.
Types of Models: COCOMO consists of a hierarchy of three increasingly detailed and accurate
forms. Any of the three forms can be adopted according to our requirements. These are types
of COCOMO model:
Basic COCOMO Model
Intermediate COCOMO Model
Detailed COCOMO Model
The first level, Basic COCOMO can be used for quick and slightly rough calculations of Software
Costs. Its accuracy is somewhat restricted due to the absence of sufficient factor
considerations.
Intermediate COCOMO takes these Cost Drivers into account and Detailed COCOMO
additionally accounts for the influence of individual project phases, i.e in case of Detailed it
accounts for both these cost drivers and also calculations are performed phase wise henceforth
producing a more accurate result. These two models are further discussed below.
Basic Model –
E= a(KLOC)^b
The above formula is used for the cost estimation of for the basic COCOMO model, and also is
used in the subsequent models. The constant values a and b for the Basic Model for the
different categories of system.The effort is measured in Person-Months and as evident from the
formula is dependent on Kilo-Lines of code. These formulas are used as such in the Basic Model
calculations, as not much consideration of different factors such as reliability, expertise is taken
into account, henceforth the estimate is rough.
Intermediate Model –
The basic Cocomo model assumes that the effort is only a function of the number of lines of
code and some constants evaluated according to the different software system. However, in
reality, no system’s effort and schedule can be solely calculated on the basis of Lines of Code.
For that, various other factors such as reliability, experience, Capability. These factors are
known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for cost estimation.

GURPREET SINGH BEDI ROLL NO-56463


Classification of Cost Drivers and their attributes:
(i) Product attributes –
Required software reliability extent
Size of the application database
The complexity of the product
(ii) Hardware attributes –
Run-time performance constraints
Memory constraints
The volatility of the virtual machine environment
Required turnabout time
(iii) Personnel attributes –
Analyst capability
Software engineering capability
Applications experience
Virtual machine experience
Programming language experience
(iv) Project attributes –
Use of software tools
Application of software engineering methods
Required development schedule
Detailed Model –
Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the software engineering process. The
detailed model uses different effort multipliers for each cost driver attribute. In detailed
cocomo, the whole software is divided into different modules and then we apply COCOMO in
different modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
Planning and requirements
System design

GURPREET SINGH BEDI ROLL NO-56463


Detailed design
Module code and test
Integration and test
Cost Constructive model

Q6: Explain various risk management activities in detail.

Ans: Risk is an inexorable and an unavoidable part of a software development process, which
constantly evolves throughout the course of a project, affecting a project or software or both.
Thus, it arise the necessity to deal and manage these risks in an efficient and effective manner.
In the field of software engineering, ​risk management​ is a methodology or a mechanism,
carried out throughout the development process to identify, manage and control risks evolved
before and during the development process.
Basically, three types of activities are covered under the risk management process.

● Risk Identification.

● Risk Analysis.

● Risk Control.

Risk Identification:

GURPREET SINGH BEDI ROLL NO-56463


It is the first step of a risk management process, which involves the identification of potential
risks that may affect a software product or a development project, and accordingly
documenting them along with their characteristics.
It is a constant process, which is carried out throughout the development due to the fact that as
the development process progresses, the more we get to know about the software product and
based on it, we may able to explore and identify more unvisited or hidden risks.
Generally, this phase helps in identifying the two types of risks, product risk and project risk.

● Product risk​: Risks pertaining to a software product or application, which may arise, due
to its inefficiency, to function, desirably, to meet the expectation of the users.

● Project risk​: These risks involves any sort of uncertain or unexpected event or action,
which may likely to occur and degrade the progress of a project.

In this phase, usually client, stakeholders, business manager, project manager and test
manager, collaborate and participates in brainstorming or small sessions, study and
analyze the project documentation plan, etc., to make out the probable list of risks
associated with the software development. Some commonly known techniques to
identify risks may include risk templates, project retrospective, Failure Mode and Effect
Analysis (FMEA), Failure Mode Effect and Criticality Analysis (FMECA), etc.

Risk Assessment:
The next stage of a risk management process is risk analysis, which involves the assessment of
the risks identified during the risk identification stage.

● This stage usually involves the analysis and prioritization of the risks, i.e. possible
outcomes of each identified risk is being assessed based on which risks are categorized
and accordingly, prioritized.

● Based on the degree of impact, possessed by each risk, they are being assigned severity
levels, namely 'High', 'Medium' and 'low'. And based on their severity, they are prioritize
i.e. High risks are considered as top priority whereas the low risk is regarded for the
bottom most priority.

Risk Control:
During this stage, risks are managed, controlled and mitigated, based on their priority so as to
achieve the desired results. It is generally divided into three activities which may be seen
below.

● Risk Management Planning:​ It involves a proper and effective plan to deal with the each
identified risk.

GURPREET SINGH BEDI ROLL NO-56463


● Risk Resolution: ​It refers to the execution of the plans, outlined during the risk
management planning stage so as to either remove or fix identified risks.

● Risk Monitoring:​ It involves, regular monitoring and tracking, the development


progress, in the direction, of resolving risk issues, which may include revaluation of the
risks, their likelihood to occur, etc., and taking and implementing necessary &
appropriate actions, wherever necessary.

Q7: Explain the design process in detail.

Ans: ​The Design Process is an approach for breaking down a large project into manageable
chunks. Architects, engineers, scientists, and other thinkers use the design process to solve
a variety of problems. Use this process to define the steps needed to tackle each project,
and remember to hold to all of your ideas and sketches throughout the process.

Here are some helpful tools to get you started:

The Design Process Worksheet

Common Core Connections

Digital Resources for Design Challenges

THE DESIGN PROCESS CONSISTS OF 6 STEPS:

1. Define the Problem

You can’t find a solution until you have a clear idea of what the problem is.

2. Collect Information

Collect sketches, take photographs and gather data to start giving you inspiration.

3. Brainstorm and Analyze Ideas

Begin to sketch, make, and study so you can start to understand how all the data and
information you’ve collected may impact your design.

4. Develop Solutions

GURPREET SINGH BEDI ROLL NO-56463


Take your preliminary ideas and form multiple small-scale design solutions.

5. Gather Feedback

Present your ideas to as many people as possible: friends, teachers, professionals, and any
others you trust to give insightful comments.

6. Improve

Reflect on all of your feedback and decide if or to what extent it should be incorporated. It
is often helpful to take solutions back through the Design Process to refine and clarify them.

Q8: Explain testing process.

Ans: ​Testing is the process of evaluating a system or its component(s) with the intent to find
whether it satisfies the specified requirements or not. In simple words, testing is executing a
system in order to identify any gaps, errors, or missing requirements in contrary to the actual
requirements.
According to ANSI/IEEE 1059 standard, Testing can be defined as - A process of analyzing a
software item to detect the differences between existing and required conditions (that is
defects/errors/bugs) and to evaluate the features of the software item.
Who does Testing?
It depends on the process and the associated stakeholders of the project(s). In the IT industry,
large companies have a team with responsibilities to evaluate the developed software in
context of the given requirements. Moreover, developers also conduct testing which is
called Unit Testing. In most cases, the following professionals are involved in testing a system
within their respective capacities −

● Software Tester
● Software Developer
● Project Lead/Manager
● End User
Different companies have different designations for people who test the software on the basis
of their experience and knowledge such as Software Tester, Software Quality Assurance
Engineer, QA Analyst, etc.
It is not possible to test the software at any time during its cycle. The next two sections state
when testing should be started and when to end it during the SDLC.
When to Start Testing?

GURPREET SINGH BEDI ROLL NO-56463


An early start to testing reduces the cost and time to rework and produce error-free software
that is delivered to the client. However in Software Development Life Cycle (SDLC), testing can
be started from the Requirements Gathering phase and continued till the deployment of the
software.
It also depends on the development model that is being used. For example, in the Waterfall
model, formal testing is conducted in the testing phase; but in the incremental model, testing
is performed at the end of every increment/iteration and the whole application is tested at the
end.
Testing is done in different forms at every phase of SDLC −
● During the requirement gathering phase, the analysis and verification of requirements
are also considered as testing.
● Reviewing the design in the design phase with the intent to improve the design is also
considered as testing.
● Testing performed by a developer on completion of the code is also categorized as
testing.
When to Stop Testing?
It is difficult to determine when to stop testing, as testing is a never-ending process and no one
can claim that a software is 100% tested. The following aspects are to be considered for
stopping the testing process −
● Testing Deadlines
● Completion of test case execution
● Completion of functional and code coverage to a certain point
● Bug rate falls below a certain level and no high-priority bugs are identified
● Management decision
Verification & Validation
These two terms are very confusing for most people, who use them interchangeably. The
following table highlights the differences between verification and validation.

Sr.No. Verification Validation

1 Verification addresses the concern: "Are Validation addresses the concern:


you building it right?" "Are you building the right thing?"

GURPREET SINGH BEDI ROLL NO-56463


2 Ensures that the software system meets Ensures that the functionalities
all the functionality. meet the intended behavior.

3 Verification takes place first and includes Validation occurs after verification
the checking for documentation, code, and mainly involves the checking of
etc. the overall product.

4 Done by developers. Done by testers.

5 It has static activities, as it includes It has dynamic activities, as it


collecting reviews, walkthroughs, and includes executing the software
inspections to verify a software. against the requirements.

6 It is an objective process and no It is a subjective process and


subjective decision should be needed to involves subjective decisions on how
verify a software. well a software works.

Q9: List various testing objectives.

Ans: Software testing is a crucial element in the software development life cycle (SDLC), which
can help software engineers save time & money of organizations by finding errors and defects
during the early stages of software development. With the assistance of this process one can
examine various components associated with the application and guarantee their
appropriateness.
The goals and objectives of software testing are numerous, which when achieved help
developers build a defectless and error free software and application that has exceptional
performance, quality, effectiveness, security, among other things. Though the objective of
testing can vary from company to company and project to project, there are some goals that
are similar for all. These objectives are:

1. Verification: A prominent objective of testing is verification, which allows testers to


confirm that the software meets the various business and technical requirements stated
by the client before the inception of the whole project. These requirements and
specifications guide the design and development of the software, hence are required to

GURPREET SINGH BEDI ROLL NO-56463


be followed rigorously. Moreover, compliance with these requirements and
specifications is important for the success of the project as well as to satisfy the client.

2. Validation:​ Confirms that the software performs as expected and as per the
requirements of the clients. ​Validation​ involves checking the comparing the final output
with the expected output and then making necessary changes if their is a difference
between the two.

3. Defects:​ The most important purpose of testing is to find ​different defects​ in the
software to prevent its failure or crash during implementation or go live of the project.
Defects if left undetected or unattended can harm the functioning of the software and
can lead to loss of resources, money, and reputation of the client. Therefore, ​software
testing​ is executed regularly during each ​stage of software development​ to find defects
of various kinds. The ultimate source of these defects can be traced back to a fault
introduced during the specification, design, development, or programming phases of
the software.

4. Providing Information:​ With the assistance of reports generated during the ​process of
software testing​, testers can accumulate a variety of information related to the software
and the steps taken to prevent its failure. These, then can be shared with all the
stakeholders of the project for better understanding of the project as well as to
establish transparency between members.

5. Preventing Defects:​ During the process of testing the aim of testes to identify ​defects
and prevent them from occurring aging in the future​. To accomplish this goal, software
is tested rigorously by a independent testers, who are not responsible for software
development.

6. Quality Analysis:​ Testing helps improve the ​quality of the software​ by constantly
measuring and verifying its design and coding. Additionally, various types of testing
techniques are used by testers, which help them achieve the desired software quality.

7. Compatibility:​ It helps validate application’s compatibility with the implementation


environment, various devices, Operating Systems, user requirements, among other
things.

8. For Optimum User Experience:​ Easy software and application accessibility and optimum
user experience are two important requirements that need to be accomplished for the
success of any project as well as to increase the revenue of the client. Therefore, to
ensure this software is tested again and again by the testers with the assistance of stress
testing, load testing, spike testing, etc.

GURPREET SINGH BEDI ROLL NO-56463


9. Verifying Performance & Functionality:​ It ensures that the software has
superior ​performance and ​functionality​. This is mainly verified by placing the software
under extreme stress to identify and measure its all plausible failure modes. To ensure
this, performance testing, ​usability testing​, functionality testing, etc. is executed by the
testers.

Q10: What are various quality attributes? Explain in detail.

Ans: ​The various quality attributes are:


▪ Interoperability​ describes the ability of a service to communicate with other services and
allow other services to communicate with it. It measures how freely information can be
exchanged. Measures like programming language agnostic data formats, content
negotiation, backwards compatible APIs, etc. can support interoperability between
services.
▪ Reliability​ reflects the ability of a service to operate correctly. Automation to enable
roll-backs and recovery can reduce the mean time between failure (MTBF).
▪ Availability​ is the ability of a service to answer to requests / be accessible. Uptime can be
increased by adding fault-tolerance measures and resilience, e.g. through redundancy.
▪ Usability​ measures the quality of user experience (UX) a service provides. It can be
increased by having a UX focused development workflow. As an unavailable or slow
service is also not usable there is a strong dependency between usability and other
attributes.
▪ Security​ has two major aspects: Confidentiality (access only granted to authorized users)
and authenticity (trust the provided information). Helpful techniques are found in the
area of cryptography, e.g. encryption and digital signatures. Additionally you should
implement secure processes like regularly invalidating or rotating credentials or enforcing
two factor authentication. Check how you are doing by executing regular penetration
tests.
▪ Performance​ is a broad topic. In the context of services people often refer to response
time or latency as a performance measure. It can be achieved by choosing the right
algorithms and data structures for the problem and sizing the system according to the
load. Add automated performance or load tests to detect regressions.
▪ Scalability​ describes the ability to deal with changes. When talking about scalability it is
important to define what changes the system is reacting to, e.g. an increased number of
users, new products offered in a shop, more requests coming in, or even more
developers joining the company. Scalability is most commonly achieved by decoupling
and separation of concerns in combination with choosing algorithms and data structures
that allow a performance increase by adding more resources.

GURPREET SINGH BEDI ROLL NO-56463


▪ Extensibility​ represents the ability to add functionality to a component without touching
other components or parts of the system. Architectures that involve loose coupling,
communication standards and evolution friendly interfaces and schemas promote
extensibility.
▪ Adaptability​ influences how easy it is to change the system if requirements have
changed. Similarly to extensibility this can be achieved by loose coupling, but also
through abstraction, e.g. putting a layer between your database and application so you
can exchange the database technology. Adaptability is also influenced by configurability.
▪ Testability​ matters when it comes to building and automating tests of individual
components, interactions between components, as well as the system as a whole. In
addition to that it is also crucial to know how well these tests can detect errors.
Testability is especially hard in distributed systems or service oriented architectures, as
components are connected through an unreliable network, different versions of services
might exist, and there is no single entity that knows the internal state of all components.
Note as well that behavior of dynamic environments involving auto-scaling and service
discovery might be hard to predict.
▪ Auditability​ captures the ability to perform audits of the system. Audits might be
required for legal, security, or financial reasons, for example. Auditability is a tough goal
as it requires all services involved in a process to be auditable. Generally, having
immutable storage and versioning of events and data already contributes a great deal
towards an auditable system.
▪ Observability​ expresses whether changes in a system are reflected, if possible, in a
quantitative manner. Promoting a DevOps culture can increase observability because the
team responsible for change is also responsible for operations, which greatly benefits
from rich metrics being available.
▪ Operability​ characterizes the ease at which the system can be deployed and operated
during runtime. Besides observability, operations can be supported by automation.
Techniques like chaos engineering can put your operability to the test by introducing
errors on purpose.

GURPREET SINGH BEDI ROLL NO-56463

You might also like