antología cdsw

Universidad Tecnolgica de Puebla

Antologa: Calidad en el Desarrollo de SoftwareCuatrimestre: Enero Abril 2011

COLABORADORES:M.C. Mara Micaela Lpez Monterrosas Ing. Claudia Snchez Morales

Calidad en el Desarrollo de Software Pgina 2 de 82

Indice IntroduccinDesde el enfoque tradicional de calidad que haba sido centrarse nicamente en tratar de evitar que se produjesen fallos durante la fabricacin, se evolucion segn tres etapas: Control de calidad, Aseguramiento de la calidad, Gestin de la calidad total. I. Control de Calidad

El control de calidad apareci en los aos 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 estndares) 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 despus de haber obtenido los resultados instalando sensores en aquellas fases que se quieren controlar. Lgicamente, cuantos ms controles se instalen ms se incrementaran en los costes derivados de dicho control.

Figura Representacin esquemtica del proceso de control de calidad

II.

Gestin 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 concepcin de la calidad presenta importantes implicaciones. 1. Est relacionada con las percepciones del cliente, que en gran medida son subjetivas.

Ingeniera en Tecnologas de la Informacin y Comunicacin


2. Es un concepto dinmico, ya que es preciso adaptarse constantemente a las cambiantes necesidades de los clientes. 3. Al considerar el valor percibido, el precio se incorpora tambin 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 organizacin en el compromiso con la calidad, es decir, la calidad debe impregnar a todas las reas de la organizacin. Los objetivos que se persiguen con las polticas de gestin de la calidad son: 1. 2. 3. 4. Satisfaccin del cliente. Constituye el objetivo prioritario. Conseguir hacer las cosas bien a la primera. Eliminar todo aquello que no aada valor. Evitar despilfarros. Mejorar la capacidad de reaccin del sistema mediante: Productos y servicios personalizados. Desarrollo rpido de nuevos productos y servicios. Anticipacin a las necesidades del cliente.

Como definicin de Gestin 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 organizacin (es decir, extendidas a toda la organizacin) 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 direccin y a travs de una completa participacin de todos los empleados.

III.

Aseguramiento de la calidad

El aseguramiento de la calidad son todas aquellas acciones, llevadas cabo sistemticamente, que estn destinadas a obtener un proceso productivo que asegure que el producto o servicio satisfar los requerimientos de calidad. En definitiva, la filosofa que sustenta esta etapa es que la calidad se construye en los procesos: si cada proceso se realiza correctamente, no existe ningn 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 caracterstico 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 obtencin del producto final. Podramos 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 certificacin que evalan dicho sistema y en caso de cumplir los requerimientos de calidad necesarios, certifican a la organizacin. El objetivo de la certificacin es doble: 1. Alcanzar y mantener la calidad del producto o servicio para satisfacer al cliente. 2. Proporcionar garantas al cliente de que el producto o servicio que se le ofrece cumple unos determinados estndares 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 adecuacin. De esta manera se obtiene el Manual de Calidad. 2. Auditar el sistema para verificar que las disposiciones se estn 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 caractersticas prescritas. El papel de los especialistas del departamento de calidad se centra en realizar auditoras de calidad para comprobar que el personal acta 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 satisfaccin y fidelizacin.



Control de calidad Concepto de calidad Orientacin de la empresa Responsabilidad de la calidad Se acta porque... Aplicacin de la calidad Actuacin Actitud Participacin del personal Importancia de la participacin Generacin de valor aadido Materializacin Filosofa Conformidad con las especificaciones Produccin Depto. de calidad Se detecta un error Al producto Corregir el error Reactiva Slo Depto. de calidad No se espera participacin No est claro Plan de inspeccin Arreglo

Aseguramiento de la calidad Aptitud para el uso Produccin Depto. de calidad + operarios Se intenta evitar el error Al proceso productivo Modificar el procedimiento Reactiva Depto. de calidad + operarios Importante Si Manual de calidad Prevencin

GCT Satisfaccin del cliente Cliente Todos los miembros Hay objetivos A todos los procesos de la empresa Mejora continua Proactiva Toda la empresa Imprescindible Si Sistema de gestin Mejora

Existen entidades internacionales reconocidas, que se preocupan por realizar metodologas, normas, estndares, 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 Ingeniera de Software), IEEE (Institute of Electrical and Electronics Engineers - Instituto de Ingenieros Elctricos y Electrnicos), ISO (International Organization for Standarization Organizacin Internacional de Estandarizacin) y tambin SPICE (Software Process Improvement and Capability dEtermination Mejoramiento de procesos de Software y determinacin de capacidad).



UNIDAD I INTRODUCCIN A LA CALIDAD EN EL DESARROLLO DE SOFTWARESe conoce como software al equipamiento lgico o soporte lgico de una computadora digital; comprende el conjunto de los componentes lgicos necesarios que hacen posible la realizacin de tareas especficas, en contraposicin a los componentes fsicos del sistema, llamados hardware. Los componentes lgicos incluyen, entre muchos otros, aplicaciones informticas; tales como el procesador de textos, que permite al usuario realizar todas las tareas concernientes a la edicin de textos; o el software de sistema, tal como el sistema operativo, que, bsicamente, permite al resto de los programas funcionar adecuadamente, facilitando la interaccin con los componentes fsicos y con el resto de las aplicaciones, proporcionando tambin una interfaz para el usuario.

1.1

GENERALIDADES DE LA CALIDAD

Algunos DEFINICIONES que nos dan una idea de la aplicacin de CALIDAD se dan a continuacin: 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 diseo.- Caractersticas 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 diseo durante su realizacin 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. Garanta de calidad.- Consiste en una auditoria cuyo objetivo es proporcionar la gestin para informar de los datos necesarios sobre la calidad del producto. Calidad de Software.- Existe una constante preocupacin de los investigadores tecnolgicos 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 preocupacin. 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 seIngeniera en Tecnologas de la Informacin y Comunicacin


mide al terminarlo. Hoy en da las necesidades de buscar una solucin 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, estndar o modelo que pueda ayudarlas a ser competitivas o llegar a la calidad. 1. Normas.- Las normas son un modelo, un patrn, ejemplo o criterio a seguir. Una norma es una frmula que tiene valor de regla y tiene por finalidad definir las caractersticas 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 pequeas mquinas de uso personal: secadores de cabello, mquinas de afeitar, etc. cuando se viaja. La incompatibilidad repercute en muchos campos. La normalizacin de los productos es, pues, importante. 2. Estndares.- 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 sinnimo de norma. Son normas y protocolos internacionales que deben cumplir productos de cualquier ndole para su distribucin y consumo por el cliente final. Beneficios de los Estndares Buenas prcticas de diseo. Prcticas que han funcionado tanto para el desarrollador como para el usuario. Mejoras del proceso de diseo. Reduccin del proceso de diseo mediante prueba y error.

Utilizacin de los Estndares Elegir qu estndar se va a seguir o a utilizar. Planificar un proceso de desarrollo adaptando los diferentes estndares elegidos. Aplicar las recomendaciones de los estndares. Revisar el proceso de desarrollo para observar si cumple los estndares adaptados. Refinar la adaptacin de los estndares: Si no se cumplen las recomendaciones del estndar Si el refinamiento del estndar elegido no es suficiente para desarrolladores y diseadores Si no se ha creado una versin del estndar adaptada al proyecto en desarrollo.



