4.1 CALIDAD DE SOFTWARE:Dentro del contexto de Ingeniera de Software, se tomar la definicin de calidad en el software propuesta por la organizacin internacional de estndares (ISO/IEC DEC 9126): La totalidad de caractersticas de un producto de software que tienen como habilidad, satisfacer necesidades explcitas o implcitas. Se puede decir que el software tiene calidad si cumple o excede las expectativas del usuario en cuanto a:1. 2. 3. 4. 5.

Funcionalidad (que sirva un propsito) Ejecucin (que sea prctico) Confiabilidad (que haga lo que debe) Disponibilidad (que funcione bajo cualquier circunstancia) Apoyo, a un costo menor o igual al que el usuario est dispuesto a pagar. Resumiendo podemos decir, que la calidad de software se refiere a: Los factores de un producto de software que contribuyen a la satisfaccin completa y total de las necesidades de un usuario u organizacin.

4.2 CMO OBTENER UN SOFTWARE DE CALIDAD?La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan uniformar la filosofa 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 poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico, administrativo y ergonmico. El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del software. El principio administrativo contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software. El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado. La adopcin de una buena poltica 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 evaluacin.

4.2.1 CMO SOFTWARE?

CONTROLAR

LA

CALIDAD

DE

Para controlar la calidad del software es necesario, ante todo, definir los parmetros, indicadores o criterios de medicin. 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: clasificacin por tipo, esfera de aplicacin, complejidad, etc., de acuerdo con los estndares 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 mtodos de valoracin de los indicadores: mtodos manuales como cuestionarios o encuestas estndares para la medicin de criterios periciales y herramientas automatizadas para medir los criterios de clculo. Definir las regulaciones organizativas para realizar el control: quines participan en el control de la calidad, cundo se realiza, qu documentos deben ser revisados y elaborados, etc

4.3 FUNCIONES SOFTWARE

DE

EVALUACIN

DE

4.3.1 FUNCIONALIDADEn esta seccin cuenta con los siguientes atributos los cuales los describimos de la siguiente forma:1.

Adecuacin: Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados. Exactitud: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de precisin. Interoperabilidad: Capacidad del producto software para interactuar con uno o ms sistemas especificados. Seguridad de acceso: Capacidad del producto software para proteger informacin y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados. Cumplimiento funcional: Capacidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con funcionalidad.

2.

3.

4.

5.

4.3.2.CONFIABILIDAD (FIABILIDAD)1.

Madurez: Capacidad del producto software para evitar fallar como resultado de fallos en el software. Tolerancia a fallos: Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos software o de infringir sus interfaces especificados. Capacidad de recuperacin: Capacidad del producto software para reestablecer un nivel de prestaciones especificado y de recuperar los datos directamente afectados en caso de fallo. Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a normas, convenciones o regulaciones relacionadas con al fiabilidad.

2.

3.

4.

4.3.3 FACTIBILIDAD DE USO (USABILIDAD)1.

Capacidad para ser entendido: Capacidad del producto software que permite al usuario entender si el software es adecuado y cmo puede ser usado para unas tareas o condiciones de uso particulares. Capacidad para ser aprendido: Capacidad del producto software que permite al usuario aprender sobre su aplicacin. Capacidad para ser operado: Capacidad del producto software que permite al usuario operarlo y controlarlo.4.

2.

3.

Capacidad de atraccin: Capacidad del producto software para ser atractivo al usuario.5.

Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a normas, convenciones, guas de estilo o regulaciones relacionadas con la usabilidad.

4.3.4 EFICIENCIA1.

Comportamiento temporal: Capacidad del producto software para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas. Utilizacin de recursos: Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su funcin bajo condiciones determinadas. Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la eficiencia.

2.

3.

4.3.5 MANTENIBILIDAD1.

Capacidad para ser analizado: Es la capacidad del producto software para serle diagnosticadas deficiencias o causas de los fallos en el software, o para identificar las partes que han de ser modificadas. Capacidad para ser cambiado: Capacidad del producto software que permite que una determinada modificacin sea implementada. Estabilidad: Capacidad del producto software para evitar efectos inesperados debidos a modificaciones del software. Capacidad para ser probado: Capacidad del producto software que permite que el software modificado sea validado. Cumplimiento de la mantenibilidad : Capacidad del producto software para adherirse a normas o convenciones relacionadas con la mantenibilidad.

