CONCLUSIONES

Conclusiones

La creciente preocupación por la calidad en la industria del software tiene como objetivo principal el desarrollo sistemático de productos y servicios de mejor calidad y el cumplimiento de las necesidades y expectativas de los clientes. En el presente artículo se hace una introducción a la calidad y al modelo de calidad adoptado por Colciencias, CMMI. Pretendemos unir esfuerzos con esta iniciativa y motivar a la comunidad académica a trabajar en calidad con las empresas desarrolladoras de software para mejorar la competitividad y la calidad global de esta industria.

Resumiendo, podemos decir, que la calidad de software se refiere a: Los factores de un producto de software que contribuyen a la satisfacción completa y total de las necesidades de un usuario u organización, cuando el interés en mejorar la calidad es el producto de software, se identifican un conjunto de atributos de software relevantes y se elabora un modelo de medición que establezca las relaciones entre las propiedades internas del producto de software y las propiedades externas. Las propiedades internas del software se evalúan en los distintos artefactos del software que, por su naturaleza, no pueden ser ejecutados (el código fuente también puede ser analizado estáticamente). Por ejemplo, el modelo de arquitectura del software se puede evaluar según los requisitos de calidad establecidos. El código fuente se puede evaluar según su facilidad para ser modificado, sin que sea necesaria su ejecución.

Entonces podemos concluir que la calidad del software nos ayuda a estar seguros a nosotros como clientes de que adquirimos un producto o servicio que cumple con los estándares de la calidad más alta y que estamos de cierta manera protegidos ante cualquier fallo o desperfecto.

PRESENTACIÓN

UNIVERSIDAD MEXIQUENSE DEL BICENTENARIO

 

Barona Araujo Jeovanny (@bvronv.vj)

Zuñiga Sánchez Alejandro Víctor (@viczuni)

Profra. Mabilia Romero Guevara

Calidad del Software

Grupo: 15LI161

Matutino

Trabajo Final

4.9. Funciones de Evaluación del Software

Las técnicas de evaluación estática se aplican en el mismo orden en que se van generando los distintos productos del desarrollo siguiendo una filosofía top-down. Esto es, la evaluación estática acompaña a las actividades de desarrollo, a diferencia de la evaluación dinámica que únicamente puede dar comienzo cuando finaliza la actividad de codificación, siguiendo así una estrategia botomup.

La evaluación estática es el único modo disponible de evaluación de artefactos para las primeras fases del proceso de desarrollo (análisis y diseño), cuando no existe código.

Así pues, la importancia de las técnicas estáticas de evaluación a la hora de controlar el nivel de calidad con el que se está llevando a cabo el desarrollo es crucial.
, la estimación de faltas que aún quedan en un producto utilizando datos de las revisiones permite dos acciones que ayudan a prevenir futuros defectos en el proyecto:
. Seguir revisando el producto para disminuir el número de faltas remanentes.
. Tomar medidas correctivas del desarrollo si las estimaciones indican que se está llevando a cabo un trabajo pobre. Es decir, si las estimaciones de faltas.

4.8. Análisis de Proceso de Ciclo Vida del Software

Etapas en el ciclo.
Veamos, a grandes rasgos, una pequeña descripción de etapas con que podemos contar a lo largo del ciclo de vida del software.
Expresión de necesidades

Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar). Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial).

Especificaciones

Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.
Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).
del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados).

Análisis

Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, … que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
• Funcional.
• Estático.
• Dinámico.

Diseño
Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).
Implementación
Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.
Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).
Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos
Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).

4.7. Análisis de Factores que Determinan la Calidad Software

Los factores que determinan la calidad se pueden clasificar en 2 grandes grupos:
1- Factores que se pueden medir directamente (Ej. errores / unidad de tiempo)
2- Factores que sólo pueden ser medidos indirectamente (Ej. facilidad de mantenimiento)
En ambos casos, se puede obtener una medida. Pero estas medidas deben ser comparadas con alguna referencia o indicador para poder llegar a una indicación de la realidad
Mc Call clasifica los factores de calidad en:
1- Características Operacionales
2- Capacidad de Soportar Cambios
3- Adaptabilidad a nuevos entornos

1- Características Operacionales
• Corrección
Es el grado en que un programa satisface sus especificaciones y consigue los objetivos pedidos por el cliente. Este factor tiene una pregunta asociada: ¿Hace lo que quiero?
• Confiabilidad
Es el grado en que se puede esperar que un programa lleve a cabo sus funciones esperadas con la precisión requerida. La pregunta asociada a este factor sería: ¿Lo hace de forma fiable todo el tiempo?
• Eficiencia
La cantidad de recursos de computadoras y de código requeridos por un programa para llevar a cabo sus funciones. La pregunta asociada a este factor sería: ¿Se ejecutará en mi hardware lo mejor que pueda?

