calidad en el desarrollo de software

Universidad Tecnológica de Puebla

Antología:

Calidad en el Desarrollo de Software

Cuatrimestre: Enero Abril 2011

COLABORADORES:M.C. María Micaela López Monterrosas

Ing. Claudia Sánchez Morales

Calidad en el Desarrollo de SoftwarePágina 2 de 82

Indice

Introducció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, se evolucionó según tres etapas: Control de calidad, Aseguramiento de la calidad, Gestión de la calidad total.

I. Control de Calidad

El control de calidad apareció en los años 30 y adquirió gran importancia en los 50 y 60. 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 tiende a considerar como una actividad a posteriori, es decir, que sirve para detectar si se han alcanzado los niveles de calidad y tomar las medidas oportunas si no ha sido así, pero sin embargo se pueden realizar controles antes, durante y después de haber obtenido los resultados instalando sensores en aquellas fases que se quieren controlar. Lógicamente, 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”

II. Gestión de la calidad total

En esta etapa el objetivo es proporcionar productos o servicios capaces de satisfacer al cliente, algo que depende de la diferencia entre sus percepciones y sus expectativas. Esta nueva concepción de la calidad presenta importantes implicaciones.

1. Está relacionada con las percepciones del cliente, que en gran medida son subjetivas.

Ingeniería en Tecnologías de la Información y Comunicación


2. Es un concepto dinámico, ya que es preciso adaptarse constantemente a las cambiantes necesidades de los clientes.

3. Al considerar el valor percibido, 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, es decir, la calidad debe impregnar a todas las áreas de la organización.

Los objetivos que se persiguen con las políticas de gestión de la calidad son:

1. Satisfacción del cliente. Constituye el objetivo prioritario. 2. Conseguir hacer las cosas bien a la primera. 3. Eliminar todo aquello que no añada valor. Evitar despilfarros. 4. Mejorar la capacidad de reacción del sistema mediante:

• Productos y servicios personalizados. • Desarrollo rápido de nuevos productos y servicios. • Anticipación a las necesidades del cliente.

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, operaciones, procesos y departamentos de una organización (es decir, extendidas a toda la organización) que tiene como objetivo enviar productos o servicios libres de defectos, en el plazo requerido y que satisfagan plenamente a los clientes, así como elevar el nivel de calidad de todas las operaciones de la empresa, 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.

III. Aseguramiento de la calidad

El aseguramiento de la calidad son todas aquellas acciones, llevadas cabo sistemáticamente, que están destinadas a obtener un proceso productivo que asegure que el producto o servicio satisfará los requerimientos de calidad. En definitiva, la filosofía que sustenta esta etapa es que la calidad se construye en los procesos: si cada proceso se realiza correctamente, no existe ningún motivo para que aparezcan defectos y, en consecuencia, no será necesario controlar la calidad del producto obtenido. La cultura de la empresa incorpora la idea de hacer las cosas bien a la primera.



Un elemento característico del aseguramiento de la calidad es el Manual de Calidad, en el que se recogen los procedimientos adecuados para realizar cada proceso, y se incluyen todas las actividades en todas las etapas hasta la obtención del producto final. Podríamos decir que el este manual es “la Biblia del sistema de aseguramiento de la calidad”.

Para que el sistema pueda ser certificado por terceros ha de estar elaborado de acuerdo a normas establecidas, como la serie ISO 9000. Una vez desarrollado el sistema de acuerdo a alguna de estas normas, existen autoridades de certificación que evalúan dicho sistema y en caso de cumplir los requerimientos de calidad necesarios, certifican a la organización. El objetivo de la certificación es doble:

1. Alcanzar y mantener la calidad del producto o servicio para satisfacer al cliente.2. Proporcionar garantías al cliente de que el producto o servicio que se le ofrece

cumple unos determinados estándares de calidad.

La vigilancia de que el proceso se realice de acuerdo al procedimiento establecido es responsabilidad de los auditores de calidad.

Pasos fundamentales en el aseguramiento de la calidad:

1. Establecer un sistema y evaluar su adecuación. De esta manera se obtiene el Manual de Calidad.

2. Auditar el sistema para verificar que las disposiciones se están implementando. 3. Revisar el sistema de manera continua, de forma que se compruebe que se

sigue trabajando del modo adecuado y que el producto tiene las características prescritas.

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. Aunque el aseguramiento de la calidad supone algunas mejoras respecto al control de calidad tradicional, siguen existiendo problemas:

1. Sigue sin desarrollarse una actividad de mejora. Dado que existen unos procedimientos claramente definidos, cualquier cambio supone un riesgo.

2. El tener unos procedimientos formales tan definidos limita de manera considerable la creatividad del personal.

3. Se da por sentado que el cliente se siente satisfecho por recibir su pedido de acuerdo a lo que especificó, cuando realmente él realizar la entrega conforme a lo pactado es algo que el cliente suele dar por supuesto, por lo que no contribuye significativamente a su satisfacción y fidelización.



Control de calidad Aseguramiento de la calidad

GCT

Concepto de calidad Conformidad con las especificaciones

Aptitud para el uso Satisfacción del cliente

Orientación de la empresa

Producción Producción Cliente

Responsabilidad de la calidad

Depto. de calidad Depto. de calidad + operarios

Todos los miembros

Se actúa porque... Se detecta un error Se intenta evitar el error Hay objetivos Aplicación de la calidad Al producto Al proceso productivo A todos los procesos de la

empresa Actuación

Corregir el error Modificar el procedimiento Mejora continua

Actitud

Reactiva Reactiva Proactiva

Participación del personal

Sólo Depto. de calidad Depto. de calidad + operarios

Toda la empresa

Importancia de la participación

No se espera participación Importante Imprescindible

Generación de valor añadido

No está claro Si Si

Materialización

Plan de inspección Manual de calidad Sistema de gestión

Filosofía

Arreglo Prevención Mejora

Existen entidades internacionales reconocidas, que se preocupan por realizar metodologías, normas, estándares, modelos y/o directrices, enfocados a los desarrolladores como a los adquisidores de software. Entre las principales se puede mencionar a: SEI (Software Engineering Institute - Instituto de Ingeniería de Software), IEEE (Institute of Electrical and Electronics Engineers - Instituto de Ingenieros Eléctricos y Electrónicos), ISO (International Organization for Standarization - 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).



UNIDAD I

INTRODUCCIÓN A LA CALIDAD EN EL DESARROLLO DE SOFTWARE

Se conoce como software al equipamiento lógico o soporte lógico de una computadora digital; comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos del sistema, llamados hardware.

Los componentes lógicos incluyen, entre muchos otros, aplicaciones informáticas; tales como el procesador de textos, que permite al usuario realizar todas las tareas concernientes a la edición de textos; o el software de sistema, tal como el sistema operativo, que, básicamente, permite al resto de los programas funcionar adecuadamente, facilitando la interacción con los componentes físicos y con el resto de las aplicaciones, proporcionando también una interfaz para el usuario.

1.1 GENERALIDADES DE LA CALIDAD

Algunos DEFINICIONES que nos dan una idea de la aplicación de CALIDAD se dan a continuación:

Calidad.- Es asegurarse de que un producto o servicio sea consistente (no variable), confiable (que haga las cosas de forma fiable todo el tiempo) y esté libre de errores y defectos.

Calidad de diseño.- Características que especifican los ingenieros de Software para el elemento. El grado de materiales, tolerancia, y las especificaciones del rendimiento.

Calidad de concordancia.- Es el grado de cumplimiento de las especificaciones del diseño durante su realización

Control de calidad.- Serie de inspecciones revisiones y pruebas utilizados a lo largo del proceso de Software para asegurarse de que cumple con los requisitos que le han sido asignados.

Garantía de calidad.- Consiste en una auditoria cuyo objetivo es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto.

Calidad de Software.- Existe una constante preocupación de los investigadores tecnológicos en lo referente a la calidad de sus productos. 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, por eso necesario que las empresas se preocupen por dar un mejor producto, pero la calidad de un producto no solo se



mide al terminarlo. Hoy en día las necesidades de buscar una solución a problemas complejos en el software ha ocasionado que las empresas dedicadas al desarrollo o mantenimiento de software sean rebasadas, es decir que no sean capaces de desarrollar o entregar un software confiable, a tiempo y apegado al presupuesto acordado con el cliente y de que el cliente confié que todo lo anterior se cumplirá. Por esto las organizaciones deben buscar una norma, estándar o modelo que pueda ayudarlas a ser competitivas o llegar a la calidad.

1. Normas.- Las normas son un modelo, un patrón, ejemplo o criterio a seguir. Una norma es una fórmula que tiene valor de regla y tiene por finalidad definir las características que debe poseer un objeto y los productos que han de tener una compatibilidad para ser usados a nivel internacional. Por ejemplo, el problema que ocasiona a muchos usuarios los distintos modelos de enchufes que existen a escala internacional para poder acoplar pequeñas máquinas de uso personal: secadores de cabello, máquinas de afeitar, etc. cuando se viaja. La incompatibilidad repercute en muchos campos. La normalización de los productos es, pues, importante.

2. Estándares.- El significado primario moderno que le siguió fue "lo que es establecido por la autoridad, la costumbre o el consentimiento general". En este sentido se utiliza como sinónimo de norma. Son normas y protocolos internacionales que deben cumplir productos de cualquier índole para su distribución y consumo por el cliente final.

Beneficios de los Estándares

• Buenas prácticas de diseño.• Prácticas que han funcionado tanto para el desarrollador como para el usuario.• Mejoras del proceso de diseño.• Reducción del proceso de diseño mediante prueba y error.

Utilización de los Estándares

• Elegir qué estándar se va a seguir o a utilizar.• Planificar un proceso de desarrollo adaptando los diferentes estándares

elegidos.• Aplicar las recomendaciones de los estándares.• Revisar el proceso de desarrollo para observar si cumple los estándares

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


http://es.wikipedia.org/wiki/Norma_(tecnolog%C3%ADa)


3. Procesos.- Conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa o simultáneamente) con un fin determinado. Este término tiene significados diferentes según la rama de la ciencia o la técnica en que se utilice.

En la siguiente tabla se presenta algunos MODELOS QUE REGULAN LA CALIDAD

Característica

PSP Inspecciones CMM ISO 9000

Propósito Gerenciamiento y mejora de la calidad

Mejora de la calidad

Mejora del gerenciamiento

Gerenciamiento de la calidad

Metodología Prescriptiva Presciptiva Descriptiva Descriptiva

Definición Exacta Exacta Vaga Vaga

Audiencia Desarrolladores y gerentes

Desarrolladores Gerentes Gerentes


http://es.wikipedia.org/wiki/T%C3%A9cnica

http://es.wikipedia.org/wiki/Ciencia


Cobertura Ciclo de vida del desarrollo

Verificación y validación

Gerenciamiento de proyectos

Aseguramiento de la Calidad

Costo Muy bajo Bajo Alto AltoCalidad Muy alta Alta Baja BajaImplementación

