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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Identificó el instrumento más viable dependiendo Requisitos de del problema que se le planteo.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.

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

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

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

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

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. 25 . calidad y otros productos del software. La medida del punto de característica da cabida a aplicaciones cuya complejidad algorítmica es alta. algunas aplicaciones se les denomina puntos de características.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Los valores constantes de la ecuación anterior y los factores de peso aplicados en las encuestas de los ámbitos de información han sido determinados empíricamente. 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. Sin embargo.

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

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

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

26

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

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

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

27

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

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

Elaboración de Formatos para Métricas

Unidad Temática:

I. Métricas de software

Tema:

Métricas de Software

Objetivo de la práctica:

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

Tiempo de la Práctica:
Descripción:

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

28

1. Cuestionario Referencias ESTIMACIÓN Es una pequeña planeación sobre qué es lo que va a ser mi proyecto. fase de diseño de bajo nivel. anticipado problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. de la duración cronológica del proyecto y del costo. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos. Asociada con cada fase debe de haber una fecha que 29 . El proyecto se desglosa en partes más pequeñas que se estiman individualmente. Cuando se planifica un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido. 3. etc. Como bases para la realización de estimaciones se usan métricas del software de proyectos pasados. PLANEACIÓN DEL PROYECTO La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance. todas tienen en común los siguientes atributos. la asignación de prioridad al proceso de su producción. Una de las actividades cruciales del proceso de gestión del proyecto del software es la planificación. que dure aproximadamente lo mismo que el trabajo anterior. Se han desarrollado varias técnicas de estimación para el desarrollo de software. de la duración cronológica del esfuerzo humano requerido. Pero qué pasa si el proyecto es totalmente distinto entonces puede que la experiencia obtenida no sea lo suficiente. No se analizara la planeación que implica a la estimación de la necesidad de un sistema de software y la habilidad de producir tal sistema. Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programación. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo proyecto requiera aproximadamente la misma cantidad de esfuerzo. 2.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Procedimiento: Organizarse en equipos de 3 personas. Hace una descripción general del proyecto detalle de la organización del plan y resume el resto del documento. Panorama. Se han de establecer de antemano el ámbito del proyecto. sin embargo estos puntos son válidos también para sistemas pequeños. 1. Plan de fases. fase de diseño de alto nivel. 2. aunque cada una tiene sus puntos fuertes y sus puntos débiles. máximo 5 Analice y determine los requerimientos de información necesarios para la conformación del nuevo formato para determina la métrica de un sistema. Se 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 analiza cómo se informa del estado del proyecto y se definen las revisiones formales asociadas con el avance de proyecto. Se hace un esbozo general de las pruebas y de las herramientas. 9. Se establece un mecanismo para aplicar las modificaciones que se requieran a medida que se desarrolle el sistema. 5. Plan de revisión e informes. 12. 8. 3. 6. Se establece un bosquejo de los posibles tipos de mantenimiento que se tienen que dar para futuras versiones del sistema. Plan de mantenimiento. Se muestra en donde encontrar las cosas dentro del plan. Plan de organización. 7. Se describe el procedimiento para instalar el sistema en la localidad del usuario.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. 11. Plan de documentación. marcas de logros y todos los artículos que deben entrar bajo contrato. Plan de instalación y operación. 4. 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. Índice. Su función es definir y controlar la documentación asociada con el proyecto. procedimientos y responsabilidades para realizar las pruebas del sistema. Se definen las responsabilidades específicas de los grupos que intervienen en el proyecto. Plan de recursos y entregas. 10. Plan de control de modificaciones. Plan de pruebas. 30 . Se resume los detalles críticos del proyecto como fechas programadas. Plan de capacitación.

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

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

Resultado de aprendizaje:  Elaborará un documento que contenga las plantillas del PSP Nivel 0 para al menos 3 casos de estudio. para medir su desempeño. 33 . medir sus tiempos. Software (PSP) Organizado Sistemático Plantillas PSP Organizado Analítico Sistemático Disciplinado Identificar los formatos y Determinar su nivel procedimientos para la personal de desarrollo al medición del PSP. 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.

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

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

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

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

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

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

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

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

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