2- Capacidad de Soportar Cambios
• Facilidad de Mantenimiento
• Es el esfuerzo requerido para localizar y arreglar un error en un programa. La pregunta asociada a este factor sería: ¿Puedo corregirlo?
• Flexibilidad
Es el esfuerzo requerido para modificar un programa operativo. La pregunta asociada a este factor sería: ¿Puedo cambiarlo?
• Facilidad de Prueba
• Es el esfuerzo requerido para probar un programa de forma que se asegure que realiza su función requerida. La pregunta asociada a este factor sería: ¿Puedo probarlo?
3- Adaptabilidad de nuevos entornos
• Portabilidad
Es el esfuerzo requerido para transferir el programa desde un hardware y/o un entorno de sistema de software a otro. Este factor tiene una pregunta asociada: ¿Podré usarlo en otra máquina?
• Reusabilidad
Es el grado en que un programa (o partes de este) se pueden rehusar en otras aplicaciones. Este factor tiene una pregunta asociada: ¿Podré rehusar alguna parte del software?
• Facilidad de Interoperación
• Es el esfuerzo requerido para acoplar un sistema a otro. Este factor tiene una pregunta asociada: ¿Podré hacerlo interactuar con otro sistema?
2- Métricas de Calidad
Es difícil desarrollar medidas directas de los anteriores factores de calidad. Por eso, se definen un conjunto de métricas para cada uno de los factores de calidad. Generalmente estas métricas definidas por MacCall solo pueden ser medidas en forma subjetiva.
Las métricas pueden estar listas de comprobaciones para obtener el grado de los atributos específicos del software. El esquema de graduación propuesto por McCall va en una escala de 0 (bajo) a 10 (alto).
En este esquema se usan las siguientes métricas:
• Facilidad de Auditoria
• La facilidad con que se puede comprobar la conformidad con los estándares
• Exactitud
La precisión de los cálculos y el control
• Normalización de las Comunicaciones
• El grado en que se usan el ancho de banda, los protocolos y las interfaces estándar
• Completitud
El grado en que se ha conseguido la total implementación de las funciones requeridas
• Concisión
Lo compacto que es el programa en términos de líneas de código
• Consistencia
El uso de un diseño uniforme de técnicas de documentación a los largo del proyecto de desarrollo de software
• Estandarización en los datos
• El uso de estructuras de datos de tipos estándar a lo largo de todo el programa
• Tolerancia de Errores
• El daño que se produce cuando el programa encuentra un error
• Eficiencia en la Ejecución
• El rendimiento en tiempo de ejecución de un programa
• Facilidad de expansión
• El grado en que se puede ampliar el diseño arquitectónico de datos o procedural
• Generalidad
La amplitud de aplicación potencial de los componentes del programa
• Independencia del Hardware
• El grado en que el software es independiente del hardware en que opera
• Instrumentación
El grado en que el programa muestra su propio funcionamiento e identifica errores que aparecen
• Modularidad
La independencia funcional de los componentes del programa
• Facilidad de Operación
• La facilidad de operación de un programa
• Seguridad
La disponibilidad de mecanismos que controlen o protejan los programas o datos
• Auto-Documentación
El grado en que el código fuente proporciona documentación significativa

4.6. La Norma ISO/IEC 9126

ISO/IEC 9126-1: Tecnología de dotación lógica – calidad del producto
ISO/IEC 9126 (1991) ha sido substituido recientemente por un nuevo estándar de cuatro partes que ha reconciliado los dos acercamientos a la utilidad. ISO/IEC 9126-1 describe las mismas seis categorías de la calidad del software que son relevantes durante el desarrollo de producto: funcionalidad, confiabilidad, utilidad, eficacia, capacidad de mantenimiento y portabilidad.

calidad del software cuando el producto es funcionando. El objetivo total es alcanzar la calidad funcionando, para el usuario final y el usuario de la ayuda.
La funcionalidad, la confiabilidad, la eficacia y la utilidad determinan la calidad funcionando para un usuario final en un contexto particular. El usuario de la ayuda se refiere a la calidad funcionando de tareas del mantenimiento y de la portabilidad.

4.5. Nomenclatura y Certificación Iso 9001 2000

La norma ISO 9001, es un método de trabajo, que se considera tan bueno, Que es el mejor para mejorar la calidad y satisfacción del consumidor.