Semanas Días Años Años

Alcance Integral Estrecho Ambiguo Ambiguo

Cuan Mensurable es

Muy Alto Alto Bajo Bajo

INSTITUTOS QUE REGULAN LA CALIDAD

La Organización Internacional para la Estandarización o ISO (del griego, σοςἴ (isos), 'igual'), nacida tras la Segunda Guerra Mundial (23 de febrero de 1947), es el organismo encargado de promover el desarrollo de normas internacionales de fabricación, comercio y comunicación para todas las ramas industriales a excepción de la eléctrica y la electrónica. 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.

La ISO es una red de los institutos de normas nacionales de 163 países, sobre la base de un miembro por país, con una Secretaría Central en Ginebra (Suiza) que coordina el sistema. La Organización Internacional de Normalización (ISO), con sede en Ginebra, 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.

Las normas desarrolladas por ISO son voluntarias, comprendiendo que ISO es un organismo no gubernamental y no depende de ningún otro organismo internacional, por lo tanto, no tiene autoridad para imponer sus normas a ningún país. Está compuesta por representantes de los organismos de normalización (ON) nacionales, que produce normas internacionales industriales y comerciales. Dichas normas se conocen como normas ISO y su finalidad es la coordinación de las normas nacionales, en consonancia con el Acta Final de la Organización Mundial del Comercio, con el propósito de facilitar el comercio, el intercambio de información y contribuir con normas comunes al desarrollo y a la transferencia de tecnologías.

De forma concreta, algunas Instituciones para el desarrollo de estándares son:

Internacionales