3. Procesos.- Conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa o simultneamente) con un fin determinado. Este trmino tiene significados diferentes segn la rama de la ciencia o la tcnica en que se utilice.

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

Caracterstic a Propsito Metodologa Definicin Audiencia

PSP Gerenciamiento y mejora de la calidad Prescriptiva Exacta Desarrolladores y gerentes

Inspecciones Mejora de calidad Presciptiva Exacta Desarrolladores la

CMM Mejora del gerenciamiento Descriptiva Vaga Gerentes

ISO 9000 Gerenciamiento de la calidad Descriptiva Vaga Gerentes



Cobertura Costo Calidad Implementac in Alcance Cuan Mensurable es

Ciclo de desarrollo Muy bajo Muy alta Semanas Integral Muy Alto

vida

del

Verificacin validacin Bajo Alta Das Estrecho Alto

y

Gerenciamiento de proyectos Alto Baja Aos Ambiguo Bajo

Aseguramiento de la Calidad Alto Baja Aos Ambiguo Bajo

INSTITUTOS QUE REGULAN LA CALIDAD La Organizacin Internacional para la Estandarizacin 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 fabricacin, comercio y comunicacin para todas las ramas industriales a excepcin de la elctrica y la electrnica. Su funcin principal es la de buscar la estandarizacin 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 pases, sobre la base de un miembro por pas, con una Secretara Central en Ginebra (Suiza) que coordina el sistema. La Organizacin Internacional de Normalizacin (ISO), con sede en Ginebra, est compuesta por delegaciones gubernamentales y no gubernamentales subdivididos en una serie de subcomits encargados de desarrollar las guas que contribuirn al mejoramiento ambiental. Las normas desarrolladas por ISO son voluntarias, comprendiendo que ISO es un organismo no gubernamental y no depende de ningn otro organismo internacional, por lo tanto, no tiene autoridad para imponer sus normas a ningn pas. Est compuesta por representantes de los organismos de normalizacin (ON) nacionales, que produce normas internacionales industriales y comerciales. Dichas normas se conocen como normas ISO y su finalidad es la coordinacin de las normas nacionales, en consonancia con el Acta Final de la Organizacin Mundial del Comercio, con el propsito de facilitar el comercio, el intercambio de informacin y contribuir con normas comunes al desarrollo y a la transferencia de tecnologas. De forma concreta, algunas Instituciones para el desarrollo de estndares son: Internacionales ISO (http://www.iso.org) IEC International Electrotechnical Commision (http://www.iec.ch)



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 SOFTWAREMantener un proceso de desarrollo controlado es la clave para generar un producto de software de calidad. En adicin 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 variacin 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. 2. 3. Concordancia con los requerimientos. Cumplir con estndares especificados. Requisitos implcitos.

Costos de la calidad: Prevencin de futuros problemas. Planificar. Revisiones. Capacitacin. Recursos Humanos.

Costos de la no calidad: Costos de correccin de errores. Resolucin de quejas. Devolucin. Imagen. Soporte.



Algunos FACTORES y/o caractersticas 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 funcin requerida. 2. CORRECCIN.- (Hace lo que quiero?). El grado en que un programa satisface sus especificaciones y consigue los objetivos de la misin 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 precisin requerida. 4. EFICIENCIA.- (Se ejecutar en mi hardware lo mejor que pueda?). La cantidad de recursos de computadora y de cdigo 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 mquina?). 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?). Tamao 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 estndares, segn sea la especialidad aplicada al software. A continuacin se trata una NORMA conocida como: EVALUACIN DEL PRODUCTO SOFTWARE: ISO 14598 Introduccin Muchas empresas de desarrollo de software han reconocido la necesidad de mejorar el producto software. La evaluacin 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 evaluacin de sus procesos y productos de software. El estndar ISO/IEC 14598 es actualmente usado como base metodolgica para la evaluacin del producto software. Este artculo presenta una exploracin sobre el mismo. Los productos de software son solo una parte de la historia. Tambin es necesario considerar mediciones en el proceso empleado para disear, desarrollar, probar y



controlar el producto. En esto juega un papel relevante la ISO/IEC 14598. La ISO/IEC 14598 ofrece una visin general, explica la relacin entre su serie y el modelo de calidad de la ISO/IEC 9126, define los trminos tcnicos utilizados, contiene requisitos generales para la especificacin y evaluacin de la calidad del software, y clarifica los conceptos generales. Adems, provee un marco de trabajo para evaluar la calidad de todos los tipos de productos de software y establece requisitos para mtodos de medicin y evaluacin de los productos de software.

Figura.

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

Es importante sealar 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 mtodos de medicin y para el proceso de evaluacin. Se ver enseguida que la ISO/IEC 14598 consta de seis partes que describen los requisitos del proceso de evaluacin 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 91261.



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 14598 El propsito de la evaluacin de la calidad del software es hacer que tanto el desarrollo y la adquisicin del software cumplan las expectativas y necesidades del usuario. Esta norma 14598 define el proceso de evaluacin y provee los requerimientos y las guas que conducen a evaluaciones de calidad, a travs de las siguientes 6 partes: I. ISO/IEC 14598 - Parte 1: Visin General Bsicamente, provee una visin general de las otras cinco partes y explica la relacin entre la evaluacin del producto software y el modelo de calidad definido en la ISO/IEC 9126. Adicionalmente, hace la presentacin del proceso de evaluacin desglosado en los siguientes pasos: Establecer los requerimientos de evaluacin. Especificar la evaluacin. Planear la evaluacin. Ejecutar la evaluacin. Vase la ilustracin de a continuacin



Figura

ISO/IEC 14598 - Parte 1: Visin General (D. A. R.)

II. ISO/IEC 14598 - Parte 2: Planificacin y Gestin Esta parte contiene los requerimientos y las guas para las funciones de soporte tales como el planeamiento y gestin para la evaluacin del producto del software. Fundamentalmente, en esta parte, se planifican las mediciones y las actividades de evaluacin. Especficamente, se incluye: Preparacin de las polticas. Definicin de objetivos organizacionales y de mejora. Identificacin de la tecnologa. Asignacin de responsabilidades. Identificacin e implementacin de tcnicas de evaluacin para software desarrollado y adquirido.Ingeniera en Tecnologas de la Informacin y Comunicacin


Entrenamiento en tecnologa, recopilacin de datos y herramientas. Comparacin y administracin de mejoras dentro la organizacin. III. ISO/IEC 14598 - Parte 3: El Proceso para Desarrolladores Esta parte provee los requerimientos y las recomendaciones para la evaluacin del producto software cuando la evaluacin 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 evaluacin 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 caractersticas fundamentales de calidad y el marco de trabajo de mediciones, deben ser definidas las etapas siguientes: Organizacin Los aspectos organizacionales de desarrollo y de soporte deben formar parte de todo el sistema de calidad y del plan de mediciones. Vase 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 tcnicamente factibles, razonables y alcanzables (dentro de los lmites de tiempo). Especificaciones En esta fase, el desarrollador realiza un mapeo de los requerimientos internos y externos de calidad, con relacin 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 medicin y valores objetivos que contribuyan a la cuantificacin de la calidad del software. Todo esto puede enfocarse por proyecto o por producto. Diseo y Planeamiento Los procedimientos requeridos para el anlisis y recopilacin de datos necesitan ser definidos. De esta manera, el plan incluir: cronogramas, designacin de responsabilidades, uso de herramientas, bases de datos y entrenamiento especializado requerido. La precisin de las mediciones y tcnicas estadsticas deben ser especificadas (vase la ISO/IEC 14598 - Parte 6). En esta fase tambin deber considerarse cmo los resultados de las mediciones impactarn 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 anlisis apropiados y se toman acciones necesarias. En cada fase del desarrollo debe procurarse lograr un montaje primeramente enfocado a las caractersticas 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 revisin general para determinar la efectividad global del ejercicio de recoleccin, para identificar costos versus costos, establecer la validez de las mtricas usadas e identificar puntos en los cuales podran obtenerse beneficios para proyectos futuros. El resultado de esta revisin podra 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 evaluacin del producto software sea conducida en funcin 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 segn ciertas especificaciones o pre-desarrollados para un mercado ms general. Los compradores tambin podran ser desarrolladores que desean integrar productos estndar en sus propios diseos de software, o tratarse de desarrolladores buscando herramientas especficas de software. Al respecto, cuatro etapas son necesarias: Establecimiento de los Requerimientos El alcance de la evaluacin 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 debern ser tambin considerados. El tiempo de la evaluacin necesita ser consistente con los objetivos; enfoques muy tempranos podran no proporcionar una figura adecuada de la situacin mientras que enfoques muy tardos podran ser muy limitados en su uso. Especificacin de la Evaluacin Durante la redaccin de las especificaciones, debe considerarse: Los requerimientos de calidad a ser evaluados correlacionados con la calidad en uso y Mtricas externas con prioridades adems de un umbral de aceptacin definido. El alcance y lo que cubren los casos de prueba donde sean aplicables referencias a mdulosIngeniera en Tecnologas de la Informacin y Comunicacin


de evaluacin. Mtodos de recoleccin de mediciones, informacin requerida y mtodos de anlisis.



Diseo de la Evaluacin El tipo de evaluacin 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 evaluacin necesita considerar: o Necesidades de acceso a la documentacin del producto, herramientas de desarrollo y personal. o Requerimientos en costos y conocimientos. o Cronograma de evaluacin y arreglos de contingencia, hitos claves y criterio para decisiones de evaluacin. o Mtodos y herramientas de reporte, procedimientos para la validacin y estandarizacin sobre proyectos futuros. Ejecucin de la Evaluacin Aunque esta etapa podra ser simplemente un registro en un libro de seguimiento, podra tenerse la necesidad de incluir: Los resultados mismos y la trazabilidad del producto as como informacin de configuracin. Registros de anlisis, resultados y decisiones. Problemas, limitaciones en las mediciones y cualquier compromiso con relacin a los objetivos originales Conclusiones sobre los resultados de la evaluacin pero tambin sobre los mtodos empleados.

V. ISO/IEC 14598 - Parte 5: El Proceso para Evaluadores Esta parte provee los requerimientos y recomendaciones para la evaluacin del producto software cuando la evaluacin es conducida por evaluadores independientes. En esta parte, tienen un rol importante los requerimientos de evaluacin, las especificaciones de evaluacin, el diseo de la evaluacin, las actividades de evaluacin y el reporte de evaluacin. Estas etapas son resumidas a continuacin: Requerimientos de Evaluacin



Los requerimientos deberan adicionalmente definir:

a. La extensin del la cobertura (o el alcance). b. Los objetivos de evaluacin y mtodos de reporte. c. Las calificaciones e independencia requeridas de un evaluador.

Especificacin de la Evaluacin Las especificaciones adicionalmente deberan cubrir: a. Definicin del alcance y formato en las mtricas empleadas identificando como debern ser derivadas a partir de los requerimientos del producto. b. La identificacin de mediciones no determinsticas para asegurar que ciertos niveles de Frecuentabilidad y objetividad requeridos sean obtenidos. c. La identificacin de mtodos de correlacin con relacin a los resultados de las mediciones. d. Se tienen identificadas tres sub-actividades con relacin a la especificacin de la evaluacin: e. El anlisis de la descripcin del producto. f. La especificacin de las mediciones a ser realizadas. g. La verificacin de la especificacin resultante frente a los requerimientos de evaluacin.

VI. ISO/IEC 14598 - Parte 6: Documentacin de los Mdulos de Evaluacin Esta parte provee las guas para la documentacin del mdulo de evaluacin. Estos mdulos representan la especificacin del modelo de calidad y las correspondientes mtricas internas y externas que sern aplicadas a una evaluacin en particular. Incluye mtodos y tcnicas de evaluacin ms las mediciones actuales resultantes de su aplicacin. En esta parte tambin se considera la administracin efectiva de complejidades inherentes a las cuestiones de medicin.



Las actividades de medicin coordinadas son una caracterstica para una evaluacin efectiva y un plan necesita proveer un cronograma de evaluacin que provea al mismo tiempo informacin ptima cuando la evaluacin sea conducida durante el desarrollo. Los mdulos de la evaluacin son componentes claves de la ISO/IEC 14598-6 y son usados para proveer un formato consistente y repetible de reporte. Dichos mdulos proveen: Visibilidad de la informacin necesitada para cuadrar con requerimientos especficos de calidad. Documentacin de las interfaces necesarias con herramientas de medicin. La ISO/IEC 14598-6 trata tambin sobre los requerimientos de la documentacin y divide a los Mdulos de evaluacin en los seis componentes siguientes: Introduccin Cubre el control del documento, las relaciones con otros documentos, los Requerimientos tcnicos y una razn para el mdulo. Alcance Se relaciona con la caractersticas de calidad o sub-caractersticas que debern ser alcanzadas, el nivel de la evaluacin (tomando en cuenta la importancia de la caracterstica, la tcnica de evaluacin usada incluyendo cualquier teora necesaria) y la aplicabilidad del mdulo. Referencias y Definiciones requeridas. Entradas requeridas Datos a ser recopilados y mtricas a ser calculadas. Informacin sobre la interpretacin de los resultados. Resultados de la Evaluacin En esta etapa se tiene la generacin del reporte de evaluacin incluyendo una revisin independiente de los resultados de la evaluacin. Normalmente, el reporte final ser precedido por un borrador de tal manera que el personal involucrado con el producto pueda proveer una retroalimentacin sobre la evaluacin.



Unidad II

Mtricas de Software 2.1 Concepto de Mtrica

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 mayora de los desafos tcnicos, las mtricas nos ayudan a entender tanto el proceso tcnico 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 trminos de productividad y de calidad, derivados del uso de nuevos mtodos y herramientas de la ingeniera de software. 4. Establecer una lnea de base para la estimacin 5. Ayudar a justificar el uso de nuevas herramientas o de formacin adicional.