2.

3.

4.

5.

4.3.6 PORTABILIDAD1.

Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propsito por el propio software considerado. Instalabilidad : Capacidad del producto software para ser instalado en un entorno especificado. Coexistencia: Capacidad del producto software para coexistir con otro software independiente, en un entorno comn, compartiendo recursos comunes. Capacidad para reemplazar: Capacidad del producto software para ser usado en lugar de otro producto software, para el mismo propsito, en el mismo entorno. Cumplimiento de la portabilidad: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la portabilidad.

2.

3.

4.

5.

4.3.7 ATRIBUTOS PARA CALIDAD DE USO

1. Efectividad: Capacidad del producto software para permitir a los usuarios alcanzar objetivos especificados con exactitud y completitud, en un contexto de uso especificado. 2. Productividad: Capacidad del producto software para permitir a los usuarios gastar una cantidad adecuada de recursos con relacin a la efectividad alcanzada, en un contexto de uso especificado. 3. Seguridad fsica: Capacidad del producto software para alcanzar niveles aceptables del riesgo de hacer dao a personas, al negocio, al software, a las propiedades o al medio ambiente en un contexto de uso especificado. 4. Satisfaccin: Capacidad del producto software para satisfacer a los usuarios en un contexto de uso especificado.

4.4. RELACIN DE LA SOFTWARE CON EL SQA

INGENIERA

DE

SOFTWARE: Programas, procedimientos y posiblemente, la documentacin asociada y los datos pertenecientes a las operaciones de un sistema computacional.

Incluye:1. 2. 3.

Entrenamiento. Soporte al consumidor Instalacin.

Caractersticas: 1. Elemento lgico, no fsico. 2. Desarrollado, no fabricado. 3. No se estropea, pero se deteriora (deterioro por cambios). 4. Mayoritariamente cerrado: usar todo o nada. 5. Construccin a la medida. 6. Mantenimiento complicado.

INGENIERA DE SOFTWARE: Es el establecimiento y uso de principios slidos de la ingeniera para obtener econmicamente un software confiable y que funcione de modo eficiente en mquinas reales.

La IEEE, elabor un definicin que establece: Es la aplicacin de un enfoque sistemtico, disciplinado y confiable al desarrollo y mantenimiento del software La ingeniera de software es una tecnologa estratificada, debe estar sustentada en un compromiso con la calidad. La gestin de calidad total, sigma seis y enfoques similares fomentan una cultura de mejora continua del proceso y es una cultura la que al final conduce al desarrollo de enfoques muy afectivos para la ingeniera de Software.

La base que sustenta a la Ingeniera de software es un enfoque de calidad que se basa en:

1.

DESARROLLO DE SOFTWARE A PEQUEA ESCALA: Proceso Simple. Modelado Mnimo. Herramientas Simples. Puede hacerlo una sola persona. Desarrollo Artesanal. Bajo costo.

2. DESARROLLO DE SOFTWARE A GRAN ESCALA : Proceso complejo. Modelado y Diseo. Herramientas Sofisticadas. Equipo de trabajo. Costo elevado. Gestin de proyecto. Posiblemente plazos de terminacin.

PROBLEMTICA ACTUAL CON EL SOFTWARE

Incapacidad para estimar, tiempo, costo y esfuerzo para el desarrollo de un producto de software. Falta de calidad del producto de software. Avance del hardware y necesidad de aplicaciones mas complejas.

Algunas Causas: 1. Naturales no fsica de la programacin. 2. Problemas derivados de la intervencin de grupos 3. Problemas de comunicacin con los clientes. 4. Poco esfuerzo en el anlisis y diseo. 5. Problemas de gestin. 6. A veces, el software debe solucionar los problemas del sistema global,

SQA

Es el conjunto de actividades, sistemticas y planeadas para asegurar que los Procesos y Productos del software cumplen con los requerimientos y estndares y procedimientos. PROCESOS: incluyen las actividades involucradas en el diseo, codificacin , mantenimiento. pruebas y

PRODUCTOS: Incluye software, datos asociados, documentacin y todo el soporte y reportes de trabajo.

SQABrinda a la Administracin implementados. Y asegura que: 1 .Una metodologa de desarrollo apropiado este establecida. 2. Que los proyectos utilicen estndares y procedimientos en su trabajo. 3. Que la documentacin sea creada para mantenimiento y mejoramiento. 4.La administracin de configuracin de Software este adecuada para controlar cambios. 5. Se realicen pruebas y se aprueben. 6. Cualquier deficiencia y desviaciones sean identificadas y llevadas con atencin a la administracin. la seguridad de que procesos oficialmente establecidos estn siendo

Propsito de SQA: Proporcionar visibilidad en los procesos utilizados en el proyecto del software y sobre los productos que genera.

Objetivos:1. 2.

3.

Planificar las actividades de aseguramiento de la calidad. Revisar y Auditar objetivamente los productos y las actividades para verificar que estn conformes con los procedimientos y estndares aplicables. Proporcionar los resultados de estas revisiones y auditorias informando a la direccin cuando sea necesarias medicin.

Resuelve Problemas como: 1. Aumenta las posibilidades de el xito final del proyecto. 2. Ayuda a definir los parmetros de medicin de la calidad de software. 3. Verifica los estndares sean aplicables correctamente. 4. Define un plan de monitoreo del proceso de desarrollo del software (ciclo de vida del software)

4.5 ISO/UNE

Cada vez ms las empresas apuestan por la innovacin de sus productos, no slo para ajustarse a las necesidades de la propia empresa y sus clientes, sino tambin para mejorar el comportamiento ambiental del productos, desde el origen de las materias primas, pasando por su fabricacin y comercializacin, el uso en su vida til y posterior disposicin como residuo. Para ellos, una empresa innovadora, debe realizar un Anlisis del Ciclo de Vida de sus productos e integrar la variable ambiental en sus departamentos de I+D+i y diseo a travs de la toma de decisiones objetivas para minimizar la huella ecolgica de los productos.

4.6 SPICE

El modelo ISO/SPICE proporciona un marco para la evaluacin de los procesos de Software. Este marco puede ser utilizado por organizaciones cuya actividad incluya la planificacin, gestin, control o mejora de los procedimientos de adquisicin, suministro, desarrollo, operacin, evolucin y soporte de software. Esta norma se traduce en ISO/IEC TR 15504 provee un marco de trabajo para la valoracin del proceso de software y parte de los mnimos requerimientos para la realizacin de una valoracin para asegurar consistencia y repetitividad de las mediciones. Los requerimientos ayudan a asegurar que las salidas de la valoracin son auto consistentes, y provee evidencia para consolidar las mediciones y para verificar conformidad con los requerimientos.

El modelo SPICE esta basado en procesos que se agrupan en cinco categoras diferentes:

Cliente-Proveedor. Ingeniera. Soporte. Administracin. Organizacin.

SPICE PROCESOS

4.7 CMM

Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.

NIVELES DEL MODELO CMM

Nivel 1: Inicial o Nivel. Este es el nivel en donde estn todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en el.

Nivel 2: Repetible. Quiere decir que el xito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. Los procesos que hay que implantar para alcanzar este nivel son: Gestin de requisitos Planificacin de proyectos Seguimiento y control de proyectos Gestin de proveedores Aseguramiento de la calidad Gestin de la configuracin

Nivel 3: Definido Resumindolo mucho, este alcanzar este nivel significa que la forma de desarrollar proyectos (gestin e ingeniera) esta definida, por definida quiere decir que esta establecida, documentada y que existen mtricas (obtencin de datos objetivos) para la consecucin de objetivos concretos.

Los procesos que hay que implantar para alcanzar este nivel son:

Desarrollo de requisitos Solucin Tcnica Integracin del producto Verificacin Validacin Desarrollo y mejora de los procesos de la organizacin Definicin de los procesos de la organizacin Planificacin de la formacin Gestin de riesgos Anlisis y resolucin de toma de decisiones La mayora de las empresas que llegan al nivel 3 paran aqu, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir ms all porque tienen cubiertas la mayora de sus necesidades.

Nivel 4: Cuantitativamente Gestionado Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organizacin. Se usan mtricas para gestionar la organizacin. Los procesos que hay que implantar para alcanzar este nivel son: Gestin cuantitativa de proyectos Mejora de los procesos de la organizacin.

Nivel 5: Optimizado Los procesos de los proyectos y de la organizacin estn orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante mtricas son identificadas, evaluadas y puestas en prctica. Los procesos que hay que implantar para alcanzar este nivel son: Innovacin organizacional Anlisis y resolucin de las causas Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultneamente ya que estn muy relacionados.

4.8 BOOTSTRAPBootstrap es otra de las iniciativas para resolver la crisis del desarrollo de Software. Esta metodologa mediante prcticas, herramientas y estndares de calidad internacional; mide, evala y propone mejoras al proceso de desarrollo de SW que siguen las Unidades de Produccin de Software (UPS) de las empresas.

La metodologa Bootstrap se compone de: 1. 2. 3. 4. 5. Un modelo. Un proceso de evaluacin. Una base de datos de soporte. Un proceso de mejora. Los instrumentos de evaluacin.

MODELO BOOTSTRAP

4.9 TSP & PSP TEAM SOFTWARE PROCESS (TSP) Y EL PERSONAL SOFTWARE PROCESS (PSP)PSP:

Apoyar a desarrollar competencias especficas, orientadas a profesionalizar las prcticas del equipo de desarrollo. Implantar prcticas de medicin y anlisis, estimacin, planeacin y seguimiento que permitan dar mayor certeza a la entrega de Productos de Software de Alta Calidad a la vez que se mejora la calidad mediante el uso de PSP/TSP, as como de las mejores prcticas para Revisiones, Pruebas, Requerimientos y Configuracin. Obtener resultados tangibles mediante la implementacin de la metodologa en proyectos piloto.

Se utilizan los datos para:

Planear y monitorear el trabajo. Administrar la calidad de los productos que se producen. Medir y mejorar el desempeo.

(TSP) es un proceso de desarrollo para equipos de ingenieros basado en CMM:

Es una solucin basada en procesos para resolver problemas de negocio:1. 2. 3.

Predecibilidad de costo y tiempo. Mejora de productividad y ciclos de desarrollo. Mejora de calidad de productos

La metodologa permite:

Con PSP, los desarrolladores utilizan procesos definidos y medibles. Se toma informacin de tamao, tiempo y defectos al momento de realizar el trabajo. Se utilizan los datos para: planear y monitorear el trabajo, administrar la calidad de los productos que se producen y medir y mejorar el desempeo. TSP ha permitido resolver problemas tpicos de negocio: predecibilidad de costo y tiempo, mejora de productividad y ciclos de desarrollo, mejora de calidad de productos.

PSP/TSP mejora el desempeo tanto de equipos como individuos; es disciplinado y gil; provee beneficios inmediatos y medibles; acelera las iniciativas de mejora de procesos organizacionales. Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo. Esto reduce de manera importante el tiempo de pruebas. Con un testing ms corto, el ciclo completo se reduce

BIBLIOGRAFA:N.A. (N.f). Calidad de Software. Obtenido el da 05 de Junio de 2011, http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF N.A. (N.f). Aseguramiento de Calidad. Obtenido el da 05 de Junio de 2011, http://www.isol.com.ar/pg005.html N.A. (N.f). Un enfoque actual sobre la calidad del software. Obtenido el da 05 de Junio de 2011, http://bvs.sld.cu/revistas/aci/vol3_3_95/aci05395.htm N.A. (N.f). Evaluacin de software en Sistemas de Informacin. Obtenido el da 05 de Junio de 2011, http://delta.cs.cinvestav.mx/~pmejia/davila-mejia.pdf N.A. (N.f). Relacin de la ingeniera de software con SQA . Obtenido el da 05 de Junio de 2011, http://www.slideshare.net/wiso08/temas-unidad-2 N.A. (N.f). Modelo SPICE . Obtenido el da 05 de Junio de 2011, http://bdigital.eafit.edu.co/bdigital/PROYECTO/P005.12CDD946/capitulo1.pdf N.A. (N.f). Modelo CMM-CMMI . Obtenido el da 05 de Junio de 2011, http://www.globales.es/imagen/internet/Informaci%C3%B3n%20General%20CMMI.pdf N.A. (N.f). Modelo de calidad CMM. Obtenido el da 05 de Junio de 2011, http://www.ingenierosoftware.com/calidad/cmm-cmmi.php N.A. (N.f). El Estndar Europeo para Evaluacin y Mejoras de Procesos de Desarrollo de Software. Obtenido el da 05 de Junio de 2011, http://ingsw.ccbas.uaa.mx/sitio/images/material/bootstrap.htm N.A. (N.f). Metodologa de PSP & TSP.Obtenido el da 05 de Junio de 2011, http://www.kernel.com.mx/documentos/psp_tsp.pdf