ISO (http://www.iso.org)

IEC – International Electrotechnical Commision (http://www.iec.ch)


http://es.wikipedia.org/wiki/Organizaci%C3%B3n_Mundial_del_Comercio

http://es.wikipedia.org/wiki/Ginebra_(ciudad)

http://es.wikipedia.org/wiki/Suiza

http://es.wikipedia.org/wiki/Ginebra_(ciudad)

http://es.wikipedia.org/wiki/Segunda_Guerra_Mundial


Otros

ANSI (http://www.ansi.org) - USA

HFES (http://www.hfes.org) - USA

UNI (http://www.unicei.it/uni) - Italia

1.2 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. En adición a los costos de la falta de calidad y lo beneficios de tenerla.

Cuando se habla de calidad, se refiere a los atributos mensurables de un producto.

En el caso del software lo que se pretende es controlar la variación del proceso que se aplica para el desarrollo del mismo, los recursos que consumimos y los atributos de calidad del producto final. Para ello nos basamos en tres ejes:

1. Concordancia con los requerimientos.2. Cumplir con estándares especificados.3. Requisitos implícitos.

Costos de la calidad:

• Prevención de futuros problemas.• Planificar.• Revisiones.• Capacitación.• Recursos Humanos.

Costos de la no calidad:

• Costos de corrección de errores.• Resolución de quejas.• Devolución.• Imagen.• Soporte.



Algunos FACTORES y/o características que determinan la calidad del software son:

1. FUNCIONALIDAD.- (¿Puedo probarlo?). El esfuerzo requerido para probar un programa con el fin de asegurar que realiza su función requerida.

2. CORRECCIÓN.- (¿Hace lo que quiero?). El grado en que un programa satisface sus especificaciones y consigue los objetivos de la misión encomendada por el cliente.

3. CONFIABILIDAD.- (¿Lo hace de forma fiable todo el tiempo?). El grado en que un programa lleva a cabo sus funciones esperadas con la precisión requerida.

4. EFICIENCIA.- (¿Se ejecutará en mi hardware lo mejor que pueda?). La cantidad de recursos de computadora y de código requeridos por un programa para llevar a cabo sus funciones.

5. USABILIDAD.- (¿Podré reusar alguna parte del software?). El grado en que un programa (o parte de un programa) se puede reusar en otras aplicaciones. Esto va relacionado con el empaquetamiento y el alcance de las funciones que realiza el programa.

6. MANTENIBILIDAD.- (¿Puedo corregirlo?). El esfuerzo requerido para localizar y arreglar un error en un programa.

7. PORTABILIDAD.- (¿Podré usarlo en otra máquina?). El esfuerzo requerido para transferir el programa desde un hardware y/o entorno de sistemas de software a otro).

8. ROBUSTEZ.- (¿Es muy grande el programa?). Tamaño del programa.9. COMPATIBILIDAD.- (¿Podré hacerlo interactuar con otro sistema?). El esfuerzo

requerido para acoplar un sistema a otro.

Estos factores con los que cuenta la calidad en el desarrollo de software se encuentran dispersos en muchas normas y estándares, según sea la especialidad aplicada al software. A continuación se trata una NORMA conocida como:

EVALUACIÓN DEL PRODUCTO SOFTWARE: ISO 14598

Introducción

Muchas empresas de desarrollo de software han reconocido la necesidad de mejorar el producto software. La evaluación independiente del producto software viene a ser insuficiente porque su calidad depende en gran medida del proceso empleado para su desarrollo. De esta manera, dichas empresas buscan la evaluación de sus procesos y productos de software. El estándar ISO/IEC 14598 es actualmente usado como base metodológica para la evaluación del producto software. Este artículo presenta una exploración sobre el mismo.

Los productos de software son solo una parte de la historia. También es necesario considerar mediciones en el proceso empleado para diseñar, desarrollar, probar y



controlar el producto. En esto juega un papel relevante la ISO/IEC 14598. La ISO/IEC 14598 ofrece una visión general, explica la relación entre su serie y el modelo de calidad de la ISO/IEC 9126, define los términos técnicos utilizados, contiene requisitos generales para la especificación y evaluación de la calidad del software, y clarifica los conceptos generales. Además, provee un marco de trabajo para evaluar la calidad de todos los tipos de productos de software y establece requisitos para métodos de medición y evaluación de los productos de software.

Figura. La ISO/IEC 14598 y el proceso para evaluar software (D. A. R.)

Es importante señalar que, 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. 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). Requisitos para evaluadores (parte 5).

La ISO/IEC 14598-1 está prevista para que se use conjuntamente con la ISO/IEC 9126-1.



Audiencia destino para la NORMA ISO 14598• Proveedores de productos de software. • Compradores de productos de software. • Organizaciones encargadas de las evaluaciones del producto de software. • Usuarios del producto y gente que hace su mantenimiento.

Alcance de la NORMA ISO 14598El 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. Esta norma 14598 define el proceso de evaluación y provee los requerimientos y las guías que conducen a evaluaciones de calidad, a través de las siguientes 6 partes:

I. ISO/IEC 14598 - Parte 1: Visión General

Básicamente, provee una visión general de las otras cinco partes y explica la relación entre la evaluación del producto software y el modelo de calidad definido en la ISO/IEC 9126. Adicionalmente, hace la presentación del proceso de evaluación desglosado en los siguientes pasos:

• Establecer los requerimientos de evaluación. • Especificar la evaluación. • Planear la evaluación. • Ejecutar la evaluación. • Véase la ilustración de a continuación



Figura ISO/IEC 14598 - Parte 1: Visión General (D. A. R.)

II. ISO/IEC 14598 - 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. Fundamentalmente, en esta parte, se planifican las mediciones y las actividades de evaluación. Específicamente, se incluye:

Preparación de las políticas.

Definición de objetivos organizacionales y de mejora.

Identificación de la tecnología.

Asignación de responsabilidades.

Identificación e implementación de técnicas de evaluación para software desarrollado y adquirido.



Entrenamiento en tecnología, recopilación de datos y herramientas.

Comparación y administración de mejoras dentro la organización.

III. 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. Se enfoca en el uso de indicadores que pueden predecir la calidad final del producto midiendo los productos intermedios que se desarrollan durante el ciclo de vida. 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.

Entonces, una vez identificadas las características fundamentales de calidad y el marco de trabajo de mediciones, 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. Véase la ISO/IEC 14598 - Parte 2.

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. Es de vital importancia verificar que el productor y las medidas de control requeridas sean técnicamente factibles, razonables y alcanzables (dentro de los límites de tiempo).

Especificaciones En esta fase, el desarrollador realiza un mapeo de los requerimientos internos y externos de calidad, con relación a las especificaciones.

Los requerimientos de mediciones resultantes de esta fase deben ser un tipo de mapeo entre las especificaciones de requerimientos, requerimientos externos de calidad, 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. Todo esto puede enfocarse por proyecto o por producto.

Diseño y Planeamiento Los procedimientos requeridos para el análisis y recopilación de datos necesitan ser definidos. De esta manera, el plan incluirá: cronogramas, designación de responsabilidades, uso de herramientas, bases de datos y entrenamiento especializado requerido. La precisión de las mediciones y técnicas estadísticas deben ser especificadas (véase la ISO/IEC 14598 - Parte 6). En esta fase también deberá considerarse cómo los resultados de las mediciones impactarán en el desarrollo; por lo tanto, acciones de contingencia y de mejora, deben ser consideradas.



Montaje (Build) y Pruebas Durante la etapa de montaje y pruebas, las mediciones actuales son recolectadas, se realizan análisis apropiados y se toman acciones necesarias. 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.

Y como etapa final del proyecto, deberá ser conducida una revisión general para determinar la efectividad global del ejercicio de recolección, para identificar costos versus costos, establecer la validez de las métricas usadas e identificar puntos en los cuales podrían obtenerse beneficios para proyectos futuros. El resultado de esta revisión podría retroalimentar directamente el lanzamiento de futuros productos.

IV. ISO/IEC 14598 - 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 pre-desarrollado. 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. Los compradores también podrían ser desarrolladores que desean integrar productos estándar en sus propios diseños de software, o tratarse de desarrolladores buscando herramientas específicas de software. Al respecto, cuatro etapas son necesarias:

Establecimiento de los Requerimientos El alcance de la evaluación necesita ser establecido. Los requerimientos para la calidad del software definidos en la ISO/IEC 9126 pueden ser usados como punto de partida pero otros aspectos como el costo y el de cumplimiento a regulaciones deberán ser también considerados. El tiempo de la evaluación necesita ser consistente con los objetivos; 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.

Especificación de la Evaluación Durante la redacción de las especificaciones, 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.

El alcance y lo que cubren los casos de prueba donde sean aplicables referencias a módulos



de evaluación.

Métodos de recolección de mediciones, información requerida y métodos de análisis.



Diseño de la Evaluación

El tipo de evaluación depende del tipo de software que está siendo evaluado. Software bajo desarrollo puede ser abordado en puntos discretos durante el desarrollo o cuando esté completo. Un plan de evaluación necesita considerar:

o Necesidades de acceso a la documentación del producto, herramientas de desarrollo y personal.

o Requerimientos en costos y conocimientos.

o Cronograma de evaluación y arreglos de contingencia, hitos claves y criterio para decisiones de evaluación.

o Métodos y herramientas de reporte, procedimientos para la validación y estandarización sobre proyectos futuros.

Ejecución de la Evaluación Aunque esta etapa podría ser simplemente un registro en un libro de seguimiento, podría tenerse la necesidad de incluir:

• Los resultados mismos y la trazabilidad del producto así como información de configuración.

• Registros de análisis, resultados y decisiones.

• Problemas, 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.

V. ISO/IEC 14598 - 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. En esta parte, tienen un rol importante los requerimientos de evaluación, las especificaciones de evaluación, el diseño de la evaluación, las actividades de evaluación y el reporte de evaluación. Estas etapas son resumidas a continuación:

Requerimientos de Evaluación



Los requerimientos deberían adicionalmente definir:

a. La extensión del la cobertura (o el alcance).

b. Los objetivos de evaluación y métodos de reporte.

c. Las calificaciones e independencia requeridas de un evaluador.

Especificación de la Evaluación Las especificaciones adicionalmente deberían cubrir:

a. Definición del alcance y formato en las métricas empleadas identificando como deberán ser derivadas a partir de los requerimientos del producto.

b. La identificación de mediciones no determinísticas para asegurar que ciertos niveles de Frecuentabilidad y objetividad requeridos sean obtenidos.

c. La identificación de métodos de correlación con relación a los resultados de las mediciones.

d. Se tienen identificadas tres sub-actividades con relación a la especificación de la evaluación:

e. El análisis de la descripción del producto.

f. La especificación de las mediciones a ser realizadas.

g. La verificación de la especificación resultante frente a los requerimientos de evaluación.

VI. ISO/IEC 14598 - 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. 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. Incluye métodos y técnicas de evaluación más las mediciones actuales resultantes de su aplicación. En esta parte también se considera la administración efectiva de complejidades inherentes a las cuestiones de medición.



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.

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. Dichos módulos proveen:

• Visibilidad de la información necesitada para cuadrar con requerimientos específicos de calidad.

• Documentación de las interfaces necesarias con herramientas de medición.

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, las relaciones con otros documentos, los Requerimientos técnicos y una razón para el módulo.

Alcance – Se relaciona con la características de calidad o sub-características que deberán ser alcanzadas, el nivel de la evaluación (tomando en cuenta la importancia de la característica, la técnica de evaluación usada incluyendo cualquier teoría necesaria) y la aplicabilidad del módulo.

Referencias y Definiciones requeridas.

Entradas requeridas – Datos a ser recopilados y métricas a ser calculadas.

Información sobre la interpretación de los resultados.

Resultados de la Evaluación En esta etapa se tiene la generación del reporte de evaluación incluyendo una revisión independiente de los resultados de la evaluación. Normalmente, 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.



Unidad II

M ét r i c a s d e S o f t w a r e

2.1 Concepto de Métrica

Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad.

En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad.

Razones para medir un producto:

1. Indicar la calidad del producto.2. Evaluar la productividad de la gente que desarrolla el producto.3. Evaluar los beneficios en términos de productividad y de calidad, derivados del uso de nuevos métodos y herramientas de la ingeniería de software.4. Establecer una línea de base para la estimación5. Ayudar a justificar el uso de nuevas herramientas o de formación adicional.

2.2 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. En el proceso de ingeniería se encuentran el costo, y el esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución, el tamaño de memoria y los defectos observados en un determinado periodo de tiempo.

Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc.

LAS MÉTRICAS DEL SOFTWARE son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia, y se explican a continuación:



MÉTRICAS TÉCNICAS: Se centran en las características de software por ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho.

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. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.

MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseñar.

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. Son las medidas que voy a hacer de mi personal que va hará el sistema.

MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño como se muestra en la siguiente figura:

La tabla lista cada proyecto del desarrollo del software de los últimos años correspondientes, datos orientados al tamaño de c/u. Refiriéndonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12.1 KLDC (miles de líneas de código) con un esfuerzo de 24 personas mes y un costo de 168 mil dólares. 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, diseño, codificación y prueba. 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, dentro del primer año de utilización también sabemos que trabajaron 3 personas en el desarrollo del proyecto.



En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puede desarrollar, para cada proyecto un conjunto de métricas sencillas de productividad y calidad orientadas al tamaño. Se obtienen las siguientes formulas:

Productividad = KLDC/persona-mesCalidad = errores/KLDCDocumentación = pags. Doc/ KLDCCosto = $/KLDC

NOTA.- persona-mes es el esfuerzo

MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa.

Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función. Los puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas del dominio de información del software y valoraciones subjetivos de la complejidad del software.

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”

Se determinan 5 características del ámbito de la información y los cálculos aparecen en la posición apropiada de la tabla. Los valores del ámbito de información están definidos de la siguiente manera.



1. Números de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicación. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado.

2. Número de salida del usuario: se encuentra cada salida que proporciona al usuario información orientada a la aplicación. En este contexto las salidas se refieren a informes, pantalla, mensajes de error. Los elementos de datos individuales dentro de un informe se encuentran por separado.

3. 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. Se cuenta cada petición por separado.

4. Número de archivos: se cuenta cada archivo maestro lógico, o sea una agrupación lógica de datos que puede ser una parte en una gran base de datos o un archivo independiente.

5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir información a otro sistema.

Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinación de la complejidad es algo subjetivo.

Para calcular los puntos de función se utiliza la siguiente relación:

PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior.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.

Evaluar cada factor en escala 0 a 5.



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.

Una vez calculado los puntos de función se usan de forma analógica a las LDC como medida de la productividad, calidad y otros productos del software.

Productividad = PF / persona-mesCalidad = Errores / PFCosto = Dólares / PFDocumentación = Pags. Doc / PF

La medida de puntos de función se diseño originalmente para ser utilizadas en aplicación de sistemas de información de gestión. Sin embargo, algunas aplicaciones se les denomina puntos de características.

La medida del punto de característica da cabida a aplicaciones cuya complejidad algorítmica es alta. Las aplicaciones de software de tiempo real de control de procesos y de sistemas que encontrados tienden a tener una complejidad algorítmica alta y por tanto fácilmente tratables por puntos de características.



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



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ónSe tiene un sistema el cual cuenta con 3 entradas de catalogo 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.



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 = ?

ESTIMACIÓN

Es una pequeña planeación sobre qué es lo que va a ser mi proyecto. Una de las actividades cruciales del proceso de gestión del proyecto del software es la planificación. Cuando se planifica un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido, de la duración cronológica del esfuerzo humano requerido, de la duración cronológica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo proyecto requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Pero qué pasa si el proyecto es totalmente distinto entonces puede que la experiencia obtenida no sea lo suficiente.

Se han desarrollado varias técnicas de estimación para el desarrollo de software, aunque cada una tiene sus puntos fuertes y sus puntos débiles, todas tienen en común los siguientes atributos.

1. Se han de establecer de antemano el ámbito del proyecto.



2. Como bases para la realización de estimaciones se usan métricas del software de proyectos pasados.

3. El proyecto se desglosa en partes más pequeñas que se estiman individualmente.

PLANEACIÓN DEL PROYECTO

La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance, anticipado problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. 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. 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, la asignación de prioridad al proceso de su producción.

Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programación, sin embargo estos puntos son validos también para sistemas pequeños.

Panorama. Hace una descripción general del proyecto detalle de la organización del plan y resume el resto del documento.Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos, fase de diseño de alto nivel, fase de diseño de bajo nivel, etc. Asociada con cada fase debe de haber una fecha que especifique cuando se debe terminar estas fases y una indicación de como se pueden solapar las distintas fases del proyecto.Plan de organización. Se definen las responsabilidades específicas de los grupos que intervienen en el proyecto.Plan de pruebas. Se hace un esbozo general de las pruebas y de las herramientas, procedimientos y responsabilidades para realizar las pruebas del sistema.Plan de control de modificaciones. Se establece un mecanismo para aplicar las modificaciones que se requieran a medida que se desarrolle el sistema.Plan de documentación. Su función es definir y controlar la documentación asociada con el proyecto.Plan de capacitación. 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 revisión e informes. Se analiza cómo se informa del estado del proyecto y se definen las revisiones formales asociadas con el avance de proyecto.Plan de instalación y operación. Se describe el procedimiento para instalar el sistema en la localidad del usuario.Plan de recursos y entregas. Se resume los detalles críticos del proyecto como fechas programadas, marcas de logros y todos los artículos que deben entrar bajo contrato.Índice. Se muestra en donde encontrar las cosas dentro del plan.



Plan de mantenimiento. Se establece un bosquejo de los posibles tipos de mantenimiento que se tienen que dar para futuras versiones del sistema.

ERRORES CLASICOS EN UN PROYECTO DE SOFTWARE

1. Mal análisis en los requerimientos.2. Una mala planeación.3. No tener una negociación (documento, contrato) con el cliente.4. No hacer un análisis costo beneficio.5. Desconocer el ambiente de trabajo de los usuarios.6. Desconocer los usuarios que trabajan con el sistema.7. Mala elección de recursos (hardware, software, humanos).



Unidad III

P r o ce s o P e r s o n a l d e D e s a r r o l l o d e S o f t w a r e

3.1 Elementos del Proceso Personal de Software (PSP)

¿Qué es el PSP?

• Un PSP es un proceso personal desarrollar software que tiene:

1. pasos definidos

2. formularios

3. estándares

• Un PSP es un marco de trabajo de medición y análisis que te ayuda a caracterizar tu proceso.

• Es también un procedimiento definido para ayudarte a mejorar tu rendimiento.

Principios PSP

• La calidad de un sistema software está condicionada por la calidad del peor de sus componentes.

• La calidad de un componente software está condicionada por el individuo que lo desarrolló.

• Está condicionada por tu:

1. conocimiento

2. disciplina

3. compromiso

• Como todo profesional software deberías conocer tu propio rendimiento.

• Deberías medir, seguir y analizar tu trabajo.

• Deberías aprender de tus variaciones de tu rendimiento.

• Deberías incorporar esas lecciones a tu manera personal de hacer.



El diseño de PSP se basa en los siguientes principios de planeación y de calidad [HUMPHREY; 95]

• Cada ingeniero es esencialmente diferente; para ser más precisos, los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales.

• Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos.

• Para hacer un trabajo de ingeniería de software de la manera correcta, los ingenieros deben planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un proceso bien definido para realizar de la mejor manera la planeación del trabajo.

• Para que los desarrolladores lleguen a entender su funcionamiento de manera personal, deben medir el tiempo que pasan en cada proceso, los defectos que inyectan y remueven de cada proyecto y finalmente medir los diferentes tamaños de los productos que llegan a producir.

• Finalmente, 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. Desarrollo de módulos de programas.

2. Definición de requisitos o procesos.

3. Realización de revisiones o pruebas.

4. Escritura de documentación, etc.

5. El PSP se puede extender al desarrollo de sistemas software de gran tamaño.

6. Es un proceso de Nivel 5 para los individuos y es un prerrequisito para el TSP

• PSP se introduce con siete pasos compatibles.

• Escribes uno o dos pequeños programas en cada paso.

• Recoges y analizas los datos de tu trabajo.

• Los usas y analizas para mejorar tu trabajo.



• Comenzando con los requerimientos, el primer paso en el proceso de PSP es la planificación.

Existe un script de planificación que sirve de guía y un resumen del plan para registrar todos los datos del mismo. Mientras los desarrolladores van siguiendo el lineamiento de trabajo sugerido por los scripts, deben ir registrando los tiempos dedicados y los datos de defectos en los logs de tiempos y defectos. Al final de la tarea, durante la fase de postmortem (PM), deben resumir los datos de tiempo y defectos, medir el tamaño del programa, e ingresar esos datos en el formulario de sumario del plan. Al finalizar, deben entregar el producto finalizado y el formulario de sumario del plan completado.

Debido a que generalmente ciertos métodos de PSP no son utilizados por los desarrolladores, los métodos de PSP son presentados en una serie de siete versiones de procesos. Estas versiones son denominadas como PSP0 a PSP3. Cada versión tiene un mismo conjunto de logs, formularios, scripts, y standards.

• Los scripts de proceso definen los pasos de cada parte del proceso, los logs y formularios proveen templates para registrar y almacenar datos, y los standards guían a los desarrolladores a mientras hacen el trabajo.



Elementos del proceso

Está construido en un formato simple de utilizar con instrucciones simples y precisas. Si bien los scripts describen qué hacer, en realidad se parecen más a checklists que a tutoriales.

Estos no incluyen los materiales instructivos que serían necesarios para usuarios no entrenados. El propósito de los scripts es el de guiar a los desarrolladores en el uso consistente de los procesos, 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).

PSP O. Proceso (punto de partida)

• PSP0 es un proceso sencillo, definido y personal.

• Utiliza tus métodos actuales de diseño y desarrollo.



• Recoge datos sobre tu trabajo:

1. tiempo gastado por fase

2. defectos encontrados en compilación y pruebas

• Proporciona un informe resumen

El paso inicial en PSP consiste en establecer una base que incluya mediciones y un formato de reportes. Esto permite medir el progreso y define los cimientos para mejorar. Esencialmente, PSP0 es el proceso habitual con el que los desarrolladores escriben software, mejorado para proveer mediciones

PSP 0.1• Se pasa a PSP0.1 agregando un estándar de código, mediciones de tamaño

y el denominado PIP (Process Improvement Proposal).

• El PIP provee una manera estructurada de registrar problemas, experiencias y sugerencias para mejorar.

• PSP0.1 también mejora las mediciones para contar separadamente métodos y procedimientos.

PSP1 Planeación personal• PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega

estimaciones de tamaño y recursos y un reporte de prueba.

• En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto. 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.

• Aprender a realizar compromisos que puedan cumplir.

• Preparar un plan ordenado para realizar su trabajo

• Establecer una base para realizar un seguimiento de su trabajo.

Mientras que la importancia de estas técnicas en proyectos grandes es comprendida, pocos desarrolladores las aplican a su trabajo personal. PSP demuestra el valor de estos métodos en el nivel personal.

PSP 2. CALIDAD PERSONAL

Un objetivo de PSP es ayudar a los desarrolladores a lidiar de manera realista y objetiva con los defectos que introducen. Los programadores por lo general se



avergüenzan de sus errores. 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.

PSP2 agrega diseño personal y revisiones de código a PSP1. Estas revisiones ayudan a encontrar defectos de manera temprana y a ver los beneficios que esto proporciona. Los desarrolladores analizan los defectos que encuentran en los primeros programas y usan estos datos para establecer checklists de revisión que estén hechos a medida de su experiencia de defectos personales.

El proceso de diseño es contemplado en PSP2.1. El objetivo no es decirle a los desarrolladores como diseñar sino orientar el criterio para la finalización del diseño, es decir, cuando han terminado que es lo que deben haber obtenido. Se establece un criterio de completitud de diseño y se examinan varias técnicas de verificación y consistencia de diseño.

PSP3. Proceso cíclico personal

Hasta este punto PSP se concentró en el proceso lineal para construcción de pequeños programas. PSP3 presenta métodos para ser usados por individuos en la realización de programas de gran escala. De todas formas sigue enfocado en el individuo y no trata los problemas de comunicación y coordinación que son una parte importante del desarrollo de sistemas de gran escala.

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. Estos programas son entonces diseñados para ser desarrollados en pasos incrementales. La primera construcción consiste en un módulo base o kernel que es ampliado en ciclos iterativos. En cada iteración se utiliza un PSP2 completo, incluyendo diseño, codificación, compilación y pruebas.



• El proceso cíclico PSP3 puede ser un elemento efectivo en un proceso de desarrollo de gran escala solo si cada incremento sucesivo de software es de alta calidad.

• De esta manera los desarrolladores pueden concentrarse en la verificación de la calidad del último incremento sin preocuparse por defectos en ciclos anteriores.

• Si un incremento anterior tiene muchos defectos, la prueba será más compleja y los beneficios de escalar PSP se pierden. Esta es una razón para enfatizar revisiones de diseño y código en los pasos anteriores de PSP.

3.2 Plantillas PSP

En esta sección se observan algunos formatos y procedimientos para la medición del PSP.

Recolección de datos.

En PSP, los desarrolladores utilizan información para monitorear su trabajo, la cual los ayuda a hacer mejores planes. Para esto, deben recolectar datos de los tiempos que dedican a cada fase del proceso, de los tamaños de los productos que producen, y de la calidad de esos productos.



Las medidas básicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso, los defectos introducidos y encontrados en cada fase, y los tamaños de los productos desarrollados en líneas de código (LOC).

Estos datos se recopilan en cada fase del proceso y se resumen a la terminación del proyecto. Todos estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los ingenieros usan como guía en su trabajo.

Las principales medidas son:• Tamaño tiempo de estimación de errores

• Coste de realización

• Defectos producidos y corregidos por hora

• Producción del proceso

• Valoración y calidad del coste de los fallos (COQ)

• Valoración del rango de fallos (A/FR)

Elementos• un guión de proceso

• un formulario resumen de plan proyecto

• un registro tiempo

• un registro de defectos

• un estándar de tipos defecto



Planificación: Estimar tiempo de desarrollo.Desarrollo: Desarrollar el producto utilizando tus métodos actuales.


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 PSPOTablas de Registro de Tiempos y DefectosCronometro (opcional)

1 Planificación Producir u obtener los requisitosEstimar las LOC necesariasEstimar el tiempo de desarrollo necesarioIndicar los datos del plan en el Resumen del Plan de ProyectoCompletar el Log de Registro de Tiempos

2 Desarrollo Diseñar el programaImplementar el diseñoCompilar el programa y corregir todos los defectos encontradosCompletar la Tabla de Registro de Tiempos

3 Post-mortem Completar el Resumen del plan del Proyecto con los datos actuales de tiempo, defectos y tamaño

Criterios de salida

Un programa probadoUn resumen del Plan de Proyectos con los datos estimados y actualesLas tablas de Registro de Tiempos y Defectos Rellenos


Post-mortem: Completar el resumen del plan proyecto, con los tiempos gastados y defectos encontrados e inyectados en cada fase.

Diseño: Diseñar el programa, usando tus métodos de diseño actuales.Codificación: Implementa el programa.Compilación: Compila hasta que esté libre defectos.Prueba: Prueba el programa y corrige todos los defectos.

Registra los defectos en el Log de defectos y tiempos por fase en el Log de tiempos.

Encabezado: Nombre, fecha, programa, instructor, lenguaje.Tamaño del Programa: Plan. Indica tu mejor estimación del tiempo total que tendrá

el desarrollo. Actual. Indica el tiempo actual en minutos gastado en cada fase.

Tiempo: A la fecha: Indica el tiempo total gastado en cada fase hasta hoy. Para programa 1A, es el tiempo gastado en el programa 1A. A la fecha % : Indica el porcentaje del total tiempo hasta hoy que se gasto en cada fase.

Defectos introducidos y removidos: Indicar el número actual de defectos inyectados y eliminados en cada fase.Defectos: A la fecha: Indica el total de defectos inyectados y eliminados en

cada fase hasta hoy. Para el programa 1A, son los defectos inyectados y eliminados en el programa 1A. A la fecha %: Indicar el porcentaje sobre el total defectos inyectados y eliminados hasta hoy en cada fase.



Logs de Registro de tiempo

Encabezado: Indicar nombre, fecha, instructor y número de programa.Fecha: Indicar la fecha actual.Inicio: Indicar el tiempo en minutos cuando empiezas una fase del proyectoFin: Indicar el tiempo en minutos cuando tu paraste tu trabajo en una fase del

proyecto, aun cuando tú no has terminado esa fase.Tiempo de interrupción: Indicar el tiempo perdido por interrupciones desde el periodo de arranque a parada.Tiempo Delta time: Indicar el tiempo transcurrido desde el inicio al tiempo de parada

descontado el tiempo de interrupción.Fase: Anotar la fase en la que estás trabajando. / Use el nombre de cada fase.Comentarios: Descripción de la interrupción. La tarea que estás haciendo.

Cualquier aspecto significativo que afecte a tu trabajo


Fecha Inicio Fin Tiempo de Interrupción

Tiempo Delta

Actividad Comentarios

9/9 9:00 9:50 50 Planeación

12:40 1:18 38 Diseño

2:45 3:53 10 58 Diseño Teléfono

10/9 11:06 12:19 6+5 62 Codificación Baño, tomé café

11/9 9:00 9:50 50 Codificación

1:15 2:35 3+8 69 Compilación Consulta de un libro

4:18 5:11 25 28 Prueba Reunión con mi jefe

13/9 9:00 9:50 50 Prueba

12:33 1:16 38 Postmortem


Tamaño

El tiempo en desarrollar un producto se encuentra altamente determinado por el tamaño del mismo. En PSP, los desarrolladores primero estiman el tamaño de los productos que planean desarrollar. Luego, al finalizar el producto, se mide el tamaño real obtenido. Esta información permite a los desarrolladores realizar a futuro una estimación de tamaños más precisa. Sin embargo, para que esta información sea útil, el tamaño de las mediciones debe corresponderse con el tiempo de desarrollo del producto. En PSP, 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, se deben considerar varias categorías de LOC. Estas son:

• Base (son los LOC iniciales del producto original)

• Agregadas (es el código agregado a un programa base existente)

• Modificadas (es el código base que es modificado en un programa existente)

• Eliminadas (es el código base que es eliminado de un programa existente)

• Reutilización (es el código tomado de una librería u utilizado, sin realizar ninguna modificació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, independientemente del código fuente).

Luego, para medir el tamaño total de un 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; esto se debe a que las LOC modificadas pueden representarse por LOC eliminadas y agregadas, y las LOC de “nuevo reutilización” ya se encuentran contabilizadas en las LOC agregadas.Logs de Registro de defectos

El estándar de tipos de defectos proporciona un conjunto general de categorías de defectos. Aunque tú puedes reemplazar este estándar por el tuyo propio, es deseable



que te manejes con estas definiciones simples de tipos hasta que tengas datos que te puedan guiar en las modificaciones. Estos estándares se utilizaron para llenar los logs de Registro de defectos. A continuación se muestra un ejemplo:

Encabezado: Indicar el nombre, fecha, instructor, y numero de programa.Fecha: Indicar la fecha cuando encontraste y corregiste el defecto.Número: Indicar un número único para este defecto. Comienza cada proyecto con 1.Tipo: Indicar el tipo de defecto a partir del estándar de tipos de defectos.Introducido: Indicar la fase donde tu juzgas que el defecto fue inyectado o introducido.Eliminado: Indicar la fase en la que encontraste y eliminaste el defecto.Tiempo de Arreglo: Indicar el tiempo que tomaste para corregir el defecto. Tú puedes dar el tiempo exacto o usar tu mejor estimación.



Defecto Arreglado: Si este defecto fue inyectado durante la corrección de otro defecto, indicar el número de ese defecto o una X si lo desconoces.

Nota: Un defecto es cualquier cosa en el programa que debe ser cambiado para que sea desarrollado, mejorado o utilizado de manera adecuada.

Finalmente, la manera más eficaz de encontrar y arreglar defectos es repasando el código fuente del programa personalmente. Mientras esto puede parecer como una manera difícil de limpiar un programa defectuoso, resulta ser más rápido y más eficaz. 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.

METRICAS DEL PSP

Con datos de tamaño, tiempo y defectos, existen muchas formas de medir, evaluar, y manejar la calidad de un programa. 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, el panorama que provee la utilización de todas estas mediciones es generalmente un indicador confiable de calidad.

Las principales mediciones de calidad son:1. Densidad de defectos2. Índice de revisión3. Índices de tiempo de desarrollo4. Índices de defectos5. Rendimiento6. Defectos por hora7. Efectividad de remoción de defectos8. Evaluación del índice de fallas

Resumen del registro de Métricas

Nombre: Fecha: 18/10/96Programa Programa # 13Profesor Lenguaje: C++Resumen Plan Actual a la Fecha Minutos/LOC 5,92 4,87 5,73 LOC/Hora 10,14 12,32 10,47 Defectos/KLOC 94,79 106,4 96,90 Rendimiento A/FRTamaño Programa (LOC): Total nuevo & Cambiado 58 47 258Tamaño Máximo 72Tamaño Mínimo 41Tiempo en fase (min.) Plan Actual Para Fecha Para Fecha % Planing 18 22 88 6,0



Diseño 35 24 151 10,2Código 149 93 637 43,1Revisión código 20 37 111 7,5Compilación 24 4 92 6,2Test 64 8 240 16,2Postmortem 33 41 160 10,8Total 343 229 1479 100Tiempo Máximo 426Tiempo Mínimo 243Introducción de defectos Plan Actual Para Fecha Para Fecha % Def/Hora Planing Diseño 1 4 16,0Código 5 5 21 84,0Revisión códigoCompilaciónTestTotal 6 5 25 100,0



Unidad IV

T é cn i c a s d e E s t i m a c ió n

México tiene un nivel de gasto en tecnologías de la información y comunicaciones (TIC) de 3.2 del PIB, ubicándose en el lugar 50 a nivel mundial. Este rezago es aún mayor en términos de gasto en software, que es 6 veces inferior al promedio mundial y 9 veces menos que el de EUA. Con estos niveles no es de extrañarnos que a nivel industria tengamos poco avance en temas como las métricas para SW.

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, o de las capacidades requeridas de los ingenieros y de la empresa.

En la vida real estimamos todo el día, por ejemplo:

• Cuando elegimos cuánto dinero llevaremos para las actividades de ese día.• Estimamos el tiempo que necesitamos si vamos en nuestro auto, en taxi o en

colectivo, dependiendo del lugar a dónde vayamos.• Estimamos cuando cruzamos la calle, si nos da tiempo o no, hasta comparamos

la velocidad del auto contra la velocidad de nosotros.• Si voy manejando, estimo si freno o no.• Cuando como estimo si con esa comida voy a engordar o no.

NOTA.- Diariamente usamos una gran cantidad de operaciones, en automático, es decir, q no nos damos cuenta.

Tradicionalmente se ha medido el tamaño del software mediante distintas métricas: recuento de las líneas de código (LOC), número de programas fuente, o técnicas similares, que no resultan aceptables como una buena práctica profesional, porque:

• Su resultado depende fuertemente del entorno técnico y el lenguaje de programación utilizado.

• Varía en función de la pericia de cada programador y del uso de normas y metodologías.

• No resultan significativas al usuario ni a la dirección.• Cuando se trata de establecer métricas de productividad y calidad en la

construcción de software, o realizar estimaciones de coste y duración, es imprescindible disponer de una medida fiable y comprensible del tamaño de lo que se construye.


http://es.wikipedia.org/wiki/M%C3%A9trica_(Inform%C3%A1tica)


ALGUNAS TÉCNICAS de estimación se presentan a continuación:

1. Por rangos.- En lugar de elegir un valor, elige varios de referencia.2. Por analogía.- Los procesos se comparan contra otros proyectos.3. Por recomposición.- La tarea se descompone en procesos más pequeños.4. Calibración de procesos.- Por ejemplo Número de bytes, LOC y casos de uso.5. Juicio de los expertos.- Da su opinión gente con más experiencia.

4.1 Puntos de Función

Lo relevante es la funcionalidad, como en cualquier inversión, a las empresas lo que les interesa es la capacidad de hacer algo con lo que compran. Por ejemplo, si se compra un camión, de alguna forma se adquirió la capacidad de transportar mercancías y con un tamaño de metros cúbicos por viaje. En primera instancia lo relevante es qué tanto requiero transportar por viaje. En otro ejemplo, si se compra un edificio, entonces se adquirió la capacidad de disponer de un espacio de X metros cuadrados distribuido en pisos; lo relevante es cuánto espacio necesita la empresa o institución.

En SW no tiene por qué ser distinto; al adquirir un paquete o al desarrollar una aplicación, lo primero que debe evaluarse es qué nuevas capacidades estoy adquiriendo.Estas capacidades o funcionalidad estarán en términos de qué transacciones puedo realizar de forma automatizada y qué grupos de datos puedo guardar.

A continuación se presentan algunos TIPS para comprender este tema:

• Se debe cumplir con medidas y evitar desviaciones en una estimación.• Los parámetros y acotaciones se toman como referencia para que una serie sea

considerada válida.

• TOLERANCIA.- Es un aspecto importante definida como la desviación máxima permitida en una pieza o proceso. Depende del fin para lo que fue diseñada la pieza o el proceso. A mayor CALIDAD menor tolerancia.

• Las métricas o técnicas aseguran que todas las piezas cumplan con parámetros de un plano u hoja de procesos.

• Algunos ejemplos de las herramientas usadas para medir son: pie de rey, micrómetro de interiores, micrómetro de exteriores, sonda de profundidad, etc.



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

• 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. Fue definida por Allan Albrecht, de IBM, 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, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la explotación y mantenimiento.

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, a través de una suma ponderada de las características del producto.

CARACTERÍSTICAS de la funcionalidad

INDEPENDIENTE DE LA TECNOLOGÍA.– Si nos basamos en líneas de código (en la tecnología) vamos a obtener resultados no comparables. Pero más que eso, tal vez lo relevante de esta característica es que una vez establecida la funcionalidad que requiero, debo escoger la tecnología que me haga más productivo para obtener tal funcionalidad.SIMPLE. – Desde su concepción, este tipo de métrica se planteó que no requiriera grandes esfuerzos para obtener una medida. 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. Sin embargo, el costo de esta simplicidad es que la métrica no es muy sensible a consideraciones muy detalladas, como lo sería por ejemplo, la complejidad de fórmulas matemáticas.ENFOQUE EN LA FUNCIONALIDAD PROPORCIONADA.– Ver qué nuevas capacidades voy a obtener con el nuevo SW, antes de cualquier evaluación técnica.BASADA EN LOS REQUERIMIENTOS DEL USUARIO.– Esta característica ayuda a que el usuario pueda entender el significado e implicaciones del tamaño del SW, 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.CONSISTENCIA.– Los resultados obtenidos entre diferentes personas o en proyectos distintos deben ser consistentes.

No es suficiente contar con una métrica, sino que sea estándar para así poderla usar entre empresas o para tener indicadores a nivel industria que todos puedan entender y operar. Por lo que se creó: ISO/IEC 14143 – Information Technology – Software


http://es.wikipedia.org/wiki/1979

http://es.wikipedia.org/wiki/IBM

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software


Measurement – Functional Size Measurement. 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.

El método se basa principalmente en la identificación de los componentes del sistema informático en términos de transacciones y grupos de datos lógicos que son relevantes para el usuario en su negocio. A cada uno de estos componentes les asigna un número de puntos por función basándose en el tipo de componente y su complejidad; y la sumatoria de esto nos da los puntos de función sin ajustar. El ajuste es un paso final basándose en las características generales de todo el sistema informático que se está contando.

Se puede identificar el procedimiento para la estimación de los puntos de función de la siguiente manera:

Paso 1. Determinar el tipo de conteoEste paso consiste en definir el tipo de conteo entre desarrollo, mantenimiento o de una aplicación ya instalada. Esta es una forma de determinar el objetivo del conteo.

Paso 2. Identificar los alcances de la medición y los límites de la aplicación.El propósito de una medición consiste en dar una respuesta a un problema de negocio. 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.



Componentes:

EI: Procesos en los que se introducen datos y que suponen la actualización de cualquier archivo interno.

EO: Procesos en los que se envía datos al exterior de la aplicación.

EQ: Procesos consistentes en la combinación de una entrada y una salida, en el que la entrada no produce ningún cambio en ningún archivo y la salida no contiene información derivada.

ILF: Grupos de datos relacionados entre sí internos al sistema.

EIF: Grupos de datos que se mantienen externamente.

Paso 3. Contar las funciones de datosEste paso consiste en identificar y contar la capacidad de almacenamiento de los datos. Se distinguen dos tipos de funciones de datos:Archivo Lógico Interno – es un grupo de datos relacionados que el usuario identifica, cuyo propósito principal es almacenar datos mantenidos a través de alguna transacción que se está considerando en el conteo.Archivo de Interfaz Externo - es un grupo de datos relacionados y referenciados pero no mantenido por alguna transacción dentro del conteo.



A cada componente identificado se le asigna una complejidad (bajo, medio o alto) considerando principalmente el número de datos.

Paso 4. Contar las funciones transaccionales.Este paso consiste en identificar y contar la capacidad de realizar operaciones.

Se distinguen tres tipos de funciones transaccionales:Entrada Externa – es un proceso cuyo propósito principal es mantener uno más archivos lógicos internos.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.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.

A cada componente identificado se le asigna una complejidad (bajo, medio o alto) considerando el número de datos utilizado en el proceso y los archivos referenciados. 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. Entradas al Sistema (EI) No. Salidas del Sistema (EO) No. Consultas BD (EQ) No. Ficheros (ILF - EIF) Factor Corrección por Complejidad: No. Atributos de Entradas x Factor Corrección por Complejidad: No. Atributos de Salidas x Factor... x Factor Corrección por Complejidad: No. Atributos de Ficheros x + Puntos de Función Sin Ajustar Puntos de Función Ajustados Ajuste de Complejidad Técnica Estimación del Esfuerzo Estimación del Tiempo de Desarrollo



Datos de Productividad del Equipo Escala de 14 Factores de Complejidad Estimación del Presupuesto.

Calcular No. 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, 3 salidas de complejidad alta y 1 de complejidad baja para el subsistema cocina, 2 salidas de complejidad baja, 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. Entradas: 9 entradas de complejidad alta para el subsistema mostrador, 3 entradas de complejidad alta para el subsistema cocina, 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. Consultas: 2 consultas de complejidad baja para el subsistema mostrador, 3 consultas de complejidad baja para el subsistema cocina, 1 consulta de complejidad baja y 3 de complejidad alta para el subsistema administración y finalmente una consulta de complejidad baja para el subsistema configuración. Ficheros Lógicos Internos: 8 almacenes intermedios de datos de complejidad alta. Ficheros Externos: No se utilizaron almacenes externos de datos.

Paso 5. Determinar los puntos de función no ajustados.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.

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

Paso 6. Determinar el valor del factor de ajuste.El factor de ajuste se obtiene sumando 0.65 a la sumatoria de los grados de influencia de las 14 características generales del sistema, multiplicado por 0.01. Dentro de las características hay criterios como: complejidad del proceso, facilidad de instalación, entrada de datos en línea, etc.

Paso 7. Determinar los puntos función ajustados.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.65+[0.01*ACT]] Obtención ACT Puntaje Factor de Ajuste Min Max Comunicación de Datos 0 5 Proceso Distribuido 0 5 Objetivos de Rendimiento 0 5 Configuración de Explotación Compartida 0 4 Tasa de transacciones 0 5 Entrada de Datos en Línea 0 5 Eficiencia con el Usuario Final 0 5 Actualizaciones en Línea

NOTA.- Obtener Información del Sistema requiere conocimiento global del sistema y construir un Modelo de entidades primarias.

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. 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. c) 2 = Aplicación batch con entrada de datos remota y utilización de periféricos de salida remotos. 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. (para el presente caso) f) 5 = Hay teleproceso con varios protocolos de comunicación. Sistema Abierto y con interfaces de todo tipo al exterior. NOTA: (la sumatoria de las valoraciones de los 14 factores dará el valor para el ACT Nº de Factor Nº de Factor Valor 0..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

Cálculo del Esfuerzo Cálculo del Esfuerzo 6 PFA = 296.82 Esfuerzo horas/persona = PFA / [1 / 8 persona / hora)] = 296.82 / 0.125 = 2374.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, C,… 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.5 horas/persona / 5 personas = 474.91 horas por miembro DURACIÓN EN MESES = 474.91 horas / 100 horas/mes = 4 meses 15 dias HORAS POR PERSONA = 2374.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; no puedo hacer un programa que cuente automáticamente. Debido a esto, distintas personas podrían llegar a un conteo diferente. Para resolver esto, se han venido depurando las reglas de conteo para eliminar posibles ambigüedades y cada vez hay más material de apoyo con ejemplos