2.2

Tipos de Mtricas de Calidad de Software

Las mediciones del mundo fsico pueden englobarse en dos categoras: medidas directas y medidas indirectas: Medidas Directas. En el proceso de ingeniera se encuentran el costo, y el esfuerzo aplicado, las lneas de cdigo producidas, velocidad de ejecucin, el tamao 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 MTRICAS DEL SOFTWARE son las que estn relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia, y se explican a continuacin:



MTRICAS TCNICAS: Se centran en las caractersticas de software por ejemplo: la complejidad lgica, el grado de modularidad. Mide la estructura del sistema, el cmo est hecho. MTRICAS DE CALIDAD: proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente. MTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniera del software. Es decir que tan productivo va a ser el software que voy a disear. MTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e informacin 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 mtodos. Son las medidas que voy a hacer de mi personal que va har el sistema. MTRICAS ORIENTADAS AL TAMAO. 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 organizacin de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamao como se muestra en la siguiente figura:

La tabla lista cada proyecto del desarrollo del software de los ltimos aos correspondientes, datos orientados al tamao de c/u. Refirindonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12.1 KLDC (miles de lneas de cdigo) con un esfuerzo de 24 personas mes y un costo de 168 mil dlares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla incluyen todas las actividades de la ingeniera de software como son anlisis, diseo, codificacin y prueba. Otra informacin del proyecto 222-01 indica que se desarrollaron 365 pginas mientras que se encontraron 29 errores tras entregrselo al cliente, dentro del primer ao de utilizacin tambin 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 mtricas sencillas de productividad y calidad orientadas al tamao. Se obtienen las siguientes formulas: Productividad = KLDC/persona-mes Calidad = errores/KLDC Documentacin = pags. Doc/ KLDC Costo = $/KLDC NOTA.- persona-mes es el esfuerzo MTRICAS ORIENTADAS A LA FUNCIN. Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las mtricas orientadas a la funcin se centran en la funcionalidad o utilidad del programa. Las mtricas orientadas a la funcin fueron el principio propuestas por Albercht quien sugiri un acercamiento a la medida de la productividad denominado mtodo del punto de funcin. Los puntos de funcin que obtienen utilizando una funcin emprica basando en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivos de la complejidad del software. Los puntos de funcin se calculan rellenando la tabla como se muestra en la siguiente figura: Calculo de mtricas de punto de funcin

Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la posicin apropiada de la tabla. Los valores del mbito de informacin estn definidos de la siguiente manera.



1. Nmeros de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicacin. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado. 2. Nmero de salida del usuario: se encuentra cada salida que proporciona al usuario informacin orientada a la aplicacin. 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. Nmeros de peticiones al usuario: una peticin est definida como una entrada interactiva que resulta de la generacin de algn tipo de respuesta en forma de salida interactiva. Se cuenta cada peticin por separado. 4. Nmero de archivos: se cuenta cada archivo maestro lgico, o sea una agrupacin lgica 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 informacin a otro sistema. Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. Las organizaciones que utilizan mtodos de puntos de funcin desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinacin de la complejidad es algo subjetivo. Para calcular los puntos de funcin se utiliza la siguiente relacin: 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 sealadas de la siguiente tabla. Evaluar cada factor en escala 0 a 5.



Los valores constantes de la ecuacin anterior y los factores de peso aplicados en las encuestas de los mbitos de informacin han sido determinados empricamente. Una vez calculado los puntos de funcin se usan de forma analgica a las LDC como medida de la productividad, calidad y otros productos del software. Productividad = PF / persona-mes Calidad = Errores / PF Costo = Dlares / PF Documentacin = Pags. Doc / PF La medida de puntos de funcin se diseo originalmente para ser utilizadas en aplicacin de sistemas de informacin de gestin. Sin embargo, algunas aplicaciones se les denomina puntos de caractersticas. La medida del punto de caracterstica da cabida a aplicaciones cuya complejidad algortmica es alta. Las aplicaciones de software de tiempo real de control de procesos y de sistemas que encontrados tienden a tener una complejidad algortmica alta y por tanto fcilmente tratables por puntos de caractersticas.



Para calcular los puntos de caractersticas, nuevamente se cuentan y ponderan los valores del mbito de informacin, como se describi anteriormente. Adems, las mtricas de punto de caracterstica tienen en cuenta otra caracterstica 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 inversin de una matriz, la decodificacin de una cadena de bits o el manejo de una interrupcin son todo ellos ejemplos de algoritmos. Para calcular los puntos de caracterstica, se utiliza la siguiente tabla.

Se usa un nico valor de peso para cada uno de los parmetros de medida y se calcula el valor del punto caracterstica global mediante la ecuacin. PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)] Debe tenerse en cuenta que los puntos de caracterstica y los puntos de funcin representan lo mismo. "funcionalidad o utilidad" en forma de software. EJERCICIOS 1.- Mtricas orientadas al tamao



Calcular: a) Productividad = KLDC/esfuerzo _ Hopital = ? _ farmacia = ? b) Calidad = Errores/KLDC _ Hospital = ? _ Farmacia = ? c) Costo = $/KLDC _ Hospital = ? _ Farmacia = ? d) Documentacin = Pags. doc/KLDC _ Hospital=? _ Farmacia=? 2.- Mtricas orientadas a la funcin Se tiene un sistema el cual cuenta con 3 entradas de catalogo productos, proveedores y clientes. Una pantalla de la elaboracin 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. Adems la entrada de factura tiene alrededor de 30 peticiones, el sistema genera alrededor de 30 archivos adems de estar conectado a un lector ptico y una impresora. Calcula los puntos de funcin.



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

ESTIMACIN Es una pequea planeacin sobre qu es lo que va a ser mi proyecto. Una de las actividades cruciales del proceso de gestin del proyecto del software es la planificacin. Cuando se planifica un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido, de la duracin cronolgica del esfuerzo humano requerido, de la duracin cronolgica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valindose de la experiencia pasada como nica gua. Si un proyecto es bastante similar en tamao y funciona un proyecto es bastante similar en tamao 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 tcnicas de estimacin para el desarrollo de software, aunque cada una tiene sus puntos fuertes y sus puntos dbiles, todas tienen en comn los siguientes atributos. 1. Se han de establecer de antemano el mbito del proyecto.



