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

analizar. 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. el autoestudio. IV. Introducción a la Calidad en el Desarrollo de Software. V. 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). permitiéndoles solucionar problemas en función de los conocimientos adquiridos de automatización de sistemas.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.Además de propiciar la realización de trabajos futuros aplicados a su entorno. la investigación y la auto práctica. 4 . DESARROLLO El manual está compuesto por 5 unidades temáticas: I. El objetivo principal del documento es brindar al alumno información que le permita al alumno identificar. II. Se integran prácticas a los temas para fortalecer el aprendizaje significativo del alumno. Con la finalidad de que el alumno pueda aplicar algunos de los conocimientos adquiridos durante el desarrollo de la asignatura. III. sitios de internet. 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). Esta información en su mayoría ha sido colectada de libros. Además de motivar en él. para brindar al alumno información seria y de calidad.

Mantenibilidad . Temas Saber Saber hacer Ser Generalidades de la Identificar conceptos de Calidad calidad.Usabilidad .Eficiencia . modelos e institutos que regulan la calidad.Portabilidad .Robustez . como: base en los factores y características que lo . procesos.Funcionalidad definan. un ensayo de los conceptos de calidad enfocada hacia el desarrollo de software involucrando cada una de los factores que conformen su gestión. para reconocer la importancia del aseguramiento de la calidad.Confiabilidad . normas. 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. .Corrección .Oportunidad Proactivo Organizado Autodidacta Analítico Sistemático Resultado de aprendizaje:  El participante podrá elaborar un cuadro sinóptico.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.Compatibilidad . estándares. 5 . Objetivo:El alumno identificará los conceptos generales de calidad y los específicos en el área de desarrollo de software.

Constituye el objetivo prioritario. durante y después de haber obtenido los resultados instalando sensores en aquellas fases que se quieren controlar. es decir. Se centra en inspeccionar el producto y separar aquel que es aceptable (de acuerdo a unos determinados estándares) del que no lo es. Es un concepto dinámico. Esta nueva concepción de la calidad presenta importantes implicaciones. que en gran medida son subjetivas. 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.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. es decir. Aseguramiento de la calidad. ya que es preciso adaptarse constantemente a las cambiantes necesidades de los clientes. Se tiende a considerar como una actividad a posteriori. que sirve para detectar si se han alcanzado los niveles de calidad y tomar las medidas oportunas si no ha sido así. Está relacionada con las percepciones del cliente. Gestión de la calidad total. la calidad debe impregnar a todas las áreas de la organización. cuantos más controles se instalen más se incrementaran en los costes derivados de dicho control. 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. Lógicamente. 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. algo que depende de la diferencia entre sus percepciones y sus expectativas. 6 . Los objetivos que se persiguen con las políticas de gestión de la calidad son:  Satisfacción del cliente. Al considerar el valor percibido. pero sin embargo se pueden realizar controles antes.

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

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.. 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. enfocados a los desarrolladores como a los adquisidores de software. ISO (International Organization for Standarization . siguen existiendo problemas: Sigue sin desarrollarse una actividad de mejora. Dado que existen unos procedimientos claramente definidos. comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas. 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. Conformidad con las especificaciones Producción Depto. que se preocupan por realizar metodologías. llamados hardware.Instituto de Ingeniería de Software). Aunque el aseguramiento de la calidad supone algunas mejoras respecto al control de calidad tradicional. por lo que no contribuye significativamente a su satisfacción y fidelización. cualquier cambio supone un riesgo. modelos y/o directrices.. de calidad Filosofía Aseguramiento de la calidad Aptitud para el uso GCT Producción Cliente Depto. Se da por sentado que el cliente se siente satisfecho por recibir su pedido de acuerdo a lo que especificó. Entre las principales se puede mencionar a: SEI (Software Engineering Institute . El tener unos procedimientos formales tan definidos limita de manera considerable la creatividad del personal. 8 . Se conoce como software al equipamiento lógico o soporte lógico de una computadora digital. en contraposición a los componentes físicos del sistema. Control de calidad Concepto de calidad Orientación de la empresa Responsabilidad de la calidad Se actúa porque.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. normas.Instituto de Ingenieros Eléctricos y Electrónicos). cuando realmente él realizar la entrega conforme a lo pactado es algo que el cliente suele dar por supuesto.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). IEEE (Institute of Electrical and Electronics Engineers .

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. 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. La normalización de los productos es. Calidad de Software. o el software de sistema. Estándares. facilitando la interacción con los componentes físicos y con el resto de las aplicaciones.. Garantía de calidad.El significado primario moderno que le siguió fue "lo que es establecido por la autoridad. pues. 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. 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. ejemplo o criterio a seguir.. Normas. un patrón. permite al resto de los programas funcionar adecuadamente. tolerancia. ¿Por qué es necesaria la calidad? Porque la competencia es cada mayor. Calidad de diseño... aplicaciones informáticas.Es asegurarse de que un producto o servicio sea consistente (no variable). la costumbre o el consentimiento general". importante. 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. máquinas de afeitar. Calidad de concordancia.Las normas son un modelo...Es el grado de cumplimiento de las especificaciones del diseño durante su realización Control de calidad. etc. tales como el procesador de textos. y las especificaciones del rendimiento. 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. que. tal como el sistema operativo. En este sentido se utiliza como sinónimo de norma. a tiempo y apegado al presupuesto acordado con el cliente y de que el cliente confié que todo lo anterior se cumplirá. La incompatibilidad repercute en muchos campos. por eso necesario que las empresas se preocupen por dar un mejor producto.Existe una constante preocupación de los investigadores tecnológicos en lo referente a la calidad de sus productos.. 2.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Los componentes lógicos incluyen. pero la calidad de un producto no solo se mide al terminarlo. GENERALIDADES DE LA CALIDAD Algunos DEFINICIONES que nos dan una idea de la aplicación de CALIDAD se dan a continuación:       Calidad. estándar o modelo que pueda ayudarlas a ser competitivas o llegar a la calidad.. Por esto las organizaciones deben buscar una norma. proporcionando también una interfaz para el usuario.Características que especifican los ingenieros de Software para el elemento. confiable (que haga las cosas de forma fiable todo el tiempo) y esté libre de errores y defectos.Consiste en una auditoria cuyo objetivo es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto. 9 . cuando se viaja. Por ejemplo. El grado de materiales. básicamente. entre muchos otros. 1. Son normas y protocolos internacionales que deben cumplir productos de cualquier índole para su distribución y consumo por el cliente final.

 Planificar un proceso de desarrollo adaptando los diferentes estándares elegidos.. 3. En la siguiente tabla se presenta algunos MODELOS QUE REGULAN LA CALIDAD 10 .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. Reducción del proceso de diseño mediante prueba y error. Utilización de los Estándares  Elegir qué estándar se va a seguir o a utilizar. Este término tiene significados diferentes según la rama de la ciencia o la técnica en que se utilice.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.  Revisar el proceso de desarrollo para observar si cumple los estándares adaptados. Procesos.  Aplicar las recomendaciones de los estándares.  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. Mejoras del proceso de diseño.

USA HFES (http://www. no tiene autoridad para imponer sus normas a ningún país.unicei. 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.hfes. por lo tanto.ch) Otros ANSI (http://www. 'igual'). Las normas desarrolladas por ISO son voluntarias. Está compuesta por representantes de los organismos de normalización (ON) nacionales. que produce normas internacionales industriales y comerciales.USA UNI (http://www. La ISO es una red de los institutos de normas nacionales de 163 países.org) IEC – International Electrotechnical Commision (http://www.Italia 11 . en consonancia con el Acta Final de la Organización Mundial del Comercio.org) . Dichas normas se conocen como normas ISO y su finalidad es la coordinación de las normas nacionales. es el organismo encargado de promover el desarrollo de normas internacionales de fabricación.iec. nacida tras la Segunda Guerra Mundial (23 de febrero de 1947). con una Secretaría Central en Ginebra (Suiza) que coordina el sistema. sobre la base de un miembro por país. La Organización Internacional de Normalización (ISO). algunas Instituciones para el desarrollo de estándares son: Internacionales ISO (http://www. comercio y comunicación para todas las ramas industriales a excepción de la eléctrica y la electrónica.iso.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. comprendiendo que ISO es un organismo no gubernamental y no depende de ningún otro organismo internacional. el intercambio de información y contribuir con normas comunes al desarrollo y a la transferencia de tecnologías. De forma concreta. con sede en Ginebra. 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.ansi. ἴσος (isos). con el propósito de facilitar el comercio.it/uni) .org) .

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

y clarifica los conceptos generales.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 9. También es necesario considerar mediciones en el proceso empleado para diseñar. dichas empresas buscan la evaluación de sus procesos y productos de software. La evaluación independiente del producto software viene a ser insuficiente porque su calidad depende en gran medida del proceso empleado para su desarrollo. En esto juega un papel relevante la ISO/IEC 14598. Los productos de software son solo una parte de la historia. Figura. Además. El estándar ISO/IEC 14598 es actualmente usado como base metodológica para la evaluación del producto software. La ISO/IEC 14598 y el proceso para evaluar software (D. 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. A.. 13 . contiene requisitos generales para la especificación y evaluación de la calidad del software. 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. De esta manera. 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). 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. La ISO/IEC 14598 ofrece una visión general. 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. explica la relación entre su serie y el modelo de calidad de la ISO/IEC 9126.) Es importante señalar que. desarrollar. El esfuerzo requerido para acoplar un sistema a otro. COMPATIBILIDAD. Requisitos para compradores (parte 4).(¿Podré hacerlo interactuar con otro sistema?). probar y controlar el producto. define los términos técnicos utilizados. R.

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. Organizaciones encargadas de las evaluaciones del producto de software. Especificar la evaluación.      Audiencia destino para la NORMA ISO 14598 Proveedores de productos de software. 2. Compradores de productos de software. Usuarios del producto y gente que hace su mantenimiento. 3. Esta norma 14598 define el proceso de evaluación y provee los requerimientos y las guías que conducen a evaluaciones de calidad. Véase la ilustración de a continuación 14 . ISO/IEC 14598 . 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. a través de las siguientes 6 partes: I. Ejecutar la evaluación.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN  Requisitos para evaluadores (parte 5). La ISO/IEC 14598-1 está prevista para que se use conjuntamente con la ISO/IEC 9126-1. 4. Establecer los requerimientos de evaluación.Parte 1: Visión General Básicamente. Planear la evaluación. 5. Adicionalmente.

Específicamente. R.) II.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Figura ISO/IEC 14598 .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. Comparación y administración de mejoras dentro la organización. Entrenamiento en tecnología.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.Parte 1: Visión General (D. Identificación e implementación de técnicas de evaluación para software desarrollado y adquirido. se planifican las mediciones y las actividades de evaluación. recopilación de datos y herramientas. A. ISO/IEC 14598 . III. Definición de objetivos organizacionales y de mejora. se incluye:        Preparación de las políticas. en esta parte. ISO/IEC 14598 . Se enfoca en el uso de indicadores que pueden predecir la calidad final del producto midiendo los productos intermedios que se 15 . Asignación de responsabilidades. Identificación de la tecnología. Fundamentalmente.

Véase la ISO/IEC 14598 .Parte 2. De esta manera. el desarrollador realiza un mapeo de los requerimientos internos y externos de calidad. las mediciones actuales son recolectadas. se realizan análisis apropiados y se toman acciones necesarias.Parte 6). acciones de contingencia y de mejora. Especificaciones En esta fase. Es de vital importancia verificar que el productor y las medidas de control requeridas sean técnicamente factibles. 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. por lo tanto. 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. ISO/IEC 14598 .CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN desarrollan durante el ciclo de vida. razonables y alcanzables (dentro de los límites de tiempo). el plan incluirá: cronogramas. deben ser consideradas. para identificar costos versus costos. Entonces. La precisión de las mediciones y técnicas estadísticas deben ser especificadas (véase la ISO/IEC 14598 . designación de responsabilidades. El resultado de esta revisión podría retroalimentar directamente el lanzamiento de futuros productos. Diseño y Planeamiento Los procedimientos requeridos para el análisis y recopilación de datos necesitan ser definidos. 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. uso de herramientas.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. En esta fase también deberá considerarse cómo los resultados de las mediciones impactarán en el desarrollo. 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. Todo esto puede enfocarse por proyecto o por producto. bases de datos y entrenamiento especializado requerido. con relación a las especificaciones. Montaje (Build) y Pruebas Durante la etapa de montaje y pruebas. establecer la validez de las métricas usadas e identificar puntos en los cuales podrían obtenerse beneficios para proyectos futuros. 16 . requerimientos externos de calidad. Y como etapa final del proyecto. Los requerimientos de mediciones resultantes de esta fase deben ser un tipo de mapeo entre las especificaciones de requerimientos. IV. deberá ser conducida una revisión general para determinar la efectividad global del ejercicio de recolección. 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. una vez identificadas las características fundamentales de calidad y el marco de trabajo de mediciones.

Los compradores también podrían ser desarrolladores que desean integrar productos estándar en sus propios diseños de software.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. podría tenerse la necesidad de incluir: Los resultados mismos y la trazabilidad del producto así como información de configuración. En esta parte. 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. Al respecto. Software bajo desarrollo puede ser abordado en puntos discretos durante el desarrollo o cuando esté completo. Problemas. El tiempo de la evaluación necesita ser consistente con los objetivos. Requerimientos en costos y conocimientos.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. las especificaciones de evaluación. o tratarse de desarrolladores buscando herramientas específicas de software. 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. Cronograma de evaluación y arreglos de contingencia. Diseño de la Evaluación El tipo de evaluación depende del tipo de software que está siendo evaluado. resultados y decisiones. las actividades de evaluación y el reporte de evaluación. ISO/IEC 14598 . 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. el diseño de la evaluación. Métodos de recolección de mediciones. Registros de análisis. Métodos y herramientas de reporte. información requerida y métodos de análisis. Especificación de la Evaluación Durante la redacción de las especificaciones. hitos claves y criterio para decisiones de evaluación. procedimientos para la validación y estandarización sobre proyectos futuros. Ejecución de la Evaluación Aunque esta etapa podría ser simplemente un registro en un libro de seguimiento. tienen un rol importante los requerimientos de evaluación. Un plan de evaluación necesita considerar: Necesidades de acceso a la documentación del producto. 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. herramientas de desarrollo y personal. El alcance y lo que cubren los casos de prueba donde sean aplicables referencias a módulos de evaluación. V. Estas etapas son resumidas a continuación: 17 . cuatro etapas son necesarias: Establecimiento de los Requerimientos El alcance de la evaluación necesita ser establecido.

las relaciones con otros documentos. 2. Alcance – Se relaciona con la características de calidad o sub-características que deberán ser alcanzadas. 4. 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. La especificación de las mediciones a ser realizadas. La extensión del la cobertura (o el alcance).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. Las calificaciones e independencia requeridas de un evaluador. 3. VI. la técnica de evaluación usada incluyendo cualquier teoría necesaria) y la aplicabilidad del módulo. 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. Documentación de las interfaces necesarias con herramientas de medición. 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. 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. La identificación de mediciones no determinísticas para asegurar que ciertos niveles de Frecuentabilidad y objetividad requeridos sean obtenidos. 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. La identificación de métodos de correlación con relación a los resultados de las mediciones. ISO/IEC 14598 . Los objetivos de evaluación y métodos de reporte. En esta parte también se considera la administración efectiva de complejidades inherentes a las cuestiones de medición. 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. La verificación de la especificación resultante frente a los requerimientos de evaluació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. 18 . el nivel de la evaluación (tomando en cuenta la importancia de la característica.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. Incluye métodos y técnicas de evaluación más las mediciones actuales resultantes de su aplicación.

nombre del profesor. Nombre de la actividad. 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. Entradas requeridas – Datos a ser recopilados y métricas a ser calculadas. resumen y presentación del tema: “Calidad del Desarrollo del Software” deberá incluir todos los conceptos vistos en clase. 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. 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 . Unidad temática. De igual manera. Instrucciones Desarrollar un mapa conceptual. Información sobre la interpretación de los resultados. matrícula.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Referencias y Definiciones requeridas. 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 alumno(os). fecha. Normalmente. encabezado y pie de página a partir de la segunda página especificando el nombre de la carrera y nombre de la actividad. 5 Legible Portada con los datos generales.

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 .

para distinguir las que aplican al área de desarrollo del software Temas Saber Concepto de métrica. 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. 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.  Métricas para cada uno de los factores anteriores.  Explicar la forma en que inciden. 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. 21 . 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.

si una organización de software mantiene registros sencillos. 2.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. y se explican a continuación: MÉTRICAS TÉCNICAS: Se centran en las características de software por ejemplo: la complejidad lógica. eficiencia. 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. Son medidas directas al software y el proceso por el cual se desarrolla. complejidad. las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto. eficiencia. Evaluar la productividad de la gente que desarrolla el producto. fiabilidad. Indicar la calidad del producto. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente. Razones para medir un producto: 1. el producto se mide para intentar aumentar su calidad. MÉTRICAS DE PRODUCTIVIDAD. y el esfuerzo aplicado. Establecer una línea de base para la estimación 5. las líneas de código producidas. 4. el cómo está hecho. se puede crear una tabla de datos orientados al tamaño como se muestra en la siguiente figura: 22 . el grado de modularidad. 3. complejidad. El proceso para intentar mejorarlo. En la mayoría de los desafíos técnicos. Se centran en el rendimiento del proceso de la ingeniería del software. como el propio producto. calidad. Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. Medidas Indirectas. Es decir que tan productivo va a ser el software que voy a diseñar. derivados del uso de nuevos métodos y herramientas de la ingeniería de software. LAS MÉTRICAS DEL SOFTWARE son las que están relacionadas con el desarrollo del software como funcionalidad. Ayudar a justificar el uso de nuevas herramientas o de formación adicional. el tamaño de memoria y los defectos observados en un determinado periodo de tiempo. 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.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 2. MÉTRICAS ORIENTADAS A LA PERSONA. etc. 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. MÉTRICAS ORIENTADAS AL TAMAÑO. En el proceso de ingeniería se encuentran el costo. Evaluar los beneficios en términos de productividad y de calidad. Se encuentra la funcionalidad. velocidad de ejecución. Mide la estructura del sistema. facilidad de mantenimiento. Son las medidas que voy a hacer de mi personal que va hará el sistema.

1 KLDC (miles de líneas de código) con un esfuerzo de 24 personas mes y un costo de 168 mil dólares. En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puede desarrollar. 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. codificación y prueba.. las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa. 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. Doc/ KLDC Costo = $/KLDC NOTA. dentro del primer año de utilización también sabemos que trabajaron 3 personas en el desarrollo del proyecto.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. diseño. Refiriéndonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12. 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 .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. 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. 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 obtienen las siguientes formulas: Productividad = KLDC/persona-mes Calidad = errores/KLDC Documentación = pags. En lugar de calcularlas las LDC. datos orientados al tamaño de c/u. Son medidas indirectas del software y del proceso por el cual se desarrolla.

Los elementos de datos individuales dentro de un informe se encuentran por separado. 1. 4. Evaluar cada factor en escala 0 a 5. pantalla.01 * SUM(fi)] Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior. Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. o sea una agrupación lógica de datos que puede ser una parte en una gran base de datos o un archivo independiente. media o compleja.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. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado. Número de salida del usuario: se encuentra cada salida que proporciona al usuario información orientada a la aplicación. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos de datos. 3. Los valores del ámbito de información están definidos de la siguiente manera. mensajes de error.65 + 0. Números de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicación. No obstante la determinación de la complejidad es algo subjetivo. Para calcular los puntos de función se utiliza la siguiente relación: PF = CUENTA_TOTAL * [0. Número de archivos: se cuenta cada archivo maestro lógico. 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. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada es denominada simple. 5. En este contexto las salidas se refieren a informes. Se cuenta cada petición por separado. 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. en cinta o discos que son utilizados para transmitir información a otro sistema. 2. 24 .

algunas aplicaciones se les denomina puntos de características. Una vez calculado los puntos de función se usan de forma analógica a las LDC como medida de la productividad. calidad y otros productos del software. 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.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. 25 . La medida del punto de característica da cabida a aplicaciones cuya complejidad algorítmica es alta. Productividad = PF / persona-mes Calidad = Errores / PF Costo = Dólares / PF Documentación = Pags. 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. 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

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

11. Su función es definir y controlar la documentación asociada con el proyecto. marcas de logros y todos los artículos que deben entrar bajo contrato. Se hace un esbozo general de las pruebas y de las herramientas. Se establece un mecanismo para aplicar las modificaciones que se requieran a medida que se desarrolle el sistema. Se analiza cómo se informa del estado del proyecto y se definen las revisiones formales asociadas con el avance de proyecto. Plan de pruebas. Se definen las responsabilidades específicas de los grupos que intervienen en el proyecto. procedimientos y responsabilidades para realizar las pruebas del sistema. 10. Plan de capacitación. 8. Plan de recursos y entregas. Plan de mantenimiento. Se muestra en donde encontrar las cosas dentro del plan. 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.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. 9. Índice. 5. Se describe el procedimiento para instalar el sistema en la localidad del usuario. 12. Plan de documentación. Se establece un bosquejo de los posibles tipos de mantenimiento que se tienen que dar para futuras versiones del sistema. Plan de revisión e informes. Plan de organización. 4. Se resume los detalles críticos del proyecto como fechas programadas. 6. 7. 30 . Plan de control de modificaciones. Plan de instalación y operación. 3.

2007. realizará un diagrama de grant (planeador) en el cual represente todas y cada una de las tareas que están involucradas en el proyecto. plasmarlas en una hoja de Excel y llevar acabo las anotaciones necesarias.2010 Procedimiento: Organizarse en equipos de 3 personas. fechas finales y responsable de esa tarea.. máximo 5 En base a su proyecto. Antecedentes Realizar una lista de actividades que se deben de desarrollar para la gestión de un programa u otra actividad. Materiales y Equipos: Computadora Ms Office 97. 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. Cuestionario Referencias 31 .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. Métricas de software Tema: Planeación de proyectos Objetivo de la práctica: El alumno.2003. 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. discernir las distintas tareas o actividades que se deben de desarrollar en su proyecto. 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.

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

medir sus tiempos. 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. para medir su desempeño. tipificar sus defectos y comparar su desempeño con su estimación inicial. Temas Saber Saber hacer Ser Elementos del Identificar los elementos del Proceso Personal de 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. Resultado de aprendizaje:  Elaborará un documento que contenga las plantillas del PSP Nivel 0 para al menos 3 casos de estudio. 33 .

Principios PSP   La calidad de un sistema software está condicionada por la calidad del peor de sus componentes. Como todo profesional software deberías conocer tu propio rendimiento. 6. deben medir el tiempo que pasan en cada proceso.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. Deberías aprender de tus variaciones de tu rendimiento. seguir y analizar tu trabajo. 7. 5. Deberías medir. El diseño de PSP se basa en los siguientes principios de planeación y de calidad [HUMPHREY. Está condicionada por tu: 1. Para que los desarrolladores lleguen a entender su funcionamiento de manera personal. Deberías incorporar esas lecciones a tu manera personal de hacer. los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos. Para desarrollar productos de calidad. La calidad de un componente software está condicionada por el individuo que lo desarrolló. Finalmente.  Es también un procedimiento definido para ayudarte a mejorar tu rendimiento. Para hacer un trabajo de ingeniería de software de la manera correcta. 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. 34 . los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales. disciplina 3. 95]      Cada ingeniero es esencialmente diferente. conocimiento 2. compromiso 4. Desarrollo de módulos de programas. los defectos que inyectan y remueven de cada proyecto y finalmente medir los diferentes tamaños de los productos que llegan a producir. 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. para ser más precisos.

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

definido y personal. Utiliza tus métodos actuales de diseño y desarrollo. tiempo gastado por fase 4.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. Si bien los scripts describen qué hacer. El propósito de los scripts es el de guiar a los desarrolladores en el uso consistente de los procesos. en realidad se parecen más a checklists que a tutoriales. Proceso (punto de partida) o PSP0 es un proceso sencillo. 1. 2. 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. Recoge datos sobre tu trabajo: 3. Estos no incluyen los materiales instructivos que serían necesarios para usuarios no entrenados. defectos encontrados en compilación y pruebas 5. 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). Proporciona un informe resumen 36 .

