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

sitios de internet. III. 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. V. II. analizar. 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). 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). IV. 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. Esta información en su mayoría ha sido colectada de libros. 4 . permitiéndoles solucionar problemas en función de los conocimientos adquiridos de automatización de sistemas. 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. DESARROLLO El manual está compuesto por 5 unidades temáticas: I. Introducción a la Calidad en el Desarrollo de Software. el autoestudio. para brindar al alumno información seria y de calidad.

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

ya que es preciso adaptarse constantemente a las cambiantes necesidades de los clientes. Constituye el objetivo prioritario. 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. Esta nueva concepción de la calidad presenta importantes implicaciones. Lógicamente. que sirve para detectar si se han alcanzado los niveles de calidad y tomar las medidas oportunas si no ha sido así.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Desde el enfoque tradicional de calidad que había sido centrarse únicamente en tratar de evitar que se produjesen fallos durante la fabricación. Es un concepto dinámico. Se tiende a considerar como una actividad a posteriori. es decir. cuantos más controles se instalen más se incrementaran en los costes derivados de dicho control. Figura “Representación esquemática del proceso de control de calidad” Gestión de la calidad total En esta etapa el objetivo es proporcionar productos o servicios capaces de satisfacer al cliente. Gestión de la calidad total. pero sin embargo se pueden realizar controles antes. 6 . Los objetivos que se persiguen con las políticas de gestión de la calidad son:  Satisfacción del cliente. la calidad debe impregnar a todas las áreas de la organización. algo que depende de la diferencia entre sus percepciones y sus expectativas. Al considerar el valor percibido. que en gran medida son subjetivas. Aseguramiento de la calidad. 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. es decir. durante y después de haber obtenido los resultados instalando sensores en aquellas fases que se quieren controlar. Control de Calidad El control de calidad apareció en los años 30 y adquirió gran importancia en los 50 y 60. Está relacionada con las percepciones del cliente.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática Métricas de Software. Saber hacer el concepto de Tipos de métricas de Identificar los tipos de Seleccionar las métricas calidad de software. 21 .  Explicar la forma en que inciden. para distinguir las que aplican al área de desarrollo del software Temas Saber Concepto de métrica. Objetivo: El alumno identificará el concepto y los tipos de métricas. 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.  Métricas para cada uno de los factores anteriores. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 7.47 94.4 96.2 10. 7.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.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN 6.14 12.87 5.0 10.79 106.8 100 Para Fecha % 1 5 5 4 21 16.32 10.0 6 5 25 100. 8.73 10.5 6.0 84.0 Def/Hora 43 .92 4.2 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.2 43.) 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.

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. 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. 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.  Estimación del esfuerzo por casos de uso.CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Unidad Temática IV Técnicas de Estimación Objetivo: El alumno empleará las técnicas de estimación para determinar el tamaño del software y el esfuerzo requerido.

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

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

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

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

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. 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. Consultas: 2 consultas de complejidad baja para el subsistema mostrador.. Atributos de Ficheros x + Puntos de Función Sin Ajustar Puntos de Función Ajustados Ajuste de Complejidad Técnica Estimación del Esfuerzo Estimación del Tiempo de Desarrollo Datos de Productividad del Equipo Escala de 14 Factores de Complejidad Estimación del Presupuesto. medio o alto) considerando el número de datos utilizado en el proceso y los archivos referenciados. Entradas al Sistema (EI) No. 3 consultas de complejidad baja para el subsistema cocina. 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. 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. Determinar los puntos de función no ajustados. 49 . 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. Calcular No. Atributos de Entradas x Factor Corrección por Complejidad: No. 2 salidas de complejidad baja. Ficheros (ILF .. Salidas del Sistema (EO) No. 3 entradas de complejidad alta para el subsistema cocina. Ficheros Externos: No se utilizaron almacenes externos de datos. Ficheros Lógicos Internos: 8 almacenes intermedios de datos de complejidad alta. Consultas BD (EQ) No. Este paso consiste en sumar el número de componentes de cada tipo conforme a la complejidad asignada y utilizar la siguiente tabla para obtener el total.EIF) Factor Corrección por Complejidad: No. x Factor Corrección por Complejidad: No. Atributos de Salidas x Factor.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. Paso 5. 3 salidas de complejidad alta y 1 de complejidad baja para el subsistema cocina. Entradas: 9 entradas de complejidad alta para el subsistema mostrador.

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. Paso 7.5 1 Comunicación de Datos 4 2 Proceso Distribuido 4 3 Objetivos de Rendimiento 1 4 Configuración de Explotación Compartida 1 5 Tasa de transacciones 3 6 Entrada de Datos en Línea 5 7 Eficiencia con el Usuario Final 2 8 Actualizaciones en Línea 3 9 Lógica de Proceso Interno Compleja 1 10 Reusabilidad del Código 1 11 Conversión e Instalación contempladas 0 12 Facilidad de Operación 1 13 Instalaciones Múltiples 2 14 Facilidad de Cambios 4 Ajuste de Complejidad Técnica (ACT) 32 50 . multiplicado por 0. Determinar los puntos función ajustados.65 a la sumatoria de los grados de influencia de las 14 características generales del sistema.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. El factor de ajuste se obtiene sumando 0. facilidad de instalación.Obtener Información del Sistema requiere conocimiento global del sistema y construir un Modelo de entidades primarias. 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. 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. c) 2 = Aplicación batch con entrada de datos remota y utilización de periféricos de salida remotos.01. Determinar el valor del factor de ajuste. (para el presente caso) f) 5 = Hay teleproceso con varios protocolos de comunicación. Dentro de las características hay criterios como: complejidad del proceso. NOTA: (la sumatoria de las valoraciones de los 14 factores dará el valor para el ACT Nº de Factor Nº de Factor Valor 0. etc.65+[0. entrada de datos en línea.. Paso 6.. 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. 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.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. Sistema Abierto y con interfaces de todo tipo al exterior.

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

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

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

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

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

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

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

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

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

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

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

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

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.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. 44.7 63 Prueba 25 25 20. Revisar los productos terminados. 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. Realizar reuniones con el equipo de trabajo y con el cliente para 20 16. 0 2. 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.8 Postmortem 20 20 16.Compilación 20 reportar los avances y tomar acuerdos. Definir el Protocolo de Entrega al Cliente dificadas) 50 3. Formalizar el inicio de un nuevo ciclo Planeación 2 2 1. Revisar las solicitudes de cambio del cliente. Acordar las tareas del equipo de trabajo.2 5. 6. Documentar el Plan del Proyecto la Fecha A 7.6 Diseño Realización 0 0 1. Documentar el Plan de Desarrollo la Fecha% 8. Establecer calendario de actividades Plan 12:33 1:16 Actual A 6. 3.7 Estudiante: _________ _________ __ Fecha: _________ _ Instructor:_ _________ _________ ___ Progra ma #: ______ Tiemp 50 38 58 62 50 69 28 50 38 . Acordar la distribución de la información al equipo de trabajo. mediciones y productos 53 4. Codificación 53de trabajo. Recolectar los reportes de actividades.

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

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

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

CALIDAD EN EL DESARROLLO DE SOFTWARE TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN El “nacimiento” de CMM se da en el año de 1986 cuando el Software Engineering Institute (SEI) junto con MITRE Corporation. provee a las organizaciones de software una guía de cómo aumentar el control de sus procesos de desarrollo y mantenimiento de software. Este proceso fue desarrollado por Watts S. universal y uniforme(institucionalizadas)  Medidas  Verificadas 67 . Éste concepto cuenta con cinco etapas evolutivas que se enfocan en la implementación de prácticas de calidad. El modelo de capacidad de madurez (CMM). 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. Los diferentes niveles permiten medir la madurez del proceso y evaluar el potencial de él. buscaron mejorar el proceso de software y desarrollaron un marco de trabajo que llamaron proceso de madurez. CMM es. Humphrey en 1986 y está basado en el concepto de la administración de la calidad total Total Quality Management (TQM) por sus siglas en inglés. como también ayudan a una organización a priorizar sus esfuerzos de mejoramiento. en pocas palabras. La arquitectura del modelo está compuesta por niveles que describen la madurez de la organización y por áreas claves de procesos KPAs (Key Process Areas). 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.

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful