Universidad Tecnológica de Puebla

Tecnologías de la Información y Comunicación

Manual de Asignatura
Basado en Competencias Profesionales

Calidad en el Desarrollo de Software

Enero 2012

ELABORÓ: UNIVERSIDAD TECNOLÓGICA
AUTORES: M.A. OSVALDO CASTAÑEDA
HERNANDEZ V2.0
APROBÓ:
COMISION NACIONAL ACADÉMICA
DE TIC

REVISÓ: UNIVERSIDAD(ES) TECNOLÓGICA(S)
REVISORES:
FECHA DE ENTRADA EN VIGOR:

CALIDAD EN EL DESARROLLO DE SOFTWARE
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

INTRODUCCIÓN ..............................................................................................................................................4
UNIDAD TEMÁTICA I INTRODUCCIÓN A LA CALIDAD DE SOFTWARE. ...............................................................................5
CONTROL DE CALIDAD ..........................................................................................................................................6
GESTIÓN DE LA CALIDAD TOTAL ..............................................................................................................................6
ASEGURAMIENTO DE LA CALIDAD ............................................................................................................................7
GENERALIDADES DE LA CALIDAD ....................................................................................................................9
INSTITUTOS QUE REGULAN LA CALIDAD .......................................................................................................11
CONCEPTOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE ........................................................................12
EVALUACIÓN DEL PRODUCTO SOFTWARE: ISO 14598 ...................................................................................13
ALCANCE DE LA NORMA ISO 14598 ...................................................................................................................14
I. ISO/IEC 14598 - PARTE 1: VISIÓN GENERAL .....................................................................................................14
II. ISO/IEC 14598 - PARTE 2: PLANIFICACIÓN Y GESTIÓN ........................................................................................15
III. ISO/IEC 14598 - PARTE 3: EL PROCESO PARA DESARROLLADORES .......................................................................15
IV. ISO/IEC 14598 - PARTE 4: EL PROCESO PARA COMPRADORES.............................................................................16
V. ISO/IEC 14598 - PARTE 5: EL PROCESO PARA EVALUADORES ...............................................................................17
VI. ISO/IEC 14598 - PARTE 6: DOCUMENTACIÓN DE LOS MÓDULOS DE EVALUACIÓN ...................................................18
UNIDAD TEMÁTICA MÉTRICAS DE SOFTWARE.........................................................................................................21
2.1 CONCEPTO DE MÉTRICA ..............................................................................................................................22
TIPOS DE MÉTRICAS DE CALIDAD DE SOFTWARE .......................................................................................................22
2.- MÉTRICAS ORIENTADAS A LA FUNCIÓN ..............................................................................................................27
ESTIMACIÓN.................................................................................................................................................29
PLANEACIÓN DEL PROYECTO ........................................................................................................................29
ERRORES CLASICOS EN UN PROYECTO DE SOFTWARE ...................................................................................32
UNIDAD TEMÁTICA III PROCESO PERSONAL DE DESARROLLO DE SOFTWARE ..................................................................33
ELEMENTOS DEL PROCESO PERSONAL DE SOFTWARE (PSP) ........................................................................................34
¿QUÉ ES EL PSP?..............................................................................................................................................34
PRINCIPIOS PSP ...............................................................................................................................................34
ESTRUCTURA DEL PSP ........................................................................................................................................34
PSP O. PROCESO (PUNTO DE PARTIDA)..................................................................................................................36
PSP 2. CALIDAD PERSONAL ...........................................................................................................................37
3.2 PLANTILLAS PSP .......................................................................................................................................38
LOGS DE REGISTRO DE TIEMPO .............................................................................................................................40

2

CALIDAD EN EL DESARROLLO DE SOFTWARE
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

METRICAS DEL PSP .......................................................................................................................................42
RESUMEN DEL REGISTRO DE MÉTRICAS...................................................................................................................43
4.1 PUNTOS DE FUNCIÓN ..................................................................................................................................45
CARACTERÍSTICAS DE LA FUNCIONALIDAD ..........................................................................................................46
4.2 PUNTOS DE CASOS DE USO ..........................................................................................................................51
1. FACTOR DE PESO DE LOS ACTORES SIN AJUSTAR (UAW) .........................................................................................52
2. FACTOR DE PESO DE LOS CASOS DE USO SIN AJUSTAR (UUCW)................................................................................52
TABLA 3: PESO DE LAS CLASES DE ANÁLISIS..............................................................................................................53
FACTORES DE COMPLEJIDAD TÉCNICA .....................................................................................................................53
FACTORES AMBIENTALES .....................................................................................................................................54
4. ESFUERZO HORAS-HOMBRE (E) ........................................................................................................................54
5.1 MOPROSOFT .........................................................................................................................................57
MODELO MOPROSOFT ...................................................................................................................................57
GESTIÓN DE NEGOCIO (DIR) ...............................................................................................................................58
GESTIÓN DE PROCESOS (GES) .............................................................................................................................60
GESTIÓN DE RECURSOS (GES) .............................................................................................................................62
ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS (OPE) ................................................................................................63
DESARROLLO Y MANTENIMIENTO DE SOFTWARE (OPE) .............................................................................................64
5.2 CMMI....................................................................................................................................................65
5.2.1 LOS CINCO NIVELES DE MADUREZ EN LOS PROCESOS DE CREACIÓN DEL SOFTWARE ...............................................66
5.2.2 CARACTERÍSTICAS COMUNES: ......................................................................................................................69
MODELO DE DESARROLLO DE SOFTWARE ...............................................................................................................70
GLOSARIO DE TÉRMINOS .....................................................................................................................................72

3

para brindar al alumno información seria y de calidad. permitiéndoles solucionar problemas en función de los conocimientos adquiridos de automatización de sistemas. IV. sitios de internet. el autoestudio. El objetivo principal del documento es brindar al alumno información que le permita al alumno identificar. diseñar y valorar distintos problemas relacionados a la gestión de trabajos de software a través de diversos problemas o planteamientos de realización (individual o grupal). Con la finalidad de que el alumno pueda aplicar algunos de los conocimientos adquiridos durante el desarrollo de la asignatura. V. Esta información en su mayoría ha sido colectada de libros.Además de propiciar la realización de trabajos futuros aplicados a su entorno. II. la investigación y la auto práctica. Métricas de Software Proceso Personal de Desarrollo de Software Técnicas de Estimación Modelos para el Aseguramiento de la Calidad de Software Cada uno de estas unidades cuenta con información que sustenta cada uno de los temas contenido en la unidad. DESARROLLO El manual está compuesto por 5 unidades temáticas: I. Además de motivar en él. en este manual se integran prácticas (casos) que le permitirán comprender conceptos y procesos de realización de un sistema bajo cierta normatividad de gestión (reglas o normas). analizar. Se integran prácticas a los temas para fortalecer el aprendizaje significativo del alumno. 4 . Introducción a la Calidad en el Desarrollo de Software. III.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN INTRODUCCIÓN El siguiente documento integra información acerca temas relacionados con la asignatura Calidad en el Desarrollo de Software.

.Portabilidad . para reconocer la importancia del aseguramiento de la calidad.Oportunidad Proactivo Organizado Autodidacta Analítico Sistemático Resultado de aprendizaje:  El participante podrá elaborar un cuadro sinóptico. un ensayo de los conceptos de calidad enfocada hacia el desarrollo de software involucrando cada una de los factores que conformen su gestión. 5 .Confiabilidad . estándares.Corrección .Mantenibilidad . modelos e institutos que regulan la calidad. procesos. Proactivo Organizado Autodidacta Sistemático Conceptos de Calidad Identificar los factores y Determinar la calidad de un en el Desarrollo de características que determinan proyecto de software con Software la calidad del software. normas.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática I Introducción a la Calidad de Software.Eficiencia .Funcionalidad definan. Objetivo:El alumno identificará los conceptos generales de calidad y los específicos en el área de desarrollo de software.Robustez .Usabilidad . como: base en los factores y características que lo .Compatibilidad . Temas Saber Saber hacer Ser Generalidades de la Identificar conceptos de Calidad calidad.

Aseguramiento de la calidad. que sirve para detectar si se han alcanzado los niveles de calidad y tomar las medidas oportunas si no ha sido así. durante y después de haber obtenido los resultados instalando sensores en aquellas fases que se quieren controlar. Constituye el objetivo prioritario. Control de Calidad El control de calidad apareció en los años 30 y adquirió gran importancia en los 50 y 60. se evolucionó según tres etapas: Control de calidad. es decir. Es un concepto dinámico. algo que depende de la diferencia entre sus percepciones y sus expectativas. Gestión de la calidad total. cuantos más controles se instalen más se incrementaran en los costes derivados de dicho control. Figura “Representación esquemática del proceso de control de calidad” Gestión de la calidad total En esta etapa el objetivo es proporcionar productos o servicios capaces de satisfacer al cliente. Lógicamente. que en gran medida son subjetivas. Al considerar el valor percibido. la calidad debe impregnar a todas las áreas de la organización. Se centra en inspeccionar el producto y separar aquel que es aceptable (de acuerdo a unos determinados estándares) del que no lo es. Los objetivos que se persiguen con las políticas de gestión de la calidad son:  Satisfacción del cliente. pero sin embargo se pueden realizar controles antes.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Desde el enfoque tradicional de calidad que había sido centrarse únicamente en tratar de evitar que se produjesen fallos durante la fabricación. ya que es preciso adaptarse constantemente a las cambiantes necesidades de los clientes. Está relacionada con las percepciones del cliente. el precio se incorpora también al concepto de calidad ya que es un factor que influye tanto en las expectativas que se formará el comprador (se tiende a asociar instintivamente alto precio y alta calidad) como en su posterior juicio del producto o servicio (¿mereció la pena pagar ese precio?) En esta etapa aparece la necesidad de implicar a todos los miembros de la organización en el compromiso con la calidad. 6 . es decir. Esta nueva concepción de la calidad presenta importantes implicaciones. Se tiende a considerar como una actividad a posteriori.

CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN       Conseguir hacer las cosas bien a la primera. Proporcionar garantías al cliente de que el producto o servicio que se le ofrece cumple unos determinados estándares de calidad. Para que el sistema pueda ser certificado por terceros ha de estar elaborado de acuerdo a normas establecidas. existen autoridades de certificación que evalúan dicho sistema y en caso de cumplir los requerimientos de calidad necesarios. así como elevar el nivel de calidad de todas las operaciones de la empresa. en el que se recogen los procedimientos adecuados para realizar cada proceso. en consecuencia. Un elemento característico del aseguramiento de la calidad es el Manual de Calidad. Podríamos decir que el este manual es “la Biblia del sistema de aseguramiento de la calidad”. como la serie ISO 9000.  Revisar el sistema de manera continua. Una vez desarrollado el sistema de acuerdo a alguna de estas normas. Pasos fundamentales en el aseguramiento de la calidad:  Establecer un sistema y evaluar su adecuación. y se incluyen todas las actividades en todas las etapas hasta la obtención del producto final. 7 . llevadas cabo sistemáticamente. Como definición de Gestión de la Calidad Total (GCT) puede por tanto darse la siguiente: es el conjunto de actividades extendidas a todas las áreas. que están destinadas a obtener un proceso productivo que asegure que el producto o servicio satisfará los requerimientos de calidad. procesos y departamentos de una organización (es decir. Evitar despilfarros. y que se consigue con un claro compromiso de la dirección y a través de una completa participación de todos los empleados. no será necesario controlar la calidad del producto obtenido. de forma que se compruebe que se sigue trabajando del modo adecuado y que el producto tiene las características prescritas. De esta manera se obtiene el Manual de Calidad. Mejorar la capacidad de reacción del sistema mediante: Productos y servicios personalizados. En definitiva. La cultura de la empresa incorpora la idea de hacer las cosas bien a la primera. la filosofía que sustenta esta etapa es que la calidad se construye en los procesos: si cada proceso se realiza correctamente. certifican a la organización. no existe ningún motivo para que aparezcan defectos y.  Auditar el sistema para verificar que las disposiciones se están implementando. en el plazo requerido y que satisfagan plenamente a los clientes. Eliminar todo aquello que no añada valor. extendidas a toda la organización) que tiene como objetivo enviar productos o servicios libres de defectos. Aseguramiento de la calidad El aseguramiento de la calidad son todas aquellas acciones. La vigilancia de que el proceso se realice de acuerdo al procedimiento establecido es responsabilidad de los auditores de calidad. Desarrollo rápido de nuevos productos y servicios. El objetivo de la certificación es doble: Alcanzar y mantener la calidad del producto o servicio para satisfacer al cliente. Anticipación a las necesidades del cliente. operaciones.