El PIP provee una manera estructurada de registrar problemas. Los programadores por lo general se avergüenzan de sus errores. PSP3 presenta métodos para ser usados por individuos en la realización de programas de gran escala. 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.1 agregando un estándar de código.  PSP1 Planeación personal  PSP1 le agrega pasos de planeamiento a PSP0. Se establece un criterio de completitud de diseño y se examinan varias técnicas de verificación y consistencia de diseño. experiencias y sugerencias para mejorar. PSP demuestra el valor de estos métodos en el nivel personal. mejorado para proveer mediciones PSP 0.1 se introduce planeamiento de cronograma y seguimiento del proyecto.  PSP0. mediciones de tamaño y el denominado PIP (Process Improvement Proposal). Esencialmente.1. El proceso de diseño es contemplado en PSP2. es decir. PSP0 es el proceso habitual con el que los desarrolladores escriben software. Proceso cíclico personal Hasta este punto PSP se concentró en el proceso lineal para construcción de pequeños programas. pocos desarrolladores las aplican a su trabajo personal. cuando han terminado que es lo que deben haber obtenido.  Preparar un plan ordenado para realizar su trabajo  Establecer una base para realizar un seguimiento de su trabajo.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 6.1 Se pasa a PSP0. Esto permite medir el progreso y define los cimientos para mejorar.  Mientras que la importancia de estas técnicas en proyectos grandes es comprendida. El paso inicial en PSP consiste en establecer una base que incluya mediciones y un formato de reportes. 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. CALIDAD PERSONAL Un objetivo de PSP es ayudar a los desarrolladores a lidiar de manera realista y objetiva con los defectos que introducen. PSP2 agrega diseño personal y revisiones de código a PSP1.1 también mejora las mediciones para contar separadamente métodos y procedimientos. PSP 2.  Aprender a realizar compromisos que puedan cumplir. 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. PSP3. Estas revisiones ayudan a encontrar defectos de manera temprana y a ver los beneficios que esto proporciona.  En PSP1. El primer paso agrega estimaciones de tamaño y recursos y un reporte de prueba. El objetivo no es decirle a los desarrolladores como diseñar sino orientar el criterio para la finalización del diseño. 37 . 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.