2. Como bases para la realizacin de estimaciones se usan mtricas del software de proyectos pasados. 3. El proyecto se desglosa en partes ms pequeas que se estiman individualmente. PLANEACIN DEL PROYECTO La planeacin efectiva de un proyecto de software depende de la planeacin detallada de su avance, anticipado problemas que puedan surgir y preparando con anticipacin soluciones tentativas a ellos. Se supondr que el administrador del proyecto es responsable de la planeacin desde la definicin de requisitos hasta la entrega del sistema terminado. No se analizara la planeacin que implica a la estimacin de la necesidad de un sistema de software y la habilidad de producir tal sistema, la asignacin de prioridad al proceso de su produccin. Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programacin, sin embargo estos puntos son validos tambin para sistemas pequeos. Panorama. Hace una descripcin general del proyecto detalle de la organizacin del plan y resume el resto del documento. Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: anlisis de requisitos, fase de diseo de alto nivel, fase de diseo de bajo nivel, etc. Asociada con cada fase debe de haber una fecha que especifique cuando se debe terminar estas fases y una indicacin de como se pueden solapar las distintas fases del proyecto. Plan de organizacin. Se definen las responsabilidades especficas 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 documentacin. Su funcin es definir y controlar la documentacin asociada con el proyecto. Plan de capacitacin. Se describe la preparacin de los programadores que participan en el proyecto y las instrucciones a los usuarios para la utilizacin del sistema que se les entregue. Plan de revisin e informes. Se analiza cmo se informa del estado del proyecto y se definen las revisiones formales asociadas con el avance de proyecto. Plan de instalacin y operacin. Se describe el procedimiento para instalar el sistema en la localidad del usuario. Plan de recursos y entregas. Se resume los detalles crticos del proyecto como fechas programadas, marcas de logros y todos los artculos 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 anlisis en los requerimientos. 2. Una mala planeacin. 3. No tener una negociacin (documento, contrato) con el cliente. 4. No hacer un anlisis costo beneficio. 5. Desconocer el ambiente de trabajo de los usuarios. 6. Desconocer los usuarios que trabajan con el sistema. 7. Mala eleccin de recursos (hardware, software, humanos).



Unidad III

Proceso Personal de Desarrollo de Software3.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. estndares Un PSP es un marco de trabajo de medicin y anlisis que te ayuda a caracterizar tu proceso. Es tambin un procedimiento definido para ayudarte a mejorar tu rendimiento.

Principios PSP 1. 2. 3. 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: conocimiento disciplina compromiso Como todo profesional software deberas conocer tu propio rendimiento. Deberas medir, seguir y analizar tu trabajo. Deberas aprender de tus variaciones de tu rendimiento. Deberas incorporar esas lecciones a tu manera personal de hacer.



El diseo de PSP se basa en los siguientes principios de planeacin y de calidad [HUMPHREY; 95] Cada ingeniero es esencialmente diferente; para ser ms precisos, los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales. Para desarrollar productos de calidad, los ingenieros deben personalmente comprometidos con la calidad de sus productos. sentirse

Para hacer un trabajo de ingeniera 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 planeacin 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 tamaos 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 mdulos de programas. 2. Definicin de requisitos o procesos. 3. Realizacin de revisiones o pruebas. 4. Escritura de documentacin, etc. 5. El PSP se puede extender al desarrollo de sistemas software de gran tamao. 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 pequeos 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 planificacin.

Existe un script de planificacin que sirve de gua 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 tamao 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 mtodos de PSP no son utilizados por los desarrolladores, los mtodos de PSP son presentados en una serie de siete versiones de procesos. Estas versiones son denominadas como PSP0 a PSP3. Cada versin 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 guan 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 ms a checklists que a tutoriales. Estos no incluyen los materiales instructivos que seran necesarios para usuarios no entrenados. El propsito 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 capacitacin en PSP o a travs de bibliografa introductoria en el uso de PSP).

PSP O. Proceso (punto de partida) PSP0 es un proceso sencillo, definido y personal. Utiliza tus mtodos actuales de diseo y desarrollo.



Recoge datos sobre tu trabajo: 1. tiempo gastado por fase 2. defectos encontrados en compilacin 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 estndar de cdigo, mediciones de tamao y el denominado PIP (Process Improvement Proposal). El PIP provee una manera estructurada de registrar problemas, experiencias y sugerencias para mejorar. PSP0.1 tambin mejora las mediciones para contar separadamente mtodos y procedimientos.

PSP1 Planeacin personal PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega estimaciones de tamao y recursos y un reporte de prueba. En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto. Los desarrolladores son enseados a: Entender la relacin entre el tamao 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 tcnicas en proyectos grandes es comprendida, pocos desarrolladores las aplican a su trabajo personal. PSP demuestra el valor de estos mtodos 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



avergenzan de sus errores. El hecho de que la mayora de los errores sean tipogrficos o errores tontos hace que los desarrolladores sientan que pueden mejorar haciendo ms esfuerzo. PSP2 agrega diseo personal y revisiones de cdigo 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 revisin que estn hechos a medida de su experiencia de defectos personales. El proceso de diseo es contemplado en PSP2.1. El objetivo no es decirle a los desarrolladores como disear sino orientar el criterio para la finalizacin del diseo, es decir, cuando han terminado que es lo que deben haber obtenido. Se establece un criterio de completitud de diseo y se examinan varias tcnicas de verificacin y consistencia de diseo. PSP3. Proceso cclico personal Hasta este punto PSP se concentr en el proceso lineal para construccin de pequeos programas. PSP3 presenta mtodos para ser usados por individuos en la realizacin de programas de gran escala. De todas formas sigue enfocado en el individuo y no trata los problemas de comunicacin y coordinacin que son una parte importante del desarrollo de sistemas de gran escala. Para escalar PSP2 a proyectos ms 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 diseados para ser desarrollados en pasos incrementales. La primera construccin consiste en un mdulo base o kernel que es ampliado en ciclos iterativos. En cada iteracin se utiliza un PSP2 completo, incluyendo diseo, codificacin, compilacin y pruebas.



El proceso cclico 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 verificacin de la calidad del ltimo incremento sin preocuparse por defectos en ciclos anteriores. Si un incremento anterior tiene muchos defectos, la prueba ser ms compleja y los beneficios de escalar PSP se pierden. Esta es una razn para enfatizar revisiones de diseo y cdigo en los pasos anteriores de PSP.

3.2

Plantillas PSP

En esta seccin se observan algunos formatos y procedimientos para la medicin del PSP. Recoleccin de datos. En PSP, los desarrolladores utilizan informacin 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 tamaos de los productos que producen, y de la calidad de esos productos.



Las medidas bsicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso, los defectos introducidos y encontrados en cada fase, y los tamaos de los productos desarrollados en lneas de cdigo (LOC). Estos datos se recopilan en cada fase del proceso y se resumen a la terminacin del proyecto. Todos estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los ingenieros usan como gua en su trabajo. Las principales medidas son: Tamao tiempo de estimacin de errores Coste de realizacin Defectos producidos y corregidos por hora Produccin del proceso Valoracin y calidad del coste de los fallos (COQ) Valoracin del rango de fallos (A/FR)

Elementos un guin de proceso un formulario resumen de plan proyecto un registro tiempo un registro de defectos un estndar de tipos defecto



No de Fase

Propsito Entradas Necesarias

Guiarte en el desarrollo de programas a nivel de mdulo Descripcin del problema Formulario de Resumen del plan del Proyecto PSPO Tablas de Registro de Tiempos y Defectos Cronometro (opcional) Producir u obtener los requisitos Estimar las LOC necesarias Estimar el tiempo de desarrollo necesario Indicar los datos del plan en el Resumen del Plan de Proyecto Completar el Log de Registro de Tiempos Disear el programa Implementar el diseo Compilar el programa y corregir todos los defectos encontrados Completar la Tabla de Registro de Tiempos Completar el Resumen del plan del Proyecto con los datos actuales de tiempo, defectos y tamao Un programa probado Un resumen del Plan de Proyectos con los datos estimados y actuales Las tablas de Registro de Tiempos y Defectos Rellenos