cualquier cambio supone un riesgo.. comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas. Entre las principales se puede mencionar a: SEI (Software Engineering Institute .CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN El papel de los especialistas del departamento de calidad se centra en realizar auditorías de calidad para comprobar que el personal actúa de la manera prevista. cuando realmente él realizar la entrega conforme a lo pactado es algo que el cliente suele dar por supuesto.Instituto de Ingeniería de Software). Se da por sentado que el cliente se siente satisfecho por recibir su pedido de acuerdo a lo que especificó. siguen existiendo problemas: Sigue sin desarrollarse una actividad de mejora. 8 . de calidad Se detecta un error Aplicación de la calidad Al producto Actuación Corregir el error Actitud Reactiva Participación del personal Importancia de la participación Generación de valor añadido Materialización Sólo Depto. enfocados a los desarrolladores como a los adquisidores de software..Organización Internacional de Estandarización) y también SPICE (Software Process Improvement and Capability dEtermination – Mejoramiento de procesos de Software y determinación de capacidad).Instituto de Ingenieros Eléctricos y Electrónicos). Dado que existen unos procedimientos claramente definidos. por lo que no contribuye significativamente a su satisfacción y fidelización. Control de calidad Concepto de calidad Orientación de la empresa Responsabilidad de la calidad Se actúa porque. Aunque el aseguramiento de la calidad supone algunas mejoras respecto al control de calidad tradicional. que se preocupan por realizar metodologías. de calidad + operarios Importante Toda la empresa Si Si Plan de inspección Manual de calidad Sistema de gestión Arreglo Prevención Mejora No se participación No está claro espera Imprescindible Existen entidades internacionales reconocidas. Conformidad con las especificaciones Producción Depto. llamados hardware. IEEE (Institute of Electrical and Electronics Engineers . de calidad + operarios Se intenta evitar el error Al proceso productivo Todos los miembros Modificar procedimiento Reactiva el Satisfacción del cliente Hay objetivos A todos los procesos de la empresa Mejora continua Proactiva Depto. estándares. modelos y/o directrices. de calidad Filosofía Aseguramiento de la calidad Aptitud para el uso GCT Producción Cliente Depto. en contraposición a los componentes físicos del sistema. El tener unos procedimientos formales tan definidos limita de manera considerable la creatividad del personal. ISO (International Organization for Standarization . normas. Se conoce como software al equipamiento lógico o soporte lógico de una computadora digital.

.Características que especifican los ingenieros de Software para el elemento.. máquinas de afeitar. La incompatibilidad repercute en muchos campos. a tiempo y apegado al presupuesto acordado con el cliente y de que el cliente confié que todo lo anterior se cumplirá..Es el grado de cumplimiento de las especificaciones del diseño durante su realización Control de calidad. pero la calidad de un producto no solo se mide al terminarlo. Una norma es una fórmula que tiene valor de regla y tiene por finalidad definir las características que debe poseer un objeto y los productos que han de tener una compatibilidad para ser usados a nivel internacional. que permite al usuario realizar todas las tareas concernientes a la edición de textos. es decir que no sean capaces de desarrollar o entregar un software confiable. 9 . Son normas y protocolos internacionales que deben cumplir productos de cualquier índole para su distribución y consumo por el cliente final. 1. o el software de sistema.. pues. ejemplo o criterio a seguir. cuando se viaja. la costumbre o el consentimiento general".Consiste en una auditoria cuyo objetivo es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto. básicamente.Es asegurarse de que un producto o servicio sea consistente (no variable). Normas. facilitando la interacción con los componentes físicos y con el resto de las aplicaciones. Calidad de concordancia. Calidad de Software. un patrón.El significado primario moderno que le siguió fue "lo que es establecido por la autoridad. Por esto las organizaciones deben buscar una norma. importante. tales como el procesador de textos. tolerancia. etc. Garantía de calidad.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Los componentes lógicos incluyen. Es necesario que cuenten con lineamientos y herramientas de apoyo necesarios para disminuir este problema y así poder liberar sus trabajos sin ninguna preocupación.. y las especificaciones del rendimiento. Por ejemplo. Calidad de diseño. 2. Estándares. confiable (que haga las cosas de forma fiable todo el tiempo) y esté libre de errores y defectos. estándar o modelo que pueda ayudarlas a ser competitivas o llegar a la calidad. el problema que ocasiona a muchos usuarios los distintos modelos de enchufes que existen a escala internacional para poder acoplar pequeñas máquinas de uso personal: secadores de cabello.Las normas son un modelo. tal como el sistema operativo. entre muchos otros.. proporcionando también una interfaz para el usuario. La normalización de los productos es. por eso necesario que las empresas se preocupen por dar un mejor producto.Serie de inspecciones revisiones y pruebas utilizados a lo largo del proceso de Software para asegurarse de que cumple con los requisitos que le han sido asignados.Existe una constante preocupación de los investigadores tecnológicos en lo referente a la calidad de sus productos.. aplicaciones informáticas. ¿Por qué es necesaria la calidad? Porque la competencia es cada mayor. permite al resto de los programas funcionar adecuadamente.. que. Hoy en día las necesidades de buscar una solución a problemas complejos en el software ha ocasionado que las empresas dedicadas al desarrollo o mantenimiento de software sean rebasadas. En este sentido se utiliza como sinónimo de norma. El grado de materiales. GENERALIDADES DE LA CALIDAD Algunos DEFINICIONES que nos dan una idea de la aplicación de CALIDAD se dan a continuación:       Calidad.

 Revisar el proceso de desarrollo para observar si cumple los estándares adaptados.Conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa o simultáneamente) con un fin determinado. Prácticas que han funcionado tanto para el desarrollador como para el usuario. Procesos.  Planificar un proceso de desarrollo adaptando los diferentes estándares elegidos.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN      Beneficios de los Estándares Buenas prácticas de diseño.  Refinar la adaptación de los estándares:  Si no se cumplen las recomendaciones del estándar  Si el refinamiento del estándar elegido no es suficiente para desarrolladores y diseñadores  Si no se ha creado una versión del estándar adaptada al proyecto en desarrollo.  Aplicar las recomendaciones de los estándares. En la siguiente tabla se presenta algunos MODELOS QUE REGULAN LA CALIDAD 10 . Mejoras del proceso de diseño. Reducción del proceso de diseño mediante prueba y error. Este término tiene significados diferentes según la rama de la ciencia o la técnica en que se utilice.. 3. Utilización de los Estándares  Elegir qué estándar se va a seguir o a utilizar.

De forma concreta.ansi. con sede en Ginebra.USA HFES (http://www.org) . algunas Instituciones para el desarrollo de estándares son: Internacionales ISO (http://www.iec. comprendiendo que ISO es un organismo no gubernamental y no depende de ningún otro organismo internacional.unicei. en consonancia con el Acta Final de la Organización Mundial del Comercio.org) . que produce normas internacionales industriales y comerciales. con el propósito de facilitar el comercio.it/uni) . no tiene autoridad para imponer sus normas a ningún país. el intercambio de información y contribuir con normas comunes al desarrollo y a la transferencia de tecnologías. está compuesta por delegaciones gubernamentales y no gubernamentales subdivididos en una serie de subcomités encargados de desarrollar las guías que contribuirán al mejoramiento ambiental. La Organización Internacional de Normalización (ISO). por lo tanto.USA UNI (http://www. comercio y comunicación para todas las ramas industriales a excepción de la eléctrica y la electrónica.org) IEC – International Electrotechnical Commision (http://www.ch) Otros ANSI (http://www. Su función principal es la de buscar la estandarización de normas de productos y seguridad para las empresas u organizaciones a nivel internacional.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Característica PSP Inspecciones CMM Propósito Gerenciamiento y mejora de la calidad Prescriptiva Exacta Desarrolladores y gerentes Ciclo de vida del desarrollo Muy bajo Muy alta Semanas Integral Muy Alto Mejora de la calidad Mejora gerenciamiento Descriptiva Vaga Gerentes del Gerenciamiento de la calidad Descriptiva Vaga Gerentes Gerenciamiento proyectos Alto Baja Años Ambiguo Bajo de Aseguramiento de la Calidad Alto Baja Años Ambiguo Bajo Metodología Definición Audiencia Cobertura Costo Calidad Implementación Alcance Cuan Mensurable es Presciptiva Exacta Desarrolladores Verificación validación Bajo Alta Días Estrecho Alto y ISO 9000 INSTITUTOS QUE REGULAN LA CALIDAD La Organización Internacional para la Estandarización o ISO (del griego. 'igual'). La ISO es una red de los institutos de normas nacionales de 163 países. con una Secretaría Central en Ginebra (Suiza) que coordina el sistema. nacida tras la Segunda Guerra Mundial (23 de febrero de 1947). ἴσος (isos). es el organismo encargado de promover el desarrollo de normas internacionales de fabricación.Italia 11 . Dichas normas se conocen como normas ISO y su finalidad es la coordinación de las normas nacionales. Está compuesta por representantes de los organismos de normalización (ON) nacionales.hfes. Las normas desarrolladas por ISO son voluntarias.iso. sobre la base de un miembro por país.

se refiere a los atributos mensurables de un producto. 6. 2.(¿Podré reusar alguna parte del software?). El esfuerzo requerido para probar un programa con el fin de asegurar que realiza su función requerida. Costos de la calidad: • Prevención de futuros problemas. El grado en que un programa lleva a cabo sus funciones esperadas con la precisión requerida. PORTABILIDAD. Para ello nos basamos en tres ejes: 1. Algunos FACTORES y/o características que determinan la calidad del software son: 1.. La cantidad de recursos de computadora y de código requeridos por un programa para llevar a cabo sus funciones. EFICIENCIA. • Revisiones. El grado en que un programa satisface sus especificaciones y consigue los objetivos de la misión encomendada por el cliente.(¿Puedo probarlo?).. El esfuerzo requerido para localizar y arreglar un error en un programa. Requisitos implícitos..(¿Es muy grande el programa?). En adición a los costos de la falta de calidad y lo beneficios de tenerla. Esto va relacionado con el empaquetamiento y el alcance de las funciones que realiza el programa. 4. 2. • Recursos Humanos. los recursos que consumimos y los atributos de calidad del producto final. Cuando se habla de calidad. 3. • Resolución de quejas.. CORRECCIÓN. 3. 7. • Capacitación.(¿Podré usarlo en otra máquina?)..(¿Hace lo que quiero?). CONFIABILIDAD. 5.. • Imagen. El grado en que un programa (o parte de un programa) se puede reusar en otras aplicaciones. Costos de la no calidad: • Costos de corrección de errores.(¿Puedo corregirlo?). Tamaño del programa.(¿Se ejecutará en mi hardware lo mejor que pueda?). ROBUSTEZ. El esfuerzo requerido para transferir el programa desde un hardware y/o entorno de sistemas de software a otro). 12 . • Planificar. • Devolución.. USABILIDAD. 8. En el caso del software lo que se pretende es controlar la variación del proceso que se aplica para el desarrollo del mismo. Cumplir con estándares especificados.(¿Lo hace de forma fiable todo el tiempo?). FUNCIONALIDAD.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN CONCEPTOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE Mantener un proceso de desarrollo controlado es la clave para generar un producto de software de calidad. • Soporte. Concordancia con los requerimientos.. MANTENIBILIDAD.

) Es importante señalar que. También es necesario considerar mediciones en el proceso empleado para diseñar. Se verá enseguida que la ISO/IEC 14598 consta de seis partes que describen los requisitos del proceso de evaluación en tres situaciones diferentes:   Requisitos para desarrolladores (parte 3).CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 9. La ISO/IEC 14598 y el proceso para evaluar software (D. Figura. El estándar ISO/IEC 14598 es actualmente usado como base metodológica para la evaluación del producto software. 13 . explica la relación entre su serie y el modelo de calidad de la ISO/IEC 9126. contiene requisitos generales para la especificación y evaluación de la calidad del software. Además. Requisitos para compradores (parte 4). dichas empresas buscan la evaluación de sus procesos y productos de software. define los términos técnicos utilizados. En esto juega un papel relevante la ISO/IEC 14598. La evaluación independiente del producto software viene a ser insuficiente porque su calidad depende en gran medida del proceso empleado para su desarrollo. Los productos de software son solo una parte de la historia. De esta manera.. R. desarrollar. A continuación se trata una NORMA conocida como: EVALUACIÓN DEL PRODUCTO SOFTWARE: ISO 14598 Introducción Muchas empresas de desarrollo de software han reconocido la necesidad de mejorar el producto software. la serie de normas ISO/IEC 14598 proporciona un marco de trabajo para evaluar la calidad de todos los tipos de productos de software e indica los requisitos para los métodos de medición y para el proceso de evaluación. COMPATIBILIDAD. A. probar y controlar el producto. según sea la especialidad aplicada al software. Estos factores con los que cuenta la calidad en el desarrollo de software se encuentran dispersos en muchas normas y estándares. El esfuerzo requerido para acoplar un sistema a otro. y clarifica los conceptos generales. La ISO/IEC 14598 ofrece una visión general.(¿Podré hacerlo interactuar con otro sistema?). Este artículo presenta una exploración sobre el mismo. provee un marco de trabajo para evaluar la calidad de todos los tipos de productos de software y establece requisitos para métodos de medición y evaluación de los productos de software.

Establecer los requerimientos de evaluación. Compradores de productos de software. 3. a través de las siguientes 6 partes: I. ISO/IEC 14598 .CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN  Requisitos para evaluadores (parte 5). 2. Usuarios del producto y gente que hace su mantenimiento.      Audiencia destino para la NORMA ISO 14598 Proveedores de productos de software. Especificar la evaluación. Organizaciones encargadas de las evaluaciones del producto de software. 4. provee una visión general de las otras cinco partes y explica la relación entre la evaluación del producto software y el modelo de calidad definido en la ISO/IEC 9126. hace la presentación del proceso de evaluación desglosado en los siguientes pasos: 1. Ejecutar la evaluación. Esta norma 14598 define el proceso de evaluación y provee los requerimientos y las guías que conducen a evaluaciones de calidad. Alcance de la NORMA ISO 14598 El propósito de la evaluación de la calidad del software es hacer que tanto el desarrollo y la adquisición del software cumplan las expectativas y necesidades del usuario.Parte 1: Visión General Básicamente. 5. Adicionalmente. Planear la evaluación. La ISO/IEC 14598-1 está prevista para que se use conjuntamente con la ISO/IEC 9126-1. Véase la ilustración de a continuación 14 .

CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Figura ISO/IEC 14598 . Definición de objetivos organizacionales y de mejora. Fundamentalmente. Específicamente. Se enfoca en el uso de indicadores que pueden predecir la calidad final del producto midiendo los productos intermedios que se 15 . Identificación e implementación de técnicas de evaluación para software desarrollado y adquirido.) II. en esta parte. se planifican las mediciones y las actividades de evaluación. III. se incluye:        Preparación de las políticas. recopilación de datos y herramientas.Parte 3: El Proceso para Desarrolladores Esta parte provee los requerimientos y las recomendaciones para la evaluación del producto software cuando la evaluación es conducida en paralelo con el desarrollo y llevada a cabo por el desarrollador.Parte 2: Planificación y Gestión Esta parte contiene los requerimientos y las guías para las funciones de soporte tales como el planeamiento y gestión para la evaluación del producto del software. Entrenamiento en tecnología. R. A. ISO/IEC 14598 . Identificación de la tecnología. ISO/IEC 14598 .Parte 1: Visión General (D. Asignación de responsabilidades. Comparación y administración de mejoras dentro la organización.

razonables y alcanzables (dentro de los límites de tiempo). El resultado de esta revisión podría retroalimentar directamente el lanzamiento de futuros productos. el desarrollador realiza un mapeo de los requerimientos internos y externos de calidad. acciones de contingencia y de mejora. En cada fase del desarrollo debe procurarse lograr un montaje primeramente enfocado a las características internas y externas de calidad que definan la calidad global del producto y que puedan ser validadas por los resultados de las pruebas y la experiencia del usuario.Parte 6). deben ser definidas las etapas siguientes: Organización Los aspectos organizacionales de desarrollo y de soporte deben formar parte de todo el sistema de calidad y del plan de mediciones. designación de responsabilidades. una vez identificadas las características fundamentales de calidad y el marco de trabajo de mediciones. Los requerimientos de mediciones resultantes de esta fase deben ser un tipo de mapeo entre las especificaciones de requerimientos. para identificar costos versus costos.Parte 2. De esta manera. Esta parte cubre el planeamiento y evaluación de mediciones internas y externas con el fin de asegurar de que la calidad del producto sea incorporada en la fase de desarrollo. Véase la ISO/IEC 14598 . establecer la validez de las métricas usadas e identificar puntos en los cuales podrían obtenerse beneficios para proyectos futuros. En esta fase también deberá considerarse cómo los resultados de las mediciones impactarán en el desarrollo.Parte 4: El Proceso para Compradores Esta parte provee los requerimientos y las recomendaciones para que la evaluación del producto software sea conducida en función a los compradores que planean adquirir o re-usar un producto de software existente o predesarrollado. ISO/IEC 14598 . Especificaciones En esta fase. deben ser consideradas. se realizan análisis apropiados y se toman acciones necesarias. las mediciones actuales son recolectadas. uso de herramientas.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN desarrollan durante el ciclo de vida. por lo tanto. requerimientos externos de calidad. Y como etapa final del proyecto. Montaje (Build) y Pruebas Durante la etapa de montaje y pruebas. IV. Es de vital importancia verificar que el productor y las medidas de control requeridas sean técnicamente factibles. 16 . Todo esto puede enfocarse por proyecto o por producto. deberá ser conducida una revisión general para determinar la efectividad global del ejercicio de recolección. el plan incluirá: cronogramas. Planeamiento del Proyecto y Requerimientos de Calidad El desarrollo y el ciclo de vida de soporte deben ser establecidos y documentados durante el plan de calidad o en otros documentos. con relación a las especificaciones. Diseño y Planeamiento Los procedimientos requeridos para el análisis y recopilación de datos necesitan ser definidos. Entonces. La precisión de las mediciones y técnicas estadísticas deben ser especificadas (véase la ISO/IEC 14598 . bases de datos y entrenamiento especializado requerido. requerimientos internos correspondientes de calidad y atributos especificados junto a sus escalas de medición y valores objetivos que contribuyan a la cuantificación de la calidad del software.

debe considerarse:        Los requerimientos de calidad a ser evaluados correlacionados con la calidad en uso y Métricas externas con prioridades además de un umbral de aceptación definido. Especificación de la Evaluación Durante la redacción de las especificaciones. el diseño de la evaluación. limitaciones en las mediciones y cualquier compromiso con relación a los objetivos originales Conclusiones sobre los resultados de la evaluación pero también sobre los métodos empleados.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Los que adquieren el producto pueden comprar paquetes completos ya sea desarrollados según ciertas especificaciones o pre-desarrollados para un mercado más general. herramientas de desarrollo y personal. Ejecución de la Evaluación Aunque esta etapa podría ser simplemente un registro en un libro de seguimiento. Métodos y herramientas de reporte. Los compradores también podrían ser desarrolladores que desean integrar productos estándar en sus propios diseños de software. resultados y decisiones. o tratarse de desarrolladores buscando herramientas específicas de software. tienen un rol importante los requerimientos de evaluación. V. Diseño de la Evaluación El tipo de evaluación depende del tipo de software que está siendo evaluado. El alcance y lo que cubren los casos de prueba donde sean aplicables referencias a módulos de evaluación. En esta parte. Métodos de recolección de mediciones. El tiempo de la evaluación necesita ser consistente con los objetivos. podría tenerse la necesidad de incluir: Los resultados mismos y la trazabilidad del producto así como información de configuración. Requerimientos en costos y conocimientos. las especificaciones de evaluación. Los requerimientos para la calidad del software definidos en la ISO/IEC 9126 pueden ser usados como punto de partida pero otros aspectos como el costo y el de cumplimiento a regulaciones deberán ser también considerados. Problemas.Parte 5: El Proceso para Evaluadores Esta parte provee los requerimientos y recomendaciones para la evaluación del producto software cuando la evaluación es conducida por evaluadores independientes. información requerida y métodos de análisis. cuatro etapas son necesarias: Establecimiento de los Requerimientos El alcance de la evaluación necesita ser establecido. Cronograma de evaluación y arreglos de contingencia. Un plan de evaluación necesita considerar: Necesidades de acceso a la documentación del producto. procedimientos para la validación y estandarización sobre proyectos futuros. las actividades de evaluación y el reporte de evaluación. Registros de análisis. ISO/IEC 14598 . enfoques muy tempranos podrían no proporcionar una figura adecuada de la situación mientras que enfoques muy tardíos podrían ser muy limitados en su uso. hitos claves y criterio para decisiones de evaluación. Al respecto. Estas etapas son resumidas a continuación: 17 . Software bajo desarrollo puede ser abordado en puntos discretos durante el desarrollo o cuando esté completo.

3. La ISO/IEC 14598-6 trata también sobre los requerimientos de la documentación y divide a los Módulos de evaluación en los seis componentes siguientes: Introducción – Cubre el control del documento. 18 . La verificación de la especificación resultante frente a los requerimientos de evaluación.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Requerimientos de Evaluación Los requerimientos deberían adicionalmente definir: 1. la técnica de evaluación usada incluyendo cualquier teoría necesaria) y la aplicabilidad del módulo. Se tienen identificadas tres sub-actividades con relación a la especificación de la evaluación: El análisis de la descripción del producto. el nivel de la evaluación (tomando en cuenta la importancia de la característica. Los módulos de la evaluación son componentes claves de la ISO/IEC 14598-6 y son usados para proveer un formato consistente y repetible de reporte. Incluye métodos y técnicas de evaluación más las mediciones actuales resultantes de su aplicación. los Requerimientos técnicos y una razón para el módulo. Dichos módulos proveen: Visibilidad de la información necesitada para cuadrar con requerimientos específicos de calidad. 4. Documentación de las interfaces necesarias con herramientas de medición. Las actividades de medición coordinadas son una característica para una evaluación efectiva y un plan necesita proveer un cronograma de evaluación que provea al mismo tiempo información óptima cuando la evaluación sea conducida durante el desarrollo.Parte 6: Documentación de los Módulos de Evaluación Esta parte provee las guías para la documentación del módulo de evaluación. 2. ISO/IEC 14598 . Las calificaciones e independencia requeridas de un evaluador. Estos módulos representan la especificación del modelo de calidad y las correspondientes métricas internas y externas que serán aplicadas a una evaluación en particular. Los objetivos de evaluación y métodos de reporte. La extensión del la cobertura (o el alcance). En esta parte también se considera la administración efectiva de complejidades inherentes a las cuestiones de medición. Especificación de la Evaluación Las especificaciones adicionalmente deberían cubrir:        Definición del alcance y formato en las métricas empleadas identificando como deberán ser derivadas a partir de los requerimientos del producto. VI. La especificación de las mediciones a ser realizadas. las relaciones con otros documentos. La identificación de mediciones no determinísticas para asegurar que ciertos niveles de Frecuentabilidad y objetividad requeridos sean obtenidos. Alcance – Se relaciona con la características de calidad o sub-características que deberán ser alcanzadas. La identificación de métodos de correlación con relación a los resultados de las mediciones.

Normalmente. fecha. resumen y presentación del tema: “Calidad del Desarrollo del Software” deberá incluir todos los conceptos vistos en clase.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Referencias y Definiciones requeridas. se le pide que considere la siguiente forma de entrega: Elabore el documento en un archivo de Word estructurado de la siguiente manera: Portada Desarrollo Conclusión 5 10 Presenta todos los conceptos vistos en clase Organiza su información para tener la correcta relación de los conceptos Representa de manera correcta los conceptos 40 20 10 10 100 19 . Información sobre la interpretación de los resultados. Resultados de la Evaluación En esta etapa se tiene la generación del reporte de evaluación incluyendo una revisión independiente de los resultados de la evaluación. Nombre del alumno(os). Ortografía sin errores. Indicador o variable FORMA Datos generales Ortografía y redacción Presentación Aspectos generales CONTENIDO Presentación Desarrollo Representación TOTAL Descripción Cumple Sí No Porcentaje Asignatura. 5 Legible Portada con los datos generales. Nombre de la actividad. encabezado y pie de página a partir de la segunda página especificando el nombre de la carrera y nombre de la actividad. Instrucciones Desarrollar un mapa conceptual. matrícula. De igual manera. Entradas requeridas – Datos a ser recopilados y métricas a ser calculadas. Unidad temática. el reporte final será precedido por un borrador de tal manera que el personal involucrado con el producto pueda proveer una retroalimentación sobre la evaluación. nombre del profesor.

Identificó el instrumento más viable dependiendo Requisitos de del problema que se le planteo. CONOCIMIENTO (SABER) Requisitos de Identifica correctamente todos los instrumentos Información para obtener información.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Lista de Cotejo Práctica 1 Indicador o Descripción variable ACTITUD (SER) Puntualidad Entrega del trabajo tiempo y forma establecida El alumno participa activamente en su equipo Trabajo en aportando propuestas para la realización del equipo trabajo. Información Cumple Si No HABILIDAD (SABER HACER) El instrumento generado tiene el orden Estructura coherente para obtener la información necesaria El instrumento generado le permitió obtener toda Presentación la información necesaria para establecer sus requerimientos de información TOTAL Evaluación: La ausencia parcial o total de algún inciso tendrá una penalización acorde a señalada en cada inciso Observación: Evaluador (Nombre Firma) Porcentaje 5 5 20 20 20 30 100 la puntuación y 20 .

 Métricas para cada uno de los factores anteriores. determinado Ser P Autodidacta Analítico Habilidad para la comunicación oral y escrita Habilidad para el trabajo en equipo Proactivo Organizado Autodidacta Analítico Sistemático Habilidad para la comunicación oral y escrita Habilidad para el trabajo en equipo Resultado de aprendizaje: Elaborará un documento que contenga una tabla en donde relacione lo siguiente:  Factores y características que determinan la calidad en el desarrollo de software.  Explicar la forma en que inciden. 21 . para distinguir las que aplican al área de desarrollo del software Temas Saber Concepto de métrica. métricas asociadas a los para asegurar la calidad en factores y características que el desarrollo de software determinan la calidad del en un contexto software. Identificar métrica.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática Métricas de Software. Objetivo: El alumno identificará el concepto y los tipos de métricas. Saber hacer el concepto de Tipos de métricas de Identificar los tipos de Seleccionar las métricas calidad de software.

Establecer una línea de base para la estimación 5. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.1 Concepto de Métrica Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad. Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. y el esfuerzo aplicado. etc. y se explican a continuación: MÉTRICAS TÉCNICAS: Se centran en las características de software por ejemplo: la complejidad lógica. 3. fiabilidad. MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Se encuentra la funcionalidad. Tipos de Métricas de Calidad de Software Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y medidas indirectas:         Medidas Directas. Evaluar la productividad de la gente que desarrolla el producto. MÉTRICAS ORIENTADAS A LA PERSONA. si una organización de software mantiene registros sencillos. eficiencia. Evaluar los beneficios en términos de productividad y de calidad. Son las medidas que voy a hacer de mi personal que va hará el sistema. el tamaño de memoria y los defectos observados en un determinado periodo de tiempo. complejidad. MÉTRICAS ORIENTADAS AL TAMAÑO. complejidad. derivados del uso de nuevos métodos y herramientas de la ingeniería de software. velocidad de ejecución. Se centran en el rendimiento del proceso de la ingeniería del software. eficiencia. las líneas de código producidas. Mide la estructura del sistema.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 2. calidad. el grado de modularidad. Medidas Indirectas. las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto. el cómo está hecho. LAS MÉTRICAS DEL SOFTWARE son las que están relacionadas con el desarrollo del software como funcionalidad. Es decir que tan productivo va a ser el software que voy a diseñar. Razones para medir un producto: 1. el producto se mide para intentar aumentar su calidad. se puede crear una tabla de datos orientados al tamaño como se muestra en la siguiente figura: 22 . Ayudar a justificar el uso de nuevas herramientas o de formación adicional. 4. MÉTRICAS DE PRODUCTIVIDAD. En la mayoría de los desafíos técnicos. En el proceso de ingeniería se encuentran el costo. como el propio producto. facilidad de mantenimiento. El proceso para intentar mejorarlo. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Indicar la calidad del producto. 2. Son medidas directas al software y el proceso por el cual se desarrolla.

. Refiriéndonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12. En lugar de calcularlas las LDC. Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función. Otra información del proyecto 222-01 indica que se desarrollaron 365 páginas mientras que se encontraron 29 errores tras entregárselo al cliente. Son medidas indirectas del software y del proceso por el cual se desarrolla. las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa. diseño. Doc/ KLDC Costo = $/KLDC NOTA.persona-mes es el esfuerzo MÉTRICAS ORIENTADAS A LA FUNCIÓN. para cada proyecto un conjunto de métricas sencillas de productividad y calidad orientadas al tamaño.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN La tabla lista cada proyecto del desarrollo del software de los últimos años correspondientes. codificación y prueba. Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla incluyen todas las actividades de la ingeniería de software como son análisis. Los puntos de función se calculan rellenando la tabla como se muestra en la siguiente figura: “Calculo de métricas de punto de función” 23 . Se obtienen las siguientes formulas: Productividad = KLDC/persona-mes Calidad = errores/KLDC Documentación = pags.1 KLDC (miles de líneas de código) con un esfuerzo de 24 personas mes y un costo de 168 mil dólares. dentro del primer año de utilización también sabemos que trabajaron 3 personas en el desarrollo del proyecto. En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puede desarrollar. datos orientados al tamaño de c/u. Los puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas del dominio de información del software y valoraciones subjetivos de la complejidad del software.

Se cuenta cada petición por separado. Número de salida del usuario: se encuentra cada salida que proporciona al usuario información orientada a la aplicación. 4. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Se determinan 5 características del ámbito de la información y los cálculos aparecen en la posición apropiada de la tabla. Número de archivos: se cuenta cada archivo maestro lógico. No obstante la determinación de la complejidad es algo subjetivo. 2. mensajes de error. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada es denominada simple. Números de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicación.65 + 0. Para calcular los puntos de función se utiliza la siguiente relación: PF = CUENTA_TOTAL * [0. En este contexto las salidas se refieren a informes. Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las respuestas a las cuestiones señaladas de la siguiente tabla. Los elementos de datos individuales dentro de un informe se encuentran por separado. o sea una agrupación lógica de datos que puede ser una parte en una gran base de datos o un archivo independiente. 3. 24 . Números de peticiones al usuario: una petición está definida como una entrada interactiva que resulta de la generación de algún tipo de respuesta en forma de salida interactiva. Los valores del ámbito de información están definidos de la siguiente manera. 1. Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. pantalla. media o compleja.01 * SUM(fi)] Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos de datos. en cinta o discos que son utilizados para transmitir información a otro sistema. Evaluar cada factor en escala 0 a 5. 5.

Una vez calculado los puntos de función se usan de forma analógica a las LDC como medida de la productividad. Doc / PF La medida de puntos de función se diseño originalmente para ser utilizadas en aplicación de sistemas de información de gestión. 25 . La medida del punto de característica da cabida a aplicaciones cuya complejidad algorítmica es alta. Las aplicaciones de software de tiempo real de control de procesos y de sistemas que encontrados tienden a tener una complejidad algorítmica alta y por tanto fácilmente tratables por puntos de características. algunas aplicaciones se les denomina puntos de características. calidad y otros productos del software.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Los valores constantes de la ecuación anterior y los factores de peso aplicados en las encuestas de los ámbitos de información han sido determinados empíricamente. Productividad = PF / persona-mes Calidad = Errores / PF Costo = Dólares / PF Documentación = Pags. Sin embargo.

CALIDAD EN EL DESARROLLO DE SOFTWARE
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

Para calcular los puntos de características, nuevamente se cuentan y ponderan los valores del ámbito de
información, como se describió anteriormente. Además, las métricas de punto de característica tienen en cuenta
otra característica del software, los algoritmos.
Un algoritmo se define como un problema de complejidad computacional limitada que se incluye dentro de un
determinado programa de computadora. La inversión de una matriz, la decodificación de una cadena de bits o el
manejo de una interrupción son todo ellos ejemplos de algoritmos.
Para calcular los puntos de característica, se utiliza la siguiente tabla.

Se usa un único valor de peso para cada uno de los parámetros de medida y se calcula el valor del punto
característica global mediante la ecuación.
PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]
Debe tenerse en cuenta que los puntos de característica y los puntos de función representan lo mismo.
"funcionalidad o utilidad" en forma de software.
EJERCICIOS
1.- Métricas orientadas al tamaño