la prueba será más compleja y los beneficios de escalar PSP se pierden. deben recolectar datos de los tiempos que dedican a cada fase del proceso. La primera construcción consiste en un módulo base o kernel que es ampliado en ciclos iterativos. los desarrolladores utilizan información para monitorear su trabajo. En PSP. 38 . 3. 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. Si un incremento anterior tiene muchos defectos. Esta es una razón para enfatizar revisiones de diseño y código en los pasos anteriores de PSP. Para esto. codificación. la cual los ayuda a hacer mejores planes. Recolección de datos. compilación y pruebas. Las medidas básicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso. De esta manera los desarrolladores pueden concentrarse en la verificación de la calidad del último incremento sin preocuparse por defectos en ciclos anteriores. los defectos introducidos y encontrados en cada fase. y de la calidad de esos productos. y los tamaños de los productos desarrollados en líneas de código (LOC). En cada iteración se utiliza un PSP2 completo. de los tamaños de los productos que producen. incluyendo diseño.2 Plantillas PSP En esta sección se observan algunos formatos y procedimientos para la medición del PSP. Estos programas son entonces diseñados para ser desarrollados en pasos incrementales.

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 . 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. 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.

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

es deseable que te manejes con estas definiciones simples de tipos hasta que tengas datos que te puedan guiar en las modificaciones. y las LOC de “nuevo reutilización” ya se encuentran contabilizadas en las LOC agregadas. Luego. 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. Logs de Registro de defectos El estándar de tipos de defectos proporciona un conjunto general de categorías de defectos. En PSP. independientemente del código fuente). Aunque tú puedes reemplazar este estándar por el tuyo propio. Sin embargo. esto se debe a que las LOC modificadas pueden representarse por LOC eliminadas y agregadas. 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. al finalizar el producto. A continuación se muestra un ejemplo: 41 . Estos estándares se utilizaron para llenar los logs de Registro de defectos.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN  Comentarios: Descripción de la interrupción. el tamaño se mide en Líneas de Código (LOC). sin realizar ninguna modificación. 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. 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. 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. se mide el tamaño real obtenido. Esta información permite a los desarrolladores realizar a futuro una estimación de tamaños más precisa. Luego. En PSP. se deben considerar varias categorías de LOC. para que esta información sea útil. Para realizar un seguimiento de la variación del tamaño de un programa durante el desarrollo. para medir el tamaño total de un producto. La tarea que estás haciendo.

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