14 12.87 5.0 Def/Hora 43 .CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 6.79 106.0 6 5 25 100.2 16.2 10.4 96. 7.2 43.90 58 72 41 426 243 Plan 47 258 Plan 18 35 149 20 24 64 33 343 Actual 22 24 93 37 4 8 41 229 Para Fecha 88 151 637 111 92 240 160 1479 Actual Para Fecha Para Fecha % 6.0 10.) 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.32 10.5 6.1 7. 8.8 100 Para Fecha % 1 5 5 4 21 16. 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.47 94.0 84.73 10.92 4.

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

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

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

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

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

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

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 . Determinar el valor del factor de ajuste. Dentro de las características hay criterios como: complejidad del proceso.65+[0. PFSA = PFTe + PFTo + PFTq + PFTif + PFTef Componente Bajo Medio Alto Total EI Eb * 3 = _ Em * 4 = _ Ea * 6 = _ PFTe EO Ob * 4 = _ Om * 5 = _ Oa * 7 = _ PFTo EQ Qb * 3 = _ Qm * 4 = _ Qa * 6 = _ PFTq ILF IFb * 7 = _ IFm * 10 = _ IFa * 15 = _ PFTif EIF EFb * 5 = _ EFm * 7 = _ EFa * 10 = _ PFTef PFSA. El factor de ajuste se obtiene sumando 0. facilidad de instalación. c) 2 = Aplicación batch con entrada de datos remota y utilización de periféricos de salida remotos. Determinar los puntos función ajustados.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. entrada de datos en línea. (para el presente caso) f) 5 = Hay teleproceso con varios protocolos de comunicación. NOTA: (la sumatoria de las valoraciones de los 14 factores dará el valor para el ACT Nº de Factor Nº de Factor Valor 0. Paso 6. Para determinar los puntos función ajustados se consideran los puntos función no ajustados por el factor de ajuste Obtener los PF Ajustados 5 Componentes Identificados Entradas PFSA = 306 PFA=PFSA* [0. multiplicado por 0. Sistema Abierto y con interfaces de todo tipo al exterior.. Paso 7..65 a la sumatoria de los grados de influencia de las 14 características generales del sistema. d) 3 = Aplicación de captura de datos En-Línea o hay un sistema de teleproceso que pasa los datos a la aplicación batch o sistema de consulta. e) 4 = Varios teleprocesos pero con el mismo protocolo de comunicaciones. Cálculo de los Puntos de Función Sin Ajustar PFSA = PFTe + PFTo + PFTq + PFTif + PFTef PFSA = 106 + 146 + 39 + 15 + 0 = 306 PF Componente Bajo Medio Alto Total EI 6 * 3 = 18 4 * 4 = 16 12 * 6 = 72 106 EO 4 * 4 = 16 5 * 5 = 25 15 * 7 = 105 146 EQ 7 * 3 = 21 0 * 4 = 0 3 * 6 = 18 39 ILF 0 * 7 = 0 0 * 10 = 0 1 * 15 = 15 15 EIF 0 * 5 = 0 0 * 7 = 0 0 * 10 = 0 0 306 Obtener los PF Ajustados Obtener Ajuste de la Complejidad Técnica 5 El sistema para determinar la valoración de uno de los Factores de Ajuste: Ej: Comunicación de Datos: Los datos usados en el sistema se envían o reciben por líneas de comunicaciones.Obtener Información del Sistema requiere conocimiento global del sistema y construir un Modelo de entidades primarias.01.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. etc. 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.

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

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

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

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

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

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

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

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

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

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

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

Contrato. Describir el proyecto. Tareas a realizar en esta categoría: 1. infraestructura. La finalidad es apoyar el cumplimiento de los objetivos del Plan Estratégico de la organización. ambiente de trabajo y proveedores.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. Metas cuantitativas del proyecto. . . Servicios e Infraestructura Crear el Plan operativo de Recursos Humanos y Ambiente de trabajo Crear el Plan operativo de Conocimiento de la organización 62 . . Responsable del proyecto. 2. Crear y mantener la Base de Conocimiento de la organización. 3. 4. Capacitar a los encargados de los involucrados en Moprosoft Crear el Plan operativo de Bienes. Registrar el proyecto.

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

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

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

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

buscaron mejorar el proceso de software y desarrollaron un marco de trabajo que llamaron proceso de madurez. 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. 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. El modelo de capacidad de madurez (CMM). como también ayudan a una organización a priorizar sus esfuerzos de mejoramiento. 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. provee a las organizaciones de software una guía de cómo aumentar el control de sus procesos de desarrollo y mantenimiento de software. CMM es. Éste concepto cuenta con cinco etapas evolutivas que se enfocan en la implementación de prácticas de calidad.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. Los diferentes niveles permiten medir la madurez del proceso y evaluar el potencial de él. en pocas palabras. universal y uniforme(institucionalizadas)  Medidas  Verificadas 67 . 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). Este proceso fue desarrollado por Watts S.

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

denominadas características comunes. Todo esto con el objetivo de realizar algunas mejoras respecto al CMMI (SW-CMM).2 Características comunes:      Compromiso de realización Capacidad para llevarla a cabo Actividades que hay que realizar Medición y análisis Verificación de la implementación 69 . 5.2.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.

I SO 9000 – 3 y CMMI con el objetivo de proveer las especificaciones para el desarrollo de software. El estándar se basa en la dimensión del proceso (tomada del modelo ISO 15504/SPICE).CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Modelo de Desarrollo de Software PROPUESTA DE ESTÁNDAR (Proyecto) El siguiente estándar está basado en los modelos 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.

71 . 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). Definido y Optimizado.

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

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

Sign up to vote on this title
UsefulNot useful