La versión actual, es del año 2000 ISO 9001:2000, que ha sido adoptada como modelo a seguir para obtener la certificación de calidad por todas las empresas.
Estos principios básicos de la gestión de la calidad, son reglas de carácter social encaminadas a mejorar la marcha y funcionamiento de una organización mediante la mejora de sus relaciones internas.
La certificación en la norma 9001, es un documento con validad legal que acredita y que certifica, que usted cumple las más estrictas normas de calidad, en aras a una mejora de la satisfacción del cliente.
Hay dos tipos de certificaciones, de empresa y de producto. Estas últimas, solo tienen en cuenta la calidad técnica del producto. Y no la satisfacción del cliente, de la que se ocuparía la certificación de empresa. Si una empresa está certificada, todos sus productos lo están.

4.4. Costo de la Calidad del Software

El Costo de la Calidad del Software CoQ, es una técnica introducida por Juran en 1996 con el fin de proporcionar a los directores de proyectos instrumentos que les permitan justificar la promoción de mejoras en el proceso de desarrollo.

• Costos de Prevención: planificación de la calidad, revisiones técnicas formales, equipo de pruebas, formación.
• Costos de Evaluación: inspección de cada proceso y entre procesos, pruebas.
• Costos de Fallos Internos: antes de la entrega. (Reparación, revisión, análisis)
• Costos de Fallos Externos: después de la entrega. (Resolución, soporte, reemplazo)

4.3. Como Controlar la Calidad del Software

Definir los parámetros, indicadores o criterios de medición. Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos:
Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.

Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo.

Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.

4.2. Cómo Obtener Calidad de Software (métodos, metodologías, estándares)

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares
para el análisis, diseño, programación y prueba del software
que permitan uniformar la filosofía de trabajo,
en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.
 El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.
 El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.
 El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado. La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

4.1. ¿Que es la Calidad del Software? .

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La calidad del software es medible y varía de un sistema a otro o de un programa a otro.
Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software.

4. Calidad Enfocada al Desarrollo de Software

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

Características operativas

Corrección. ¿Hace lo que quiero?

Fiabilidad. ¿Lo hace de forma fiable todo el tiempo?

Eficiencia. ¿Se ejecutará en mi hardware lo mejor que pueda?

Seguridad (Integridad). ¿Es seguro?

Facilidad de uso. ¿Está diseñado para ser usado?

Capacidad de soportar los cambios

Facilidad de mantenimiento. ¿Puedo corregirlo?

Flexibilidad. ¿Puedo cambiarlo?

Facilidad de prueba. ¿Puedo probarlo?

Adaptabilidad a nuevos entornos

Portabilidad. ¿Podré usarlo en otra máquina?

Reusabilidad. ¿Podré reutilizar alguna parte del software?

Interoperabilidad. ¿Podré hacerlo interactuar con otro sistema?

3.3.6. Nivel Optimizado

La característica principal aquí es que la organización entera lleva a cabo mejoras continuas en el proceso, en base a la retroalimentación cuantitativa y al ensayo de ideas y tecnologías innovadoras. Todos los cambios realizados en cualquier parte del proceso son vigilados y controlados con el sistema de métricas. Durante todo el desarrollo no suelen suceder errores.

La organización cuenta con los medios para identificar las debilidades y reforzar el proceso con el objeto de prevenir defectos. Los datos relativos a la eficiencia del proceso de software se usan para analizar el costo y el beneficio de usar nuevas tecnologías y de implementar cambios al proceso de software.

Los proyectos de software analizan los defectos para determinar sus causas. Los procesos de software se evalúan para prevenir que los defectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidas son difundidas a otros proyectos. Es importante llevar a cabo retroalimentación en esta fase. De ella depende el control efectivo del proceso. Ésta debe de estar dirigida hacia un objetivo para no caer en la retroalimentación de errores desde un principio y seguir alimentando en forma incorrecta el proceso.

3.3.5. Nivel Administrativo

El cambio del nivel definido al administrado es muy difícil ya que no está bien explicado  en la estructura de CMM. En este nivel la organización mide la calidad del producto y del proceso de software. Ambas partes son seguidas en forma cuantitativa y se controlan mediante métricas detalladas. La capacidad de rendimiento del proceso es previsible.

Como su nombre lo dice, la administración de proyectos juega un papel esencial. En éste nivel el proyecto se entiende como un conjunto de procesos y la administración de los mismos y sus cambios. Todos los procedimientos y métricas necesarios en los niveles

anteriores se integran en éste nivel. El administrador del proyecto debe de dirigir todos los procesos paralelos y desarrollos hacia una meta definida. Debe de encargarse de procesos preventivos para corregir posibles errores antes de que se vuelvan incontrolables.

Los procesos de software son muy predecibles. Cuando sucede algo no contemplado es fácilmente corregible debido al control del proceso. La empresa es capaz de proponerse metas cuantitativas para la calidad de los productos y de los procesos de software. Es posible medir la productividad y calidad de los procesos de software a través de todo el proyecto. Las mediciones permiten detectar cuando las variaciones del rendimiento se salen de los rangos aceptables, de manera que se puedan tomar medidas correctivas para asegurar la calidad.

