Configuración de Equipos de Comunicaciones
Una red de datos es un sistema que enlaza dos o más puntos (terminales) por un medio físico, el cual sirve para enviar o recibir un determinado flujo de información. El medio de Internet ofrece lo siguiente:
• Vías económicas y rápidas para comunicarse en forma escrita entre sí (las versiones de audiovisuales de dicha comunicación no tienen aún un uso difundido en esta etapa);
Los factores de calidad del software sirven para descomponer el
concepto genérico de “calidad” en otros más sencillos, para facilitar su
control y su medición.
Dado que la división en factores es una
división subjetiva, existen varias clasificaciones de los factores de calidad.
Veremos la de McCall, que los agrupa en tres perspectivas: operativa, de
mantenimiento y evolutiva.
Factores operativos de la calidad del software.
Los
factores operativos son aquellos que afectan al uso del software:
- Corrección: el software
cumple las especificaciones
- Fiabilidad: grado en el
que el software es confiable, es decir, no tiene fallos
- Eficiencia: necesidad de
recursos software y hardware del producto
- Seguridad: grado en el
que puede controlarse el acceso al software y a los datos
- Facilidad de uso: grado
de esfuerzo necesario para utilizar el software
Factores de mantenimiento de la calidad del
software.
Los factores de mantenimiento son aquellos
que se aplican a la capacidad de modificación del software:
- Flexibilidad: esfuerzo
necesario para modificar un programa
- Facilidad de prueba:
esfuerzo requerido para realizar las pruebas de un programa
- Facilidad de mantenimiento:
esfuerzo requerido para localizar y reparar un error
Factores evolutivos
Los factores evolutivos son aquellos que
indican si el software se puede trasladar con facilidad a otra máquina o a otro
producto de base (SO, SGBD, etc.), o incrementar sus prestaciones:
- Portabilidad: facilidad
para migrar el software de un entorno de operación a otro
- Capacidad de
reutilización: grado en el que un programa o parte del mismo se puede
utilizar en otras aplicaciones.
- Capacidad de
interoperación: esfuerzo necesario para que un software opere
conjuntamente con otros sistemas.
2. Evaluación de la calidad del
producto: documentación, pruebas de
aceptación, operación y mantenimiento.
DOCUMENTACION:
Manual de calidad. Es el
documento principal para establecer e implantar un sistema de calidad. Puede
haber manuales a nivel de empresa, departamento, producto,
específicos (compras, proyectos).
La creación de software y la
realización de proyectos de creación de software implican la creación y gestión
de la documentación asociada. Cada paso en la creación y producción de software
supone la generación de documentación que se tiene que contemplar y gestionar.
La correcta gestión de esta documentación permite controlar los proyectos,
facilita la utilización por parte del usuario y disminuye los costes. El
concepto de documentación de software comprende diferentes tipos de
documentación e implica diferentes roles:
– Documentación de arquitectura/diseño: Define las prácticas, técnicas y tipos de
representaciones utilizadas por los arquitectos de software para registrar una
arquitectura de software. Una de las ramas de la fase diseño de software
implica la creación de un libro blanco sobre aspectos concretos del sistema,
como la interfaz de diseño, el código, el documento de diseño, los elementos de
diseño, etc., y es útil para los diseñadores, desarrolladores, administradores,
etc. de las base de datos o aplicaciones.
–Documentación técnica: Acompaña al software y describe varios aspectos de su
funcionamiento. Documenta el código, algoritmos, interfaces y API. La
documentación técnica puede ser utilizada por los desarrolladores, probadores y
también por los clientes finales o clientes. Varias herramientas, como Doxygen,
Ndoc, RoboDoc, etc., permiten generar automáticamente documentación a partir
del código fuente y crear manuales de referencia en formas como por ejemplo
archivos de texto o HTML.
– Requisitos de software: Los requisitos son la descripción de lo que un software hará o no hará y
son declaraciones que identifican atributos, capacidades, características o
cualidades de un sistema. Los requisitos afectan a todos los agentes
involucrados en la producción: usuarios, clientes, gerentes, ventas, marketing,
arquitectos de software, ingenieros de usabilidad, diseñadores de interacción,
desarrolladores, etc. Se muestran en una variedad de estilos y notaciones y
pueden ser especificados como declaraciones de lenguaje natural, fórmulas
matemáticas, dibujos o todas ellas combinadas. La necesidad de documentación de
los requisitos está relacionada con la complejidad del producto y su impacto.
– Documentación para el usuario
final: Son los manuales para el usuario
final, administradores de sistemas y personal de soporte, y explican cómo
funciona el programa. El manual describe cada función del programa y ayuda al
usuario, al tiempo que puede proporcionar asistencia para solucionar problemas
más complejos. Es muy importante que los documentos de usuario estén al día. A
pesar de que no necesitan estar organizados de una manera determinada, es
importante que tengan un índice exhaustivo. La documentación del usuario se
considera que constituye un contrato que especifica lo que el software hará.
Las tres formas básicas de la documentación de usuario son el tutorial, el
enfoque temático y la lista de referencia.
– Documentación de marketing: Para determinadas tipologías de software es necesario
disponer de diferentes materiales promocionales. La documentación informa de lo
que hace el producto exactamente e impele al posible comprador a su compra.
PRUEBAS DE ACEPTACION:
Estas pruebas las realiza
el cliente. Son básicamente pruebas funcionales, sobre el sistema completo, y
buscan una cobertura de la especificación de requisitos y del manual del usuario. Estas pruebas no se realizan durante
el desarrollo, pues sería impresentable al cliente; sino que se
realizan sobre el producto terminado e integrado o pudiera ser una versión
del producto o una iteración funcionad pactada previamente con el cliente.
La experiencia muestra que aún después del más cuidadoso proceso de pruebas por parte del desarrollador, quedan
una serie de errores que sólo aparecen cuando el cliente comienza a usarlo. Los
desarrolladores suelen llevar las manos a la cabeza y expresan:
"Pero, ¿a quién se le ocurre usar así mi programa?"
Sea como sea, el cliente
siempre tiene razón. Decir que los requisitos no estaban claros, o que el
manual es ambiguo puede salvar la cara; pero ciertamente no deja satisfecho al
cliente. Alegar que el cliente es un inútil es otra tentación muy fuerte, que
conviene reprimir.
Una prueba de aceptación
puede ir desde un informal caso de prueba hasta la ejecución sistemática de una
serie de pruebas bien planificadas. De hecho, las pruebas de aceptación pueden
tener lugar a lo largo de semanas o meses, descubriendo así errores latentes o
escondidos que pueden ir degradando el funcionamiento del sistema. Estas
pruebas son muy importantes, ya que definen el paso nuevas fases del proyecto como el despliegue y mantenimiento.
Se emplean dos técnicas para las pruebas de aceptación:
1. La prueba alfa.
Se lleva a cabo, por un
cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como
observador del usuario. Las pruebas alfa se llevan a cabo en un entorno
controlado. Para que tengan validez, se debe primero crear un ambiente con las mismas condiciones que se encontrarán en
las instalaciones del cliente. Una vez logrado esto, se procede a realizar las
pruebas y a documentar los resultados.
2. La prueba beta.
Se lleva a cabo por los
usuarios finales del software en 1os lugares de trabajo de 1os clientes. A diferencia de la prueba alfa, el desarrollador no está
presente normalmente. Así, la prueba beta es una aplicación "en vivo"
del software en un entorno que no puede ser controlado por el desarrollador. El
cliente registra todos 1os problemas (reales o imaginarios) que encuentra durante la
prueba beta e informa a intervalos regulares a1 desarrollador.
Como resultado de los problemas
informados durante la prueba beta, el desarrollador del software lleva a cabo
modificaciones y así prepara una versión del producto de software para toda
la clase de clientes.
Operación y mantenimiento.
Un
producto software envuelve muchos aspectos y características que provocan que
sea totalmente necesario supervisar su funcionamiento correcto durante un
tiempo después de la entrega del mismo. Ante la dificultad que entraña
garantizar el comportamiento correcto del programa en circunstancias no
previstas, los test de aceptación del producto incluyen pruebas a largo plazo
del software (a petición del cliente). A esta fase de supervisión se le
denomina fase de operación. Sólo cuando termina esta fase el cliente acepta
definitivamente el producto, que había sido aceptado provisionalmente al ser
entregado (fase de transferencia). Más tarde, es posible que el software
necesite ser modificado, ya sea consecuencia de la detección de errores o bien
ante nuevas exigencias y necesidades del usuario del sistema. A esta fase se le
conoce como fase de mantenimiento. Es importante reseñar que durante estas
fases de operación y mantenimiento (OM) se debe generar y actualizar el
denominado documento de historia del proyecto (DHP); documento que incluye
todos los errores (y sus correcciones) y modificaciones realizadas en el
producto. Este documento es de gran ayuda para poder calcular y analizar la
fiabilidad del sistema software a la vez que evaluar el rendimiento del equipo
de trabajo.
Modelos de calidad (MOPROSOFT,
SWCMM, ISO)
Los modelos de calidad son
referencias que las organizaciones utilizan para mejorar su gestión. Los modelos, a diferencia de las normas,
no contienen requisitos que deben cumplir los sistemas de gestión de la calidad sino directrices para la
mejora.
MOPROSOFT: es el
Modelo de Procesos para la Industria del Software de México, que fue encargado
a solicitud de la Secretaría de Economía a la Asociación Mexicana para la
Calidad en Ingeniería del Software (AMCIS) en convenio con la Facultad de
Ciencias de la Universidad Nacional Autónoma de México, con la finalidad de
fomentar la estandarización de su actividades a través de la incorporación de
las mejores prácticas en gestión e ingeniería de software.
Estructura
y procesos de MoProSoft.
Cabe destacar que MoProSoft, es un modelo
para el desarrollo y mantenimiento de software que está enfocado en procesos
considerando la estructura básica de una empresa, considerando tres niveles de
organización: la Alta Dirección, Gerencia y Operación, de tal manera que el
modelo pretende apoyar a las empresas de desarrollo y/o mantenimiento de
software en la estandarización de sus prácticas, en la evaluación de su
efectividad y en la integración de la mejora continua. Las categorías antes
mencionadas contienen los procesos que conforman el MoProSoft de la siguiente
manera y como se muestran en las figuras 1:
a)
Alta Dirección: contiene el proceso de Gestión de Negocio.
b)
Gerencia o Gestión: contiene los procesos de Gestión de Procesos, Gestión de
Proyectos, Gestión de Recursos. Este último proceso contiene tiene a su vez
tres subprocesos que son: Recursos Humanos y Ambiente de Trabajo, Bienes
Servicios e Infraestructura y Conocimiento de la Organización.
c)
Operación: esta categoría contiene los procesos de Administración de Proyectos
Específicos y el de Desarrollo y Mantenimiento de Software.
SWCMM: Modelo de Madurez de la Capacidad
para el desarrollo de Software (Capability Maturity Model for Software,
SW-CMM). Es un modelo de procesos para el desarrollo y mantenimiento de
sistemas de software, diseñado sobre los criterios:
·
La calidad de un producto o sistema
es consecuencia directa de los procesos empleados en su desarrollo.
·
Las organizaciones que desarrollan
software presentan un atributo denominado madurez, cuya medida es proporcional
a los niveles de capacidad e institucionalización de los procesos que emplean
en su trabajo.
Niveles de
madurez definidos en SW-CMM
Nivel 1:
Inicial
Los
resultados de calidad obtenidos son consecuencia de las personas y de las
herramientas que emplean. No de los procesos, porque o no los hay o no se
emplean.
Nivel 2:
Repetible
Se considera un Nivel 2 de madurez cuando
se llevan a cabo prácticas básicas de gestión de proyectos, de gestión de
requisitos, control de versiones y de los trabajos realizados por subcontratistas.
Los equipos de los proyectos pueden aprovechar las prácticas realizadas para
aplicarlas en nuevos proyectos.
Nivel 3:
Definido
Los procesos comunes para desarrollo y
mantenimiento del software están documentados de manera suficiente en una
biblioteca accesible a los equipos de desarrollo. Las personas han recibido la
formación necesaria para comprender los procesos. Para cada proyecto en
particular, se adaptan los procesos estándar según las necesidades del caso, es
consistente la base de procesos.
Nivel 4:
Gestionado
La organización mide la calidad del
producto y del proceso de forma cuantitativa con base a métricas establecidas
La capacidad de los procesos empleados es
previsible, y el sistema de medición permite detectar si las variaciones de
capacidad exceden los rangos aceptables para adoptar medidas correctivas.
Nivel 5:
Optimizado
La mejora continua de los procesos afecta
a toda la organización, que cuenta con medios para identificar las debilidades
y reforzar la prevención de defectos. Se analizan de forma sistemática datos
relativos a la eficacia de los procesos de software para analizar el coste y el
beneficio de las adaptaciones y las mejoras.
Se analizan los defectos de los proyectos
para determinar las causas, y su mapeado sobre los procesos. Es el nivel más
alto de CMM por el momento.
ISO:
Modelo de
calidad ISO 9000
Este modelo de calidad fue desarrollado
por el Comité Técnico ISO/TC 176 de la ISO (Organización Internacional de
Normalización) y documentado en la familia de normas ISO 9000, como respuesta a
la necesidad de las organizaciones
de mejorar la calidad de sus productos y servicios y así cumplir
con las expectativas de sus clientes.
Esta familia se compone de una serie de
normas que permiten establecer
requisitos y/o directrices relativos a un Sistema de Gestión de la Calidad.
Destacan las siguientes:
- ISO 9000: Sistemas de Gestión de la Calidad.
Fundamentos y Vocabulario
- ISO 9001: Sistemas de Gestión de la Calidad.
Requisitos
- ISO 9004: Gestión de la Calidad. Calidad de una
Organización. Orientación para lograr el éxito sostenido
Dentro de esta familia, la norma
mayormente utilizada es la ISO 9001, puede ser utilizada por cualquier organización, grande o pequeña,
independientemente de su campo de actividad y establece los
criterios para un sistema de gestión de calidad y es el único estándar en la
familia que puede certificarse a través de entidades externa acreditada, no
obstante, todas están basadas en 7 principios básicos de calidad.
Modelo de
excelencia EFQM
EFQM representa
las siglas en inglés de European Foundation Quality Management, traducida al
español como Fundación Europea
para la Gestión de la Calidad, es una organización sin ánimo de lucro,
que el utiliza el conocimiento basado en datos, el aprendizaje y entendimiento
y las oportunidades de networking para aumentar la competitividad de
organizaciones e individuos de todo el mundo,
Se estableció en 1989, con el
propósito de dar una respuesta al trabajo de W. Edwards Deming y el
estandarizar de los conceptos de gestión de la calidad total, en efecto el
Modelo EFQM, propone una gestión integrada de la estratégica con el
funcionamiento operativo orientado a resultados.
El Modelo de Excelencia, es un marco de
referencia, no normativo,
cuyo concepto fundamental es realizar diagnósticos del nivel de excelencia de la gestión de las
organizaciones, inicialmente mediante la aplicación de nueve criterios. Cinco
(5) de ellos considerados “Agentes
Facilitadores” o “Impulsores
del Cambio” y cuatro (4) son “Resultados”, donde:
- Los criterios que hacían referencia
a un Agente Facilitador tratan
sobre lo que la organización
hace.
- Los criterios que hacían referencia
a los Resultados tratan
sobre lo que la organización
logra.
- Los criterios que hacían referencia
a los Resultados son
consecuencia de los Agentes
Facilitadores.
Históricamente, el Modelo EFQM ha
constituido una referencia para que las organizaciones desarrollen una cultura de mejora e innovación. En
su última versión (2020) se ha reinventado para ayudar a las
organizaciones a afrontar el cambio, a impulsar el rendimiento y a prepararse
para el futuro, de una manera más simple de comprender.
Actualmente
la estructura del Modelo EFQM se basa en una lógica sencilla pero muy poderosa,
que responde a tres ejes principales:
- Dirección: ¿»Por qué» existe la organización?
¿»Qué» propósito cumple? ¿»Por qué» esta estrategia concreta?
- Ejecución: ¿»Cómo» tiene la intención de
cumplir con su propósito y estrategia?
- Resultados: ¿»Qué» ha logrado hasta ahora?
¿»Qué» quiere lograr en el futuro?
Las organizaciones que adopten el Modelo
EFQM y alcancen un nivel sostenible excepcional de excelencia, pueden obtener
un Premio de Excelencia EFQM,
otorgado por la EFQM cuando la organización culmina de manera efectiva el
proceso de evaluación de EFQM.
Fundamentos
del Modelo EFQM
El Modelo EFQM consta de 7 criterios
alineados con un eje estratégico, los tres ejes de la estructura del modelo,
son la base de la conexión entre el propósito y la estrategia de una
organización y a su vez orienta las acciones de la creación de valor sostenible
para sus grupos de interés clave y la generación de resultados sobresalientes.
Software quality factors.
Software quality factors serve to
break down the generic concept of “quality” into simpler ones, to facilitate
its control and measurement.
Since factoring is subjective, there are several classifications of
quality factors. We will see McCall's, who groups them into three perspectives:
operational, maintenance and evolutionary.
Software quality operational
factors.
Operational factors are those that
affect the use of the software:
• Correction: software meets
specifications
• Reliability: degree to which the
software is reliable, that is, it has no bugs
• Efficiency: need for software and hardware resources of the
product
•
Security: degree to which access to software and data can be controlled
• Ease of use: degree of effort
required to use the software
Software quality maintenance
factors.
Maintenance factors are those that apply to the modifiability of the
software:
• Flexibility: effort required to
modify a program
• Ease of testing: effort required
to test a program
• Ease of maintenance: effort
required to locate and repair an error
Evolutionary factors
Evolutionary factors are those that indicate whether the software can be
easily transferred to another machine or to another base product (OS, DBMS,
etc.), or to increase its performance:
• Portability: ease of migrating
software from one operating environment to another
• Reusability: degree to which a
program or part of it can be used in other applications.
• Interoperation capacity: effort
required for software to operate jointly with other systems.
2.
EVALUATION OF PRODUCT QUALITY: DOCUMENTATION, ACCEPTANCE TESTS, OPERATION AND
MAINTENANCE.
DOCUMENTATION:
Quality
manual. It is the main document to establish and implement a quality system.
There may be manuals at the company, department, product, specific level
(purchases, projects).
Building
software and completing software building projects involve creating and
managing associated documentation. Each step in the creation and production of
software supposes the generation of documentation that has to be contemplated
and managed. Proper management of this documentation allows projects to be
controlled, facilitates use by the user and reduces costs. The concept of
software documentation comprises different types of documentation and involves
different roles:
- Architecture
/ Design Documentation: Defines the practices, techniques, and types of
representations used by software architects to record a software architecture.
One of the branches of the software design phase involves the creation of a
white paper on specific aspects of the system, such as the design interface,
the code, the design document, the design elements, etc., and is useful for the
designers, developers, administrators, etc. of the databases or applications.
–Technical
documentation:
It accompanies the software and describes various aspects of its operation.
Document the code, algorithms, interfaces, and APIs. The technical
documentation can be used by developers, testers and also by end customers or
clients. Various tools, such as Doxygen, Ndoc, RoboDoc, etc., allow you to
automatically generate documentation from source code and create reference
manuals in forms such as text or HTML files.
-
Software requirements: Requirements are the description of what a software
will or will not do and are statements that identify attributes, capabilities,
characteristics or qualities of a system. The requirements affect all agents
involved in production: users, customers, managers, sales, marketing, software
architects, usability engineers, interaction designers, developers, etc. They
are displayed in a variety of styles and notations and can be specified as
natural language statements, mathematical formulas, drawings, or all of them in
combination. The need for documentation of the requirements is related to the
complexity of the product and its impact.
-
Documentation for the end user: These are the manuals for the end user, system
administrators and support personnel, and they explain how the program works.
The manual describes each function of the program and helps the user, while it
can provide assistance in solving more complex problems. It is very important
that user documents are up to date. Although they do not need to be organized
in a certain way, it is important that they have a comprehensive index. User
documentation is considered to be a contract specifying what the software will
do. The three basic forms of user documentation are the tutorial, the topic
focus, and the reference list.
-
Marketing documentation: For certain types of software it is necessary to have
different promotional materials. The documentation informs of what the product
does exactly and encourages the prospective buyer to purchase.
ACCEPTANCE
TESTS:
These
tests are performed by the customer. They are basically functional tests, on
the complete system, and seek coverage of the requirements specification and
the user manual. These tests are not carried out during development, as it
would be unpresentable to the customer; rather, they are carried out on the
finished and integrated product or it could be a version of the product or a
functional iteration previously agreed with the client.
Experience
shows that even after the most careful testing process by the developer, a
series of errors remain that only appear when the customer starts using it.
Developers usually put their hands to their heads and express:
"But who would use my program
like this?"
Either
way, the customer is always right. Saying that the requirements were unclear,
or that the manual is ambiguous can save face; but it certainly does not
satisfy the customer. Claiming that the client is useless is another very
strong temptation, which should be repressed.
An
acceptance test can range from an informal test case to the systematic
execution of a well-planned series of tests. In fact, acceptance tests can take
place over weeks or months, thus uncovering latent or hidden errors that can
gradually degrade the performance of the system. These tests are very
important, as they define the passage of new phases of the project such as
deployment and maintenance.
Two techniques are used for
acceptance testing:
1. The
alpha test.
It is carried out, by a client, at
the development site. The software is used naturally with the developer as an
observer of the user. Alpha testing takes place in a controlled environment. To
be valid, you must first create an environment with the same conditions that
will be found in the client's facilities. Once this is achieved, the tests are
carried out and the results are documented.
2. The
beta test.
It is carried out by the end users
of the software in the workplaces of the clients. Unlike alpha testing, the
developer is not normally present. Thus, beta testing is a "live"
application of the software in an environment that cannot be controlled by the
developer. The client records all problems (real or imagined) that it
encounters during beta testing and reports back to the developer at regular
intervals.
As a result of the problems
reported during the beta test, the software developer makes modifications and
thus prepares a version of the software product for all class of customers.
Operation
and maintenance.
A
software product involves many aspects and characteristics that make it
absolutely necessary to supervise its correct operation for a time after it has
been delivered. Given the difficulty of ensuring the correct behavior of the
program in unforeseen circumstances, the product acceptance tests include
long-term tests of the software (at the customer's request). This supervision
phase is called the operation phase. Only when this phase ends does the
customer definitively accept the product, which had been provisionally accepted
upon delivery (transfer phase). Later, it is possible that the software needs
to be modified, either as a result of the detection of errors or due to new
demands and needs of the system user. This phase is known as the maintenance
phase. It is important to note that during these phases of operation and
maintenance (OM) the so-called project history document (DHP) must be generated
and updated; document that includes all errors (and their corrections) and
modifications made to the product. This document is of great help to be able to
calculate and analyze the reliability of the software system while evaluating
the performance of the work team.
3.
Quality models (MOPROSOFT, SWCMM, ISO)
Quality
models are references that organizations use to improve their management. The
models, unlike the standards, do not contain requirements that must be met by
quality management systems, but rather guidelines for improvement.
MOPROSOFT: is the Process Model
for the Software Industry of Mexico, which was commissioned at the request of
the Ministry of Economy to the Mexican Association for Quality in Software
Engineering (AMCIS) in agreement with the Faculty of Sciences of the National
University Autónoma de México, in order to promote the standardization of its
activities through the incorporation of best practices in software management
and engineering.
Structure and processes of
MoProSoft.
It should be noted that MoProSoft is a model for the development and
maintenance of software that is focused on processes considering the basic
structure of a company, considering three levels of organization: Senior
Management, Management and Operation, in such a way that the model intends to
support to software development and / or maintenance companies in the
standardization of their practices, in the evaluation of their effectiveness
and in the integration of continuous improvement. The aforementioned categories
contain the processes that make up MoProSoft as follows and as shown in figures
1:
a) Senior Management: contains the
Business Management process.
b) Management or Management:
contains the processes of Process Management, Project Management, Resource
Management. This last process contains, in turn, three sub-processes which are:
Human Resources and Work Environment, Goods, Services and Infrastructure and
Knowledge of the Organization.
c) Operation: this category
contains the Administration of Specific Projects and the Software Development
and Maintenance processes.
SWCMM: 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.
Maturity levels defined in SW-CMM
Level 1: Initial
The quality results obtained are a
consequence of the people and the tools they use. Not of the processes, because
either there are none or they are not used.
Level 2: Repeatable
A Level 2 maturity is considered when basic practices of project
management, requirements management, version control and work performed by
subcontractors are carried out. Project teams can take advantage of completed
practices to apply them to new projects.
Level 3: Defined
Common processes for software development and maintenance are
sufficiently documented in a library accessible to development teams. People
have received the necessary training to understand the processes. For each
project in particular, the standard processes are adapted according to the
needs of the case, the process base is consistent.
Level 4: Managed
The organization measures product and process quality quantitatively
based on established metrics
The capacity of the processes used is foreseeable, and the measurement
system allows detecting if the variations in capacity exceed the acceptable
ranges to adopt corrective measures.
Level 5: Optimized
Continuous process improvement affects the entire organization, which
has the means to identify weaknesses and reinforce defect prevention. Data
regarding the effectiveness of software processes is systematically analyzed to
analyze the cost and benefit of adaptations and improvements.
The defects of the projects are analyzed to determine the causes, and
their mapping on the processes. It is the highest level of CMM at the moment.
ISO:
ISO 9000 quality model
This quality model was developed by the ISO Technical Committee ISO / TC
176 (International Organization for Standardization) and documented in the ISO
9000 family of standards, in response to the need for organizations to improve
the quality of their products and services. and thus meet the expectations of
its customers.
This family is made up of a series of
standards that allow establishing requirements and / or guidelines related to a
Quality Management System. The following stand out:
• ISO 9000: Quality Management
Systems. Fundamentals and Vocabulary
• ISO 9001: Quality Management
Systems. Requirements
• ISO 9004: Quality Management.
Quality of an Organization. Guidance for sustained success
Within this family, the most widely used standard is ISO 9001, it can be
used by any organization, large or small, regardless of its field of activity
and establishes the criteria for a quality management system and is the only
standard in the family. that can be certified through accredited external
entities, however, all are based on 7 basic principles of quality.
EFQM Excellence Model
EFQM stands for European
Foundation Quality Management, translated into Spanish as European Foundation
for Quality Management, is a non-profit organization, which uses data-based knowledge,
learning and understanding and opportunities for networking to increase the
competitiveness of organizations and individuals around the world,
It was established in 1989, with the purpose of responding to the work
of W. Edwards Deming and standardizing the concepts of total quality
management, in effect the EFQM Model, proposes an integrated management of the
strategic with the operational oriented operation to results.
The Excellence Model is a non-normative
frame of reference, whose fundamental concept is to carry out diagnoses of the
level of excellence in the management of organizations, initially by applying
nine criteria. Five (5) of them are considered “Facilitating Agents” or
“Drivers of Change” and four (4) are “Results”, where:
• The criteria that referred to a
Facilitating Agent deal with what the organization does.
• The criteria that referred to the
Results deal with what the organization achieves.
• The criteria that referred to the
Results are a consequence of the Facilitating Agents.
Historically, the EFQM Model has been a reference for organizations to
develop a culture of improvement and innovation. In its latest version (2020)
it has been reinvented to help organizations cope with change, drive
performance and prepare for the future, in a way that is simpler to understand.
Currently the structure of the EFQM
Model is based on a simple but very powerful logic, which responds to three
main axes:
• Address: »Why» does the
organization exist? »What» purpose does it serve? »Why» this specific strategy?
• Execution: »How» do you intend to
fulfill your purpose and strategy?
• Results: »What» have you achieved
so far? »What» do you want to achieve in the future?
Organizations that adopt the EFQM Model and achieve an exceptionally sustainable
level of excellence can earn an EFQM Award of Excellence, awarded by EFQM when
the organization effectively completes the EFQM assessment process.
Fundamentals of the EFQM Model
The EFQM Model consists of 7 criteria aligned with a strategic axis, the
three axes of the model's structure, are the basis of the connection between
the purpose and the strategy of an organization and at the same time orient the
actions of the creation of sustainable value for its key stakeholders and the
generation of outstanding results.
No hay comentarios:
Publicar un comentario