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

II.Además de propiciar la realización de trabajos futuros aplicados a su entorno.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. V. Esta información en su mayoría ha sido colectada de libros. Introducción a la Calidad en el Desarrollo de Software. IV. Se integran prácticas a los temas para fortalecer el aprendizaje significativo del alumno. 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). Métricas de Software Proceso Personal de Desarrollo de Software Técnicas de Estimación Modelos para el Aseguramiento de la Calidad de Software Cada uno de estas unidades cuenta con información que sustenta cada uno de los temas contenido en la unidad. DESARROLLO El manual está compuesto por 5 unidades temáticas: I. Con la finalidad de que el alumno pueda aplicar algunos de los conocimientos adquiridos durante el desarrollo de la asignatura. El objetivo principal del documento es brindar al alumno información que le permita al alumno identificar. Además de motivar en él. en este manual se integran prácticas (casos) que le permitirán comprender conceptos y procesos de realización de un sistema bajo cierta normatividad de gestión (reglas o normas). analizar. el autoestudio. permitiéndoles solucionar problemas en función de los conocimientos adquiridos de automatización de sistemas. para brindar al alumno información seria y de calidad. 4 . sitios de internet. III. la investigación y la auto práctica.

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

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

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

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

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

Utilización de los Estándares  Elegir qué estándar se va a seguir o a utilizar. Prácticas que han funcionado tanto para el desarrollador como para el usuario. Procesos.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.  Revisar el proceso de desarrollo para observar si cumple los estándares adaptados. Este término tiene significados diferentes según la rama de la ciencia o la técnica en que se utilice. Mejoras del proceso de diseño.Conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa o simultáneamente) con un fin determinado.. 3. En la siguiente tabla se presenta algunos MODELOS QUE REGULAN LA CALIDAD 10 . Reducción del proceso de diseño mediante prueba y error.  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.  Planificar un proceso de desarrollo adaptando los diferentes estándares elegidos.  Aplicar las recomendaciones de los estándares.

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

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

El estándar ISO/IEC 14598 es actualmente usado como base metodológica para la evaluación del producto software. desarrollar. Figura. según sea la especialidad aplicada al software. También es necesario considerar mediciones en el proceso empleado para diseñar. Además. 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. El esfuerzo requerido para acoplar un sistema a otro. COMPATIBILIDAD.) Es importante señalar que. En esto juega un papel relevante la ISO/IEC 14598.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 9. probar y controlar el producto.. De esta manera. contiene requisitos generales para la especificación y evaluación de la calidad del 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.(¿Podré hacerlo interactuar con otro sistema?). Estos factores con los que cuenta la calidad en el desarrollo de software se encuentran dispersos en muchas normas y estándares. 13 . explica la relación entre su serie y el modelo de calidad de la ISO/IEC 9126. 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. Requisitos para compradores (parte 4). La ISO/IEC 14598 ofrece una visión general. dichas empresas buscan la evaluación de sus procesos y productos de software. la serie de normas ISO/IEC 14598 proporciona un marco de trabajo para evaluar la calidad de todos los tipos de productos de software e indica los requisitos para los métodos de medición y para el proceso de evaluación. R. 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). Este artículo presenta una exploración sobre el mismo. La ISO/IEC 14598 y el proceso para evaluar software (D. y clarifica los conceptos generales. A. define los términos técnicos utilizados. Los productos de software son solo una parte de la historia.

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

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

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

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

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

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

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 . CONOCIMIENTO (SABER) Requisitos de Identifica correctamente todos los instrumentos Información para obtener información. Identificó el instrumento más viable dependiendo Requisitos de del problema que se le planteo.

 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 .CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática Métricas de Software. Identificar métrica.  Métricas para cada uno de los factores anteriores. determinado Ser P Autodidacta Analítico Habilidad para la comunicación oral y escrita Habilidad para el trabajo en equipo Proactivo Organizado Autodidacta Analítico Sistemático Habilidad para la comunicación oral y escrita Habilidad para el trabajo en equipo Resultado de aprendizaje: Elaborará un documento que contenga una tabla en donde relacione lo siguiente:  Factores y características que determinan la calidad en el desarrollo de software. 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. para distinguir las que aplican al área de desarrollo del software Temas Saber Concepto de métrica.

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

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

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

25 . algunas aplicaciones se les denomina puntos de características. 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. Productividad = PF / persona-mes Calidad = Errores / PF Costo = Dólares / PF Documentación = Pags. Una vez calculado los puntos de función se usan de forma analógica a las LDC como medida de la productividad. La medida del punto de característica da cabida a aplicaciones cuya complejidad algorítmica es alta. Sin embargo. 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 y otros productos del software.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Los valores constantes de la ecuación anterior y los factores de peso aplicados en las encuestas de los ámbitos de información han sido determinados empíricamente.

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

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

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

Cuestionario Referencias 31 .2003. máximo 5 En base a su proyecto. plasmarlas en una hoja de Excel y llevar acabo las anotaciones necesarias.. 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.2007.2010 Procedimiento: Organizarse en equipos de 3 personas. fechas finales y responsable de esa tarea. Métricas de software Tema: Planeación de proyectos Objetivo de la práctica: El alumno. Materiales y Equipos: Computadora Ms Office 97. Antecedentes Realizar una lista de actividades que se deben de desarrollar para la gestión de un programa u otra actividad.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Nombre de la Práctica: Elaboración de un plan de trabajo (gráfica de gant) Unidad Temática: I. Dividir en sub-actividades cada una de las tareas o actividades primarias indicando o marcando intervalos de tiempo específicos a estas Una vez hecho lo anterior deberán de nombrar a un responsable el cual tenga el control y sepa la dirección de proyecto a emprender o desarrollar. discernir las distintas tareas o actividades que se deben de desarrollar en su proyecto. 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. realizará un diagrama de grant (planeador) en el cual represente todas y cada una de las tareas que están involucradas en el proyecto.

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

33 . 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. tipificar sus defectos y comparar su desempeño con su estimación inicial.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática III Proceso Personal de Desarrollo de Software Objetivo:El alumno identificará el Proceso Personal de Software. Temas Saber Saber hacer Ser Elementos del Identificar los elementos del Proceso Personal de PSP. medir sus tiempos. para medir su desempeño. Resultado de aprendizaje:  Elaborará un documento que contenga las plantillas del PSP Nivel 0 para al menos 3 casos de estudio.

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

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

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

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

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

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. Todos estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los ingenieros usan como guía en su trabajo. defectos y tamaño Un programa probado Un resumen del Plan de Proyectos con los datos estimados y actuales Las tablas de Registro de Tiempos y Defectos Rellenos 39 .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.

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

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

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

1 7. 7.32 10.2 16.) Planing Diseño Código Revisión código Compilación Test Postmortem Total Tiempo Máximo Tiempo Mínimo Introducción de defectos Planing Diseño Código Revisión código Compilación Test Total Fecha: 18/10/96 Programa # 13 Lenguaje: C++ Plan Actual a la Fecha 5.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 6.2 43.5 6.8 100 Para Fecha % 1 5 5 4 21 16.4 96.14 12.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.92 4. 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 Def/Hora 43 .47 94.0 10.0 84.73 10.0 6 5 25 100.2 10.79 106. 8.87 5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