3.3.4. Nivel Definido

En éste nivel la empresa ha definido un conjunto de procesos, metodologías y herramientas usados por todos los niveles involucrados en el proceso, tanto administrativos como desarrolladores. Existen pautas y criterios definidos para adaptar un proceso estándar a las

necesidades y características propias de cada proyecto. El nivel de definición es detallado y completo. En el proceso ya no existe dependencia de esfuerzos individuales, pues todos conocen el proceso.

El nivel 3 mantiene la misma línea que el nivel 2 pero lo expande a todo el proceso, hay un leguaje común dentro de la organización. La administración del proyecto especifica en todo proceso que tareas realizar, quién las debe de realizar, el proceso y el tiempo necesario. La organización hace uso de las prácticas exitosas al estandarizar procesos de desarrollo.

También se recomienda contar con un grupo de personas dentro del equipo dedicadas al proceso de ingeniería de software. Ellos deben de encargarse de llevar a cabo actividades como la evaluación de líderes o revisiones de código con el fin de buscar mejoras en el proceso y saber como se desarrolla éste dentro de la organización.

3.3.3. Nivel Repetido

En el nivel repetible se establecen prácticas básicas de administración de proyecto que permiten establecer control de requerimientos, calendarizaciones y costos. El equipo que desarrolló el proyecto puede aprovechar su experiencia e inversión en procesos para aplicarla en un nuevo proyecto.

Los proyectos repetibles llevan a cabo procesos definidos, medidos, entrenados y probados. Este nivel no garantiza que todos los proyectos dentro de la empresa tienen el mismo nivel de madurez. Algunos pueden estar todavía en el nivel inicial.

Es importante en éste nivel contar con procesos formales de documentación. Éste proceso debe ser comunicado a todos los niveles involucrados en el proyecto y continuamente mejorados por lo que debe de existir mucha precisión en la documentación de todos los procesos. Los análisis de proyectos anteriores proporcionan información importante acerca de todos los niveles de desarrollo. Ésta información permite hacer compromisos inteligentes en cuanto a tiempos o costos se refiere.

En este nivel los líderes de proyecto toman más importancia que en el nivel anterior. Dejan de encargarse de situaciones técnicas para dedicarse a administrar el proceso. Ya pueden hacer un compromiso y seguir planes realistas basados en los resultados de proyectos similares. Son responsables de la estimación y cambios en términos de calidad, costo y tiempo. Deben de identificar los problemas que surjan durante el proyecto en el momento y darles solución o tomarlos en cuenta para futuros procesos.

A partir de éste nivel es importante llevar una implementación controlada de métricas y medidas de software ya que si no se hace así desde los primeros niveles, en los próximos será muy tardado llevar acabo una transición.

3.3.2. Nivel Inicial

Éste nivel es el primer estado en la evolución de las organizaciones que desarrollan software. En éste nivel se encuentran todas las empresas que no han logrado implementar las prácticas básicas de administración de proyectos e ingeniería de software definidas a partir del nivel 2 o superiores.

En éste nivel suele ser frecuente el encontrar crisis dentro de la compañía. Esto se puede deber a diversos factores como comprometerse de más sobre los tiempos y alcances del producto, falta de comunicación en el equipo de desarrollo, etc. Cuando se presentan éstas crisis, generalmente el equipo deja de lado los procesos iniciales como el análisis y el diseño para dedicarse únicamente a codificar y si da tiempo realizar todas las pruebas necesarias.

En estas empresas, el software es producto del esfuerzo de artistas individuales como líderes de proyecto excepcionales o un efectivo equipo de desarrollo. Cada héroe crea su

proceso con un estilo propio y suele ser necesario que la misma persona este involucrada en el siguiente proyecto para que pueda ser repetido. Muchas veces los equipos realizan proyectos que cumplen los requerimientos necesarios sin entender claramente como lo lograron y otras lo logran pero exceden por mucho el presupuesto inicial o la calendarización.

La administración participa en gran manera del proceso en éste nivel, aunque generalmente en una forma ineficiente. Ellos ocupan una parte significativa de su tiempo en arreglar problemas y hablar con los clientes insatisfechos. Ante una situación de crisis permanente, se les hace difícil destinar recursos para definir o documentar procesos, lo que lleva a un ciclo infinito. Normalmente no existe buena relación entre administrativos y desarrolladores debido a que hay muchos roces debido a la presión de la entrega o de los errores existentes.

3.3.1. Definición de Modelo