26

CALIDAD EN EL DESARROLLO DE SOFTWARE
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

Calcular:
a) Productividad = KLDC/esfuerzo
_ Hopital = ?
_ farmacia = ?
b) Calidad = Errores/KLDC
_ Hospital = ?
_ Farmacia = ?
c) Costo = $/KLDC
_ Hospital = ?
_ Farmacia = ?
d) Documentación = Pags. doc/KLDC
_ Hospital=?
_ Farmacia=?

2.- Métricas orientadas a la función
Se tiene un sistema el cual cuenta con 3 entradas de catálogo productos, proveedores y clientes. Una pantalla de la
elaboración de facturas, 4 tipos de reportes proporcionados tanto en pantalla como en papel. Estas
representaciones son: factura, lista de inventario, estado de cuenta de los clientes y estado de cuenta con los
proveedores. Además la entrada de factura tiene alrededor de 30 peticiones, el sistema genera alrededor de 30
archivos además de estar conectado a un lector óptico y una impresora. Calcula los puntos de función.

27

CALIDAD EN EL DESARROLLO DE SOFTWARE
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

Contestación de las preguntas basada en la complejidad media:
1=0; 2=5; 3=3; 4=5; 5=5;
6=5; 7=1; 8=5; 9=2; 10=2;
11=4; 12=0; 13=0; 14=4
· Fi =?
· PF = ?
· Productividad = ?
· Calidad = ?
· Costo = ?
· Documentación = ?
Nombre de la Práctica:

Elaboración de Formatos para Métricas

Unidad Temática:

I. Métricas de software

Tema:

Métricas de Software

Objetivo de la práctica:

El alumno, realizará diversos tipos de formatos con los cuales podrá
hacer una estimación de la métrica de los software desarrollados o a
desarrollar para poder dar una estimación de tiempo y dinero para la
gestión de este..
3 Hrs
Fecha:

Tiempo de la Práctica:
Descripción:

