SOFTWARE QUALITY

FACTORS

teacher: Students:

Villegas, Arteaga,
Anabel Manuel.
27.928.441

bladestone3
94@gmail.c
om|0424-
8417581

Meneses,
Emilianny.
28.229.366

emixmenese
sx@gmail.co
m|0424-
8119482

Ortega,
 November 12, 2021.

Software quality factors

The various factors that influence the software, are termed as software factors. They can be
broadly divided into two categories. The classification is done on the basis of measurability. The
first category of the factors is of those that can be measured directly such as number of logical
errors and the second category clubs those factors which can be measured only indirectly for
example maintainability but the each of the factors are to be measured to check for the content
and the quality control. Few factors of quality are available and they are mentioned below.

Correctness: Extent to which a program satisfies its specification and fulfills the client’s objective.

Reliability: Extent to which a program is supposed to perform its function with the required
precision.

Efficiency: Amount of computing and code requires by a program to perform its function.

Integrity: Extent to which access to software and data is denied to unauthorizes users.

Usability: Labor required to understand, operate, prepare input and interpret output of a
program.

Maintainability: Effort required to locate and fix an error in a program.

Flexibility: Effort needed to modify an operational program.

Testability: Effort required to test the programs for their functionality.

Portability: Effort required to run the program from one platform to other or to different
hardware.

Reusability: Extent to which the program or it’s parts can be used as building blocks or as
prototypes for other programs.

Interoperability: Effort required to couple one system to another.

Product quality assessment

We believe that one should measure software code quality by using the source code as the source
of truth. The reason for this is that source code is the only tangible asset in a released software
product. Once code is shipped, it doesn’t matter anymore how nice your architecture documents
were or how well-defined your software development processes were.

A positive side-effect of taking source code as starting point is that most work on code quality can
be automated. This means that the results can be obtained fast and in a relatively inexpensive
way. Moreover, the generated data is reproducible and can be benchmarked.
Quality models (MOPROSOFT, SWCMM, ISO)
MOPROSOFT
Process Model for the Software Industry is a model for the improvement and evaluation of the
development and maintenance processes of software systems and products. Developed by the
Mexican Association for Quality in Software Engineering through the Faculty of Accounting and
Administration of the National Autonomous University of Mexico (UNAM) and at the request of
the Ministry of Economy to obtain a Mexican standard that is appropriate to the size
characteristics of the vast majority of Mexican software development and maintenance
companies. Moprosoft is the name of the model in the university and professional community,
and the technical standard to which it gives content is NMX-059/02-NYCE-2005, which was
declared Mexican Standard on August 15, 2005 with the publication of its declaration in the
Official Gazette of the Federation.

Moprosoft believes that the CMMI and ISO / IEC 15504 evaluation and improvement models are
not appropriate for small and medium-sized software development and maintenance companies.
This model has been developed on the process areas of levels 2 and 3 of the SW-CMM model and
taking inspiration from the framework of ISO / IEC 15504.

CMM-SW
Capability Maturity Model for Software development (SW-CMM). It is a process model for the
development and maintenance of software systems, designed on the criteria:

The quality of a product or system is a direct consequence of the processes used in its
development.

Organizations that develop software present an attribute called maturity, whose measure is
proportional to the levels of capacity and institutionalization of the processes they use in their
work.

ISO
ISO 17025 is a standard oriented to conformity assessment. It contains the general requirements
for the competence of testing and calibration laboratories. This standard was published by ISO in
December 1999 and revised in May 2005. It is the result of the partnership between The
International Standards Organization and the International Electrotechnical Commission.

The standard replaces ISO Guide 25 and EN 45001 and takes into account the operational
experience gained since the previous standards were published.

Project planning
Project planning is the set of activities with which software project management begins.

The estimate begins with a description of the scope of the product. The problem is broken down
into a set of smaller problems, each of which is estimated based on historical data and experience.

The primary objective is to made reasonable estimates of resources, cost and time planning.

Estimates involve a period of time and should be updated as the project progresses.
Control
Software control is the process of the physical storage in a definitive software library of all
software to ensure that only correctly released, licensed, and authorized versions of software are
in use. Processes in this category include the tracking of releases, patches, service packs, and bug
fixes. Software distribution is an additional process through which all software from the definitive
software library is disseminated to authorized users to ensure that only correctly released and
licensed versions of software are in use. This often the single most expensive activity to a support
organization.

Project estimation
Estimate to Completion (ETC) is the estimated time a resource takes to complete de assignment.
Value is important for project planning and for revenue recognition. In the short term, estimates
help project managers to allocate work hours more effectively. In the long term, Project managers
Will be able to compare estimates with actual data, which can help produce more accurate plans
and forecasts. The estimation properties show the current and new ETC values. ETC can be
allocated for both working and non-working resources. Work resources always have defined
availability value as it is necessary information. An availability value is not required to assign ETC to
non-working resources.

Software Metrics: function-oriented metrics and sized-oriented

metrics.
Function-Oriented Metrics
Function-oriented software metrics use a measure of the functionality delivered by the application
as a normalization value. Since functionality cannot be measured directly, it must be derived
indirectly by other direct measures.

Function-oriented metrics were first proposed by Albretch, who suggested a measure called a
function point.

Function points are derived with an empirical relationship based on (direct) accounting measures
of the software information domain and software complexity assessments.

Number of user inputs

Each user input that provides different application-oriented data is counted. Entries should be
distinguished from requests, which are counted separately.

Number of user outputs

Each user output that provides the user with application-oriented information is counted. In this
context the output refers to reports, screens, error messages.

Number of user requests

A request is defined as an interactive input that produces some immediate software response in
the form of interactive output.
Number of files
Each logical master file (that is, a logical group of data that can be a part of a large database or a
separate file) is counted.

Number of external interfaces

All machine-readable interfaces (for example: disk or tape data files) that are used to transmit
information to another system are counted.

After the above data has been collected, a complexity value is associated with the account.

Sized-Oriented Metrics
Sized-oriented software metrics come from the standardization of quality and/or productivity
measures considering the size of the software that has been produced. If a software organization
maintains simple records, a size-oriented data table can be created. The table lists each software
development project for the past several years and the corresponding measurements for each
project. It should be noted that the effort and cost recorded in the table includes all software
engineering activities (analysis, design, coding and testing) and not just coding.