Un Modelo muestra características únicas que resaltan una idea, esta idea puede ser o no seguida por quienes la perciben. Un modelo representa el ingenio y la obra de una persona o de la naturaleza por sí mismo, creando una gama de características que son imitadas por los demás. Los modelos económicos son unos de los más comunes en cuanto a imitación. Un estado desarrolla por sí solo un esquema financiero en el que erario público es la clave central, las ganancias de los negocios y la renta colabora con el progreso y a muchos otros países les agrada la idea, por lo que adoptan el mismo proceso y de esta manera contribuyen con una buena negociación y acuerdos bilaterales que favorezcan ambas economías.

3.3. CMM

A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América, desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993. 

Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser: 

• Definidas en un procedimiento documentado 
• Provistas (la organización) de los medios y formación necesarios 
• Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas) 
• Medidas 
• Verificadas 

A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez. 

Los niveles son: 

• Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible. 
• Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente. 
• Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews). 
• Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad. 
• Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación. 

Así es como el modelo CMM establece una medida del progreso, conforme al avance en niveles de madurez. Cada nivel a su vez cuenta con un número de áreas de proceso que deben lograrse. El alcanzar estas áreas o estadios se detecta mediante la satisfacción o insatisfacción de varias metas claras y cuantificables. Con la excepción del primer nivel, cada uno de los restantes Niveles de Madurez está compuesto por un cierto número de Áreas Claves de Proceso, conocidas a través de la documentación del CMM por su sigla inglesa: KPA. 

Cada KPA identifica un conjunto de actividades y prácticas interrelacionadas, las cuales cuando son realizadas en forma colectiva permiten alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: 

• Gestión
• Organizacional 
• Ingeniería. 

Las prácticas que deben ser realizadas por cada Area Clave de Proceso están organizadas en 5 Características Comunes, las cuales constituyen propiedades que indican si la implementación y la institucionalización de un proceso clave es efectivo, repetible y duradero. 

Estas 5 características son: 

• Compromiso de la realización
• La capacidad de realización
• Las actividades realizadas
• Las mediciones y el análisis
• La verificación de la implementación. 

Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una guía útil para orientar sus esfuerzos. Además, el SEI proporciona formación a evaluadores certificados (Lead Assesors) capacitados para evaluar y certificar el nivel CMM en el que se encuentra una organización. Esta certificación es requerida por el Departamento de Defensa de los Estados Unidos, pero también es utilizada por multitud de organizaciones de todo el mundo para valorar a sus subcontratistas de software. 

Se considera típico que una organización dedique unos 18 meses para progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso intenso de la dirección. 

Como consecuencia, muchas organizaciones que realizan funciones de factoría de software o, en general, outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de los países en el que más organizaciones certificadas exista sea India, donde han florecido las factorías de software que trabajan para clientes estadounidenses y europeos. 

A partir de 2001, en que se presentó el modelo CMMI, el SEI ha dejado de desarrollar el SW-CMM, cesando la formación de los evaluadores en diciembre de 2003, quienes dispondrán hasta fin de 2005 para reciclarse al CMMI. Las organizaciones que sigan el modelo SW-CMM podrán continuar haciéndolo, pero ya no podrán ser certificadas a partir de fin de 2005. 

3.2. SPICE

SPICE realiza los siguiente tipos de análisis:

• DC - Función de transferencia.
• AC - Respuesta en frecuencia de circuito.
• Transitorio - Evolución del circuito en el tiempo.

Dependiendo del software utilizado y versión del mismo, se encuentran implementados análisis avanzados, que pueden ir desde un sencillo cálculo de respuesta en frecuencia, hasta la simulación de diseños de radio frecuencia y análisis térmico, entre ellos:

• Punto operativo CD
• Análisis de CA
• Análisis de CA de Frecuencia Única
• Análisis de Transitorio
• Análisis de Fourier
• Análisis de Ruido
• Análisis de Figura de Ruido
• Análisis de Distorsión
• Análisis de CD
• Análisis de Peor-caso.
• Comportamiento de Monte Carlo
• Sensibilidad
• Barrido de Parámetro
• Barrido de Temperatura

3.1. ISO

ISO (Internacional Organization for Standardization) es la Organización Internacional de Normalización, cuya principal actividad es la elaboración de normas técnicas internacionales.

Las normas ISO contribuyen a que el desarrollo, la producción y el suministro de bienes y servicios sean más eficaces, seguros y transparentes. Gracias a estas normas, los intercambios comerciales entre países son más fáciles y justos. Proporcionan a los gobiernos un fundamento técnico para la legislación en materia de salud, seguridad y medio ambiente. También contribuyen a la transferencia de tecnología a los países en vías de desarrollo y, además, sirven para proteger a los consumidores y usuarios en general, ante cualquier problema surgido de un producto o servicio, haciéndoles la vida más sencilla.