1

Planificacin

2

Desarrollo

3

Post-mortem Criterios de salida

Planificacin: Desarrollo:

Estimar tiempo de desarrollo. Desarrollar el producto utilizando tus mtodos actuales.



Post-mortem: Diseo: Codificacin: Compilacin: Prueba:

Completar el resumen del plan proyecto, con los tiempos gastados y defectos encontrados e inyectados en cada fase. Disear el programa, usando tus mtodos de diseo actuales. Implementa el programa. Compila hasta que est libre defectos. 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. Tamao del Programa: Plan. Indica tu mejor estimacin 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 nmero 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 nmero de programa. Fecha: Indicar la fecha actual. Inicio: Indicar el tiempo en minutos cuando empiezas una fase del proyecto Fin: Indicar el tiempo en minutos cuando tu paraste tu trabajo en una fase del proyecto, aun cuando t no has terminado esa fase. Tiempo de interrupcin: 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 interrupcin. Fase: Anotar la fase en la que ests trabajando. / Use el nombre de cada fase. Comentarios: Descripcin de la interrupcin. La tarea que ests haciendo. Cualquier aspecto significativo que afecte a tu trabajo

Fecha 9/9

Inicio 9:00 12:40 2:45

Fin 9:50 1:18 3:53 12:19 9:50 2:35 5:11 9:50

Tiempo de Interrupcin

Tiempo Delta 50 38

Actividad Planeacin Diseo Diseo Codificacin Codificacin Compilacin Prueba Prueba Postmortem

Comentarios

10 6+5

58 62 50

Telfono Bao, tom caf

10/9 11/9

11:06 9:00 1:15 4:18

3+8 25

69 28 50

Consulta de un libro Reunin con mi jefe

13/9

9:00

12:33 1:16 38 Ingeniera en Tecnologas de la Informacin y Comunicacin


Tamao El tiempo en desarrollar un producto se encuentra altamente determinado por el tamao del mismo. En PSP, los desarrolladores primero estiman el tamao de los productos que planean desarrollar. Luego, al finalizar el producto, se mide el tamao real obtenido. Esta informacin permite a los desarrolladores realizar a futuro una estimacin de tamaos ms precisa. Sin embargo, para que esta informacin sea til, el tamao de las mediciones debe corresponderse con el tiempo de desarrollo del producto. En PSP, el tamao se mide en Lneas de Cdigo (LOC). Para realizar un seguimiento de la variacin del tamao de un programa durante el desarrollo, se deben considerar varias categoras de LOC. Estas son: Base (son los LOC iniciales del producto original) Agregadas (es el cdigo agregado a un programa base existente) Modificadas (es el cdigo base que es modificado en un programa existente) Eliminadas (es el cdigo base que es eliminado de un programa existente) Reutilizacin (es el cdigo tomado de una librera u utilizado, sin realizar ninguna modificacin, en un nuevo programa) Nueva Reutilizacin (esta medida cuenta los LOC que se agregan a una librera) Total (es tamao total del programa, independientemente del cdigo fuente).

Luego, para medir el tamao total de un producto, el clculo es el siguiente: Total LOC = Base Eliminadas + Agregadas + Reutilizacin Las LOC modificadas y de nueva reutilizacin 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 reutilizacin ya se encuentran contabilizadas en las LOC agregadas. Logs de Registro de defectos El estndar de tipos de defectos proporciona un conjunto general de categoras de defectos. Aunque t puedes reemplazar este estndar 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 estndares se utilizaron para llenar los logs de Registro de defectos. A continuacin se muestra un ejemplo:

Encabezado: Indicar el nombre, fecha, instructor, y numero de programa. Fecha: Indicar la fecha cuando encontraste y corregiste el defecto. Nmero: Indicar un nmero nico para este defecto. Comienza cada proyecto con 1. Tipo: Indicar el tipo de defecto a partir del estndar 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 estimacin.



Defecto Arreglado: Si este defecto fue inyectado durante la correccin de otro defecto, indicar el nmero 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 ms eficaz de encontrar y arreglar defectos es repasando el cdigo fuente del programa personalmente. Mientras esto puede parecer como una manera difcil de limpiar un programa defectuoso, resulta ser ms rpido y ms eficaz. Un mtodo para realizar revisiones de cdigo es la utilizacin de guas en las que se determina cuales son los defectos que ms frecuentemente se inyectan. METRICAS DEL PSP Con datos de tamao, 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 medicin por s sola puede indicar adecuadamente la calidad de un programa, el panorama que provee la utilizacin de todas estas mediciones es generalmente un indicador confiable de calidad. Las principales mediciones de calidad son: 1. Densidad de defectos 2. ndice de revisin 3. ndices de tiempo de desarrollo 4. ndices de defectos 5. Rendimiento 6. Defectos por hora 7. Efectividad de remocin de defectos 8. Evaluacin del ndice de fallasResumen del registro de Mtricas Nombre: Programa Profesor Resumen Minutos/LOC LOC/Hora Defectos/KLOC Rendimiento A/FR Tamao Programa (LOC): Total nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo en fase (min.) Planing Fecha: 18/10/96 Programa # 13 Lenguaje: C++ Actual a la Fecha 4,87 5,73 12,32 10,47 106,4 96,90

Plan 5,92 10,14 94,79

58 72 41 Plan 18

47

258 Para Fecha % 6,0

Actual Para Fecha 22 88



Diseo Cdigo Revisin cdigo Compilacin Test Postmortem Total Tiempo Mximo Tiempo Mnimo 243 Introduccin de defectos Planing Diseo Cdigo Revisin cdigo Compilacin Test Total

35 149 20 24 64 33 343 426 Plan 1 5

24 93 37 4 8 41 229

151 637 111 92 240 160 1479

10,2 43,1 7,5 6,2 16,2 10,8 100 Para Fecha % Def/Hora

Actual Para Fecha 5 4 21 16,0 84,0

6

5

25

100,0



Unidad IV

Tcnicas de EstimacinMxico tiene un nivel de gasto en tecnologas de la informacin y comunicaciones (TIC) de 3.2 del PIB, ubicndose en el lugar 50 a nivel mundial. Este rezago es an mayor en trminos 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 extraarnos que a nivel industria tengamos poco avance en temas como las mtricas para SW. Es conocido que grandes proyectos han fracasado al no estar a tiempo o dentro de presupuesto por una mala estimacin de esfuerzo o duracin, o de las capacidades requeridas de los ingenieros y de la empresa. En la vida real estimamos todo el da, por ejemplo: Cuando elegimos cunto dinero llevaremos para las actividades de ese da. Estimamos el tiempo que necesitamos si vamos en nuestro auto, en taxi o en colectivo, dependiendo del lugar a dnde 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 automtico, es decir, q no nos damos cuenta. Tradicionalmente se ha medido el tamao del software mediante distintas mtricas: recuento de las lneas de cdigo (LOC), nmero de programas fuente, o tcnicas similares, que no resultan aceptables como una buena prctica profesional, porque: Su resultado depende fuertemente del entorno tcnico y el lenguaje de programacin utilizado. Vara en funcin de la pericia de cada programador y del uso de normas y metodologas. No resultan significativas al usuario ni a la direccin. Cuando se trata de establecer mtricas de productividad y calidad en la construccin de software, o realizar estimaciones de coste y duracin, es imprescindible disponer de una medida fiable y comprensible del tamao de lo que se construye.