El alumno deberá diseñar y construir un instrumento que permita medir la cantidad de código de cada
uno de los procesos involucrados en el diseño y/o desarrollo de un sistema.
Antecedentes
En base a los diagramas mostrados anteriormente, diseñar un instrumento en el cual pueda englobar o
presentar todas y cada una de las características que este lleva.
Entregue una impresión de su “formato” con la descripción de cada uno de los campos que conforman a
su formato asi como presentar un ejemplo del llenado del mismo.
Materiales y Equipos:
Computadora

28

2. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos. de la duración cronológica del proyecto y del costo. sin embargo estos puntos son válidos también para sistemas pequeños. anticipado problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. Pero qué pasa si el proyecto es totalmente distinto entonces puede que la experiencia obtenida no sea lo suficiente. aunque cada una tiene sus puntos fuertes y sus puntos débiles. que dure aproximadamente lo mismo que el trabajo anterior. PLANEACIÓN DEL PROYECTO La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance. 2. Se han de establecer de antemano el ámbito del proyecto. Hace una descripción general del proyecto detalle de la organización del plan y resume el resto del documento. fase de diseño de alto nivel. Si un proyecto es bastante similar en tamaño y funciona un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo proyecto requiera aproximadamente la misma cantidad de esfuerzo. Panorama. 1. Una de las actividades cruciales del proceso de gestión del proyecto del software es la planificación. máximo 5 Analice y determine los requerimientos de información necesarios para la conformación del nuevo formato para determina la métrica de un sistema. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Cuestionario Referencias ESTIMACIÓN Es una pequeña planeación sobre qué es lo que va a ser mi proyecto. de la duración cronológica del esfuerzo humano requerido. etc. 1. Cuando se planifica un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido. Como bases para la realización de estimaciones se usan métricas del software de proyectos pasados. Asociada con cada fase debe de haber una fecha que 29 . 3. No se analizara la planeación que implica a la estimación de la necesidad de un sistema de software y la habilidad de producir tal sistema. todas tienen en común los siguientes atributos. El proyecto se desglosa en partes más pequeñas que se estiman individualmente. Se han desarrollado varias técnicas de estimación para el desarrollo de software. fase de diseño de bajo nivel. Se supondrá que el administrador del proyecto es responsable de la planeación desde la definición de requisitos hasta la entrega del sistema terminado.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Procedimiento: Organizarse en equipos de 3 personas. Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programación. Plan de fases. la asignación de prioridad al proceso de su producción.

4. Plan de recursos y entregas. Se establece un bosquejo de los posibles tipos de mantenimiento que se tienen que dar para futuras versiones del sistema. marcas de logros y todos los artículos que deben entrar bajo contrato. 8. Se resume los detalles críticos del proyecto como fechas programadas. 7. Se hace un esbozo general de las pruebas y de las herramientas. 9.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN especifique cuando se debe terminar estas fases y una indicación de como se pueden solapar las distintas fases del proyecto. Se analiza cómo se informa del estado del proyecto y se definen las revisiones formales asociadas con el avance de proyecto. 30 . Se establece un mecanismo para aplicar las modificaciones que se requieran a medida que se desarrolle el sistema. 3. Plan de mantenimiento. procedimientos y responsabilidades para realizar las pruebas del sistema. 10. Se describe la preparación de los programadores que participan en el proyecto y las instrucciones a los usuarios para la utilización del sistema que se les entregue. Plan de control de modificaciones. Plan de pruebas. Su función es definir y controlar la documentación asociada con el proyecto. Se muestra en donde encontrar las cosas dentro del plan. Se describe el procedimiento para instalar el sistema en la localidad del usuario. Plan de instalación y operación. 5. Plan de organización. Plan de revisión e informes. Plan de capacitación. 12. Índice. 6. Se definen las responsabilidades específicas de los grupos que intervienen en el proyecto. 11. Plan de documentación.

2010 Procedimiento: Organizarse en equipos de 3 personas.. realizará un diagrama de grant (planeador) en el cual represente todas y cada una de las tareas que están involucradas en el proyecto. Materiales y Equipos: Computadora Ms Office 97. Métricas de software Tema: Planeación de proyectos Objetivo de la práctica: El alumno. 2 Hrs Fecha: Tiempo de la Práctica: Descripción: El alumno deberá diseñar y construir un planeador de actividades en la cual muestre cada una de las tareas involucradas en su proyecto o en cualquier proyecto haciendo hincapié a las fechas de inicio y culminación de las actividades así como las herramientas necesarias para el desarrollo de las mismas y el encargado o responsable de quien realiza dicha tarea.2003.2007. Entregue una impresión de su “formato” con la las diferentes tareas principales y sub tareas que están involucradas marcando o delimitando fechas de inicio. fechas finales y responsable de esa tarea. Cuestionario Referencias 31 . discernir las distintas tareas o actividades que se deben de desarrollar en su proyecto. Antecedentes Realizar una lista de actividades que se deben de desarrollar para la gestión de un programa u otra actividad. plasmarlas en una hoja de Excel y llevar acabo las anotaciones necesarias.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Nombre de la Práctica: Elaboración de un plan de trabajo (gráfica de gant) Unidad Temática: I. Dividir en sub-actividades cada una de las tareas o actividades primarias indicando o marcando intervalos de tiempo específicos a estas Una vez hecho lo anterior deberán de nombrar a un responsable el cual tenga el control y sepa la dirección de proyecto a emprender o desarrollar. máximo 5 En base a su proyecto.

Mala elección de recursos (hardware. No hacer un análisis costo beneficio.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ERRORES CLASICOS EN UN PROYECTO DE SOFTWARE 1. Desconocer los usuarios que trabajan con el sistema. 7. 6. Una mala planeación. Desconocer el ambiente de trabajo de los usuarios. 32 . No tener una negociación (documento. 4. Mal análisis en los requerimientos. humanos). 3. 5. contrato) con el cliente. 2. software.

33 . medir sus tiempos. tipificar sus defectos y comparar su desempeño con su estimación inicial. para medir su desempeño. Software (PSP) Organizado Sistemático Plantillas PSP Organizado Analítico Sistemático Disciplinado Identificar los formatos y Determinar su nivel procedimientos para la personal de desarrollo al medición del PSP.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática III Proceso Personal de Desarrollo de Software Objetivo:El alumno identificará el Proceso Personal de Software. Temas Saber Saber hacer Ser Elementos del Identificar los elementos del Proceso Personal de PSP. Resultado de aprendizaje:  Elaborará un documento que contenga las plantillas del PSP Nivel 0 para al menos 3 casos de estudio.

los ingenieros deben planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un proceso bien definido para realizar de la mejor manera la planeación del trabajo. 7. Para desarrollar productos de calidad. Principios PSP   La calidad de un sistema software está condicionada por la calidad del peor de sus componentes. Está condicionada por tu: 1. Para hacer un trabajo de ingeniería de software de la manera correcta. Como todo profesional software deberías conocer tu propio rendimiento. 6. 5. disciplina 3. Deberías aprender de tus variaciones de tu rendimiento. El diseño de PSP se basa en los siguientes principios de planeación y de calidad [HUMPHREY. para ser más precisos. La calidad de un componente software está condicionada por el individuo que lo desarrolló. Para que los desarrolladores lleguen a entender su funcionamiento de manera personal. Desarrollo de módulos de programas. compromiso 4. deben analizar los resultados de cada trabajo y utilizar estos resultados para mejorar sus procesos personales Estructura del PSP El PSP se aplica en tareas personales estructuradas: 1.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Elementos del Proceso Personal de Software (PSP) ¿Qué es el PSP? Un PSP es un proceso personal desarrollar software que tiene:  pasos definidos  formularios  estándares  Un PSP es un marco de trabajo de medición y análisis que te ayuda a caracterizar tu proceso. los defectos que inyectan y remueven de cada proyecto y finalmente medir los diferentes tamaños de los productos que llegan a producir. seguir y analizar tu trabajo. Deberías medir. los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos.  Es también un procedimiento definido para ayudarte a mejorar tu rendimiento. los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales. Finalmente. Deberías incorporar esas lecciones a tu manera personal de hacer. 95]      Cada ingeniero es esencialmente diferente. 34 . conocimiento 2. deben medir el tiempo que pasan en cada proceso.

scripts. Comenzando con los requerimientos. medir el tamaño del programa.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 2. deben entregar el producto finalizado y el formulario de sumario del plan completado. Escribes uno o dos pequeños programas en cada paso. etc. Elementos del proceso 35 . Es un proceso de Nivel 5 para los individuos y es un prerrequisito para el TSP PSP se introduce con siete pasos compatibles. Al finalizar. los métodos de PSP son presentados en una serie de siete versiones de procesos. deben ir registrando los tiempos dedicados y los datos de defectos en los logs de tiempos y defectos. 5. Realización de revisiones o pruebas. 8. los logs y formularios proveen templates para registrar y almacenar datos. 9. El PSP se puede extender al desarrollo de sistemas software de gran tamaño. Debido a que generalmente ciertos métodos de PSP no son utilizados por los desarrolladores. el primer paso en el proceso de PSP es la planificación. Existe un script de planificación que sirve de guía y un resumen del plan para registrar todos los datos del mismo. y los standards guían a los desarrolladores a mientras hacen el trabajo. Los usas y analizas para mejorar tu trabajo. Los scripts de proceso definen los pasos de cada parte del proceso. 3. Al final de la tarea. formularios. 4. Escritura de documentación. 6. Recoges y analizas los datos de tu trabajo. Estas versiones son denominadas como PSP0 a PSP3. 10. durante la fase de postmortem (PM). e ingresar esos datos en el formulario de sumario del plan. y standards. 7. Mientras los desarrolladores van siguiendo el lineamiento de trabajo sugerido por los scripts. Definición de requisitos o procesos. deben resumir los datos de tiempo y defectos. Cada versión tiene un mismo conjunto de logs.

CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Está construido en un formato simple de utilizar con instrucciones simples y precisas. definido y personal. Recoge datos sobre tu trabajo: 3. Proceso (punto de partida) o PSP0 es un proceso sencillo. 1. PSP 3 Proceso Desarr Personal PSP 2 Calidad Cíclico ollo Personal Revisión del 1código PSP Cíclico Revisión Planificació Estimación del diseño n Personal del Tamaño PSP 0 de Medición Informe Personal pruebas Proces PSP O. Utiliza tus métodos actuales de diseño y desarrollo. Proporciona un informe resumen 36 . defectos encontrados en compilación y pruebas 5. 2. en realidad se parecen más a checklists que a tutoriales. Estos no incluyen los materiales instructivos que serían necesarios para usuarios no entrenados. los cuales ellos conocen (mediante la asistencia a cursos de capacitación en PSP o a través de bibliografía introductoria en el uso de PSP). Si bien los scripts describen qué hacer. tiempo gastado por fase 4. El propósito de los scripts es el de guiar a los desarrolladores en el uso consistente de los procesos.

PSP3. De todas formas sigue enfocado en el individuo y no trata los problemas de comunicación y coordinación que son una parte importante del desarrollo de sistemas de gran escala. Esencialmente. El PIP provee una manera estructurada de registrar problemas. cuando han terminado que es lo que deben haber obtenido. Los desarrolladores analizan los defectos que encuentran en los primeros programas y usan estos datos para establecer checklists de revisión que estén hechos a medida de su experiencia de defectos personales.1 Se pasa a PSP0.1 se introduce planeamiento de cronograma y seguimiento del proyecto.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 6. PSP0 es el proceso habitual con el que los desarrolladores escriben software. PSP3 presenta métodos para ser usados por individuos en la realización de programas de gran escala. El proceso de diseño es contemplado en PSP2. 37 .  En PSP1. experiencias y sugerencias para mejorar. Los desarrolladores son enseñados a:  Entender la relación entre el tamaño de los programas que escriben y el tiempo que les toma desarrollarlos. Esto permite medir el progreso y define los cimientos para mejorar.  Preparar un plan ordenado para realizar su trabajo  Establecer una base para realizar un seguimiento de su trabajo.1.1 también mejora las mediciones para contar separadamente métodos y procedimientos. PSP demuestra el valor de estos métodos en el nivel personal. PSP 2. mejorado para proveer mediciones PSP 0.  Mientras que la importancia de estas técnicas en proyectos grandes es comprendida. Los programadores por lo general se avergüenzan de sus errores. pocos desarrolladores las aplican a su trabajo personal. El primer paso agrega estimaciones de tamaño y recursos y un reporte de prueba.1 agregando un estándar de código.  PSP1 Planeación personal  PSP1 le agrega pasos de planeamiento a PSP0.  Aprender a realizar compromisos que puedan cumplir. El paso inicial en PSP consiste en establecer una base que incluya mediciones y un formato de reportes. Estas revisiones ayudan a encontrar defectos de manera temprana y a ver los beneficios que esto proporciona. mediciones de tamaño y el denominado PIP (Process Improvement Proposal). Se establece un criterio de completitud de diseño y se examinan varias técnicas de verificación y consistencia de diseño. El hecho de que la mayoría de los errores sean tipográficos o errores tontos hace que los desarrolladores sientan que pueden mejorar haciendo más esfuerzo.  PSP0. PSP2 agrega diseño personal y revisiones de código a PSP1. El objetivo no es decirle a los desarrolladores como diseñar sino orientar el criterio para la finalización del diseño. Proceso cíclico personal Hasta este punto PSP se concentró en el proceso lineal para construcción de pequeños programas. es decir. CALIDAD PERSONAL Un objetivo de PSP es ayudar a los desarrolladores a lidiar de manera realista y objetiva con los defectos que introducen.

Si un incremento anterior tiene muchos defectos. De esta manera los desarrolladores pueden concentrarse en la verificación de la calidad del último incremento sin preocuparse por defectos en ciclos anteriores. deben recolectar datos de los tiempos que dedican a cada fase del proceso. Recolección de datos. 3. Esta es una razón para enfatizar revisiones de diseño y código en los pasos anteriores de PSP. codificación. y los tamaños de los productos desarrollados en líneas de código (LOC). La primera construcción consiste en un módulo base o kernel que es ampliado en ciclos iterativos.2 Plantillas PSP En esta sección se observan algunos formatos y procedimientos para la medición del PSP. En PSP. Estos programas son entonces diseñados para ser desarrollados en pasos incrementales. incluyendo diseño. de los tamaños de los productos que producen. compilación y pruebas. los desarrolladores utilizan información para monitorear su trabajo. Para esto. 38 . Las medidas básicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso. y de la calidad de esos productos. la cual los ayuda a hacer mejores planes. la prueba será más compleja y los beneficios de escalar PSP se pierden. los defectos introducidos y encontrados en cada fase. Especific aciones Requerimi entos Y Planificaci Diseño ón de Alto nivel Repaso al Diseño De Alto nivel Desarrollo Cíclico Postmorte m Ciclo específico Diseño detallado Y Repaso del diseño Desarrollo de las pruebas Y repaso Implementación Y Repaso del código Compilación Pruebas Integració n Pruebas del sistema Uso Valorar de nuevo Y Reciclar El proceso cíclico PSP3 puede ser un elemento efectivo en un proceso de desarrollo de gran escala solo si cada incremento sucesivo de software es de alta calidad.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Para escalar PSP2 a proyectos más grandes la estrategia consiste en subdividir el proceso personal de desarrollo de grandes programas en elementos en la escala de PSP2. En cada iteración se utiliza un PSP2 completo.