¿QUÉ ES UNA NORMA?

La norma es un documento público, consensuado por todas las partes interesadas y aprobado por un Organismo de Normalización reconocido.

Las normas contienen especificaciones técnicas basadas en los resultados de la experiencia y del desarrollo tecnológico. Son una herramienta de desarrollo económico y social de un país, ya que sirven como base para mejorar la calidad en la gestión, el diseño y producción de los productos y servicios, y para aumentar la competitividad en los mercados nacionales e internacionales.

La ventajas del uso de las normas en vez de especificaciones privadas, es que las normas:

• Están al alcance de todos, y por tanto pueden ser documentos de referencias nacionales e internacionales.
• Son documentos aceptados por el mercado y por la sociedad, ya que son fruto del consenso de todas las partes interesadas, incluyendo consumidores y usuarios.

3. Estándares de Calidad Aplicados al Software

La calidad es importante para poder satisfacer a los clientes que pidan un sistema de calidad y cada vez hay mucho mayor competitividad en este mundo de la informática lo cual hace que cada uno de los desarrolladores busque opciones del como poder desarrollar software de calidad y en ello se han creado desde hace mucho tiempo atrás los estándares que hoy en día rigen en torno a este mundo para el desarrollo correcto de aplicaciones de calidad cumpliendo con sus normas y parámetros en aras de conseguir la ansiada calidad, y en este trabajo hablaremos específicamente de 3 estándares aplicados al desarrollo de software y esos son:

•ISO

•SPICE

•CMM

2.8. Métodos y Herramientas

Reusabilidad
  * El grado en que un programa (o partes de un programa) se puede reusar en otras aplicaciones. 
  * Esto va relacionado con el   empaquetamiento y el alcance de las funciones que realiza el programa.

Métricas
  * Representan medidas indirectas, es decir, nunca se mide realmente la calidad, sino algunas de sus manifestaciones. El factor que lo complica es la relación precisa entre la variable que es medida y la calidad del software. No se puede medir directamente la calidad del software por la naturaleza subjetiva de esta actividad.

Inspecciones
Inspeccionar es revisar un programa con el objetivo de encontrar defectos en él.
  * Las inspecciones actúan de manera estática.
  *   realizarse antes que la prueba.

Métodos de desarrollo formales
  * Método formal es cualquier técnica que trate la construcción y/o el análisis de modelos matemáticos que contribuyen a la automatización del desarrollo de sistemas informáticos

Medidas de fiabilidad
  * La fiabilidad del equipo lógico se define en términos estadísticos como la «probabilidad de operación libre de fallos de un programa de ordenador en un entorno determinado y durante un tiempo específico».
  * Lenguajes de cuarta generación
Los lenguajes de cuarta generación o bien 4GL son herramientas encargadas de optimizar el desarrollo de software   automatizando la creación de este. Se han utilizado principalmente en la generación de código para GUI y además en la implementación de programas que facilitan las tareas de los desarrolladores y clientes 

Reingeniería de procesos
Es la revisión fundamental y el cambio radical del diseño de procesos, para mejorar drásticamente el rendimiento en términos de costo, calidad, servicio y rapidez. La reingeniería de procesos es una especie de reinvención, más que un mejoramiento gradual.

2.7. Actividades del SQA

Para poder lograr una buena adherencia con los estándares se debe medir cuantitativamente, donde sea posible, los aspectos de calidad (por ejemplo complejidad, confiabilidad, mantenimiento, seguridad, defectos, número de problemas) utilizando métricas bien establecidas. Para cumplir con esto, se deben realizar chequeos de:

- Administración.
- Documentación.
- Estándares, prácticas, convenciones y métricas.
- Revisiones e intervenciones.
- Actividades de testeo.
- Reporte de errores y acciones correctivas.
- Herramientas, técnicas y métodos.
- Control del código
- Control de medios.
- Colección de registros, mantenimiento y retención.
- Control de los proveedores
- Entrenamiento.
- Administración del riesgo.

La forma en que se llevarán a cabo estas actividades se define en el SQAP, el cual irá evolucionado es las sucesivas fases del desarrollo. Para guiar a la Gerencia de SQA, en el siguiente punto se apuntan las guías para cada una de las actividades.

2.6. Habilidades y Capacidades del Personal de SQA

• Conocimiento de todo el proceso de desarrollo de software.
• Experiencia en varios roles dentro de la organización.
• Una persona proactiva.
• Capacidad de seguimiento de actividades.
• Capacidad de un trato amable con la gente.
• Es también responsable de asegurar la calidad de los productos generados en el proyecto y del proceso utilizado.
• Debe revisar la calidad de planificación del proyecto y la valoración del proyecto.
• Debe asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el así como disminuir la calidad del mismo.