El modelo de capacidad de madurez (CMM). Los diferentes niveles permiten medir la madurez del proceso y evaluar el potencial de él. La arquitectura del modelo está compuesta por niveles que describen la madurez de la organización y por áreas claves de procesos KPAs (Key Process Areas). universal y uniforme(institucionalizadas)  Medidas  Verificadas 67 . buscaron mejorar el proceso de software y desarrollaron un marco de trabajo que llamaron proceso de madurez. Éste concepto cuenta con cinco etapas evolutivas que se enfocan en la implementación de prácticas de calidad. una aplicación de TQM para software Niveles madurez Nivel 1 Inicial Nivel 2 Repetible Nivel 3 Definido Nivel 4 Gestionado Nivel 5 Optimizado de Áreas Claves Ninguna Gestión de configuraciones Garantía de calidad Gestión subcontratación del software Seguimiento y supervisión del proyecto Planificación del proyecto Gestión de requisitos Revisiones periódicas Coordinación entre grupos Ingeniería de productos de software Gestión de integración del software Programa de formación Definición de procesos de la organización Enfoque del proceso de la organización Gestión de calidad de software Gestión cualitativa del proceso Gestión de cambios del proceso Gestión de cambios de tecnología Prevención de defectos Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:  Definidas en un procedimiento documentado  Provistas (la organización) de los medios y formación necesarios  Ejecutadas de un modo sistemático. provee a las organizaciones de software una guía de cómo aumentar el control de sus procesos de desarrollo y mantenimiento de software.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. CMM es. Este proceso fue desarrollado por Watts S. 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. en pocas palabras. Fue diseñado para guiar a las organizaciones de software en la selección de estrategias para el mejoramiento de procesos mediante la determinación de la madurez de los procesos actuales e identificando los elementos más críticos de la calidad de software y del mejoramiento de procesos. como también ayudan a una organización a priorizar sus esfuerzos de mejoramiento.

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

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

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 . que permitan mostrar los niveles de madurez de los procesos para producir software. I SO 9000 – 3 y CMMI con el objetivo de proveer las especificaciones para el desarrollo de software.

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

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

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

Sign up to vote on this title
UsefulNot useful