NOTA: Cualquier métrica tiene un ámbito de acción y alcance definido que hay que entender para usarla correctamente. Así por ejemplo, el metro lineal no es lo mejor para medir grandes distancias en el mar. En nuestro caso, Puntos Función, está enfocado a medir sistemas informáticos completos, no programas. En este sentido no tiene un nivel de precisión suficiente para medir el tamaño de programas individuales.

4.2 Puntos de Casos de Uso

Puntos de caso de uso es un método de estimación de esfuerzo para proyectos de software, a partir de sus casos de uso. Fue desarrollado por Gustav Karner en 1993, basándose en el método de punto de función, y supervisado por Ivar Jacobson. Ha sido analizado posteriormente en otros estudios.

El método utiliza los actores y casos de uso relevados para calcular el esfuerzo que significará desarrollarlos. A los casos de uso se les asigna una complejidad basada en transacciones, entendidas como una interacción entre el usuario y el sistema, mientras que a los actores se les asigna una complejidad basada en su tipo, es decir, si son interfaces con usuarios u otros sistemas. También se utilizan factores de entorno y de complejidad técnica para ajustar el resultado.

Al inicio de un proyecto de software, cuando apenas se conocen los casos de uso y sus actores asociados, se puede proyectar una breve descripción de cada caso de uso, en el cual se describe de forma breve la funcionalidad que éste debe brindar.

El UUCP son los puntos de casos de uso sin ajustar, esto nos puede servir para tener una idea un poco más precisa de la dificultad de los casos de uso e interfaces, tomando en cuenta los pesos de los actores (UAW) y los pesos de los casos de uso (UUCW). UUCP = UAW + UUCW

Estas siglas significan:

• UUCP: Puntos de casos de uso sin ajustar. • UAW: Factor de peso de los actores sin ajustar. • UUCW: Factor de peso de los casos de uso sin ajustar.

Aplicando el análisis de puntos de función a estos casos de uso, se puede obtener una estimación trivial del tamaño y a partir de ella una estimación del esfuerzo.


http://es.wikipedia.org/wiki/Ivar_Jacobson

http://es.wikipedia.org/wiki/M%C3%A9trica_de_punto_funci%C3%B3n

http://es.wikipedia.org/w/index.php?title=Gustav_Karner&action=edit&redlink=1

http://es.wikipedia.org/wiki/Casos_de_uso

http://es.wikipedia.org/wiki/Software


MÉTODO

El método de punto de casos de uso consta de cuatro etapas, en las que se desarrollan los siguientes cálculos:

1. Factor de peso de los actores sin ajustar (UAW) 2. Factor de peso de los casos de uso sin ajustar (UUCW) 3. Puntos de caso de uso ajustados (UCP) 4. Esfuerzo horas-hombre