2.5. Roles y Responsabilidades de los Equipos de Desarrollo

El Cliente

Se puede pensar que tratar al cliente como parte del equipo de desarrollo es extraño, pero en realidad, no lo es: El cliente es un factor importante en el éxito de un proyecto, tanto como cualquier otro miembro del equipo, por eso es importante contar con la participación activa del cliente dentro del proyecto.

También es importante entender quién es en realidad “El Cliente”. Tanto si se desarrolla software para clientes actuales, como si se desarrolla para uno mismo, o para la propia empresa u organización, siempre hay un rol de cliente. El cliente, es en esencia, quien pone en marcha el proyecto, paga las cuentas, o define el resultado final. Aun si no se tiene literalmente un “cliente”, es bueno entender que aun así existe un rol “cliente” en su proyecto. Esto puede ayudar a evitar confusiones. Si hay varias personas diciendo que características se necesitan, hay que asegurarse de que exista algún responsable de tomar las decisiones cuando estos requisitos sean contradictorios.

El Analista

El analista es alguien que es responsable de entender las necesidades del cliente, y asegurarse de que la solución que está siendo desarrollada se ajusta a esas necesidades.

Las actividades típicas de un analista incluyen la elicitación de requisitos, reuniones con clientes y la redacción de especificaciones funcionales.

Incluso si un proyecto es demasiado pequeño para escribir un verdadero documento de especificación, la comprensión de las necesidades del cliente es un trabajo importante, dado que a menudo el éxito de un proyecto de desarrollo depende de qué tan cerca está la solución desarrollada de las expectativas del cliente.

El Arquitecto de Software

El papel del arquitecto de software es traducir los requisitos, tal como se define por el analista, en una solución técnica. Él puede crear un diseño técnico, o simplemente algunos bocetos a mano alzada, de cómo el sistema va a estar estructurado. En cualquier caso, es la responsabilidad del arquitecto a pensar en el sistema antes de que se desarrolle. Si se hace bien, durante la fase de diseño que se abordarán correctamente todos los problemas que se enfrenten en el desarrollo de la solución.

A menudo hay muchas maneras de lograr algo. El arquitecto de una aplicación es el que decide qué camino tomar, en base a la arquitectura global que ha elegido. Cuando el desarrollo se ha iniciado, es responsabilidad del arquitecto realizar un seguimiento del desarrollo, para ver si todavía se mantiene en consonancia con el diseño general.

El Arquitecto del Sistema

Al igual que el arquitecto de software, el Arquitecto del Sistema es responsable de pensar el sistema antes de construirlo. Asi como el  arquitecto de software es responsable para el software, un arquitecto del sistema es responsable del hardware. Muchas aplicaciones ejecutan completamente en un único servidor. Muchos otros sin embargo se ejecutan en grupos de servidores, con servidores dedicados de bases de datos, servidores web y balanceadores de carga. Un arquitecto del sistema tiene en cuenta los requisitos de rendimiento y disponibilidad, el número de usuarios / visitantes, etc. y en base a esto, diseña una infraestructura de servidores y una red.

El Desarrollador de Software

El desarrollo efectivo de una aplicacion es hecha por los desarrolladores del equipo. Pero un desarrollador tiene más responsabilidades que solo escribir código. Él es a menudo responsable de hacer el seguimiento de su propio progreso, e informar al jefe de proyecto de los problemas a los que se enfrenta. Él es también quien implementa las ideas del arquitecto, y como tal, puede tener que discutir las (in)posibilidades de la implementación con el arquitecto.

Una responsabilidad importante es documentar el código. Mientras que muchos desarrolladores piensan que la documentación es algo que será realizado mejor por alguien más, esta es en realidad una responsabilidad importante del desarrollador.

La Documentación de Código tiene como objetivo el explicar a otros desarrolladores aquellas cosas que no resulten evidentes o claras a partir de la lectura del propio código en sí. Se debe dar una idea de por qué un fragmento de código es de la manera que es. El desarrollador es el único que conoce los pensamientos e ideas detrás del código que escribe, lo cual lo convierte en el candidato perfecto para documentarlo.

El Jefe de Desarrolladores

Un desarrollador líder, que tiene las mismas responsabilidades que los otros desarrolladores, pero también tiene añadidas algunas más. Un desarrollador líder debe entrenar a los otros desarrolladores, y ayudarles a resolver los problemas que puedan enfrentar. Este desarrollador, que suele ser el miembro del equipo más experimentado, también será capaz de asegurarse de que la ejecución sigue de cerca al diseño planteado, y no se dé lugar a lo que se denomina “invasión de características” durante el desarrollo. El desarrollador líder tiene una gran influencia en la calidad del código.