Todos estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los ingenieros usan como guía en su trabajo. defectos y tamaño Un programa probado Un resumen del Plan de Proyectos con los datos estimados y actuales Las tablas de Registro de Tiempos y Defectos Rellenos 39 . Las principales medidas son:  Tamaño tiempo de estimación de errores  Coste de realización  Defectos producidos y corregidos por hora  Producción del proceso  Valoración y calidad del coste de los fallos (COQ)  Valoración del rango de fallos (A/FR)  Elementos  un guión de proceso  un formulario resumen de plan proyecto  un registro tiempo  un registro de defectos  un estándar de tipos defecto No de Fase Propósito Guiarte en el desarrollo de programas a nivel de módulo Entradas Necesarias Descripción del problema Formulario de Resumen del plan del Proyecto PSPO Tablas de Registro de Tiempos y Defectos Cronometro (opcional) Producir u obtener los requisitos Estimar las LOC necesarias Estimar el tiempo de desarrollo necesario Indicar los datos del plan en el Resumen del Plan de Proyecto Completar el Log de Registro de Tiempos Diseñar el programa Implementar el diseño Compilar el programa y corregir todos los defectos encontrados Completar la Tabla de Registro de Tiempos 1 Planificación 2 Desarrollo 3 Post-mortem Criterios salida de Completar el Resumen del plan del Proyecto con los datos actuales de tiempo.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Estos datos se recopilan en cada fase del proceso y se resumen a la terminación del proyecto.

Para programa 1A. A la fecha %: Indicar el porcentaje sobre el total defectos inyectados y eliminados hasta hoy en cada fase. Registra los defectos en el Log de defectos y tiempos por fase en el Log de tiempos. Logs de Registro de tiempo        Encabezado: Indicar nombre. Encabezado: Nombre. Desarrollo: Desarrollar el producto utilizando tus métodos actuales. Indica tu mejor estimación del tiempo total que tendrá el desarrollo. instructor. con los tiempos gastados y defectos encontrados e inyectados en cada fase. Tiempo de interrupción: Indicar el tiempo perdido por interrupciones desde el periodo de arranque a parada. A la fecha % : Indica el porcentaje del total tiempo hasta hoy que se gasto en cada fase. lenguaje. fecha. Tiempo: A la fecha: Indica el tiempo total gastado en cada fase hasta hoy. Compilación: Compila hasta que esté libre defectos. / Use el nombre de cada fase. 40 . Prueba: Prueba el programa y corrige todos los defectos. Defectos introducidos y removidos: Indicar el número actual de defectos inyectados y eliminados en cada fase. Fase: Anotar la fase en la que estás trabajando. Post-mortem: Completar el resumen del plan proyecto. aun cuando tú no has terminado esa fase. usando tus métodos de diseño actuales.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN                 Planificación: Estimar tiempo de desarrollo. Inicio: Indicar el tiempo en minutos cuando empiezas una fase del proyecto Fin: Indicar el tiempo en minutos cuando tu paraste tu trabajo en una fase del proyecto. son los defectos inyectados y eliminados en el programa 1A. programa. Fecha: Indicar la fecha actual. fecha. Para el programa 1A. Defectos: A la fecha: Indica el total de defectos inyectados y eliminados en cada fase hasta hoy. Codificación: Implementa el programa. Tiempo Delta time: Indicar el tiempo transcurrido desde el inicio al tiempo de parada descontado el tiempo de interrupción. Diseño: Diseñar el programa. es el tiempo gastado en el programa 1A. Tamaño del Programa: Plan. instructor y número de programa. Indica el tiempo actual en minutos gastado en cada fase. Actual.

Para realizar un seguimiento de la variación del tamaño de un programa durante el desarrollo. se mide el tamaño real obtenido. para que esta información sea útil. Cualquier aspecto significativo que afecte a tu trabajo Tamaño El tiempo en desarrollar un producto se encuentra altamente determinado por el tamaño del mismo. Logs de Registro de defectos El estándar de tipos de defectos proporciona un conjunto general de categorías de defectos. esto se debe a que las LOC modificadas pueden representarse por LOC eliminadas y agregadas. los desarrolladores primero estiman el tamaño de los productos que planean desarrollar. el tamaño de las mediciones debe corresponderse con el tiempo de desarrollo del producto. En PSP. el cálculo es el siguiente: Total LOC = Base – Eliminadas + Agregadas + Reutilización Las LOC modificadas y de “nueva reutilización” no son incluidas en el total. y las LOC de “nuevo reutilización” ya se encuentran contabilizadas en las LOC agregadas. para medir el tamaño total de un producto. A continuación se muestra un ejemplo: 41 . al finalizar el producto. Aunque tú puedes reemplazar este estándar por el tuyo propio. Luego. Sin embargo. Esta información permite a los desarrolladores realizar a futuro una estimación de tamaños más precisa. independientemente del código fuente). sin realizar ninguna modificación. Estos estándares se utilizaron para llenar los logs de Registro de defectos. el tamaño se mide en Líneas de Código (LOC). En PSP. Estas son:          Base (son los LOC iniciales del producto original) Agregadas (es el código agregado a un programa base existente) Modificadas (es el código base que es modificado en un programa existente) Eliminadas (es el código base que es eliminado de un programa existente) Reutilización (es el código tomado de una librería u utilizado. La tarea que estás haciendo.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN  Comentarios: Descripción de la interrupción. en un nuevo programa) Nueva Reutilización (esta medida cuenta los LOC que se agregan a una librería) Total (es tamaño total del programa. Luego. es deseable que te manejes con estas definiciones simples de tipos hasta que tengas datos que te puedan guiar en las modificaciones. se deben considerar varias categorías de LOC.

Finalmente. Rendimiento 42 . Fecha: Indicar la fecha cuando encontraste y corregiste el defecto. Defecto Arreglado: Si este defecto fue inyectado durante la corrección de otro defecto. PSP provee una serie de mediciones de calidad que ayudan a los desarrolladores a examinar la calidad de sus programas desde varias perspectivas. mejorado o utilizado de manera adecuada. Tipo: Indicar el tipo de defecto a partir del estándar de tipos de defectos. METRICAS DEL PSP Con datos de tamaño. existen muchas formas de medir. fecha. Como ninguna medición por sí sola puede indicar adecuadamente la calidad de un programa. Comienza cada proyecto con 1. Tiempo de Arreglo: Indicar el tiempo que tomaste para corregir el defecto. resulta ser más rápido y más eficaz. indicar el número de ese defecto o una X si lo desconoces. Índice de revisión 3. Las principales mediciones de calidad son: 1. Mientras esto puede parecer como una manera difícil de limpiar un programa defectuoso. el panorama que provee la utilización de todas estas mediciones es generalmente un indicador confiable de calidad. Densidad de defectos 2. y manejar la calidad de un programa. Tú puedes dar el tiempo exacto o usar tu mejor estimación. la manera más eficaz de encontrar y arreglar defectos es repasando el código fuente del programa personalmente. y numero de programa. tiempo y defectos. Nota: Un defecto es cualquier cosa en el programa que debe ser cambiado para que sea desarrollado. Un método para realizar revisiones de código es la utilización de guías en las que se determina cuales son los defectos que más frecuentemente se inyectan. Introducido: Indicar la fase donde tu juzgas que el defecto fue inyectado o introducido. Índices de tiempo de desarrollo 4. Índices de defectos 5. evaluar.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN         Encabezado: Indicar el nombre. instructor. Número: Indicar un número único para este defecto. Eliminado: Indicar la fase en la que encontraste y eliminaste el defecto.

2 10.14 12.0 Def/Hora 43 .8 100 Para Fecha % 1 5 5 4 21 16.32 10.0 84.79 106.92 4.4 96.5 6.2 43.47 94.90 58 72 41 426 243 Plan 47 258 Plan 18 35 149 20 24 64 33 343 Actual 22 24 93 37 4 8 41 229 Para Fecha 88 151 637 111 92 240 160 1479 Actual Para Fecha Para Fecha % 6.0 10.2 16. 8.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 6. 7. Defectos por hora Efectividad de remoción de defectos Evaluación del índice de fallas Resumen del registro de Métricas Nombre: Programa Profesor Resumen Minutos/LOC LOC/Hora Defectos/KLOC Rendimiento A/FR Tamaño Programa (LOC): Total nuevo & Cambiado Tamaño Máximo Tamaño Mínimo Tiempo en fase (min.73 10.87 5.0 6 5 25 100.1 7.) Planing Diseño Código Revisión código Compilación Test Postmortem Total Tiempo Máximo Tiempo Mínimo Introducción de defectos Planing Diseño Código Revisión código Compilación Test Total Fecha: 18/10/96 Programa # 13 Lenguaje: C++ Plan Actual a la Fecha 5.

CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática IV Técnicas de Estimación Objetivo: El alumno empleará las técnicas de estimación para determinar el tamaño del software y el esfuerzo requerido. Temas Puntos de función Saber Saber hacer Ser Identificar el procedimiento Calcular la cuenta ajustada Organizado para la estimación de los de puntos de función para Analítico puntos de función estimar el tamaño del Sistemático software.  Estimación del esfuerzo por casos de uso. Resultado de aprendizaje: Elaborará un documento con base en un caso de estudio que contenga lo siguiente:  Estimación de la complejidad por puntos de función. Puntos de caso de Identificar el procedimiento Calcular el esfuerzo Organizado uso para la estimación de esfuerzo requerido para el desarrollo Analítico utilizando casos de uso de software con base en Sistemático casos de uso. 44 .

Si voy manejando.. Cuando como estimo si con esa comida voy a engordar o no. ALGUNAS TÉCNICAS de estimación se presentan a continuación:      Por rangos. es imprescindible disponer de una medida fiable y comprensible del tamaño de lo que se construye. en automático. en taxi o en colectivo.. o realizar estimaciones de coste y duración. En otro ejemplo. que no resultan aceptables como una buena práctica profesional.2 del PIB. porque: Su resultado depende fuertemente del entorno técnico y el lenguaje de programación utilizado. En la vida real estimamos todo el día. No resultan significativas al usuario ni a la dirección. número de programas fuente. estimo si freno o no. si se compra un camión..Diariamente usamos una gran cantidad de operaciones.1 Puntos de Función Lo relevante es la funcionalidad. Varía en función de la pericia de cada programador y del uso de normas y metodologías. si se compra un edificio. o de las capacidades requeridas de los ingenieros y de la empresa. q no nos damos cuenta. o técnicas similares. elige varios de referencia. Por ejemplo. Cuando se trata de establecer métricas de productividad y calidad en la construcción de software. Por analogía. Es conocido que grandes proyectos han fracasado al no estar a tiempo o dentro de presupuesto por una mala estimación de esfuerzo o duración.Por ejemplo Número de bytes. Tradicionalmente se ha medido el tamaño del software mediante distintas métricas: recuento de las líneas de código (LOC). Con estos niveles no es de extrañarnos que a nivel industria tengamos poco avance en temas como las métricas para SW.. LOC y casos de uso. dependiendo del lugar a dónde vayamos. de alguna forma se adquirió la capacidad de transportar mercancías y con un tamaño de metros cúbicos por viaje. Por recomposición.Los procesos se comparan contra otros proyectos. Este rezago es aún mayor en términos de gasto en software. Juicio de los expertos. Estimamos cuando cruzamos la calle. a las empresas lo que les interesa es la capacidad de hacer algo con lo que compran.En lugar de elegir un valor. como en cualquier inversión. 4. si nos da tiempo o no. entonces se adquirió la capacidad de 45 . En primera instancia lo relevante es qué tanto requiero transportar por viaje. que es 6 veces inferior al promedio mundial y 9 veces menos que el de EUA. NOTA. Estimamos el tiempo que necesitamos si vamos en nuestro auto.Da su opinión gente con más experiencia.. es decir. Calibración de procesos.La tarea se descompone en procesos más pequeños.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN México tiene un nivel de gasto en tecnologías de la información y comunicaciones (TIC) de 3. ubicándose en el lugar 50 a nivel mundial. hasta comparamos la velocidad del auto contra la velocidad de nosotros.. por ejemplo:      Cuando elegimos cuánto dinero llevaremos para las actividades de ese día.

Pero más que eso. Sin embargo. Los parámetros y acotaciones se toman como referencia para que una serie sea considerada válida. A continuación se presentan algunos TIPS para comprender este tema: Se debe cumplir con medidas y evitar desviaciones en una estimación. Algunos ejemplos de las herramientas usadas para medir son: pie de rey. de IBM. Viéndolo de otro punto de vista: Los Puntos de Función son una métrica que permite traducir en un número el tamaño de la funcionalidad que brinda un producto de software desde el punto de vista del usuario. tal vez lo relevante de esta característica es que una vez establecida la funcionalidad que requiero. el costo de esta simplicidad es que la métrica no es muy sensible a consideraciones muy detalladas. Una ventaja es que puedo establecer el tamaño de un SW que tal vez llegue a tener miles de líneas de código en pocas horas. El Costo de producir software es entre el 20 y 25% del costo total de la aplicación del software La métrica del punto función es un método utilizado en ingeniería del software para medir el tamaño del software. etc.. – Desde su concepción.– Si nos basamos en líneas de código (en la tecnología) vamos a obtener resultados no comparables. INDEPENDIENTE DE LA TECNOLOGÍA. En SW no tiene por qué ser distinto. como lo sería por ejemplo. micrómetro de interiores. debo escoger la tecnología que me haga más productivo para obtener tal funcionalidad. micrómetro de exteriores. TOLERANCIA. 2. CARACTERÍSTICAS de la funcionalidad 1. lo primero que debe evaluarse es qué nuevas capacidades estoy adquiriendo. desde el diseño inicial hasta la explotación y mantenimiento. 46 . al adquirir un paquete o al desarrollar una aplicación. este tipo de métrica se planteó que no requiriera grandes esfuerzos para obtener una medida. la complejidad de fórmulas matemáticas. y también ser útil en cualquiera de las fases de vida del software.Es un aspecto importante definida como la desviación máxima permitida en una pieza o proceso.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN disponer de un espacio de X metros cuadrados distribuido en pisos. Depende del fin para lo que fue diseñada la pieza o el proceso. a través de una suma ponderada de las características del producto. Las métricas o técnicas aseguran que todas las piezas cumplan con parámetros de un plano u hoja de procesos. SIMPLE. Estas capacidades o funcionalidad estarán en términos de qué transacciones puedo realizar de forma automatizada y qué grupos de datos puedo guardar. sonda de profundidad. A mayor CALIDAD menor tolerancia. Fue definida por Allan Albrecht. Los dos principales determinantes para estimar el esfuerzo son: el tamaño de lo que se requiere y la productividad de quien lo va a hacer. lo relevante es cuánto espacio necesita la empresa o institución. en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software.

antes de cualquier evaluación técnica. El alcance de la medición define la funcionalidad que va a ser incluida en una medición específica y puede abarcar más de una aplicación. Determinar el tipo de conteo Este paso consiste en definir el tipo de conteo entre desarrollo. Otro punto muy importante con esta característica es que puedo establecer un tamaño desde que tengo los requerimientos y no necesito esperar a terminar el proyecto para saber de qué tamaño va a ser. El método se basa principalmente en la identificación de los componentes del sistema informático en términos de transacciones y grupos de datos lógicos que son relevantes para el usuario en su negocio. A cada uno de estos componentes les asigna un número de puntos por función basándose en el tipo de componente y su complejidad. No es suficiente contar con una métrica. Esta es una forma de determinar el objetivo del conteo. Por lo que se creó: ISO/IEC 14143 – Information Technology – Software Measurement – Functional Size Measurement. CONSISTENCIA. Este estándar define los conceptos de una métrica de tamaño basada en la funcionalidad y las características que debe cumplir un método para poder estar homologado al estándar y ser considerado una medida del tamaño de la funcionalidad.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 3. sin tener que ser un experto en sistemas. El ajuste es un paso final basándose en las características generales de todo el sistema informático que se está contando.– Los resultados obtenidos entre diferentes personas o en proyectos distintos deben ser consistentes. Paso 2. El propósito de una medición consiste en dar una respuesta a un problema de negocio. sino que sea estándar para así poderla usar entre empresas o para tener indicadores a nivel industria que todos puedan entender y operar. BASADA EN LOS REQUERIMIENTOS DEL USUARIO. Se puede identificar el procedimiento para la estimación de los puntos de función de la siguiente manera: Paso 1. mantenimiento o de una aplicación ya instalada. 4. Identificar los alcances de la medición y los límites de la aplicación. y la sumatoria de esto nos da los puntos de función sin ajustar.– Ver qué nuevas capacidades voy a obtener con el nuevo SW. 47 . ENFOQUE EN LA FUNCIONALIDAD PROPORCIONADA. 5.– Esta característica ayuda a que el usuario pueda entender el significado e implicaciones del tamaño del SW.

en el que la entrada no produce ningún cambio en ningún archivo y la salida no contiene información derivada. Paso 4. Paso 3. medio o alto) considerando principalmente el número de datos. Se distinguen dos tipos de funciones de datos: Archivo Lógico Interno – es un grupo de datos relacionados que el usuario identifica. Contar las funciones transaccionales. Consulta Externa – es un proceso cuyo propósito principal es presentar información al usuario leída de uno o más grupos de datos. Este paso consiste en identificar y contar la capacidad de realizar operaciones. Se distinguen tres tipos de funciones transaccionales: Entrada Externa – es un proceso cuyo propósito principal es mantener uno más archivos lógicos internos.es un grupo de datos relacionados y referenciados pero no mantenido por alguna transacción dentro del conteo. EIF: Grupos de datos que se mantienen externamente. Contar las funciones de datos Este paso consiste en identificar y contar la capacidad de almacenamiento de los datos. Salida Externa – es un proceso cuyo propósito principal es presentar información al usuario mediante un proceso lógico diferente al de sólo recuperar los datos. EQ: Procesos consistentes en la combinación de una entrada y una salida. 48 .CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Componentes: EI: Procesos en los que se introducen datos y que suponen la actualización de cualquier archivo interno. ILF: Grupos de datos relacionados entre sí internos al sistema. Archivo de Interfaz Externo . A cada componente identificado se le asigna una complejidad (bajo. EO: Procesos en los que se envía datos al exterior de la aplicación. cuyo propósito principal es almacenar datos mantenidos a través de alguna transacción que se está considerando en el conteo.

Entradas al Sistema (EI) No. Este paso consiste en sumar el número de componentes de cada tipo conforme a la complejidad asignada y utilizar la siguiente tabla para obtener el total. Ficheros Externos: No se utilizaron almacenes externos de datos. 2 entradas de complejidad baja y 4 entradas de complejidad media para el subsistema administración y 4 entradas de complejidad baja para el subsistema configuración. 49 . Consultas: 2 consultas de complejidad baja para el subsistema mostrador. Atributos de Entradas x Factor Corrección por Complejidad: No. Ficheros (ILF . 3 consultas de complejidad baja para el subsistema cocina. Estos 5 componentes lógicos básicos son con los que se describe la funcionalidad de una aplicación y los podemos representar gráficamente de la siguiente forma: Proceso de Estimación Mediante PF No. medio o alto) considerando el número de datos utilizado en el proceso y los archivos referenciados. 1 consulta de complejidad baja y 3 de complejidad alta para el subsistema administración y finalmente una consulta de complejidad baja para el subsistema configuración.EIF) Factor Corrección por Complejidad: No. 2 salidas de complejidad baja. Entradas: 9 entradas de complejidad alta para el subsistema mostrador.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN A cada componente identificado se le asigna una complejidad (bajo. Salidas del Sistema (EO) No.. Determinar los puntos de función no ajustados. 4 salidas de complejidad media y 3 salidas de complejidad alta para el subsistema administración y sólo una salida de complejidad baja para el subsistema configuración. 3 entradas de complejidad alta para el subsistema cocina. Elementos y su Complejidad Contar los Elementos de cada Componente y su Complejidad 3 Componentes Identificados Salidas Entradas Consultas Ficheros Lógicos Internos Ficheros Externos Cantidad Complejidad Cantidad Complejidad Definición de los Componentes del Sistema Salidas: 9 salidas de complejidad alta y 1 de complejidad media para el subsistema mostrador. Atributos de Ficheros x + Puntos de Función Sin Ajustar Puntos de Función Ajustados Ajuste de Complejidad Técnica Estimación del Esfuerzo Estimación del Tiempo de Desarrollo Datos de Productividad del Equipo Escala de 14 Factores de Complejidad Estimación del Presupuesto.. Atributos de Salidas x Factor. x Factor Corrección por Complejidad: No. Ficheros Lógicos Internos: 8 almacenes intermedios de datos de complejidad alta. Paso 5. Consultas BD (EQ) No. 3 salidas de complejidad alta y 1 de complejidad baja para el subsistema cocina. Calcular No.

La valoración para este factor se determina a través de la elección de las siguientes alternativas: a) 0 = Sistema Aislado del exterior (sólo usuarios directos) b) 1 = Aplicación batch con entrada de datos remota o (exclusiva) utilización de periféricos de salida remotos.65+[0. Paso 7. Determinar el valor del factor de ajuste.01.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Cálculo de los Puntos de Función Sin Ajustar Por tanto los PFSA (Puntos de Función Sin Ajustar) se calculan como la suma de los productos de cada componente por su peso determinado en la tabla correspondiente. c) 2 = Aplicación batch con entrada de datos remota y utilización de periféricos de salida remotos. (para el presente caso) f) 5 = Hay teleproceso con varios protocolos de comunicación.65 a la sumatoria de los grados de influencia de las 14 características generales del sistema. entrada de datos en línea. d) 3 = Aplicación de captura de datos En-Línea o hay un sistema de teleproceso que pasa los datos a la aplicación batch o sistema de consulta.Obtener Información del Sistema requiere conocimiento global del sistema y construir un Modelo de entidades primarias. Determinar los puntos función ajustados.5 1 Comunicación de Datos 4 2 Proceso Distribuido 4 3 Objetivos de Rendimiento 1 4 Configuración de Explotación Compartida 1 5 Tasa de transacciones 3 6 Entrada de Datos en Línea 5 7 Eficiencia con el Usuario Final 2 8 Actualizaciones en Línea 3 9 Lógica de Proceso Interno Compleja 1 10 Reusabilidad del Código 1 11 Conversión e Instalación contempladas 0 12 Facilidad de Operación 1 13 Instalaciones Múltiples 2 14 Facilidad de Cambios 4 Ajuste de Complejidad Técnica (ACT) 32 50 .. Paso 6.. NOTA: (la sumatoria de las valoraciones de los 14 factores dará el valor para el ACT Nº de Factor Nº de Factor Valor 0. facilidad de instalación. Sistema Abierto y con interfaces de todo tipo al exterior. multiplicado por 0. Para determinar los puntos función ajustados se consideran los puntos función no ajustados por el factor de ajuste Obtener los PF Ajustados 5 Componentes Identificados Entradas PFSA = 306 PFA=PFSA* [0.01*ACT]] Obtención ACT Puntaje Factor de Ajuste Min Max Comunicación de Datos 0 5 Proceso Distribuido 0 5 Objetivos de Rendimiento 0 5 Configuración de Explotación Compartida 0 4 Tasa de transacciones 0 5 Entrada de Datos en Línea 0 5 Eficiencia con el Usuario Final 0 5 Actualizaciones en Línea NOTA. Dentro de las características hay criterios como: complejidad del proceso. Cálculo de los Puntos de Función Sin Ajustar PFSA = PFTe + PFTo + PFTq + PFTif + PFTef PFSA = 106 + 146 + 39 + 15 + 0 = 306 PF Componente Bajo Medio Alto Total EI 6 * 3 = 18 4 * 4 = 16 12 * 6 = 72 106 EO 4 * 4 = 16 5 * 5 = 25 15 * 7 = 105 146 EQ 7 * 3 = 21 0 * 4 = 0 3 * 6 = 18 39 ILF 0 * 7 = 0 0 * 10 = 0 1 * 15 = 15 15 EIF 0 * 5 = 0 0 * 7 = 0 0 * 10 = 0 0 306 Obtener los PF Ajustados Obtener Ajuste de la Complejidad Técnica 5 El sistema para determinar la valoración de uno de los Factores de Ajuste: Ej: Comunicación de Datos: Los datos usados en el sistema se envían o reciben por líneas de comunicaciones. e) 4 = Varios teleprocesos pero con el mismo protocolo de comunicaciones. etc. PFSA = PFTe + PFTo + PFTq + PFTif + PFTef Componente Bajo Medio Alto Total EI Eb * 3 = _ Em * 4 = _ Ea * 6 = _ PFTe EO Ob * 4 = _ Om * 5 = _ Oa * 7 = _ PFTo EQ Qb * 3 = _ Qm * 4 = _ Qa * 6 = _ PFTq ILF IFb * 7 = _ IFm * 10 = _ IFa * 15 = _ PFTif EIF EFb * 5 = _ EFm * 7 = _ EFa * 10 = _ PFTef PFSA. El factor de ajuste se obtiene sumando 0.

 UUCW: Factor de peso de los casos de uso sin ajustar.2 Puntos de Casos de Uso Puntos de caso de uso es un método de estimación de esfuerzo para proyectos de software. También se utilizan factores de entorno y de complejidad técnica para ajustar el resultado. no puedo hacer un programa que cuente automáticamente. no programas. cuando apenas se conocen los casos de uso y sus actores asociados.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Cálculo del Esfuerzo Cálculo del Esfuerzo 6 PFA = 296. A los casos de uso se les asigna una complejidad basada en transacciones. entendidas como una interacción entre el usuario y el sistema. 51 . en el cual se describe de forma breve la funcionalidad que éste debe brindar. si son interfaces con usuarios u otros sistemas. es decir. 4. Fue desarrollado por Gustav Karner en 1993. esto nos puede servir para tener una idea un poco más precisa de la dificultad de los casos de uso e interfaces.… 300 20 a 30 Lenguajes 3GL: Cobol 100 10 a 20 Lenguajes 4GL: VisualXX 20 5 a 10 Cálculo de la Duración del Proyecto Cálculo de la Duración del Proyecto 7 DURACIÓN DEL PROYECTO EN HORAS = 2374. distintas personas podrían llegar a un conteo diferente. El método utiliza los actores y casos de uso relevados para calcular el esfuerzo que significará desarrollarlos. En este sentido no tiene un nivel de precisión suficiente para medir el tamaño de programas individuales. se han venido depurando las reglas de conteo para eliminar posibles ambigüedades y cada vez hay más material de apoyo con ejemplos NOTA: Cualquier métrica tiene un ámbito de acción y alcance definido que hay que entender para usarla correctamente. Ha sido analizado posteriormente en otros estudios.5 horas/persona LÍNEAS DE CÓDIGO = PFA * (LINEAS POR PF) Cambiar horas/efectivas por horas productivas estimadas Esfuerzo Entorno y Lenguaje Líneas de Código por PF Horas por PF Lenguajes 2GL: Ensamblador. está enfocado a medir sistemas informáticos completos. C.91 horas por miembro DURACIÓN EN MESES = 474.5 horas/persona / 5 personas = 474. mientras que a los actores se les asigna una complejidad basada en su tipo.125 = 2374. el metro lineal no es lo mejor para medir grandes distancias en el mar. a partir de sus casos de uso.5 Horas/mes productivas estimadas en el proyecto Calculadas de 20 días laborables y De 5 horas productivas estimadas de las 8 de la jornada laboral normal diaria Se asigna la cantidad de participantes en el proyecto Cálculo del Presupuesto del Proyecto Cálculo del Presupuesto del Proyecto 8 Costo Total del Proyecto = sueldos 1 participante del proyecto * 5 participantes * 5 meses + Otros costos necesarios durante la realización del proyecto = 2000 * 5 * 5 = 50000 DURACIÓN DEL PROYECTO EN MESES = 5 meses Participante 1: Sueldo Participante 2: Sueldo Participante n: Sueldo En la práctica se deben especificar Otros costos de operación para determinar el presupuesto total del proyecto Desventaja: Se le ha criticado a las métricas funcionales que requieren que alguien “identifique” la funcionalidad y “evalúe” la complejidad basándose en los criterios y reglas establecidas. Así por ejemplo. En nuestro caso. UUCP = UAW + UUCW Estas siglas significan:  UUCP: Puntos de casos de uso sin ajustar. tomando en cuenta los pesos de los actores (UAW) y los pesos de los casos de uso (UUCW). Al inicio de un proyecto de software. Para resolver esto. El UUCP son los puntos de casos de uso sin ajustar.82 / 0. y supervisado por Ivar Jacobson. basándose en el método de punto de función.82 Esfuerzo horas/persona = PFA / [1 / 8 persona / hora)] = 296. Debido a esto. se puede proyectar una breve descripción de cada caso de uso.91 horas / 100 horas/mes = 4 meses 15 dias HORAS POR PERSONA = 2374.  UAW: Factor de peso de los actores sin ajustar. Puntos Función.

Esfuerzo horas-hombre 1. lo que quiere decir que se ejecutan todas o no se ejecuta ninguna. Factor de peso de los actores sin ajustar (UAW) 2. Tipo actor de Descripción Factor Simple Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de 1 programación (API). Factor de peso de los casos de uso sin ajustar (UUCW) Este punto funciona muy similar al anterior. • Basado en clases de análisis. Toma en cuenta el número de clases que tiene un caso de uso y lo evalúa según la siguiente tabla: Tipo de caso de uso Descripción Factor Simple Menos de 5 clases 5 Medio 5 a 10 clases Complejo Más de 10 clases 15 10 52 . MÉTODO El método de punto de casos de uso consta de cuatro etapas. pero para determinar el nivel de complejidad se puede realizar mediante dos métodos: basado en transacciones o basado en clases de análisis. TCP/IP) o una persona interactuando a 2 través de una interfaz en modo texto. 2. Este puntaje se calcula determinando si cada actor es una persona u otro sistema. este representaría el valor cantidadDeUnTipoDeActor en la fórmula y se tiene que multiplicar por el valor que tenga su factor correspondiente. Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica (GUI). • Basado en transacciones: Toma en cuenta el número de transacciones que se pueden realizar en un caso de uso y lo evalúa según la siguiente tabla: Tipo de caso de uso Descripción Factor Simple 3 transacciones o menos 5 Medio 4 a 7 transacciones 10 Complejo Más de 7 transacciones 15 Tabla 2: Peso de las transacciones. en las que se desarrollan los siguientes cálculos: 1. Una vez terminado esto se procede a sumar cada producto para obtener el UAW. además evalúa la forma en la que este interactúa con el caso de uso. Puntos de caso de uso ajustados (UCP) 4. para obtener el resultado por cada tipo de actor. La fórmula sería: UAW = Sum(cantidadDeUnTipoDeActor*Factor) Para realizar esta operación sería necesario contar cuántos actores de cada tipo existen en el sistema. Factor de peso de los casos de uso sin ajustar (UUCW) 3. se puede obtener una estimación trivial del tamaño y a partir de ella una estimación del esfuerzo. 3 Tabla 1: Peso de los actores sin ajustar. Una transacción es un conjunto de actividades atómicas. Factor de peso de los actores sin ajustar (UAW) Consiste en la evaluación de la complejidad de los actores con los que tendrá que interactuar el sistema.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Aplicando el análisis de puntos de función a estos casos de uso. Medio Otro sistema interactuando a través de un protocolo (ej. y la cantidad de actores de cada tipo.

Puntos de caso de uso ajustados (UCP) Para esto se utilizan las siglas UCP y se obtiene al multiplicar el UUCP el TCF y el EF quedando la operación de la siguiente forma: UCP = UUCP x TCF x EF Estas siglas significan: UCP: Puntos de casos de uso ajustados.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Tabla 3: Peso de las clases de análisis. Una vez hecho esto se suma cada producto para obtener el factor de peso de los casos de uso sin ajustar (UUCW). 3. 1 T3 Eficiencia del usuario final. UUCP: Puntos de casos de uso sin ajustar. 1 T5 El código debe ser reutilizable. 2 T2 Objetivos de performance o tiempo de respuesta. 0. Ahora independientemente del camino utilizado para determinar el tipo de caso de uso. Factores de complejidad técnica Este se compone de 13 puntos que evalúan la complejidad de los módulos del sistema que se desarrolla. 1 T13 Se requiere facilidades especiales de entrenamiento a usuario. Esta estimación es bastante imprecisa debido principalmente a la escasa información que se tiene. y podrá ser refinada a medida que se obtenga más información. Para una mejor comprensión. 2 T9 Facilidad de cambio. cada uno de estos factores tienen un peso definido con los cuales se obtendrá puntos ponderados por cada uno de ellos. Para realizar esta operación se debe contar cuántos casos de uso de cada tipo hay en el sistema y esta cantidad se sustituiría en el campo nombrado como Cantidad De Un Tipo De Caso Uso y se multiplica por el valor que tenga su factor correspondiente. TCF: Factores técnicos. Medio De 3 a 4. 1 T10 Concurrencia. 1 T12 Provee acceso directo a terceras partes. pero permitirá obtener una idea del esfuerzo necesario para llevar adelante el mismo. la fórmula es la misma y se presenta a continuación: La fórmula sería: UUCW = Sum (CantidadDeUnTipoDeCasoUso*Factor). Cada uno de estos puntos se debe evaluar según la siguiente escala: Descripción Valor Irrelevante De 0 a 2. a continuación se mostrará una tabla con los ítems: Factor Descripción Peso T1 Sistema distribuido. según la valoración que se le asigne. 1 Tabla 4: Peso de los factores de complejidad técnica. para obtener el resultado por cada tipo de caso de uso. 0. EF: Factores ambientales. 1 T4 Procesamiento interno complejo.5 T7 Facilidad de uso. 53 . 1 T6 Facilidad de instalación. 1 T11 Incluye objetivos especiales de seguridad.5 T8 Portabilidad.

Estos factores se muestran a continuación: Factor Descripción Peso E1 Familiaridad con el modelo de proyecto utilizado. Esfuerzo horas-hombre (E) Este cálculo se realiza con el fin de tener una aproximación del esfuerzo. que están relacionados con las habilidades y experiencia del grupo de personas involucradas con el desarrollo del proyecto.6 + (0. Cada uno de estos factores se debe calificar con un valor de 0 a 5. pero a través del tiempo se ha ido mejorando.03 * EFactor) Para obtener el EFactor se debe sumar todos los productos obtenidos al multiplicar el peso de cada punto por el valor asignado. después se multiplican y se suma cada producto para obtener el TFactor. después se multiplica por -0.03 y se le suma el 1. también contar la cantidad de estos mismos del E7 y E8 que son mayores que 3. se sugería utilizar 20 horas persona por UCP. pensando solo en el desarrollo según las funcionalidades de los casos de uso. 1 E4 Capacidad del analista líder. Las fórmulas para este punto son: TFactor = Sum (Valor*Peso) TCF = 0. esto nos va a dar el TCF. Luego. Así.01 * TFactor) Para realizar este cálculo. 0. se debe seguir la segunda fórmula multiplicando el TFactor por 0. Está basado en los factores ambientales y se calcula de la siguiente manera: Primero se debe contar la cantidad de factores ambientales del E1 al E6 que tienen una puntuación menor a 3.4. Las fórmulas para este punto son: EFactor = Sum(Valor * Peso) EF = 1.5 E3 Experiencia en orientación a objetos. 0. se obtiene el peso de los factores ambientales (EF).5 E2 Experiencia en la aplicación. se debe evaluar cada factor. asignándole un valor como se menciona anteriormente. 1. Factores ambientales Los factores sobre los cuales se realiza la evaluación son 8 puntos. Factor Filtro De E1 a E6 Factor < 3 De E7 a E8 Factor > 3 Tabla 7: Factor de el esfuerzo horas-persona.6. 1 E6 Estabilidad de los requerimientos 2 E7 Personal part-time -1 E8 Dificultad del lenguaje de programación -1 Tabla 6: Peso de los factores ambientales. Para evaluar el resultado o la cantidad total según la siguiente tabla: Horas-Persona (CF) Descripción 20 Si el valor es<=2 54 .CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Esencial 5 Tabla 5: Escala de los factores de complejidad técnica.01 y sumar el resultado a 0.5 E5 Motivación.4 + (-0. 4. Anteriormente.

Este 40% se refiere al esfuerzo total para el desarrollo de las funcionalidades especificadas en los Casos de Uso. generalmente un 40%. para el esfuerzo total en el desarrollo del proyecto: Actividad Porcentaje Análisis 10% Diseño 20% Programación 40% Pruebas 15% Sobrecarga 15% Se puede identificar el procedimiento para la estimación de esfuerzo utilizando casos de uso de la siguiente manera: Identificar los Componentes del Sistema a partir de: Diagramas de Casos de Uso (UML) Diagramas de Contexto o DFD (P. Si el valor es<=4 Si el valor es>=5 Al realizar la multiplicación del UCP por las horas. Estructurada) Componentes a Identificar: Salidas Entradas Consultas Ficheros Lógicos Internos Ficheros Externos 55 . que representa una parte del total del esfuerzo de todo el proyecto.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 28 36 Tabla 8: Cantidad de horas-persona según el valor.persona. En la siguiente tabla se detallan la distribución en porcentaje. CF: Horas-Persona. se consigue un esfuerzo estimado. El esfuerzo en horas-persona viene dado por: E = UCP x CF Estas siglas significan: E: Esfuerzo estimado en horas-persona. UCP: Puntos de Casos de Uso ajustados.

desventajas y ejemplos de empresas que los utilizan. 56 . Resultado de aprendizaje: Elaborará un documento que contenga lo siguiente:  Tabla comparativa entre los modelos MOPROSOFT y CMMI que incluya ventajas.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática V Modelos para el aseguramiento de la calidad del software Objetivo: El alumno identificará el uso de los principales Modelos para asegurar la calidad en la Industria del Desarrollo de Software. CMMI Identificar la estructura del Determinar el alcance de Organizado modelo integrado de madurez los componentes de las Analítico y capacidad (CMMI). Ser Determinar el alcance de Organizado los componentes de las Analítico áreas claves de Sistemático MOPROSOFT. Temas Saber Saber hacer MOPROSOFT Identificar la estructura del modelo de proceso y de evaluación para la industria mexicana de software. áreas claves del proceso en Sistemático el nivel 2 de CMMI.

6.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Tareas de aseguramiento de Calidad (SQA): • • • • • Establecer un plan SQA. y cumplir con los lineamientos de ISO15504. concluyéndose en el estudio que no había un modelo de procesos y evaluación que se adaptara 100% a las empresas mexicanas. 4. Por supuesto que no se trataba de “inventar el hilo negro”. Las estrategias del PROSOFT son: 1. 3. El compromiso era cubrir por lo menos las prácticas del modelo CMM-SW nivel 3 e ISO9000:2000. Feedback para mejora continua. 5. Por lo que se propuso desarrollar un modelo de procesos y un método de evaluación “a la medida” de nuestra industria. 57 . Asegurar que las desviaciones se documenten. con respecto al método de evaluación Modelo MOPROSOFT En Junio de 2003 se hizo público el MoProSoft (el Modelo de Procesos para la Industria de Software) como documento base para la norma mexicana. Resulta muy claro que los costos de la falta de calidad son mucho mayores a los que se requieren para implementar un buen sistema de aseguramiento de la calidad. 7. 5. Un EJEMPLO claro de los beneficios de tener un buen sistema de SQA es poder detectar los errores de un programa antes de su entrega e implementación. Descripción del proceso de desarrollo. Promover exportaciones y la atracción de inversiones Educación y formación de personal competente Contar con un marco legal promotor de la industria Desarrollar el mercado interno Fortalecer a la industria local Alcanzar niveles internacionales en capacidad de procesos Promover la construcción de infraestructura física y de telecomunicaciones La Secretaria de Economía encargó a la Dra. ya que resulta mucho más caro corregir el error una vez implementado y a la vez que se pierde la imagen de la organización al presentar productos que tenga fallas notables. en el caso del modelo de procesos. Software. que tiene como objetivo Fortalecer a la Industria de Software en México. 2. Hanna Oktaba de la UNAM y a un grupo de colaboradores investigar que procesos podían utilizarse en la industria mexicana para el desarrollo de software. Revisión de Actividades de Ing. en su mayoría PyMES (Pequeña y Mediana empresa).1 MOPROSOFT Para identificar la estructura del modelo de proceso y de evaluación para la industria mexicana de software se puede observar lo siguiente: En 2002 la Secretaría de Economía (SE) inició el Programa para el Desarrollo de la Industria de Software (PROSOFT).

El objetivo de las pruebas controladas fue demostrar que. las empresas adecuaron los procesos de MoProSoft a sus necesidades. Posteriormente. para lo cual es necesario considerar las necesidades de los clientes. Adicionalmente habilita a la organización para responder a un ambiente de cambio y a sus miembros para trabajar en función de los objetivos establecidos 58 . así se desarrolló EvalProSoft (el método de Evaluación de Procesos de Software) En julio de 2004 se realizó el proceso de selección de cuatro empresas a las cuales se les aplicó una evaluación inicial para conocer sus niveles de capacidades con respecto al modelo de MoProSoft. Su nombre completo es: NMX-I-059/04-NYCE-2005 Tecnología de la Información-Software-Modelos de procesos y evaluación para desarrollo y mantenimiento de software: Parte 01: Definición de conceptos y productos Parte 02: Requisitos de procesos (MoProSoft) Parte 03: Guía de implantación de procesos Parte 04: Directrices para la evaluación (EvalProSoft) MOPROSOFT clasifica a sus procesos en 3 categorías que son: Categoría Alta Dirección (DIR) Gestión (GES) Operación (OPE) Alta dirección. Gestión y operación Proceso Gestión de Negocio Gestión de Procesos Gestión de Proyectos Gestión de Recursos Administración de Proyectos Específicos Desarrollo y Mantenimiento de Software Gestión de Negocio (DIR) Propósito: Establecer la razón de ser de la organización. entre agosto y diciembre. sus objetivos y las condiciones para lograrlos. definieron las plantillas de los productos y empezaron a implementar los procesos. las empresas pueden elevar sus niveles de capacidad y “no morir en el intento”. El trabajo se realizó dentro del Subcomité de Software del NYCE (Normalización Y Certificación en Electrónica). En 2005 todos los esfuerzos se centraron en convertir los dos modelos en la norma mexicana. en un lapso de tiempo relativamente corto. con el apoyo de una consultora un día a la semana.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN También se trabajó con un equipo de trabajo para definir el método de evaluación basado en MoProSoft como modelo de procesos. así como evaluar los resultados para poder proponer cambios que permitan la mejora continua. La norma fue aprobada por el NYCE el 5 de julio y el 15 de agosto publicada en el Diario Oficial de la Federación.

Objetivos. Procesos requeridos. Plan de comunicación con el cliente Necesidad de mejora 59 . Estrategias. Valores. Cartera de proyectos. Presupuesto. Estrategia de recursos. Visión. Estructura de la organización.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Tareas a realizar en esta categoría: Plan estratégico de la organización: Misión.

Responsable y autoridad. Nombre del proceso. Así como definir. e implantar las actividades de mejora en los mismos. Indicadores. Realizar una plantilla para documentar los procesos. planear. Definir las formas de evaluar la efectividad en el cumplimiento de los objetivos del proceso. Capacitar en el uso de la plantilla para documentarlos Usar diagramas de actividades de UML Producto PLANTILLA PARA DOCUMENTAR LOS PROCESOS Proceso. Tareas a realizar en esta categoría: Capacitar a los encargados de los procesos en Moprosoft Definir el catálogo de procesos de la organización Identificar los procesos Documentar los procesos. Propósito. Indicar quien es el responsable principal de la ejecución 60 . Describir las actividades más generales del proceso.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Gestión de Procesos (GES) Propósito: Establecer los procesos de la organización. en función de los Procesos Requeridos identificados en el Plan Estratégico. Descripción. Objetivos generales y resultados esperados de la ejecución del proceso.

Salidas. Autoridad es quien comprueba la ejecución y el cumplimiento del propósito del proceso. Esta descripción puede acompañarse de un diagrama de actividades. 61 . Actividades. Definir los documentos o productos que se utilizan en este proceso. Roles. Productos internos. . Cargos de las personas involucradas en este proceso. Lista de procesos de los cuales se compone el proceso en cuestión.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN de este proceso. Tareas que se llevan a cabo en este proceso. Definir los documentos o productos resultados de este proceso. Definir los documentos o productos que sirven de base para este proceso. . Procesos relacionados. Entradas. Subprocesos. Otros procesos con los cuales se tiene relación. Gestión de Proyectos (GES) Propósito Asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización.

Contrato. Metas cuantitativas del proyecto. . La finalidad es apoyar el cumplimiento de los objetivos del Plan Estratégico de la organización. Describir el proyecto. 3. Capacitar a los encargados de los involucrados en Moprosoft Crear el Plan operativo de Bienes. Registrar el proyecto. Responsable del proyecto. 2. Crear y mantener la Base de Conocimiento de la organización. Gestión de Recursos (GES) Propósito: Conseguir y dotar a la organización de los recursos humanos.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Tareas a realizar en esta categoría:       Definir el proyecto. ambiente de trabajo y proveedores. 4. Tareas a realizar en esta categoría: 1. Servicios e Infraestructura Crear el Plan operativo de Recursos Humanos y Ambiente de trabajo Crear el Plan operativo de Conocimiento de la organización 62 . infraestructura. . .

Acordar la distribución de la información al equipo de trabajo. 6. Estudiante: _Juan Luís Guerra_____ ____ Fecha: _09/10/06__ Programa:_Raíz Cuadrada___ __________ . Codificación 53de trabajo. 44. Establecer calendario de actividades Plan 12:33 1:16 Actual A 6. Formalizar el inicio de un nuevo ciclo Planeación 2 2 1.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Administración de proyectos específicos (OPE) Propósito: Establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados. Realizar reuniones con el equipo de trabajo y con el cliente para 20 16. Documentar el Plan del Proyecto la Fecha A 7. Revisar las solicitudes de cambio del cliente.7 63 Prueba 25 25 20. Definir ciclos y actividades 33 4:18 5:11 25 Tiempo en Fase 4. 0 2.2 5.7 Estudiante: _________ _________ __ Fecha: _________ _ Instructor:_ _________ _________ ___ Progra ma #: ______ Tiemp 50 38 58 62 50 69 28 50 38 .8 Postmortem 20 20 16. Revisar los productos terminados. Documentar el Plan de Desarrollo la Fecha% 8. 3.6 Diseño Realización 0 0 1. Establecer el Equipo de trabajo 13/9 9:00 9:50 (minutos) 5. Programa #: _1A Instructor: Fecha Inicio Fin Tiempo de _XX________ Interrupción ___________ ____ 9/9 9:00 9:50 Lenguaje: ___C____ 12:40 1:18 Tamaño del Tareas a realizar en esta categoría: programa 2:45 3:53 10 (LOC) Planeación Plan 10/9 11:06 12:19 6+5 1. Definir el Protocolo de Entrega al Cliente dificadas) 50 3. Acordar las tareas del equipo de trabajo.Compilación 20 reportar los avances y tomar acuerdos. Recolectar los reportes de actividades. Definir el proceso específico con base en la Descripción Actual del Proyecto y el proceso de Desarrollo y 11/9 9:00 9:50 Total Mantenimiento del Software (Nuevas&Mo 1:15 2:35 3+8 2. mediciones y productos 53 4.

Análisis y diseño 11. Entradas: 1. Casos de uso generales y detallados 8. Documentación del proceso (Gestión de proyectos) Salidas: 1. Armar el equipo 3. Texto con el problema 7. Reporte de seguimiento Desarrollo y Mantenimiento de software (OPE) Propósito: Es la realización sistemática de las actividades de análisis. Diagrama de la base de datos 13. Diagrama de componentes por paquete 64 . Plan de Desarrollo Lecciones aprendidas 1. Glosario de términos 9. integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados. Socialización de conocimientos 4. Inicio 2. Proceso de desarrollo y mantenimiento de software (OPE) Incluye: Ciclos de Desarrollo. Fases de un Ciclo. Reporte de mediciones y Sugerencias de Mejora 2. Actividades de una Fase Fases: Para cada fase se describen los productos a generar y/o las actividades a realizar 1. Prototipo (si aplica) 10. Arquitectura y diagrama de paquetes principales del sistema 14. Plan de Proyecto 2. Requerimientos 5. construcción.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Evaluación y control 1. Evaluar el cumplimiento del Plan del Proyecto y Plan de Desarrollo 2. Los requerimientos se recolectan y se validan con el cliente 6. Generar el Protocolo de entrega y terminación del ciclo. Diagramas de clases 12. Descripción del proyecto (Gestión de proyectos) 2. diseño.

hay que documentarlo. Desprecian cualquier institucionalización de buenas prácticas. 2. Se concentran en desarrollar entornos de desarrollo y repositorios. Pruebas de integración 4. Evaluación del proceso y producto Documentar las Lecciones aprendidas Experiencias al aplicar el modelo de procesos de software en la empresa:  Toda la organización debe saber que se está aplicando Moprosoft.Estúpido. 3 – Sabotaje. Negligencia total. Falta de recompensa y degradación de las prestaciones. que fue refinado posteriormente por Tom Schorsch. Organizaciones negligentes. Impiden cualquier desarrollo de software con éxito.2 CMMI Anthony Finkelstein describió que hay organizaciones que no han alcanzado siquiera el nivel 1 de CMM (en el que aunque sea de modo heroico se llega a producir software).CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 15. descrédito consciente de los esfuerzos de su propia gente en la mejora de proceso del software. 65 .  Las organizaciones no siempre tienen claro cuales son sus procesos. Organizaciones obstructivas. Este «Modelo de Incapacidad e Inmadurez».  Avanzar paso a paso. Su gran preocupación es la reutilización del software. Pruebas e integración 3. pues abruma la cantidad de tareas a realizar y documentar. Imponen procesos contra-productivos para impedir cualquier avance. no correr.  Muchas empresas tienen un proceso implícito de desarrollo. incluye tres niveles de idiotez o Inmadurez:     0 – Tonto o Nulo. 2 – Lunático o Despectivo. Prueba del sistema Cierre 1. Construcción La construcción se hará en cada subgrupo y se probará en cada subgrupo 1. Su gran objetivo es la programación automática.  Se debe empezar por documentar lo mas general  Se puede aplicar Moprosoft de manera que se avance en la madurez de la organización. proponiendo que existen niveles negativos o de inmadurez. 5. Código 2. 1 . Organizaciones desdeñosas.  Se confunde procesos con estructura.  Capacitar en las técnicas necesarias para el modelado del negocio y del desarrollo.

ayudando a asegurar la comunicación y consistencia y evitando gastar el tiempo determinado cual es el próximo paso a seguir.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ¿Por qué PSP nos conduce al CMMI? El CMMI significa decir que se hace. hacer lo que se dice y medirlo. Se exceden los presupuestos. A continuación se presentan algunos puntos clave para poder identificar si una organización se encuentra dentro de un nivel de capacidad de Inmadurez o dentro de un Nivel de Capacidad de Madurez. Proceso Inmaduro Proceso Maduro Personal. Esto hace que el proceso este accesible para todos. ¿Quién no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de software? Como esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos problemas. en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software. aprobado y accesible. 66 . El personal ha sido entrenado: Ingenieros y gerencia (conocen el proceso).1 Los Cinco Niveles De Madurez En Los Procesos De Creación Del Software El departamento de defensa de los Estados Unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas. Adoptando el framework del RUP (Rational Unified Process ). Es practicado: Se utiliza en forma cotidiana. Es posible agregarle variantes de procesos o prácticas para customizarlo al proceso de la organización. Es controlado: las actualizaciones son notificadas a la empresa. No es fácil reproducirlo en nuevos proyectos. Es percibido como poco eficiente. No todo el mundo lo conoce. y a ayudar al Departamento de Defensa". publicado. dedicado exclusivamente a los problemas del software. Se mide: utilización. Se valida: el proceso mantiene coherencia con los requerimientos y estándares. Se verifica: los proyectos siguen el proceso establecido. se la pone a disposición de todos los miembros del equipo en su desktop. beneficios y rendimiento se cuantifican. Una vez definido el proceso. Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos 4 problemas". Se aplica a veces solamente. 5. se presentaron diversos estamentos y la Universidad Carnegie Mellon ganó el concurso en 1985. Es apoyado: Gerencia asigna responsables. El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM. y aun así continuar conformando el acercamiento por RUP. No está documentado. Es documentado. Es definido: Sistemático. las fechas alargaban más y más. es posible aplicar el proceso que se convirtió en el estándar de ipso de la industria de desarrollo de software. No se mide. Es mantenido: es revisado para que cumpla los requisitos.2. creando el SEI. en una forma sencilla de seguir y aplicar. No se cumplen los tiempos de entrega. Puede mejorarse: existe el mecanismo para la mejora continua. tal como lo es una interfaz web. No hay entrenamiento. los presupuestos se disparaban.

Este proceso fue desarrollado por Watts S. Los diferentes niveles permiten medir la madurez del proceso y evaluar el potencial de él. provee a las organizaciones de software una guía de cómo aumentar el control de sus procesos de desarrollo y mantenimiento de software. CMM es. La arquitectura del modelo está compuesta por niveles que describen la madurez de la organización y por áreas claves de procesos KPAs (Key Process Areas). universal y uniforme(institucionalizadas)  Medidas  Verificadas 67 . buscaron mejorar el proceso de software y desarrollaron un marco de trabajo que llamaron proceso de madurez. Éste concepto cuenta con cinco etapas evolutivas que se enfocan en la implementación de prácticas de calidad. una aplicación de TQM para software Niveles madurez Nivel 1 Inicial Nivel 2 Repetible Nivel 3 Definido Nivel 4 Gestionado Nivel 5 Optimizado de Áreas Claves Ninguna Gestión de configuraciones Garantía de calidad Gestión subcontratación del software Seguimiento y supervisión del proyecto Planificación del proyecto Gestión de requisitos Revisiones periódicas Coordinación entre grupos Ingeniería de productos de software Gestión de integración del software Programa de formación Definición de procesos de la organización Enfoque del proceso de la organización Gestión de calidad de software Gestión cualitativa del proceso Gestión de cambios del proceso Gestión de cambios de tecnología Prevención de defectos 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. en pocas palabras. Humphrey en 1986 y está basado en el concepto de la administración de la calidad total Total Quality Management (TQM) por sus siglas en inglés.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN El “nacimiento” de CMM se da en el año de 1986 cuando el Software Engineering Institute (SEI) junto con MITRE Corporation. Fue diseñado para guiar a las organizaciones de software en la selección de estrategias para el mejoramiento de procesos mediante la determinación de la madurez de los procesos actuales e identificando los elementos más críticos de la calidad de software y del mejoramiento de procesos. como también ayudan a una organización a priorizar sus esfuerzos de mejoramiento. El modelo de capacidad de madurez (CMM).

que describen las funciones de ingeniería del software que deben llevarse a cabo para el desarrollo de una buena práctica. el CMMI o "Modelo de Capacidad y Madurez . Mejora la gestión de la calidad es. Por lo tanto. 68 . Estos niveles sirven de referencia para el conocimiento del estado de la madurez del proceso del software en la organización. en gran medida. el SEI evolucionó la madurez y publicó Capability Maturity Model for Software (CMM). CMMI define un conjunto de áreas clave del proceso. el SEI publicó un nuevo modelo.En diciembre de 2000. agrupadas en cinco niveles inclusivos. la eficacia y la eficiencia de la metodología de desarrollo de una organización productora de software. responsabilidad de la dirección La mejora de la calidad debe basarse en mejorar los procesos y no en las personas Hay que medir la mejora de la calidad Se necesitan incentivos para mantener un esfuerzo de mejora La mejora de la calidad es un proceso continuo Después de cuatro años de experiencia con la madurez del proceso de software. gestión y mantenimiento de software Para conseguirlo se aplican las bases de la Gestión de la Calidad Total (Total Quality Management) en la Ingeniería del Software. obteniéndose una visión precisa del rigor. basado en conocimientos adquiridos de evaluaciones de los procesos de software y extensos feedback.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN CMM: un modelo para la mejora de Procesos de Software Objetivo: Mejorar la calidad de los procesos de desarrollo. las disposiciones del CMM son definitivamente aplicables a todo aquello que esté directamente relacionado con el desarrollo y mantenimiento de sistemas informáticos. Mediante un amplio conjunto de métricas se determina la calidad de cada una de las áreas clave.Integración". éste describe un camino de mejoramiento evolutivo para pasar desde un proceso inmaduro a un proceso maduro y disciplinado.

5. Todo esto con el objetivo de realizar algunas mejoras respecto al CMMI (SW-CMM).2 Características comunes:      Compromiso de realización Capacidad para llevarla a cabo Actividades que hay que realizar Medición y análisis Verificación de la implementación 69 . denominadas características comunes.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Cada una de las áreas está organizada en cinco secciones.2.

ajustando dicha dimensión Investigación de Tendenc Tecnológicas Planificación Planificación de Recursos R Valoración y Mejora Continua Seguimiento y Control P l a Preparación para n la Realización i Preparación a la f Implantación R i P e c l a a a l c n i i i z ó f a Evaluación y Control n i Planificación c c Estratégica i E a ó v c n a i l ó u n a c 70 . que permitan mostrar los niveles de madurez de los procesos para producir software. I SO 9000 – 3 y CMMI con el objetivo de proveer las especificaciones para el desarrollo de software.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Modelo de Desarrollo de Software PROPUESTA DE ESTÁNDAR (Proyecto) El siguiente estándar está basado en los modelos ISO 15504 / SPICE. El estándar se basa en la dimensión del proceso (tomada del modelo ISO 15504/SPICE).

CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN a tres niveles (tomados del modelo CMMI). Definido y Optimizado. los cuales son: Inicial. 71 .

Constituye el acervo de conocimientos de la organización y permite evaluar y mantener vigente la tecnología operativa. etc. durante su uso”. por su propiedad. "Cualidad" es lo que hace que una persona o cosa sea lo que es. determinante del grado de satisfacción que el producto proporcione al consumidor. una dimensión. características. términos que en realidad son características individuales que en conjunto constituyen la calidad del producto. La calidad no tiene un significado popular de lo mejor en el sentido absoluto. Teniendo en cuenta lo anterior la calidad de un producto puede definirse como: “La resultante de una combinación de características de ingeniería y fabricación. 72 . De esta actividad deriva el conocimiento y aprendizaje organizacional. ya que es él.” “Es lo que el cliente dice que necesita más lo que realmente necesita” “Suministrar bienes o servicios que no regresan. la encontraremos en el Griego Kalos: Bueno. Hermoso. Al establecer lo que entendemos por calidad se exige un equilibrio entre estas características. medida de desempeño esperado. Indicador: Es un signo o medición de un fenómeno. a clientes que si lo hacen “ "Es el conjunto de cualidades de una persona o cosa". industrialmente quiere decir. Apto. “Cumplir con las necesidades del cliente y exceder las expectativas en forma constante (siempre). Análisis: Consiste en la interpretación del desempeño de los procesos para su control y mejora. una temperatura.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Glosario de términos Calidad Si buscamos el significado etimológico de la palabra Calidad. Se establecen para llevar a cabo la gestión de la calidad las siguientes definiciones para llegar comprender los conceptos relacionados a la Calidad en una empresa. una presión o cualquier otro requerimiento que se use para establecer la naturaleza de un producto o servicio. Hablando de calidad podemos resaltar sus características estas pueden ser: Un requisito físico o químico. Auditoria de calidad: Consiste en la verificación del cumplimiento de las normas. virtud. servicial y durable. metodología y procedimientos de los sistemas y procesos de calidad Documentación: Es el registro cotidiano del desempeño de los procesos y sistemas. Esta definición nos lleva a pensar en términos como confiable. utilizado para evaluar o comparar acciones realizadas Efectividad: Se refiere a la capacidad para entregar resultados planeados. Estándar: Norma. Favorable y en el Latín Qualitatem: Propiedad. Eficiencia: Se refiere al logro de objetivos y al aprovechamiento de los recursos disponibles. mejor dentro de ciertas condiciones del consumidor. Índice: Es la relación cuantitativa entre dos cantidades relacionadas con un mismo fenómeno. quien en última instancia determina la clase y la calidad del producto que desea. don. atributo.

congruentes con los Principios y Valores de Calidad. expresados formalmente por la dirección general. productos intermedios y productos finales Diseña y realiza los estudios de estabilidad de los productos intermedios. Desarrolla. que incluye la planeación estratégica.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Modelo de calidad: Es una descripción de la interacción de los componentes de los principales elementos del sistema de administración de la organización. Sistema: Es un conjunto de elementos con un fin común. materiales. Sistema de calidad: Es el conjunto de la estructura de organización de responsabilidades. En la terminología industrial Control. uno es el decidir la combinación de ingredientes que dará gusto apropiado (Ingeniería de la calidad). medición. Cubre dos aspectos fundamentales y diferenciados. Estas acciones deben ser demostrables para proporcionar la confianza adecuada (tanto a la propia empresa como a los clientes) de que se cumplen los requisitos del Sistema de la Calidad. formando un todo dinámico. Es el aspecto de la función general de la gestión que determina y aplica la política de la calidad. de Procedimientos. y otro el asegurar que nuestra producción tenga la combinación de ingredientes que considere apropiados (Control de calidad). implantadas dentro del Sistema de Calidad de la empresa. eficiencia y adaptabilidad/flexibilidad Métodos de muestreo. Técnicas y actividades de carácter operativo utilizadas para satisfacer los requisitos relativos a la calidad. sus productos y servicios. Política de calidad: Directrices y objetivos generales de una empresa relativos a la calidad. Participa en el desarrollo. la asignación de recursos y otras acciones sistemáticas en el campo de la calidad. es decir es la gerencia o el manejo de los proceso productivos enfocada al mejoramiento continuo. es el acto de delimitar responsabilidad y autoridad con el fin de liberar la gerencia de detalles innecesarios. que se interrelacionan entre sí. (Forma parte de las políticas generales de una organización. Corresponde a las necesidades propias de una organización para satisfacer los objetivos de calidad propuesto 73 . el desarrollo de actividades operacionales y de evaluación relativas a la calidad Control de Calidad: Realiza o participa en la caracterización de los nuevos productos en sus diferentes fases de desarrollo y en el establecimiento de las especificaciones de calidad de los mismos. conservando los medios para asegurarse de que los resultados sean satisfactorios. tales como la planeación de la calidad. Sistema de medición: Es el medio a través del cual se obtiene información sobre el desempeño de la organización. ejecución y perfeccionamiento del Sistema de Calidad. de calibración. frecuencias y responsables. Aseguramiento de Calidad: Consiste en tener y seguir un conjunto de acciones planificadas y sistemáticas. efectividad. Se integra por diversos elementos. de procesos y de recursos que se establecen para llevar a cabo la gestión de calidad. La gestión de calidad: Tiene que ver con la organización interna que ejerce la determinación de los procesos productivos y de las características y cualidades de los productos. Se refiere al esquema predeterminado de referencia que define los sistemas y prácticas de calidad de la organización. entre los que se incluyen: Indicadores de control. ejecuta o coordina la ejecución de los métodos de ensayo para determinar las características de calidad de las materias primas.

Sign up to vote on this title
UsefulNot useful