1. Factor de peso de los actores sin ajustar (UAW)

Consiste en la evaluación de la complejidad de los actores con los que tendrá que interactuar el sistema. Este puntaje se calcula determinando si cada actor es una persona u otro sistema, además evalúa la forma en la que este interactúa con el caso de uso, y la cantidad de actores de cada tipo.

Tipo de

actorDescripción Factor

SimpleOtro sistema que interactúa con el sistema a desarrollar mediante

una interfaz de programación (API).1

MedioOtro sistema interactuando a través de un protocolo (ej. TCP/IP) o

una persona interactuando a través de una interfaz en modo texto.2

ComplejoUna persona que interactúa con el sistema mediante una interfaz

gráfica (GUI).3

Tabla 1: Peso de los actores sin ajustar.

La fórmula sería: UAW = Sum(cantidadDeUnTipoDeActor*Factor)

Para realizar esta operación sería necesario contar cuántos actores de cada tipo existen en el sistema, este representaría el valor cantidadDeUnTipoDeActor en la fórmula y se tiene que multiplicar por el valor que tenga su factor correspondiente, para obtener el resultado por cada tipo de actor. Una vez terminado esto se procede a sumar cada producto para obtener el UAW.



2. Factor de peso de los casos de uso sin ajustar (UUCW)

Este punto funciona muy similar al anterior, pero para determinar el nivel de complejidad se puede realizar mediante dos métodos: basado en transacciones o basado en clases de análisis.

Una transacción es un conjunto de actividades atómicas, lo que quiere decir que se ejecutan todas o no se ejecuta ninguna.

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

• Basado en clases de análisis.

Toma en cuenta el número de clases que tiene un caso de uso y lo evalúa según la siguiente tabla:

Tipo de caso de uso Descripción Factor

Simple Menos de 5 clases 5

Medio 5 a 10 clases 10

Complejo Más de 10 clases 15

Tabla 3: Peso de las clases de análisis.

Ahora independientemente del camino utilizado para determinar el tipo de caso de uso, la fórmula es la misma y se presenta a continuación: La fórmula sería: UUCW = Sum (CantidadDeUnTipoDeCasoUso*Factor). 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 CantidadDeUnTipoDeCasoUso y se multiplica por el valor que tenga su factor correspondiente, para obtener el resultado por cada tipo de caso de uso. Una vez hecho esto se suma cada producto para obtener el factor de peso de los casos de uso sin ajustar (UUCW).



Esta estimación es bastante imprecisa debido principalmente a la escasa información que se tiene, pero permitirá obtener una idea del esfuerzo necesario para llevar adelante el mismo, y podrá ser refinada a medida que se obtenga más información.

3. Puntos de caso de uso ajustados (UCP)

Para esto se utilizan las siglas UCP y se obtiene al multiplicar el UUCP el TCF y el EF quedando la operación de la siguiente forma:

UCP = UUCP x TCF x EF

Estas siglas significan:

• UCP: Puntos de casos de uso ajustados. • UUCP: Puntos de casos de uso sin ajustar. • TCF: Factores técnicos. • EF: Factores ambientales.

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, cada uno de estos factores tienen un peso definido con los cuales se obtendrá puntos ponderados por cada uno de ellos, según la valoración que se le asigne. Para una mejor comprensión, a continuación se mostrará una tabla con los ítems:

Factor Descripción Peso

T1 Sistema distribuido. 2

T2 Objetivos de performance o tiempo de respuesta. 1

T3 Eficiencia del usuario final. 1

T4 Procesamiento interno complejo. 1

T5 El código debe ser reutilizable. 1

T6 Facilidad de instalación. 0.5

T7 Facilidad de uso. 0.5

T8 Portabilidad. 2

T9 Facilidad de cambio. 1



T10 Concurrencia. 1

T11 Incluye objetivos especiales de seguridad. 1

T12 Provee acceso directo a terceras partes. 1

T13 Se requiere facilidades especiales de entrenamiento a usuario. 1

Tabla 4: Peso de los factores de complejidad técnica.

Cada uno de estos puntos se debe evaluar según la siguiente escala:

Descripción Valor

Irrelevante De 0 a 2.

Medio De 3 a 4.

Esencial 5

Tabla 5: Escala de los factores de complejidad técnica.

Las fórmulas para este punto son:

• TFactor = Sum (Valor*Peso) • TCF = 0.6 + (0.01 * TFactor)

Para realizar este cálculo, se debe evaluar cada factor, asignándole un valor como se menciona anteriormente, después se multiplican y se suma cada producto para obtener el TFactor. Luego, se debe seguir la segunda fórmula multiplicando el TFactor por 0.01 y sumar el resultado a 0.6, esto nos va a dar el TCF.