4 96.79 106.5 6. 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.0 6 5 25 100.2 43. 8.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.14 12.92 4.2 16.0 84.8 100 Para Fecha % 1 5 5 4 21 16.73 10.32 10.) 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.1 7.0 10.47 94.0 Def/Hora 43 .87 5.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 6.2 10. 7.

 Estimación del esfuerzo por casos de uso.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. 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. 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. 44 . 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.

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

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. Fue definida por Allan Albrecht. de IBM. lo primero que debe evaluarse es qué nuevas capacidades estoy adquiriendo. INDEPENDIENTE DE LA TECNOLOGÍA.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. Las métricas o técnicas aseguran que todas las piezas cumplan con parámetros de un plano u hoja de procesos. como lo sería por ejemplo. Sin embargo. etc. el costo de esta simplicidad es que la métrica no es muy sensible a consideraciones muy detalladas. Estas capacidades o funcionalidad estarán en términos de qué transacciones puedo realizar de forma automatizada y qué grupos de datos puedo guardar. 2. Algunos ejemplos de las herramientas usadas para medir son: pie de rey. sonda de profundidad. la complejidad de fórmulas matemáticas. micrómetro de exteriores. A mayor CALIDAD menor tolerancia. Pero más que eso. 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. – Desde su concepción. y también ser útil en cualquiera de las fases de vida del software. A continuación se presentan algunos TIPS para comprender este tema: Se debe cumplir con medidas y evitar desviaciones en una estimación. 46 . En SW no tiene por qué ser distinto. 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. micrómetro de interiores. CARACTERÍSTICAS de la funcionalidad 1. 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.. debo escoger la tecnología que me haga más productivo para obtener tal funcionalidad. Los parámetros y acotaciones se toman como referencia para que una serie sea considerada válida. SIMPLE. tal vez lo relevante de esta característica es que una vez establecida la funcionalidad que requiero. al adquirir un paquete o al desarrollar una aplicación. 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. desde el diseño inicial hasta la explotación y mantenimiento.– Si nos basamos en líneas de código (en la tecnología) vamos a obtener resultados no comparables. este tipo de métrica se planteó que no requiriera grandes esfuerzos para obtener una medida.Es un aspecto importante definida como la desviación máxima permitida en una pieza o proceso. 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. TOLERANCIA.

Paso 2. 4. 5. 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. 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. Determinar el tipo de conteo Este paso consiste en definir el tipo de conteo entre desarrollo.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 3. y la sumatoria de esto nos da los puntos de función sin ajustar. sin tener que ser un experto en sistemas. ENFOQUE EN LA FUNCIONALIDAD PROPORCIONADA.– Esta característica ayuda a que el usuario pueda entender el significado e implicaciones del tamaño del SW. mantenimiento o de una aplicación ya instalada. 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. Identificar los alcances de la medición y los límites de la aplicación. Se puede identificar el procedimiento para la estimación de los puntos de función de la siguiente manera: Paso 1. El propósito de una medición consiste en dar una respuesta a un problema de negocio. Esta es una forma de determinar el objetivo del conteo.– Los resultados obtenidos entre diferentes personas o en proyectos distintos deben ser consistentes. 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. 47 . 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. Por lo que se creó: ISO/IEC 14143 – Information Technology – Software Measurement – Functional Size Measurement. sino que sea estándar para así poderla usar entre empresas o para tener indicadores a nivel industria que todos puedan entender y operar. No es suficiente contar con una métrica. BASADA EN LOS REQUERIMIENTOS DEL USUARIO. El ajuste es un paso final basándose en las características generales de todo el sistema informático que se está contando. antes de cualquier evaluación técnica. CONSISTENCIA.– Ver qué nuevas capacidades voy a obtener con el nuevo SW.

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. 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. en el que la entrada no produce ningún cambio en ningún archivo y la salida no contiene información derivada. 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. EO: Procesos en los que se envía datos al exterior de la aplicación. Se distinguen dos tipos de funciones de datos: Archivo Lógico Interno – es un grupo de datos relacionados que el usuario identifica.es un grupo de datos relacionados y referenciados pero no mantenido por alguna transacción dentro del conteo. EQ: Procesos consistentes en la combinación de una entrada y una salida. Contar las funciones de datos Este paso consiste en identificar y contar la capacidad de almacenamiento de los datos. medio o alto) considerando principalmente el número de 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. A cada componente identificado se le asigna una complejidad (bajo. EIF: Grupos de datos que se mantienen externamente. Paso 3. Paso 4. Archivo de Interfaz Externo . ILF: Grupos de datos relacionados entre sí internos al sistema. 48 . Contar las funciones transaccionales. cuyo propósito principal es almacenar datos mantenidos a través de alguna transacción que se está considerando en el conteo. Este paso consiste en identificar y contar la capacidad de realizar operaciones.

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. Ficheros Externos: No se utilizaron almacenes externos de datos. Salidas del Sistema (EO) No. Consultas: 2 consultas de complejidad baja para el subsistema mostrador. 49 . medio o alto) considerando el número de datos utilizado en el proceso y los archivos referenciados. Entradas al Sistema (EI) No. Entradas: 9 entradas de complejidad alta para el subsistema mostrador. 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. 2 salidas de complejidad baja. Calcular No. Determinar los puntos de función no ajustados.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. Atributos de Entradas x Factor Corrección por Complejidad: No. 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. Paso 5.EIF) Factor Corrección por Complejidad: No. x Factor Corrección por Complejidad: No. 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. 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. Atributos de Salidas x Factor. 3 consultas de complejidad baja 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. Consultas BD (EQ) No.. Ficheros Lógicos Internos: 8 almacenes intermedios de datos de complejidad alta. Ficheros (ILF . 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. 3 entradas de complejidad alta para el subsistema cocina.. 3 salidas de complejidad alta y 1 de complejidad baja para el subsistema cocina.

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 . Dentro de las características hay criterios como: complejidad del proceso. entrada de datos en línea.. e) 4 = Varios teleprocesos pero con el mismo protocolo de comunicaciones.65+[0. Paso 6. 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. etc. multiplicado por 0. Paso 7. Sistema Abierto y con interfaces de todo tipo al exterior. 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.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. (para el presente caso) f) 5 = Hay teleproceso con varios protocolos de comunicación. 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.Obtener Información del Sistema requiere conocimiento global del sistema y construir un Modelo de entidades primarias. Determinar los puntos función ajustados.65 a la sumatoria de los grados de influencia de las 14 características generales del sistema. 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. c) 2 = Aplicación batch con entrada de datos remota y utilización de periféricos de salida remotos. El factor de ajuste se obtiene sumando 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.01.. NOTA: (la sumatoria de las valoraciones de los 14 factores dará el valor para el ACT Nº de Factor Nº de Factor Valor 0. 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. Determinar el valor del factor de ajuste. facilidad de instalación.

está enfocado a medir sistemas informáticos completos. Puntos Función.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.2 Puntos de Casos de Uso Puntos de caso de uso es un método de estimación de esfuerzo para proyectos de software.125 = 2374. En nuestro caso. 4. esto nos puede servir para tener una idea un poco más precisa de la dificultad de los casos de uso e interfaces. si son interfaces con usuarios u otros sistemas. cuando apenas se conocen los casos de uso y sus actores asociados.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. Para resolver esto.  UAW: Factor de peso de los actores sin ajustar. UUCP = UAW + UUCW Estas siglas significan:  UUCP: Puntos de casos de uso sin ajustar.5 horas/persona / 5 personas = 474. a partir de sus casos de uso. 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. basándose en el método de punto de función. no puedo hacer un programa que cuente automáticamente. A los casos de uso se les asigna una complejidad basada en transacciones. tomando en cuenta los pesos de los actores (UAW) y los pesos de los casos de uso (UUCW). es decir. 51 . Ha sido analizado posteriormente en otros estudios. También se utilizan factores de entorno y de complejidad técnica para ajustar el resultado. distintas personas podrían llegar a un conteo diferente. no programas. El método utiliza los actores y casos de uso relevados para calcular el esfuerzo que significará desarrollarlos.91 horas / 100 horas/mes = 4 meses 15 dias HORAS POR PERSONA = 2374.82 Esfuerzo horas/persona = PFA / [1 / 8 persona / hora)] = 296. Así por ejemplo. mientras que a los actores se les asigna una complejidad basada en su tipo.91 horas por miembro DURACIÓN EN MESES = 474. y supervisado por Ivar Jacobson.  UUCW: Factor de peso de los casos de uso sin ajustar. el metro lineal no es lo mejor para medir grandes distancias en el mar. Debido a esto.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. C. se puede proyectar una breve descripción de cada caso de uso.… 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.82 / 0. Fue desarrollado por Gustav Karner en 1993. En este sentido no tiene un nivel de precisión suficiente para medir el tamaño de programas individuales. entendidas como una interacción entre el usuario y el sistema. en el cual se describe de forma breve la funcionalidad que éste debe brindar. Al inicio de un proyecto de software. El UUCP son los puntos de casos de uso sin ajustar.

Factor de peso de los casos de uso sin ajustar (UUCW) 3. • Basado en clases de análisis. TCP/IP) o una persona interactuando a 2 través de una interfaz en modo texto. lo que quiere decir que se ejecutan todas o no se ejecuta ninguna. 3 Tabla 1: Peso de los actores sin ajustar. MÉTODO El método de punto de casos de uso consta de cuatro etapas. este representaría el valor cantidadDeUnTipoDeActor en la fórmula y se tiene que multiplicar por el valor que tenga su factor correspondiente. 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 . se puede obtener una estimación trivial del tamaño y a partir de ella una estimación del esfuerzo. y la cantidad de actores de cada tipo. Una transacción es un conjunto de actividades atómicas. en las que se desarrollan los siguientes cálculos: 1. 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 actores sin ajustar (UAW) Consiste en la evaluación de la complejidad de los actores con los que tendrá que interactuar el sistema. Factor de peso de los casos de uso sin ajustar (UUCW) Este punto funciona muy similar al anterior. Factor de peso de los actores sin ajustar (UAW) 2.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. además evalúa la forma en la que este interactúa con el caso de uso. pero para determinar el nivel de complejidad se puede realizar mediante dos métodos: basado en transacciones o basado en clases de análisis. Una vez terminado esto se procede a sumar cada producto para obtener el UAW. para obtener el resultado por cada tipo de actor. Puntos de caso de uso ajustados (UCP) 4. 2. Medio Otro sistema interactuando a través de un protocolo (ej. Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica (GUI). Este puntaje se calcula determinando si cada actor es una persona u otro sistema. 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). Esfuerzo horas-hombre 1. • 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.

0. según la valoración que se le asigne. 2 T2 Objetivos de performance o tiempo de respuesta. 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. 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. y podrá ser refinada a medida que se obtenga más información. Ahora independientemente del camino utilizado para determinar el tipo de caso de uso. Para una mejor comprensión. 1 T13 Se requiere facilidades especiales de entrenamiento a usuario. 1 Tabla 4: Peso de los factores de complejidad técnica. a continuación se mostrará una tabla con los ítems: Factor Descripción Peso T1 Sistema distribuido.5 T8 Portabilidad. 1 T12 Provee acceso directo a terceras partes. 1 T10 Concurrencia. 1 T6 Facilidad de instalación. cada uno de estos factores tienen un peso definido con los cuales se obtendrá puntos ponderados por cada uno de ellos. UUCP: Puntos de casos de uso sin ajustar. 1 T11 Incluye objetivos especiales de seguridad.5 T7 Facilidad de uso. 53 . 1 T4 Procesamiento interno complejo. 3. 1 T5 El código debe ser reutilizable. Medio De 3 a 4. 1 T3 Eficiencia del usuario final.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Tabla 3: Peso de las clases de análisis. pero permitirá obtener una idea del esfuerzo necesario para llevar adelante el mismo. Una vez hecho esto se suma cada producto para obtener el factor de peso de los casos de uso sin ajustar (UUCW). TCF: Factores técnicos. para obtener el resultado por cada tipo de caso de uso. 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. 2 T9 Facilidad de cambio. 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. 0. EF: Factores ambientales. Esta estimación es bastante imprecisa debido principalmente a la escasa información que se tiene.