ALGUNAS TCNICAS de estimacin se presentan a continuacin: 1. 2. 3. 4. 5. Por rangos.- En lugar de elegir un valor, elige varios de referencia. Por analoga.- Los procesos se comparan contra otros proyectos. Por recomposicin.- La tarea se descompone en procesos ms pequeos. Calibracin de procesos.- Por ejemplo Nmero de bytes, LOC y casos de uso. Juicio de los expertos.- Da su opinin gente con ms experiencia.

4.1 Puntos de FuncinLo relevante es la funcionalidad, como en cualquier inversin, a las empresas lo que les interesa es la capacidad de hacer algo con lo que compran. Por ejemplo, si se compra un camin, de alguna forma se adquiri la capacidad de transportar mercancas y con un tamao de metros cbicos 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 cunto espacio necesita la empresa o institucin. En SW no tiene por qu ser distinto; al adquirir un paquete o al desarrollar una aplicacin, lo primero que debe evaluarse es qu nuevas capacidades estoy adquiriendo. Estas capacidades o funcionalidad estarn en trminos de qu transacciones puedo realizar de forma automatizada y qu grupos de datos puedo guardar.

A continuacin se presentan algunos TIPS para comprender este tema: Se debe cumplir con medidas y evitar desviaciones en una estimacin. Los parmetros y acotaciones se toman como referencia para que una serie sea considerada vlida. TOLERANCIA.- Es un aspecto importante definida como la desviacin mxima permitida en una pieza o proceso. Depende del fin para lo que fue diseada la pieza o el proceso. A mayor CALIDAD menor tolerancia. Las mtricas o tcnicas aseguran que todas las piezas cumplan con parmetros de un plano u hoja de procesos. Algunos ejemplos de las herramientas usadas para medir son: pie de rey, micrmetro de interiores, micrmetro de exteriores, sonda de profundidad, etc.



Los dos principales determinantes para estimar el esfuerzo son: el tamao 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 aplicacin del software La mtrica del punto funcin es un mtodo utilizado en ingeniera del software para medir el tamao del software. Fue definida por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la tecnologa utilizada para la construccin y explotacin del software, y tambin ser til en cualquiera de las fases de vida del software, desde el diseo inicial hasta la explotacin y mantenimiento. Vindolo de otro punto de vista: Los Puntos de Funcin son una mtrica que permite traducir en un nmero el tamao de la funcionalidad que brinda un producto de software desde el punto de vista del usuario, a travs de una suma ponderada de las caractersticas del producto. CARACTERSTICAS de la funcionalidad INDEPENDIENTE DE LA TECNOLOGA. Si nos basamos en lneas de cdigo (en la tecnologa) vamos a obtener resultados no comparables. Pero ms que eso, tal vez lo relevante de esta caracterstica es que una vez establecida la funcionalidad que requiero, debo escoger la tecnologa que me haga ms productivo para obtener tal funcionalidad. SIMPLE. Desde su concepcin, este tipo de mtrica se plante que no requiriera grandes esfuerzos para obtener una medida. Una ventaja es que puedo establecer el tamao de un SW que tal vez llegue a tener miles de lneas de cdigo en pocas horas. Sin embargo, el costo de esta simplicidad es que la mtrica no es muy sensible a consideraciones muy detalladas, como lo sera por ejemplo, la complejidad de frmulas matemticas. ENFOQUE EN LA FUNCIONALIDAD PROPORCIONADA. Ver qu nuevas capacidades voy a obtener con el nuevo SW, antes de cualquier evaluacin tcnica. BASADA EN LOS REQUERIMIENTOS DEL USUARIO. Esta caracterstica ayuda a que el usuario pueda entender el significado e implicaciones del tamao del SW, sin tener que ser un experto en sistemas. Otro punto muy importante con esta caracterstica es que puedo establecer un tamao desde que tengo los requerimientos y no necesito esperar a terminar el proyecto para saber de qu tamao va a ser. CONSISTENCIA. Los resultados obtenidos entre diferentes personas o en proyectos distintos deben ser consistentes. No es suficiente contar con una mtrica, sino que sea estndar 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



Measurement Functional Size Measurement. Este estndar define los conceptos de una mtrica de tamao basada en la funcionalidad y las caractersticas que debe cumplir un mtodo para poder estar homologado al estndar y ser considerado una medida del tamao de la funcionalidad. El mtodo se basa principalmente en la identificacin de los componentes del sistema informtico en trminos de transacciones y grupos de datos lgicos que son relevantes para el usuario en su negocio. A cada uno de estos componentes les asigna un nmero de puntos por funcin basndose en el tipo de componente y su complejidad; y la sumatoria de esto nos da los puntos de funcin sin ajustar. El ajuste es un paso final basndose en las caractersticas generales de todo el sistema informtico que se est contando. Se puede identificar el procedimiento para la estimacin de los puntos de funcin de la siguiente manera: Paso 1. Determinar el tipo de conteo Este paso consiste en definir el tipo de conteo entre desarrollo, mantenimiento o de una aplicacin ya instalada. Esta es una forma de determinar el objetivo del conteo.

Paso 2. Identificar los alcances de la medicin y los lmites de la aplicacin. El propsito de una medicin consiste en dar una respuesta a un problema de negocio. El alcance de la medicin define la funcionalidad que va a ser incluida en una medicin especfica y puede abarcar ms de una aplicacin.



Componentes: EI: Procesos en los que se introducen datos y que suponen la actualizacin de cualquier archivo interno. EO: Procesos en los que se enva datos al exterior de la aplicacin. EQ: Procesos consistentes en la combinacin de una entrada y una salida, en el que la entrada no produce ningn cambio en ningn archivo y la salida no contiene informacin 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 datos Este paso consiste en identificar y contar la capacidad de almacenamiento de los datos. Se distinguen dos tipos de funciones de datos: Archivo Lgico Interno es un grupo de datos relacionados que el usuario identifica, cuyo propsito principal es almacenar datos mantenidos a travs de alguna transaccin que se est considerando en el conteo. Archivo de Interfaz Externo - es un grupo de datos relacionados y referenciados pero no mantenido por alguna transaccin dentro del conteo.



A cada componente identificado se le asigna una complejidad (bajo, medio o alto) considerando principalmente el nmero 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 propsito principal es mantener uno ms archivos lgicos internos. Salida Externa es un proceso cuyo propsito principal es presentar informacin al usuario mediante un proceso lgico diferente al de slo recuperar los datos. Consulta Externa es un proceso cuyo propsito principal es presentar informacin al usuario leda de uno o ms grupos de datos. A cada componente identificado se le asigna una complejidad (bajo, medio o alto) considerando el nmero de datos utilizado en el proceso y los archivos referenciados. Estos 5 componentes lgicos bsicos son con los que se describe la funcionalidad de una aplicacin y los podemos representar grficamente de la siguiente forma:

Proceso de Estimacin Mediante PF No. Entradas al Sistema (EI) No. Salidas del Sistema (EO) No. Consultas BD (EQ) No. Ficheros (ILF - EIF) Factor Correccin por Complejidad: No. Atributos de Entradas x Factor Correccin por Complejidad: No. Atributos de Salidas x Factor... x Factor Correccin por Complejidad: No. Atributos de Ficheros x + Puntos de Funcin Sin Ajustar Puntos de Funcin Ajustados Ajuste de Complejidad Tcnica Estimacin del Esfuerzo Estimacin del Tiempo de Desarrollo



Datos de Productividad del Equipo Escala de 14 Factores de Complejidad Estimacin del Presupuesto.

Calcular No. Elementos y su Complejidad Contar los Elementos de cada Componente y su Complejidad 3 Componentes Identificados Salidas Entradas Consultas Ficheros Lgicos Internos Ficheros Externos Cantidad Complejidad Cantidad Complejidad Definicin 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 administracin y slo una salida de complejidad baja para el subsistema configuracin. 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 administracin y 4 entradas de complejidad baja para el subsistema configuracin. 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 administracin y finalmente una consulta de complejidad baja para el subsistema configuracin. Ficheros Lgicos Internos: 8 almacenes intermedios de datos de complejidad alta. Ficheros Externos: No se utilizaron almacenes externos de datos.

Paso 5. Determinar los puntos de funcin no ajustados. Este paso consiste en sumar el nmero de componentes de cada tipo conforme a la complejidad asignada y utilizar la siguiente tabla para obtener el total.

Clculo de los Puntos de Funcin Sin Ajustar Por tanto los PFSA (Puntos de Funcin 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 caractersticas generales del sistema, multiplicado por 0.01. Dentro de las caractersticas hay criterios como: complejidad del proceso, facilidad de instalacin, entrada de datos en lnea, etc. Paso 7. Determinar los puntos funcin ajustados. Para determinar los puntos funcin ajustados se consideran los puntos funcin no ajustados por el factor de ajuste Obtener los PF Ajustados 5 Componentes Identificados Entradas PFSA = 306 PFA=PFSA* [0.65+[0.01*ACT]] Obtencin ACT Puntaje Factor de Ajuste Min Max Comunicacin de Datos 0 5 Proceso Distribuido 0 5 Objetivos de Rendimiento 0 5 Configuracin de Explotacin Compartida 0 4 Tasa de transacciones 0 5 Entrada de Datos en Lnea 0 5 Eficiencia con el Usuario Final 0 5 Actualizaciones en Lnea

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

Clculo de los Puntos de Funcin 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 Tcnica 5 El sistema para determinar la valoracin de uno de los Factores de Ajuste: Ej: Comunicacin de Datos: Los datos usados en el sistema se envan o reciben por lneas de comunicaciones. La valoracin para este factor se determina a travs de la eleccin de las siguientesIngeniera en Tecnologas de la Informacin y Comunicacin


alternativas: a) 0 = Sistema Aislado del exterior (slo usuarios directos) b) 1 = Aplicacin batch con entrada de datos remota o (exclusiva) utilizacin de perifricos de salida remotos. c) 2 = Aplicacin batch con entrada de datos remota y utilizacin de perifricos de salida remotos. d) 3 = Aplicacin de captura de datos En-Lnea o hay un sistema de teleproceso que pasa los datos a la aplicacin 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 comunicacin. 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 Comunicacin de Datos 4 2 Proceso Distribuido 4 3 Objetivos de Rendimiento 1 4 Configuracin de Explotacin Compartida 1 5 Tasa de transacciones 3 6 Entrada de Datos en Lnea 5 7 Eficiencia con el Usuario Final 2 8 Actualizaciones en Lnea 3 9 Lgica de Proceso Interno Compleja 1 10 Reusabilidad del Cdigo 1 11 Conversin e Instalacin contempladas 0 12 Facilidad de Operacin 1 13 Instalaciones Mltiples 2 14 Facilidad de Cambios 4 Ajuste de Complejidad Tcnica (ACT) 32 Clculo del Esfuerzo Clculo del Esfuerzo 6 PFA = 296.82 Esfuerzo horas/persona = PFA / [1 / 8 persona / hora)] = 296.82 / 0.125 = 2374.5 horas/persona LNEAS DE CDIGO = PFA * (LINEAS POR PF) Cambiar horas/efectivas por horas productivas estimadas Esfuerzo Entorno y Lenguaje Lneas de Cdigo 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 Clculo de la Duracin del Proyecto Clculo de la Duracin del Proyecto 7 DURACIN DEL PROYECTO EN HORAS = 2374.5 horas/persona / 5 personas = 474.91 horas por miembro DURACIN 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 das 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 Clculo del Presupuesto del Proyecto Clculo del Presupuesto del Proyecto 8 Costo Total del Proyecto = sueldos 1 participante del proyecto * 5 participantes * 5 meses + Otros costos necesarios durante la realizacin del proyecto = 2000 * 5 * 5 = 50000 DURACIN DEL PROYECTO EN MESES = 5 meses Participante 1: Sueldo Participante 2: Sueldo Participante n: Sueldo En la prctica se deben especificar Otros costos de operacin para determinar el presupuesto total del proyecto Desventaja: Se le ha criticado a las mtricas funcionales que requieren que alguien identifique la funcionalidad y evale la complejidad basndose en los criterios y reglas establecidas; no puedo hacer un programa que cuente automticamente. Debido a esto, distintas personas podran llegar a un conteo diferente. Para resolver esto, se han venido depurando las reglas de conteo para eliminar posibles ambigedades y cada vez hay ms material de apoyo con ejemplos



NOTA: Cualquier mtrica tiene un mbito de accin 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 Funcin, est enfocado a medir sistemas informticos completos, no programas. En este sentido no tiene un nivel de precisin suficiente para medir el tamao de programas individuales.

4.2

Puntos de Casos de Uso

Puntos de caso de uso es un mtodo de estimacin de esfuerzo para proyectos de software, a partir de sus casos de uso. Fue desarrollado por Gustav Karner en 1993, basndose en el mtodo de punto de funcin, y supervisado por Ivar Jacobson. Ha sido analizado posteriormente en otros estudios.

El mtodo 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 interaccin 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. Tambin se utilizan factores de entorno y de complejidad tcnica 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 descripcin 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 ms 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 anlisis de puntos de funcin a estos casos de uso, se puede obtener una estimacin trivial del tamao y a partir de ella una estimacin del esfuerzo.



MTODO El mtodo de punto de casos de uso consta de cuatro etapas, en las que se desarrollan los siguientes clculos: 1. 2. 3. 4. 1. Factor de peso de los actores sin ajustar (UAW) Consiste en la evaluacin de la complejidad de los actores con los que tendr que interactuar el sistema. Este puntaje se calcula determinand

antología cdsw

Documents