Factores ambientales

Los factores sobre los cuales se realiza la evaluación son 8 puntos, que están relacionados con las habilidades y experiencia del grupo de personas involucradas con el desarrollo del proyecto. Estos factores se muestran a continuación:

Factor Descripción Peso

E1 Familiaridad con el modelo de proyecto utilizado. 1.5

E2 Experiencia en la aplicación. 0.5

E3 Experiencia en orientación a objetos. 1

E4 Capacidad del analista líder. 0.5

E5 Motivación. 1



E6 Estabilidad de los requerimientos 2

E7 Personal part-time -1

E8 Dificultad del lenguaje de programación -1

Tabla 6: Peso de los factores ambientales.

Cada uno de estos factores se debe calificar con un valor de 0 a 5.

Las fórmulas para este punto son:

• EFactor = Sum(Valor * Peso)

• EF = 1.4 + (-0.03 * EFactor)

Para obtener el EFactor se debe sumar todos los productos obtenidos al multiplicar el peso de cada punto por el valor asignado, después se multiplica por -0.03 y se le suma el 1.4. Así, se obtiene el peso de los factores ambientales (EF).

4. Esfuerzo horas-hombre (E)

Este cálculo se realiza con el fin de tener una aproximación del esfuerzo, pensando solo en el desarrollo según las funcionalidades de los casos de uso. Anteriormente, se sugería utilizar 20 horas persona por UCP, pero a través del tiempo se ha ido mejorando. 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, también contar la cantidad de estos mismos del E7 y E8 que son mayores que 3.

Factor Filtro

De E1 a E6 Factor < 3

De E7 a E8 Factor > 3

Tabla 7: Factor de el esfuerzo horas-persona.

Para evaluar el resultado o la cantidad total según la siguiente tabla:

Horas-Persona (CF) Descripción



20 Si el valor es<=2

28 Si el valor es<=4

36 Si el valor es>=5

Tabla 8: Cantidad de horas-persona según el valor.

El esfuerzo en horas-persona viene dado por:E = UCP x CFEstas siglas significan:E: Esfuerzo estimado en horas-persona.UCP: Puntos de Casos de Uso ajustados.CF: Horas-Persona.

Al realizar la multiplicación del UCP por las horas- persona, se consigue un esfuerzo estimado, que representa una parte del total del esfuerzo de todo el proyecto, generalmente un 40%. Este 40% se refiere al esfuerzo total para el desarrollo de las funcionalidades especificadas en los Casos de Uso.

En la siguiente tabla se detallan la distribución en porcentaje, 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. Estructurada)

Componentes a Identificar: Salidas Entradas Consultas Ficheros Lógicos Internos Ficheros Externos



Unidad V

M o d e lo s p a r a e l A s eg u r a m i e n t o d e C a l id a d d e l

S o f t w a r e

Tareas de aseguramiento de Calidad (SQA):

• Establecer un plan SQA.• Descripción del proceso de desarrollo.• Revisión de Actividades de Ing. Software.• Asegurar que las desviaciones se documenten.• Feedback para mejora continua.

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

Resulta muy claro que los costos de la falta de calidad son mucho mayores a los que se requieren para implementar un buen sistema de aseguramiento de la calidad.

5.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), que tiene como objetivo Fortalecer a la Industria de Software en México.

Las estrategias del PROSOFT son:

• 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. Hanna Oktaba de la UNAM y a un grupo de colaboradores investigar que procesos podían utilizarse en la industria mexicana para el desarrollo de software, en su mayoría PyMES (Pequeña y Mediana empresa), concluyéndose en el estudio que no había un modelo de procesos y evaluación que se adaptara 100% a las empresas mexicanas.

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”. El compromiso era cubrir por lo menos las prácticas del modelo CMM-SW nivel 3 e ISO9000:2000, en el caso del modelo de procesos, y cumplir con los lineamientos de ISO15504, 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.

También se trabajó con un equipo de trabajo para definir el método de evaluación basado en MoProSoft como modelo de procesos, así 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. Posteriormente, entre agosto y diciembre, con el apoyo de una consultora un día a la semana, las empresas adecuaron los procesos de MoProSoft a sus necesidades, definieron las plantillas de los productos y empezaron a implementar los procesos. El objetivo de las pruebas controladas fue demostrar que, 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. El trabajo se realizó dentro del Subcomité de Software del NYCE (Normalización Y Certificación en Electrónica), 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. 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: Alta dirección, Gestión y operación

Categoría Proceso

Alta Dirección (DIR) Gestión de Negocio

Gestión (GES) Gestión de Procesos

Gestión de Proyectos

Gestión de Recursos

Operación (OPE) 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, sus objetivos y las condiciones para lograrlos, para lo cual es necesario considerar las necesidades de los clientes, así como evaluar los resultados para poder proponer cambios que permitan la mejora continua. 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



Tareas a realizar en esta categoría:Plan estratégico de la organización:Misión, Visión, Valores, Objetivos, Estrategias, Procesos requeridos, Cartera de proyectos, Estructura de la organización, Estrategia de recursos, Presupuesto, Plan de comunicación con el clienteNecesidad de mejora

Gestión de Procesos (GES)

Propósito:

Establecer los procesos de la organización, en función de los Procesos Requeridos identificados en el Plan Estratégico. Así como definir, planear, e implantar las actividades de mejora en los mismos.

Tareas a realizar en esta categoría:

Capacitar a los encargados de los procesos en Moprosoft• Definir el catálogo de procesos de la organización• Identificar los procesos• Documentar los procesos.• Realizar una plantilla para documentar los procesos.


Planificación

Estratégica

Preparación para

la Realización

Valoración y Mejora

Continua


• Capacitar en el uso de la plantilla para documentarlos• Usar diagramas de actividades de UML

PLANTILLA PARA DOCUMENTAR LOS PROCESOS

Proceso. Nombre del proceso.

Propósito. Objetivos generales y resultados esperados de la ejecución del proceso.

Descripción. Describir las actividades más generales del proceso.

Indicadores. Definir las formas de evaluar la efectividad en el cumplimiento de los objetivos del proceso.

Responsable y autoridad. Indicar quien es el responsable principal de la ejecución de este proceso. Autoridad es quien comprueba la ejecución y el cumplimiento del propósito del proceso.

Subprocesos. Lista de procesos de los cuales se compone el proceso en cuestión.


Preparación a la

Implantación

Evaluación y Control

Planificación


Procesos relacionados. Otros procesos con los cuales se tiene relación.

Entradas. Definir los documentos o productos que sirven de base para este proceso.

Salidas. Definir los documentos o productos resultados de este proceso.

Productos internos. Definir los documentos o productos que se utilizan en este proceso.

Roles. Cargos de las personas involucradas en este proceso.

Actividades. Tareas que se llevan a cabo en este proceso. Esta descripción puede acompañarse de un diagrama de actividades.

Gestión de Proyectos (GES)

Propósito Asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización.




• Definir el proyecto. • Registrar el proyecto.• Describir el proyecto.• Responsable del proyecto.• Contrato.• Metas cuantitativas del proyecto.

Gestión de Recursos (GES)

Propósito:

Conseguir y dotar a la organización de los recursos humanos, infraestructura, ambiente de trabajo y proveedores. Crear y mantener la Base de Conocimiento de la organización. La finalidad es apoyar el cumplimiento de los objetivos del Plan Estratégico de la organización.


Planificación Realización

Evaluación y Control



• Capacitar a los encargados de los involucrados en Moprosoft• Crear el Plan operativo de Bienes, Servicios e Infraestructura• Crear el Plan operativo de Recursos Humanos y Ambiente de trabajo• Crear el Plan operativo de Conocimiento de la organizació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.


Seguimiento y Control

Planificación de

Recursos

Investigación de

Tendencias

Tecnológicas



• Planeación• Definir el proceso específico con base en la Descripción del Proyecto y el

proceso de Desarrollo y Mantenimiento del Software• Definir el Protocolo de Entrega al Cliente• Definir ciclos y actividades• Establecer el Equipo de trabajo• Establecer calendario de actividades• Documentar el Plan del Proyecto• Documentar el Plan de Desarrollo• Formalizar el inicio de un nuevo ciclo

Realización

• Acordar las tareas del equipo de trabajo.• Acordar la distribución de la información al equipo de trabajo.• Recolectar los reportes de actividades, mediciones y productos de trabajo.• Revisar los productos terminados.• Revisar las solicitudes de cambio del cliente.• Realizar reuniones con el equipo de trabajo y con el cliente para reportar los

avances y tomar acuerdos.

Evaluación y control


Planificación Realización

Evaluación y

Control Cierre


• Evaluar el cumplimiento del Plan del Proyecto y Plan de Desarrollo• Generar el Protocolo de entrega y terminación del ciclo.

Entradas:

• Descripción del proyecto (Gestión de proyectos)• Documentación del proceso (Gestión de proyectos)

Salidas:

• Plan de Proyecto • Plan de Desarrollo

Lecciones aprendidas

• Reporte de mediciones y Sugerencias de Mejora• Reporte de seguimiento

Desarrollo y Mantenimiento de software (OPE)

Propósito:

Es la realización sistemática de las actividades de análisis, diseño, construcción,

integración y pruebas de productos de software nuevos o modificados cumpliendo con

los requerimientos especificados.

Proceso de desarrollo y mantenimiento de software (OPE)

Incluye: Ciclos de Desarrollo, Fases de un Ciclo, Actividades de una Fase

Fases:

Para cada fase se describen los productos a generar y/o las actividades a realizar

• Inicio• Armar el equipo• Socialización de conocimientos• Requerimientos• Los requerimientos se recolectan y se validan con el cliente • Texto con el problema• Casos de uso generales y detallados• Glosario de términos



• Prototipo (si aplica)• Análisis y diseño• Diagramas de clases• Diagrama de la base de datos• Arquitectura y diagrama de paquetes principales del sistema• Diagrama de componentes por paquete• Construcción

La construcción se hará en cada subgrupo y se probará en cada subgrupo

Código

Pruebas e integración Pruebas de integraciónPrueba del sistema

Cierre

Evaluación del proceso y productoDocumentar 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.Se debe empezar por documentar lo mas generalSe puede aplicar Moprosoft de manera que se avance en la madurez de la organización.Avanzar paso a paso, no correr, pues abruma la cantidad de tareas a realizar y documentar.Las organizaciones no siempre tienen claro cuales son sus procesos.Se confunde procesos con estructura.Muchas empresas tienen un proceso implícito de desarrollo, hay que documentarlo.Capacitar en las técnicas necesarias para el modelado del negocio y del desarrollo.

5.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), proponiendo que existen niveles negativos o de inmadurez. Este «Modelo de Incapacidad e Inmadurez», que fue refinado posteriormente por Tom Schorsch, incluye tres niveles de idiotez o Inmadurez:



0 – Tonto o Nulo. Organizaciones negligentes. Impiden cualquier desarrollo de software con éxito. Su gran preocupación es la reutilización del software. 1 - Estúpido. Organizaciones obstructivas. Imponen procesos contra-productivos para impedir cualquier avance. Se concentran en desarrollar entornos de desarrollo y repositorios. 2 – Lunático o Despectivo. Organizaciones desdeñosas. Desprecian cualquier institucionalización de buenas prácticas. Su gran objetivo es la programación automática.3 – Sabotaje. Negligencia total, descrédito consciente de los esfuerzos de su propia gente en la mejora de proceso del software. Falta de recompensa y degradación de las prestaciones.

¿Por qué PSP nos conduce al CMMI?

El CMMI significa decir que se hace, hacer lo que se dice y medirlo. 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, en una forma sencilla de seguir y aplicar, tal como lo es una interfaz web.

Es posible agregarle variantes de procesos o prácticas para customizarlo al proceso de la organización, y aun así continuar conformando el acercamiento por RUP. Una vez definido el proceso, se la pone a disposición de todos los miembros del equipo en su desktop. Esto hace que el proceso este accesible para todos, ayudando a asegurar la comunicación y consistencia y evitando gastar el tiempo determinado cual es el próximo paso a seguir.

A continuación se presentan algunos puntos clave para poder identificar si una organización se encuentra dentro de un nivel de capacidad de Inmadurez o dentro de un Nivel de Capacidad de Madurez.

Proceso Inmaduro Proceso Maduro

Personal.No está documentado.No es fácil reproducirlo en nuevos proyectos.No hay entrenamiento.No todo el mundo lo conoce.No se mide.Se aplica a veces solamente.Es percibido como poco eficiente.

Es definido: Sistemático.Es documentado, publicado, aprobado y accesible.El personal ha sido entrenado: Ingenieros y gerencia (conocen el proceso).Es practicado: Se utiliza en forma cotidiana.Es apoyado: Gerencia asigna responsables.



No se cumplen los tiempos de entrega.Se exceden los presupuestos.

Es mantenido: es revisado para que cumpla los requisitos.Es controlado: las actualizaciones son notificadas a la empresa.Se verifica: los proyectos siguen el proceso establecido.Se valida: el proceso mantiene coherencia con los requerimientos y estándares.Se mide: utilización, beneficios y rendimiento se cuantifican.Puede mejorarse: existe el mecanismo para la mejora continua.

5.2.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, los presupuestos se disparaban, las fechas alargaban más y más. ¿Quién no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de software? Como esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa".

Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos 4 problemas", se presentaron diversos estamentos y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI.

El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM.

El “nacimiento” de CMM se da en el año de 1986 cuando el Software Engineering Institute (SEI) junto con MITRE Corporation, buscaron mejorar el proceso de software y desarrollaron un marco de trabajo que llamaron proceso de madurez. Este proceso fue desarrollado por Watts S. Humphrey en 1986 y está basado en el concepto de la administración de la calidad total Total Quality Management (TQM) por sus siglas en inglés.



El modelo de capacidad de madurez (CMM), provee a las organizaciones de software una guía de cómo aumentar el control de sus procesos de desarrollo y mantenimiento de software. 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.

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). Los diferentes niveles permiten medir la madurez del proceso y evaluar el potencial de él, como también ayudan a una organización a priorizar sus esfuerzos de mejoramiento. Éste concepto cuenta con cinco etapas evolutivas que se enfocan en la implementación de prácticas de calidad. CMM es, en pocas palabras, una aplicación de TQM para software

Niveles de

madurez

Áreas Claves

Nivel 1

Inicial

Ninguna

Nivel 2

Repetible

Gestión de configuracionesGarantía de calidadGestión subcontratación del softwareSeguimiento y supervisión del proyectoPlanificación del proyectoGestión de requisitos

Nivel 3

Definido

Revisiones periódicasCoordinación entre gruposIngeniería de productos de softwareGestión de integración del softwarePrograma de formaciónDefinición de procesos de la organizaciónEnfoque del proceso de la organización

Nivel 4

Gestionado

Gestión de calidad de softwareGestión cualitativa del proceso

Nivel 5

Optimizado

Gestión de cambios del proceso Gestión de cambios de tecnologíaPrevenció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, universal y uniforme(institucionalizadas) • Medidas



• Verificadas

CMM: un modelo para la mejora de Procesos de Software

Objetivo: Mejorar la calidad de los procesos de desarrollo, 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.

• Mejora la gestión de la calidad es, en gran medida, responsabilidad de la dirección• La mejora de la calidad debe basarse en mejorar los procesos y no en las

personas• Hay que medir la mejora de la calidad• Se necesitan incentivos para mantener un esfuerzo de mejora• La mejora de la calidad es un proceso continuo

Después de cuatro años de experiencia con la madurez del proceso de software, el SEI evolucionó la madurez y publicó Capability Maturity Model for Software (CMM).En diciembre de 2000, el SEI publicó un nuevo modelo, el CMMI o "Modelo de Capacidad y Madurez - Integración", éste describe un camino de mejoramiento evolutivo para pasar desde un proceso inmaduro a un proceso maduro y disciplinado, basado en conocimientos adquiridos de evaluaciones de los procesos de software y extensos feedback. Por lo tanto, las disposiciones del CMM son definitivamente aplicables a todo aquello que esté directamente relacionado con el desarrollo y mantenimiento de sistemas informáticos.

CMMI define un conjunto de áreas clave del proceso, que describen las funciones de ingeniería del software que deben llevarse a cabo para el desarrollo de una buena práctica, agrupadas en cinco niveles inclusivos. Estos niveles sirven de referencia para el conocimiento del estado de la madurez del proceso del software en la organización. Mediante un amplio conjunto de métricas se determina la calidad de cada una de las áreas clave, obteniéndose una visión precisa del rigor, la eficacia y la eficiencia de la metodología de desarrollo de una organización productora de software.



Cada una de las áreas está organizada en cinco secciones, denominadas características comunes. Todo esto con el objetivo de realizar algunas mejoras respecto al CMMI (SW-CMM).

5.2.2 Características comunes:

• Compromiso de realización• Capacidad para llevarla a cabo• Actividades que hay que realizar• Medición y análisis• Verificación de la implementación



Modelo de Desarrollo de Software

PROPUESTA DE ESTÁNDAR (Proyecto)

El siguiente estándar está basado en los modelos ISO 15504 / SPICE, I SO 9000 – 3 y CMMI con el objetivo de proveer las especificaciones para el desarrollo de software, 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), ajustando dicha dimensión a tres niveles (tomados del modelo CMMI), los cuales son: Inicial, Definido y Optimizado.



Glosario de términos

Calidad

Si buscamos el significado etimológico de la palabra Calidad, la encontraremos en el Griego Kalos: Bueno, Hermoso, Apto, Favorable y en el Latín Qualitatem: Propiedad.

Hablando de calidad podemos resaltar sus características estas pueden ser: Un requisito físico o químico, una dimensión, una temperatura, una presión o cualquier otro requerimiento que se use para establecer la naturaleza de un producto o servicio. La calidad no tiene un significado popular de lo mejor en el sentido absoluto, industrialmente quiere decir, mejor dentro de ciertas condiciones del consumidor, ya que es él, quien en última instancia determina la clase y la calidad del producto que desea.

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, durante su uso”.

“Cumplir con las necesidades del cliente y exceder las expectativas en forma constante (siempre).”

“Es lo que el cliente dice que necesita más lo que realmente necesita”

“Suministrar bienes o servicios que no regresan, a clientes que si lo hacen “

"Es el conjunto de cualidades de una persona o cosa", "Cualidad" es lo que hace que una persona o cosa sea lo que es, por su propiedad, atributo, características, don, virtud, etc.

Esta definición nos lleva a pensar en términos como confiable, servicial y durable, 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.

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.

Análisis: Consiste en la interpretación del desempeño de los procesos para su control y mejora. De esta actividad deriva el conocimiento y aprendizaje organizacional.

Auditoria de calidad: Consiste en la verificación del cumplimiento de las normas, 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. Constituye el acervo de conocimientos de la organización y permite evaluar y mantener vigente la tecnología operativa.

Estándar: Norma, medida de desempeño esperado, utilizado para evaluar o comparar acciones realizadas

Efectividad: Se refiere a la capacidad para entregar resultados planeados.

Eficiencia: Se refiere al logro de objetivos y al aprovechamiento de los recursos disponibles.



Indicador: Es un signo o medición de un fenómeno.

Índice: Es la relación cuantitativa entre dos cantidades relacionadas con un mismo fenómeno.

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. Se refiere al esquema predeterminado de referencia que define los sistemas y prácticas de calidad de la organización, congruentes con los Principios y Valores de Calidad.

Sistema: Es un conjunto de elementos con un fin común, que se interrelacionan entre sí, formando un todo dinámico.

Sistema de medición: Es el medio a través del cual se obtiene información sobre el desempeño de la organización, sus productos y servicios. Se integra por diversos elementos, entre los que se incluyen:

• Indicadores de control, efectividad, eficiencia y adaptabilidad/flexibilidad

• Métodos de muestreo, frecuencias y responsables, medición, de calibración.

Política de calidad: Directrices y objetivos generales de una empresa relativos a la calidad, expresados formalmente por la dirección general. (Forma parte de las políticas generales de una organización.

Aseguramiento de Calidad: Consiste en tener y seguir un conjunto de acciones planificadas y sistemáticas, implantadas dentro del Sistema de Calidad de la empresa. 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. Cubre dos aspectos fundamentales y diferenciados, uno es el decidir la combinación de ingredientes que dará gusto apropiado (Ingeniería de la calidad), y otro el asegurar que nuestra producción tenga la combinación de ingredientes que considere apropiados (Control 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, es decir es la gerencia o el manejo de los proceso productivos enfocada al mejoramiento continuo. Es el aspecto de la función general de la gestión que determina y aplica la política de la calidad, que incluye la planeación estratégica, la asignación de recursos y otras acciones sistemáticas en el campo de la calidad, tales como la planeación de la calidad, 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. Desarrolla, ejecuta o coordina la ejecución de los métodos de ensayo para determinar las características de calidad de las materias primas, materiales, productos intermedios y productos finales

• Diseña y realiza los estudios de estabilidad de los productos intermedios.• Participa en el desarrollo, ejecución y perfeccionamiento del Sistema de Calidad.• Técnicas y actividades de carácter operativo utilizadas para satisfacer los requisitos relativos a la

calidad.

En la terminología industrial Control, es el acto de delimitar responsabilidad y autoridad con el fin de

liberar la gerencia de detalles innecesarios, conservando los medios para asegurarse de que los

resultados sean satisfactorios.



Sistema de calidad: Es el conjunto de la estructura de organización de responsabilidades, de Procedimientos, de procesos y de recursos que se establecen para llevar a cabo la gestión de calidad. Corresponde a las necesidades propias de una organización para satisfacer los objetivos de calidad propuesto


calidad en el desarrollo de software

Documents