que están relacionados con las habilidades y experiencia del grupo de personas involucradas con el desarrollo del proyecto. esto nos va a dar el TCF. pero a través del tiempo se ha ido mejorando. Las fórmulas para este punto son: TFactor = Sum (Valor*Peso) TCF = 0. Anteriormente.5 E5 Motivación.5 E3 Experiencia en orientación a objetos. después se multiplican y se suma cada producto para obtener el TFactor. 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. 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. se obtiene el peso de los factores ambientales (EF).6.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. Estos factores se muestran a continuación: Factor Descripción Peso E1 Familiaridad con el modelo de proyecto utilizado.01 * TFactor) Para realizar este cálculo.5 E2 Experiencia en la aplicación. 1 E4 Capacidad del analista líder.01 y sumar el resultado a 0.03 * EFactor) Para obtener el EFactor se debe sumar todos los productos obtenidos al multiplicar el peso de cada punto por el valor asignado.4 + (-0. Factor Filtro De E1 a E6 Factor < 3 De E7 a E8 Factor > 3 Tabla 7: Factor de el esfuerzo horas-persona. se debe evaluar cada factor.6 + (0. se sugería utilizar 20 horas persona por UCP. 4. después se multiplica por -0. 0. Las fórmulas para este punto son: EFactor = Sum(Valor * Peso) EF = 1.4. también contar la cantidad de estos mismos del E7 y E8 que son mayores que 3. Esfuerzo horas-hombre (E) Este cálculo se realiza con el fin de tener una aproximación del esfuerzo. 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 . se debe seguir la segunda fórmula multiplicando el TFactor por 0. Cada uno de estos factores se debe calificar con un valor de 0 a 5.03 y se le suma el 1. Factores ambientales Los factores sobre los cuales se realiza la evaluación son 8 puntos. asignándole un valor como se menciona anteriormente. 0. pensando solo en el desarrollo según las funcionalidades de los casos de uso. 1. Así. Luego.

Este 40% se refiere al esfuerzo total para el desarrollo de las funcionalidades especificadas en los Casos de Uso.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. 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.persona. UCP: Puntos de Casos de Uso ajustados. Estructurada) Componentes a Identificar: Salidas Entradas Consultas Ficheros Lógicos Internos Ficheros Externos 55 . En la siguiente tabla se detallan la distribución en porcentaje. generalmente un 40%. Si el valor es<=4 Si el valor es>=5 Al realizar la multiplicación del UCP por las horas. se consigue un esfuerzo estimado. que representa una parte del total del esfuerzo de todo el proyecto. El esfuerzo en horas-persona viene dado por: E = UCP x CF Estas siglas significan: E: Esfuerzo estimado en horas-persona. CF: Horas-Persona.

56 . Temas Saber Saber hacer MOPROSOFT Identificar la estructura del modelo de proceso y de evaluación para la industria mexicana de software. desventajas y ejemplos de empresas que los utilizan. Ser Determinar el alcance de Organizado los componentes de las Analítico áreas claves de Sistemático MOPROSOFT. áreas claves del proceso en Sistemático el nivel 2 de CMMI. Resultado de aprendizaje: Elaborará un documento que contenga lo siguiente:  Tabla comparativa entre los modelos MOPROSOFT y CMMI que incluya ventajas. CMMI Identificar la estructura del Determinar el alcance de Organizado modelo integrado de madurez los componentes de las Analítico y capacidad (CMMI).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.

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). 7. concluyéndose en el estudio que no había un modelo de procesos y evaluación que se adaptara 100% a las empresas mexicanas. 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. que tiene como objetivo Fortalecer a la Industria de Software en México. Las estrategias del PROSOFT son: 1. 5. 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. 57 . Feedback para mejora continua. 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. Asegurar que las desviaciones se documenten. 4. Por supuesto que no se trataba de “inventar el hilo negro”. 3. 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. Por lo que se propuso desarrollar un modelo de procesos y un método de evaluación “a la medida” de nuestra industria. Descripción del proceso de desarrollo. en su mayoría PyMES (Pequeña y Mediana empresa). 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. Revisión de Actividades de Ing. 2. 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. 6. 5. Software.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. en el caso del modelo de procesos. y cumplir con los lineamientos de ISO15504. El compromiso era cubrir por lo menos las prácticas del modelo CMM-SW nivel 3 e ISO9000:2000.

Posteriormente. El trabajo se realizó dentro del Subcomité de Software del NYCE (Normalización Y Certificación en Electrónica). definieron las plantillas de los productos y empezaron a implementar los procesos. así como evaluar los resultados para poder proponer cambios que permitan la mejora continua. 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. El objetivo de las pruebas controladas fue demostrar que. las empresas adecuaron los procesos de MoProSoft a sus necesidades.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. sus objetivos y las condiciones para lograrlos. 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. En 2005 todos los esfuerzos se centraron en convertir los dos modelos en la norma mexicana. con el apoyo de una consultora un día a la semana. 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. entre agosto y diciembre. 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. 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 . en un lapso de tiempo relativamente corto. las empresas pueden elevar sus niveles de capacidad y “no morir en el intento”. para lo cual es necesario considerar las necesidades de los clientes.

Procesos requeridos. Presupuesto. Visión. Estrategia de recursos. Cartera de proyectos.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. Estrategias. Valores. Plan de comunicación con el cliente Necesidad de mejora 59 . Objetivos. Estructura de la organización.

Capacitar en el uso de la plantilla para documentarlos Usar diagramas de actividades de UML Producto PLANTILLA PARA DOCUMENTAR LOS PROCESOS Proceso. Indicadores. Nombre del proceso. e implantar las actividades de mejora en los mismos. planear. Realizar una plantilla para documentar los procesos.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. Propósito. Describir las actividades más generales del proceso. 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. 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. Así como definir. Definir las formas de evaluar la efectividad en el cumplimiento de los objetivos del proceso. Responsable y autoridad. Indicar quien es el responsable principal de la ejecución 60 .

Productos internos.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN de este proceso. 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. Cargos de las personas involucradas en este proceso. Tareas que se llevan a cabo en este proceso. Entradas. Subprocesos. Definir los documentos o productos resultados de este proceso. Autoridad es quien comprueba la ejecución y el cumplimiento del propósito del proceso. Actividades. Definir los documentos o productos que sirven de base para este proceso. Esta descripción puede acompañarse de un diagrama de actividades. . Roles. Definir los documentos o productos que se utilizan en este proceso. Lista de procesos de los cuales se compone el proceso en cuestión. 61 . Salidas. Procesos relacionados.

. Gestión de Recursos (GES) Propósito: Conseguir y dotar a la organización de los recursos humanos. Responsable del proyecto. Tareas a realizar en esta categoría: 1. La finalidad es apoyar el cumplimiento de los objetivos del Plan Estratégico de la organización. Describir el proyecto. . 2. Metas cuantitativas del proyecto. 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 .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. Crear y mantener la Base de Conocimiento de la organización. Contrato. Capacitar a los encargados de los involucrados en Moprosoft Crear el Plan operativo de Bienes. ambiente de trabajo y proveedores. . 4. 3. infraestructura. Registrar el proyecto.

Recolectar los reportes de actividades.7 Estudiante: _________ _________ __ Fecha: _________ _ Instructor:_ _________ _________ ___ Progra ma #: ______ Tiemp 50 38 58 62 50 69 28 50 38 . 3. Documentar el Plan del Proyecto la Fecha A 7. Establecer calendario de actividades Plan 12:33 1:16 Actual A 6.8 Postmortem 20 20 16. 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.6 Diseño Realización 0 0 1. Definir el Protocolo de Entrega al Cliente dificadas) 50 3.Compilación 20 reportar los avances y tomar acuerdos. Realizar reuniones con el equipo de trabajo y con el cliente para 20 16. Establecer el Equipo de trabajo 13/9 9:00 9:50 (minutos) 5. Acordar la distribución de la información al equipo de trabajo. mediciones y productos 53 4.2 5. Revisar los productos terminados. 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. Acordar las tareas del equipo de trabajo. 44. Codificación 53de trabajo. 0 2. Estudiante: _Juan Luís Guerra_____ ____ Fecha: _09/10/06__ Programa:_Raíz Cuadrada___ __________ . 6.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. 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. Formalizar el inicio de un nuevo ciclo Planeación 2 2 1. Documentar el Plan de Desarrollo la Fecha% 8.

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

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

en una forma sencilla de seguir y aplicar. Esto hace que el proceso este accesible para todos. dedicado exclusivamente a los problemas del software. 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. Adoptando el framework del RUP (Rational Unified Process ). Una vez definido el proceso. las fechas alargaban más y más. Puede mejorarse: existe el mecanismo para la mejora continua. No se mide. 66 . 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 verifica: los proyectos siguen el proceso establecido. Se valida: el proceso mantiene coherencia con los requerimientos y estándares. los presupuestos se disparaban. No todo el mundo lo conoce. 5. y aun así continuar conformando el acercamiento por RUP. se la pone a disposición de todos los miembros del equipo en su desktop. Es definido: Sistemático. Se exceden los presupuestos. se presentaron diversos estamentos y la Universidad Carnegie Mellon ganó el concurso en 1985. Es controlado: las actualizaciones son notificadas a la empresa. Es practicado: Se utiliza en forma cotidiana. beneficios y rendimiento se cuantifican. Proceso Inmaduro Proceso Maduro Personal. No hay entrenamiento. El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM. No está documentado.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. ayudando a asegurar la comunicación y consistencia y evitando gastar el tiempo determinado cual es el próximo paso a seguir. hacer lo que se dice y medirlo. Se mide: utilización. publicado. Es posible agregarle variantes de procesos o prácticas para customizarlo al proceso de la organización. ¿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. Se aplica a veces solamente. y a ayudar al Departamento de Defensa". en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software. creando el SEI. Es mantenido: es revisado para que cumpla los requisitos. es posible aplicar el proceso que se convirtió en el estándar de ipso de la industria de desarrollo de software. No se cumplen los tiempos de entrega. aprobado y accesible. Es percibido como poco eficiente. No es fácil reproducirlo en nuevos proyectos.2. El personal ha sido entrenado: Ingenieros y gerencia (conocen el proceso). Es apoyado: Gerencia asigna responsables.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. Es documentado. tal como lo es una interfaz web.

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. 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. como también ayudan a una organización a priorizar sus esfuerzos de mejoramiento. en pocas palabras. 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 . CMM es. 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. 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. Este proceso fue desarrollado por Watts 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. provee a las organizaciones de software una guía de cómo aumentar el control de sus procesos de desarrollo y mantenimiento de software. Los diferentes niveles permiten medir la madurez del proceso y evaluar el potencial de él. El modelo de capacidad de madurez (CMM).

el CMMI o "Modelo de Capacidad y Madurez . éste describe un camino de mejoramiento evolutivo para pasar desde un proceso inmaduro a un proceso maduro y disciplinado. Por lo tanto. la eficacia y la eficiencia de la metodología de desarrollo de una organización productora de software. obteniéndose una visión precisa del rigor.En diciembre de 2000. Mediante un amplio conjunto de métricas se determina la calidad de cada una de las áreas clave. Mejora la gestión de la calidad es.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. el SEI publicó un nuevo modelo. en gran medida. 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. el SEI evolucionó la madurez y publicó Capability Maturity Model for Software (CMM). que describen las funciones de ingeniería del software que deben llevarse a cabo para el desarrollo de una buena práctica. CMMI define un conjunto de áreas clave del proceso. 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.Integración". Estos niveles sirven de referencia para el conocimiento del estado de la madurez del proceso del software en la organización. basado en conocimientos adquiridos de evaluaciones de los procesos de software y extensos feedback. agrupadas en cinco niveles inclusivos. las disposiciones del CMM son definitivamente aplicables a todo aquello que esté directamente relacionado con el desarrollo y mantenimiento de sistemas informáticos. 68 .

5.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 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 . Todo esto con el objetivo de realizar algunas mejoras respecto al CMMI (SW-CMM). denominadas características comunes.2.

que permitan mostrar los niveles de madurez de los procesos para producir 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). 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 . 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 a tres niveles (tomados del modelo CMMI). Definido y Optimizado. 71 . los cuales son: Inicial.

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. Eficiencia: Se refiere al logro de objetivos y al aprovechamiento de los recursos disponibles. Hablando de calidad podemos resaltar sus características estas pueden ser: Un requisito físico o químico. una dimensión.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. Al establecer lo que entendemos por calidad se exige un equilibrio entre estas características. atributo. virtud. industrialmente quiere decir. determinante del grado de satisfacción que el producto proporcione al consumidor. don. La calidad no tiene un significado popular de lo mejor en el sentido absoluto. Apto. la encontraremos en el Griego Kalos: Bueno. una temperatura. “Cumplir con las necesidades del cliente y exceder las expectativas en forma constante (siempre). quien en última instancia determina la clase y la calidad del producto que desea. Estándar: Norma. 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. Constituye el acervo de conocimientos de la organización y permite evaluar y mantener vigente la tecnología operativa. utilizado para evaluar o comparar acciones realizadas Efectividad: Se refiere a la capacidad para entregar resultados planeados. etc. una presión o cualquier otro requerimiento que se use para establecer la naturaleza de un producto o servicio.” “Es lo que el cliente dice que necesita más lo que realmente necesita” “Suministrar bienes o servicios que no regresan. servicial y durable. Esta definición nos lleva a pensar en términos como confiable. 72 . mejor dentro de ciertas condiciones del consumidor. Hermoso. De esta actividad deriva el conocimiento y aprendizaje organizacional. Índice: Es la relación cuantitativa entre dos cantidades relacionadas con un mismo fenómeno. 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. Auditoria de calidad: Consiste en la verificación del cumplimiento de las normas. características. Favorable y en el Latín Qualitatem: Propiedad. Análisis: Consiste en la interpretación del desempeño de los procesos para su control y mejora. durante su uso”. 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". términos que en realidad son características individuales que en conjunto constituyen la calidad del producto. ya que es él. por su propiedad. medida de desempeño esperado. "Cualidad" es lo que hace que una persona o cosa sea lo que es.

Desarrolla. de procesos y de recursos que se establecen para llevar a cabo la gestión de calidad. de Procedimientos. productos intermedios y productos finales Diseña y realiza los estudios de estabilidad de los productos intermedios. que incluye la planeación estratégica. es decir es la gerencia o el manejo de los proceso productivos enfocada al mejoramiento continuo. frecuencias y responsables. 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. entre los que se incluyen: Indicadores de control. Sistema: Es un conjunto de elementos con un fin común.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. Aseguramiento de Calidad: Consiste en tener y seguir un conjunto de acciones planificadas y sistemáticas. es el acto de delimitar responsabilidad y autoridad con el fin de liberar la gerencia de detalles innecesarios. implantadas dentro del Sistema de Calidad de la empresa. Cubre dos aspectos fundamentales y diferenciados. la asignación de recursos y otras acciones sistemáticas en el campo de la calidad. ejecución y perfeccionamiento del Sistema de Calidad. de calibración. Sistema de calidad: Es el conjunto de la estructura de organización de responsabilidades. sus productos y servicios. efectividad. 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. (Forma parte de las políticas generales de una organización. que se interrelacionan entre sí. En la terminología industrial Control. Sistema de medición: Es el medio a través del cual se obtiene información sobre el desempeño de la organización. ejecuta o coordina la ejecución de los métodos de ensayo para determinar las características de calidad de las materias primas. uno es el decidir la combinación de ingredientes que dará gusto apropiado (Ingeniería de la calidad). Se refiere al esquema predeterminado de referencia que define los sistemas y prácticas de calidad de la organización. Política de calidad: Directrices y objetivos generales de una empresa relativos a la calidad. materiales. Se integra por diversos elementos. Participa en el desarrollo. formando un todo dinámico. Corresponde a las necesidades propias de una organización para satisfacer los objetivos de calidad propuesto 73 . medición. expresados formalmente por la dirección general. Es el aspecto de la función general de la gestión que determina y aplica la política de la calidad. y otro el asegurar que nuestra producción tenga la combinación de ingredientes que considere apropiados (Control de calidad). Técnicas y actividades de carácter operativo utilizadas para satisfacer los requisitos relativos a la calidad. congruentes con los Principios y Valores de Calidad. tales como la planeación de la calidad. 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. conservando los medios para asegurarse de que los resultados sean satisfactorios. eficiencia y adaptabilidad/flexibilidad Métodos de muestreo.