El Diseñador Gráfico

“Lo de dentro es lo que cuenta.”, es tan cierto, como que también la percepción de los usuarios depende mucho de la mirada y la sensación que le produce una aplicación o sitio web. No importa lo buena que la aplicación sea, si la interfaz es inconsistente, se sentirá menos robusto.

Es importante reconocer el papel del diseñador en un proyecto. Es bueno tener alguien encargado de la disposición general de una aplicación. Esto puede ir desde el diseño completo de la interfaz de usuario, hasta el definir sólo algunas directrices de interfaz de usuario que los desarrolladores deban cumplir.

Incluso si el diseño está determinado por los desarrolladores, es una responsabilidad importante crear un diseño consistente en toda la aplicación.

El Tester

Las pruebas son una parte importante para asegurar que el software funciona de la manera que debería. El papel de ‘tester’ se realiza a menudo por los desarrolladores para los aspectos técnicos y los usuarios para los aspectos funcionales. Un problema que surge de hacer a los desarrolladores probar su propio código es que, no importa lo bueno que sean, se ven influidos por la forma de su código fue creado. Cuando se prueba, se tendrá en cuenta esas mismas situaciones que que ya se tuvieron en cuenta a la hora de escribirlo.

Si se prueba código de otra persona, se puede pensar en escenarios que la otra persona no los pensó. Así que incluso si no se tiene un equipo de Testers dedicado, es una buena idea que cada desarrollador pruebe código de otro desarrollador, en lugar del suyo propio.

El Gerente del Proyecto

Un gerente de proyecto tiene muchas responsabilidades. Es responsable de la planificación del proyecto, de mantener el proyecto dentro del presupuesto, y de la solución de problemas. En resumen, él resuelve cualquier problema que ponga en peligro el progreso del proyecto.

Muchas de las tareas del gerente del proyecto tienen que ver con la comunicación, la comunicación al cliente sobre el progreso del proyecto y la comunicación con todos los miembros del equipo. Incluso en los proyectos de desarrollo que no cuentan con un gerente de proyecto, es conveniente asignar el rol de gerente de proyecto a alguien, para que quede claro quién es responsable de la ejecución del mismo.

El Administrador de Cuentas

Si usted desarrolla proyectos para clientes, sus proyectos pueden beneficiarse de las funciones de un Administrador de Cuentas. Un administrador de cuentas cultiva la relación con el cliente. Aunque la gestión de proyectos y administración de cuentas se hace a menudo por la mismo persona dentro de un proyecto, hay situaciones en las que ayuda a dividir estos roles.

Un administrador de cuentas puede mantener una relación más independiente con el cliente, y avisar si el cliente no está contento con la forma en que se ejecuta el proyecto por parte del gerente del proyecto.

Al separar los roles de Administrador de cuentas, y Gerente de proyecto, también lograremos evitar conflictos de interés.

El director del proyecto puede concentrarse y proyectar lo mejor de sus habilidades para el funcionamiento del proyecto, mientras que el administrador de cuentas puede tomarse el trabajo de reconocer oportunidades comerciales.

El Administrador de sistemas

El sistema en que la aplicación será instalada es creado por un administrador del sistemas.

Se arman los servidores, se instala el sistema operativo, un servidor web, PHP, una base de datos y cualquier software adicional que se requiera.

Incluso antes de que el proyecto se haya terminado, un administrador del sistema puede tener que construir los entornos de desarrollo y ambientes de prueba.

Más adelante en el proyecto, se ocupara de mantener los sistemas operando.

El Administrador de Código

El Código es importante y debe ser tratado como tal, el código necesita ser gestionado. Si varios de los desarrolladores están trabajando en conjunto, el código que escriben deben integrarse en algún momento, independientemente del sistema de control de versiones utilizado.

Además, cuando haya terminado, el proyecto debe ser implementado. La implementación del proyecto significa tomar el código y desplegarlo en el servidor. Aunque usualmente no hay una persona manejando esto, es importante identificar dicho rol.

El Capacitador

Cuando un proyecto se haya completado, los usuarios pueden necesitar ser capacitados, en particular si en el proyecto se desarrollado una aplicación.

No es común capacitar a los usuarios de un sitio web, pero a menudo hay un back-end que los administradores tendrán que ser aprender a usar.

El Capacitador relaciona las soluciones que se han creado con el usuario final.

Una importante responsabilidad del Capacitador es explicar cómo la aplicación resuelve el problema del cliente y, como tal, juega un papel importante en asegurar que las expectativas del cliente sobre el software están en línea con lo que ha sido creado.