G18701

UNIVERSIDAD TCNICA PARTICULAR DE LOJA
La Universidad Catlica de Loja
MODALIDAD ABIERTA Y A DISTANCIA
ESCUELA DE CIENCIAS DE LA COMPUTACIN

Gua didctica
I NGENIERA DEL SOFTWARE

7
CICLO
CARRERA: Ingeniera en Informtica AUTOR: Armando Cabrera Silva
Reciba asesora virtual en: www.utpl.edu.ec
OCTUBRE 2009 - FEBRERO 2010

MATERIAL DE USO DIDCTICO PARA ESTUDIANTES DE LA UNIVERSIDAD TCNICA PARTICULAR DE LOJA, PROHIBIDA SU REPRODUCCIN TOTAL O PARCIAL POR CUALQUIER MEDIO
INGENIERA DEL SOFTWARE

Gua didctica
Armando Cabrera Silva UNIVERSIDAD TCNICA PARTICULAR DE LOJA CC Ecuador 3.0 By NC ND Diagramacin, diseo e impresin: EDITORIAL DE LA UNIVERSIDAD TCNICA PARTICULAR DE LOJA Call Center: 593 - 7 - 2588730, Fax: 593 - 7 - 2585977 C. P.: 11- 01- 608 www.utpl.edu.ec San Cayetano Alto s/n Loja - Ecuador Primera edicin
ISBN - 978 - 9942 - 00 - 619 - 9
Esta versin impresa, ha sido licenciada bajo las licencias Creative Commons Ecuador 3.0 de Reconocimiento - No comercial - Sin Obras Derivadas; la cual permite copiar, distribuir y comunicar pblicamente la obra, mientras se reconozca la autora original, no se utilice con fines comerciales ni se realicen obras derivadas. http://www.creativecommons.org/licences/by-nc-nd/3.0/ec/
Febrero, 2009
NDICE
TEM PGINA INTRODUCCIN ........................................................................................................................................... 5 OBJETIVOS GENERALES .......................................................................................................................... 5 BIBLIOGRAFA ............................................................................................................................................... 6 ORIENTACIONES GENERALES ............................................................................................................... 7
PRIMER BIMESTRE
OBJETIVOS ESPECFICOS......................................................................................................................... 9 DESARROLLO DEL APRENDIZAJE........................................................................................................ 11 Captulo 1: .................................................................................................................................................................... 11 Conceptos de gestin de proyectos Captulo 2: .................................................................................................................................................................... 16 Mtricas del proceso, proyecto y producto Captulo 3: .................................................................................................................................................................... 25 Estimacin para proyectos de software Captulo 4: .................................................................................................................................................................... 32 Calendarizacin de proyectos de software
SEGUNDO BIMESTRE
OBJETIVOS ESPECFICOS......................................................................................................................... 37 DESARROLLO DEL APRENDIZAJE........................................................................................................ 39 Captulo 5: .................................................................................................................................................................... 39 Gestin del riesgo Captulo 6: .................................................................................................................................................................... 44 Gestin del cambio Captulo 7: .................................................................................................................................................................... 48 Ingeniera de software basada en componentes Captulo 8: .................................................................................................................................................................... 59 Reingeniera SOLUCIONARIO ............................................................................................................................................ 65
EVALUACIONES A DISTANCIA
PRELIMINARES
Gua didctica: Ingeniera del Software
Introduccin
La ingeniera del software ha evolucionado: desde una idea oscura practicada por un nmero de relativamente pequeo de fanticos hasta una disciplina de ingeniera legtima. En la actualidad se reconoce como una materia valiosa para la investigacin seria, el estudio consciente y el animado debate. En la industria el ingeniero de software ha sustituido al programador como el titular laboral de preferencia. Los modelos de proceso, los mtodos de ingeniera y las herramientas de software se ha adoptado exitosamente a lo largo de un amplio espectro de aplicaciones industriales. Aunque los gestores y los profesionales reconocen por igual la necesidad de un enfoque ms disciplinado del software, continan debatiendo la forma en que se aplicar la disciplina. Individuos y compaas todava desarrollan software de manera aleatoria y artesanal, aun cuando construyan sistemas para atender las tecnologas ms avanzadas de la actualidad; de igual manera muchos profesionales y estudiantes no estn consientes de los mtodos, procesos, herramientas y metodologas modernas que se utilizan para grarantizar el xito de los proyectos de software, tomando a estas como actividades burocrticas y consumidoras de tiempo y alineadas con la necesidad entregar productos de software en tiempo y costos no acordes con el alcance real del proyecto. Adems, contina el debate y la controversia acerca de la verdadera naturaleza del enfoque de la ingeniera del software. El estado de esta disciplina es un estudio de contrastes. Las actitudes han cambiado, el progreso se ha materializado, pero todava falta mucho por hacer antes de que la disciplina alcance la madurez. En nuestro Pas se estn haciendo esfuerzos espordicos para aplicar los conceptos de ingeniera al desarrollo de proyectos de software y que nacen de la necesidad de mejorar la competitividad del sector a nivel nacional e internacional; por esta razn es importante que como estudiantes de este curso podamos asimilar la importancia de considerar al desarrollo de software como una disciplina de la ingenieria y no como una mera actividad desarrollo de productos.
UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja
PRELIMINARES
Objetivo generales
Dotar al estudiante del marco conceptual y las tcnicas necesarias que permitan manejar la gestin de proyectos y los temas avanzados de la ingeniera de software
Bibliografa
Texto Base Pressman Roger., Ingeniera de Software un Enfoque Prctico. 6ta edicin. McGraw-Hill Mxico. ISBN 970-10-5473-3. 2005. Bibliografa complementaria Mc Connell Steve, Desarrollo y gestin de Proyectos Informticos Ed. McGraw-Hill. 1998 ISBN: 8448112296. Fundamentos d la Direccin de Proyectos PMI, Project Management Institute, Inc, Newtown Square, Pennsylvania EEUU, ISBN 1-930699-45-X 2004 Grompone Juan, Gestin de Proyectos de Software. 1era. Edicin, Editorial La Flor de Itapbi Montevideo Uruguay ISBN 9974-592-05-4 1996. Linger Richard C, Cleanroom Software Engineering Reference Model Version 1.0 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 1996
PRELIMINARES
Orientaciones generales
Estudiar a distancia es un reto que requiere esfuerzo, dedicacin y sobre todo de organizacin, por ello debe hacer de esta actividad un trabajo continuo y sistemtico, organice su tiempo de manera que pueda verdaderamente aprovechar los contenidos que se le estn ofreciendo. Le sugiero hacer vida esta frase, que aunque le puede parecer trillada, es la que ms se adapta a la realidad de las personas que estudian a distancia: No deje para maana lo que puede y debe hacer hoy Le propongo algunas orientaciones que le servirn en su proceso de aprendizaje: 1. Materiales Para su estudio usted dispondr del texto bsico, mencionado en la bibliografa y la gua didctica. La gua didctica ser quien oriente su camino en el proceso de enseanza-aprendizaje; por lo que, la debe tener siempre a la mano y seguir las pautas y sugerencias que se darn para todo el proceso educativo. Inicie su estudio leyendo la gua didctica con gran atencin, ponga especial inters en el propsito que se plantean al inicio de cada captulo, los conceptos claves y el plan que se sugiere seguir para cumplir con el propsito del captulo. Esta gua cuenta con recursos didcticos que le apoyarn: resmenes, cuadros, ejemplos, auto evaluaciones y solucionario. Es necesario realizar las actividades planteadas y reflexione sobre el nivel de captacin que est alcanzando. 2. Cmo estudiar? Para ayudarse en el proceso de aprendizaje utilice las tcnicas de estudio que ms se adapten a su manera de aprender: subrayado, resmenes, cuadros sinpticos y trate, en lo posible, de estudiar en un horario y ambiente adecuado. Estudie detenidamente los contenidos del texto bsico sugeridos en la gua, no se conforme nicamente con leerlos, trate de asimilarlos en profundidad, integrarlos y darles una elaboracin personal; slo as podr llegar a la aplicacin y transferencia de los conocimientos. Intente organizar su tiempo de tal manera que pueda dedicar al estudio de esta materia las horas que se han planeado en cada captulo. El ambiente en donde usted estudie influye mucho en su proceso de asimilacin de contenidos, por lo que, trate en lo posible que ste sea el ms adecuado especialmente en lo que se refiere a iluminacin, temperatura y ventilacin. 3. Apoyo tecnolgico e Interactividad Para usted ya es familiar, que cuenta con el apoyo tecnolgico de una plataforma o entorno virtual de aprendizaje (EVA) www.utplonline.edu.ec, este entorno, accesible nicamente para los estudiantes de la UTPL, le permite interactuar con docentes y compaeros. Consulte con frecuencia el espacio ANUNCIOS donde encontrar informacin y orientaciones sobre el desarrollo de esta asignatura. Desde este semestre se empieza a calificar su participacin a travs del Campus Virtual, interacte a travs de los foros.
PRELIMINARES
Finalmente recuerde que aunque estudia a distancia, esto no significa que est solo, llmenos o escrbanos al correo electrnico las veces que sea necesario, ser muy grato aclarar cualquier duda o interrogante que tuviera.
Plan de desarrollo de contenidos

La materia consta de dos bimestres, los contenidos en funcin del texto base son: PRIMER BIMESTRE Captulos de Texto Base Captulo 21. Conceptos de Gestin de Proyectos Captulo 22. Mtricas de proceso y proyecto Captulo 23. Estimacin de proyectos de software Captulo 24. Calendarizacin de proyectos de software Pginas 640 - 661 663 - 688 690 - 722 725 - 746 Horas 8 8 8 8 32 SEGUNDO BIMESTRE Captulos de Texto Base Captulo 25 Gestin del Riesgo Pginas 747 - 766 Horas 8 8 8 8 32
Captulo 27 Gestin del Cambio 796 - 827 Captulo 30 Ingeniera del software basada en 858 - 878 componentes Captulo 31 Reingeniera 902 337
PRIMER BIMESTRE
PRIMER BIMESTRE
Objetivos especficos
Conocer como se debe gestionar el personal, el proceso y los problemas durante un proyecto de software. Conocer como pueden emplear las mtricas de software para gestionar el proceso de software y el respectivo proceso. Conocer y aplicar las tcnicas que pueden aplicarse para evaluar formalmente los riesgos que pueden incidir en el xito del proyecto. Conocer y aplicar tcnicas y herramientas para la adecuada calendarizacin de proyectos de software.
Contenidos
CAPTULO 1 CONCEPTOS DE GESTIN DE PROYECTOS DATOS GENERALES: PROPSITO CONCEPTOS CLAVE ESQUEMA DE ESTUDIO CUESTIONES DE REPASO INTERACTIVIDAD A TRAVS DE LOS FOROS DE CAMPUS VIRTUAL EJERCICIOS DOCUMENTACIN ADICIONAL
CAPTULO 2 MTRICAS DEL PROCESO, PROYECTO Y PRODUCTO DATOS GENERALES: PROPSITO CONCEPTOS CLAVE ESQUEMA DE ESTUDIO CUESTIONES DE REPASO INTERACTIVIDAD A TRAVS DE LOS FOROS DE CAMPUS VIRTUAL EJERCICIOS DOCUMENTACIN ADICIONAL
PRIMER BIMESTRE
CAPTULO 3 ESTIMACIN PARA PROYECTOS DE SOFTWARE DATOS GENERALES: PROPSITO CONCEPTOS CLAVE ESQUEMA DE ESTUDIO CUESTIONES DE REPASO INTERACTIVIDAD A TRAVS DE LOS FOROS DE CAMPUS VIRTUAL EJERCICIOS DOCUMENTACIN ADICIONAL CAPTULO 4 CALENDARIZACIN DE PROYECTOS DE SOFTWARE DATOS GENERALES: PROPSITO CONCEPTOS CLAVE ESQUEMA DE ESTUDIO CUESTIONES DE REPASO INTERACTIVIDAD A TRAVS DE LOS FOROS DE CAMPUS VIRTUAL EJERCICIOS DOCUMENTACIN ADICIONAL
10
PRIMER BIMESTRE
Desarrollo del aprendizaje

Captulo 1: Conceptos de Gestin de Proyectos
Datos Generales:
Texto base Captulo Pginas Pressman Roger S. Ingeniera del Software. Un enfoque prctico 6ta edicin. McGrawHill Interamericana Mexico. 2005. 21. Conceptos de Gestin de Proyectos 640 661 Horas de estudio empleadas para el desarrollo del contenido 8 horas
Propsito
En captulo se consideran conceptos claves que conducen a la gestin efectiva de proyectos de software. La gestin de proyectos de software involucra la planificacin supervisin y control del personal, el proceso y los eventos que ocurren mientras el software evoluciona desde un concepto preliminar hasta una implementacin operativa
Conceptos Clave
Gestin de proyectos Es la aplicacin de conocimientos, habilidades, herramientas y tcnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La gestin de proyectos se logra mediante la aplicacin e integracin de los procesos de direccin de proyectos de inicio, planificacin, ejecucin, seguimiento y control, y cierre. mbito del software La primera actividad de gestin dentro de un proyecto de software es la determinacin del mbito (alcance) del software el que no debe ser ambiguo ni incomprensible a nivel de gestin y tcnico. Se debe acotar un enunciado del mbito del software: establecer de manera explcita los datos cuantitativos (nmero de usuarios simultneos, tiempos de respuesta mximo etc.), y describir los factores que reducen los riesgos (los algoritmos se comprenden bien y estn disponibles en C++) Descomposicin del problema A veces llamada particin o elaboracin del problema, es una actividad que se asienta en el ncleo del anlisis de requisitos, Durante la fijacin del mbito no se realiza intento alguno por descomponer completamente el problema. Ms bien, la descomposicin se aplica en dos grandes reas: 1) la funcionalidad que debe entregarse, 2) el proceso que se emplear para entregarla. Equipo de software La mejor estructura del equipo depende del estilo de gestin de cada organizacin, del nmero de personas que integrarn el equipo y de sus grados de habilidad, as como de la dificultad global del problema
11
PRIMER BIMESTRE
Equipos giles La filosofa gil alienta la satisfaccin del cliente y la temprana entrega incremental de software; pequeos equipos de trabajo enormemente motivados; mtodos informales; mnimos productos de trabajo de ingeniera de software; y simplicidad global de desarrollo. Los equipos giles adoptan caractersticas de los equipos de proyecto exitosos, y evitan muchas de las toxinas que crean problemas. Sin embargo, el enfoque gil subraya la competencia individual (miembros del equipo) en conjuncin con la colaboracin del grupo como factores de xito cruciales para el equipo. Lderes de equipos La gestin del proyecto es una actividad intensamente humana; por tanto, los profesionales competentes con frecuencia no son buenos lderes de equipo. Simplemente no tienen la mezcla correcta de habilidades con el personal. Modelo de liderazgo: Motivacin Organizacin Ideas o innovacin Resolucin de problemas Dotes de gestin Incentivos Influencia y fomento de la cultura de equipo
Participantes Para ser eficaz, el equipo de proyecto debe estar organizado en una forma que maximice las capacidades y habilidades de cada persona. Taxonoma: Gestores ejecutivos Gestores Profesionales Clientes Usuarios finales
Proceso El proceso de desarrollo de software es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo. Concretamente define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo [Jacobson 98].
12
PRIMER BIMESTRE
Esquema de estudio
A continuacin se detallan los temas que se deben desarrollar, una descripcin general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilacin de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicacin a cada tema, marcar las actividades que estima que necesita tutora y realizar anotaciones.
TEMA A REVISAR DESCRIPCIN DEL CONTENIDO A REVISAR ACTIVIDADES RECOMENDADAS ANOTACIONES:
21.1 El espectro de la gestin
PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)
Se describe el enfoque principal de la gestin de proyectos de software basado en las cuatro P: personal, producto, proceso y proyecto. Defina dada uno de los enfoques de la gestin de proyectos y establezca como se interrelacionan.
REQUIERO TUTORA?
TEMA A REVISAR DESCRIPCIN DEL CONTENIDO A REVISAR
21.2.Personal
Se describe la importancia del personal en un proyecto de software. El personal debe estar organizado en equipos eficientes, motivados para hacer un trabajo de software de alta calidad y coordinados para lograr una comunicacin eficaz Razone la importancia de contar con personal altamente capacitado para el desarrollo de un proyecto de software. Haga anotaciones de las principales caractersticas que a su criterio debe cumplir el personal de software. Indique cuales son a su criterio las principales caractersticas que debe cumplir un lder de equipo Analice el ensayo HOGAR SEGURO de la Pg. 651, comente acerca de la conversacin de los actores
ACTIVIDADES RECOMENDADAS
ANOTACIONES:
REQUIERO TUTORA?
21.3 Producto
Permite examinar el producto y el problema que se intenta resolver desde el inicio del proyecto, es decir establecer y acotar el mbito del producto: establecer de manera explcita los datos cuantitativos, las restricciones o limitaciones y los factores de reducen los riesgos. Defina el mbito del problema para una pequea aplicacin de inventarios de un hospital donde se deben registrar ingresos y egresos, caducidad de medicinas, etc.
REQUIERO TUTORA?
13
PRIMER BIMESTRE
21.4 Proceso
Describe cmo seleccionar un marco de trabajo comn mediante la aplicacin de un paradigma de ingeniera de software adecuado y la eleccin de un conjunto de tareas para llevar a cabo el trabajo. Consultar modelos de procesos de referencia, tradicionales (MSF RUP), giles (XP AUP), realizar observaciones a cada uno de ellos y encontrar puntos coincidentes.
REQUIERO TUTORA?
21.5 Proyecto
Describe un enfoque de sentido comn para la efectiva gestin de proyectos y evitar algunos problemas planteados. Realice tablas resumen de los principales problemas (adems de los indicados en libro), los que usted considera perjudicaran la gestin de un proyectos de software.
REQUIERO TUTORA?
21.6 El principio W HH
5
Permite abordar los objetivos del proyecto, los hitos, y planificacin, responsabilidades, gestin y enfoques tcnicos y recursos requeridos. Analice detalladamente cada una de las preguntas planteadas por el principio, para la definicin de caractersticas claves del proyecto.
REQUIERO TUTORA?
Cuestiones de repaso
Como medidor de asimilacin de los contenidos, desarrollaremos las siguientes cuestiones de repaso; le recomendamos que responda las preguntas de auto evaluacin y para su informacin registre el nivel de desempeo que observo, esto le permitir saber los temas que debe volver a revisar si su desempeo lo considera medio, y en caso de observar un desempeo malo recuerde que puede solicitar tutora mediante el campus virtual o telefnicamente.
14
PRIMER BIMESTRE
No. 1. 2. 3. 4. 5. 6. 7.
Cuestin Defina proceso de software. Qu buscara usted en la persona que va a dirigir un proyecto de software? Qu factores usted considera indispensables al elegir una estructura de un equipo de software? Qu opciones se tienen cuando se define la estructura de un equipo de software? Cules son las seales que indican que un proyecto de software est en peligro? Cules son las actividades de gestin que abarca un proyecto de software? Qu debe hacer el equipo de software cuando ya se ha seleccionado un modelo de proceso?
DESPUS DE RESPONDER, EL DESEMPEO HA SIDO:
Malo
Medio
Muy bien
Interactividad a travs de los Foros de Campus Virtual

Ingrese peridicamente al campus virtual que se encuentra en la siguiente direccin: http://www.utplonline.edu.ec e interactu con el foro y las peguntas planteadas para este captulo, recuerde que su participacin ser calificada como parte de la evaluacin a distancia.
Ejercicios
Para reforzar el nivel de conocimientos del presente captulo se deben realizar las siguientes actividades. Problemas: 21.1, 21.3, 21.4, 21.6, 21.7, 21.8, 21.9, 21.10, 21.11.
Documentacin adicional
Para ampliar la informacin del texto base se dispone de bibliografa adicional, que estar disponible como anexo en la gua de estudio o en digital, a estos ltimos recursos podr acceder a travs del campus virtual.
DESCRIPCIN Este articulo trata las metodologas propias de los proyectos de software. Archivo disponible en UTPLONLINE
Gestin de proyectos de Software
1
PRIMER BIMESTRE
Captulo 2
Mtricas del Proceso, Proyecto y Producto
Datos Generales:
Texto base Captulos Pginas Presuman Roger S. Ingeniera del Software. Un enfoque prctico 6ta edicin. McGraw-Hill Interamericana Mxico. 2005. 22 Mtricas del Proceso de Proceso y Proyecto 663 685 Horas de estudio empleadas para el desarrollo del contenido 8 horas
Propsito
Este captulo le permitir al estudiante, a travs de la medicin, obtener un visn de la eficacia del proceso de software y los proyectos que se llevan a cabo utilizando el proceso como marco de trabajo. La medicin permitir destacar las tendencias (ya sean buenas o malas) y hacer mejores estimaciones y como marcar las reas problema de modo que se puedan desarrollar remedios y mejorar el proceso de software.
Conceptos Clave
EED Mtrica de calidad (eficacia en la eliminacin de defectos - EFD) que ofrece servicios tanto en el mbito del proyecto como en el del proceso. Permite filtrar las actividades de garanta de calidad y de control conforme se aplica a travs de todas las actividades del marco de trabajo del proceso. Indicador Es una mtrica o combinacin de mtricas que proporcionan una visin del proceso, del proyecto o del software en s, y poder hacer ajustes para que las cosas mejoren. Medicin Proporciona una indicacin cuantitativa de extensin, cantidad, dimensiones, capacidad y tamao de algunos atributos de un proceso o producto. Pueden ser directas, por ejemplo: nmero de lneas de cdigo, nmero de errores encontrados, etc., o pueden ser indirectas, por ejemplo: funcionalidad, calidad, complejidad, etc. Medida Acto de determinar una medida Medidas de calidad Las mtricas de calidad se asocian a unos determinados atributos medibles, no siempre evidentes, para reconocer la presencia o ausencia de calidad.
1
PRIMER BIMESTRE
Medidas de productividad Las mtricas de productividad recogen la eficiencia del proceso de produccin de software y relacionan el software que se ha construido con el esfuerzo que ha costado elaborarlo.
MEPS
Conforme una organizacin se siente ms cmoda con la recopilacin y el empleo de mtricas del proceso, la deduccin de indicadores simples da la pauta para un enfoque ms riguroso llamado mejora estadstica del proceso de software (MEPS). Aplica el anlisis de falla de software para recopilar informacin acerca de todos los errores y defectos que se encuentran al desarrollar y utilizar una aplicacin, sistema o producto.
Mtrica
Es una medida cuantitativa del grado en que un sistema o proceso posee un atributo dado. Por lo general relaciona una o ms medidas, por ejemplo: nmero de errores encontrados por cada mil lneas de cdigo.
METRICAS DEL SOFTWARE Mtricas tcnicas Mtricas de calidad Se centran en las caractersticas del software por ejemplo: la complejidad lgica, el grado de modularidad. Proporcionan un indicador de cmo se ajusta el software a los requisitos implcitos e explcitos del cliente. Proporcionan informacin sobre la forma en que la gente desarrolla el software, desde la perspectiva de la efectividad de las herramientas y mtodos. Son medidas directas al software y el proceso por el cual se desarrolla. Son medidas indirectas del software y del proceso por el cual se desarrolla. Estas medidas se centran en la funcionalidad o utilidad del software.
Mtricas de productividad Se centran en el rendimiento del proceso de la Ingeniera de Software. Mtricas orientadas a la persona Mtricas orientadas al tamao Mtricas orientadas a la funcin
Mtricas de casos de uso

El caso de uso se define en etapas tempranas del proceso de software, lo que permite emplearlo en la estimacin antes de iniciar las actividades significativas de modelado y construccin
Mtricas de proyecto
Las mtricas del proceso se recopilan en el curso de todos los proyectos y durante largos periodos. Proporcionan un conjunto de indicadores de proceso que conduzcan a la mejora de los procesos de largo plazo. La nica forma de racional de mejorar cualquier proceso es medir sus atributos especficos, desarrollar un conjunto de mtricas significativas con base en dichos atributos y luego emplear las mtricas para ofrecer indicadores que conducirn a una estrategia de mejora
1
PRIMER BIMESTRE
Mtricas de proceso
A diferencia de las mtricas del proceso de software que se utilizan con propsitos estratgicos, las mtricas del proyecto son tcticas. Es decir, un gerente de proyecto y un equipo de software emplean las mtricas del proyecto y los indicadores que se deducen de ellas para adaptar el flujo de trabajo del proyecto y las actividades tcnicas. La primera aplicacin de las mtricas del proyecto en la mayora de proyectos de software ocurre durante la estimacin.
Mtricas orientadas a la funcin

Se usa de manera efectiva como medio para medir la funcionalidad que entrega un sistema. Emplea datos histricos, se usa para: 1) estimar el costo o el esfuerzo requerido para disear, codificar y probar el software; 2) predecir el nmero de errores que se encontrarn durante la prueba; 3) pronosticar el nmero de componentes, de las lneas de cdigo proyectadas, o ambas en el sistema implementado. La medida de punto de funcin se propuso en 1979 y trata de medir la funcionalidad o utilidad del software. Clculo del punto de funcin1 1. Hay que completar la siguiente tabla de valores del dominio de la informacin:
Parmetro Nmero de entradas de usuario Nmero de salidas de usuario Nmero de peticiones de usuario Nmero de archivos Nmero de interfaces externas Total Cuenta Factor de ponderacin Simple Medio Complejo 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 Subtotal
Donde: Entradas de usuario. Son entradas que proporcionan diferentes datos a la aplicacin. No confundirlos con las peticiones de usuario. Salidas de usuario. Son reportes, pantallas o mensajes de error que proporcionan informacin. Los elementos de un reporte, no se cuentan de forma separada. Peticiones de usuario. Es una entrada interactiva que produce la generacin de alguna respuesta del software en forma de salida interactiva. Archivos. Son los archivos que pueden ser parte de una base de datos o independientes. Interfaces externas. Son los archivos que se usan para transmitir informacin a otro sistema.
1. Puntos de Funcin.-Basados en una combinacin de caractersticas del programa: Entradas y salidas externas; interacciones de usuario; interfaces externas; ficheros usados por el sistema. Se asocia un peso con cada uno de ellos. Los puntos de funcin se calculan multiplicando cada factor por su peso y sumando todos ellos.
1
PRIMER BIMESTRE
Indicaciones: Contar cada medida por separado. Asociar, de alguna manera, un valor de complejidad a cada medida. La siguiente tabla muestra una heurstica para decidir la complejidad de todo el sistema.
Tipos de archivos referenciados 0-1 2-3 4+ Tipos de datos elementales 1-5 bajo bajo medio 6-19 bajo medio alto alto alto 20+ medio
2.
Para cada medida, multiplicar su cuenta por el factor de complejidad elegido y escribirlo en la columna de la extrema derecha. Sumar la columna de la extrema derecha y obtener un total T que indica el valor del dominio de la informacin. Responder a cada una de las siguientes catorce preguntas y asignarles un valor entre 0 y 5, donde 0 es no influencia, 1 es incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es esencial. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Requiere el sistema copias de seguridad y de recuperacin fiables? Requiere comunicacin de datos? Existen funciones de procesamiento distribuido? Es crtico el rendimiento? Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? Requiere entrada de datos interactiva? Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? Se actualizan los archivos maestros de forma interactiva? Son complejas las entradas, las salidas, los archivos o las peticiones? Es complejo el procesamiento interno? Se ha diseado el cdigo para ser reutilizable? Estn incluidas en el diseo la conversin y la instalacin? Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario?
1
PRIMER BIMESTRE
Sumar los puntos asignados a cada respuesta y obtener un total F que indica un valor de ajuste de complejidad. 3. El punto de funcin FP se calcula con la siguiente ecuacin:
PF = T * (0.65 + 0.01 * F).
Mtricas orientadas a objetos

Las mtricas de proyectos de software convencionales (LCD o PF) se aplican en la estimacin de proyectos de software orientados a objetos. Sin embargo estas mtricas no proporcional el suficiente grado de granularidad para la planificacin y los ajustes de esfuerzo que se requieren conforme se itera a lo largo de un proceso evolutivo o incremental. Se sugiere el siguiente conjunto de mtricas para proyectos de OO: Nmero de guiones de escenario Nmero de clases clave Nmero de clases de apoyo Nmero promedio de clases de apoyo por clase clave. Nmero de subsistemas.
Mtricas orientadas al tamao

Preceden de la normalizacin de las medidas de calidad o productividad considerando el tamao de software que se ha producido. El desarrollo de mtricas que se asimilen con mtricas similares precedentes de otros proyectos requiere elegir lneas de cdigo (LDC) como valor de normalizacin Medidas Lneas de cdigo2 (LDC). Esfuerzo en hombre-mes. Costo en dlares. Nmero de pginas de documentacin. Nmero de errores. Fallas detectadas antes de entregar el software al cliente. Nmero de defectos. Fallas detectadas despus de entregar el software al cliente. Nmero de personas en el proyecto.
2. Qu es una lnea de cdigo? Es una medida propuesta inicialmente cuando los programas se escriban en tarjetas, con una lnea por tarjeta. actualmente los lenguajes permiten escribir varias sentencias en una lnea, o una misma sentencia en varias lneas. Se debe decidir qu programas deberan contarse como parte del sistema. Asumen una relacin lineal entre el tamao y el volumen de documentacin
20
PRIMER BIMESTRE
Mtricas Errores por KLDC (mil lneas de cdigo). Defectos por KLDC. Costo por KLDC. Pginas de documentacin por KLDC. Errores por hombre-mes. LDC por hombre-mes. Costo por pgina de documentacin.
Ventajas Son fciles de calcular. Muchos modelos de estimacin de software usan LOC o KLOC como datos de entrada. Existen un amplio conjunto de datos y literatura basados en LOC.
Desventajas Son dependientes del lenguaje de programacin. Perjudica a los programas cortos pero bien diseados.
Su uso en estimacin es difcil porque hay que estimar las LOC a producirse mucho antes de que se complete el anlisis y el diseo.
Esquema de estudio
21
PRIMER BIMESTRE
TEMA A REVISAR
22.1 Mtricas en los dominios del proceso y el proyecto
DESCRIPCIN DEL CONTENIDO A REVISAR
Permite definir, como una organizacin puede adoptar una visin estratgica al proporcionar informacin de la eficacia de un proceso de software. Adems, en este captulo se analiza las principales determinantes de calidad del software y la eficacia organizacional Revisar puntos 22.1.1, interesa que se adquiera un conocimiento general del tema. Realice un anlisis desde su perspectiva de las determinantes para la calidad del software y la eficacia organizacional, tome como base la figura 22.1 Revisar puntos 22.1.2, interesa que se adquiera un conocimiento general del tema. Analice el ensayo HOGAR SEGURO de la pgina 668 comente acerca de los puntos tratados por los actores.
ANOTACIONES:
REQUIERO TUTORA?
22.2 Medicin del Software
Describe las principales categoras para efectuar la medicin del software. Analice cada una de las mtricas del software, realice un cuadro comparativo que permita establecer sus principales caractersticas, coincidencias y diferencias. Revisar el punto 15.2, interesa que se adquiera un conocimiento general del tema. Revisar el punto 15.3. Interesa que adquiera conocimiento general acerca de las mtricas del modelo de anlisis. Analice el ensayo HOGAR SEGURO de la Pg.: 473 comente acerca de los puntos tratados por los actores. Investigue cada una de las herramientas para la medicin de software que se presentan en la pgina 676.
ANOTACIONES:
REQUIERO TUTORA?
22.3 Mtricas para la calidad del software Permite determinar la calidad del software a travs de la medicin de errores y defectos, lo que proporciona un indicio de la efectividad de la garanta de la calidad del software. Analice cada una de las mtricas de calidad propuestas en la Pg.: 677 678 e indique cual usted considera de mayor importancia al momento de medir la calidad del software. Analice el ensayo HOGAR SEGURO de la pgina 679 comente acerca de los puntos tratados por los actores.
REQUIERO TUTORA?
22
PRIMER BIMESTRE
22.4 Integracin de las mtricas dentro del procesos de software
Describe el enfoque para instituir un programa de de recopilacin de mtricas en una organizacin a partir de una lnea base de mtricas para la calidad. Defina un programa de mtricas para una organizacin, para esto fundamente con los puntos 22.5 y 22.6. Analice el programa de mtricas descrito en la Pg.: 685 y realice un anlisis comparativo con el que desarrollo en el punto anterior.
REQUIERO TUTORA?
No. 1. 2. 3. 4. 5. 6. 7. 8.
Cuestin Indique las determinantes para la calidad del software y la eficacia organizacional Qu lineamientos se deben aplicar cuando se recopilan mtricas del software? Cmo se emplean las mtricas durante un proyecto? Qu es una lnea base de mtricas y que beneficios proporciona? Indique cual es el proceso de recopilacin de mtricas de software Indique cual es la forma racional de mejorar un proceso. Por qu las mtricas del proyecto se utilizan con propsitos estratgicos? Indique cuales son las medidas de calidad
Malo
Medio
Muy bien

Ingrese peridicamente al campus virtual que se encuentra en la siguiente direccin: http://www.utplonline.edu.ec y de respuesta a las siguiente preguntas que se han previsto como parte del foro, su aporte es importante. Realice un anlisis entre las mtricas orientadas al tamao y a los puntos de funcin, establezca sus caractersticas principales contrapuntos
23
PRIMER BIMESTRE
Ejercicios
Para reforzar el nivel de conocimientos del presente captulo se deben realizar las siguientes actividades. Desarrollar los problemas de la pgina 687 del 22.1 al 22.9 y de la pgina 499 problema 15.15
DESCRIPCIN Este artculo presenta la estrategia de puntos de funcin como una mtrica estndar para establecer el tamao del software. Archivo disponible en UTPLONLINE
Puntos por funcin una mtrica estndar para establecer el ta...
Este artculo presenta las primeras etapas de la gestin de un proyecto informtico: la estimacin previa de los posibles costes en la construccin de software de aplicacin en la informtica de gestin.
Mtricas de productividad y modelos estimacin de costes
24
PRIMER BIMESTRE
Captulo 3
Estimacin para proyectos de Software
Datos Generales:
Texto base Captulo Pginas Pressman Roger S. Ingeniera del Software. Un enfoque prctico 6ta edicin. McGrawHill Interamericana Mxico. 2005. 23 Estimacin para proyectos de software 691 717 Horas de estudio empleadas para el desarrollo del contenido 8 horas
Propsito
Este captulo plantea la necesidad de utilizacin de metodologas tradicionales para la estimacin de proyectos software en donde se ha resuelto correctamente la necesidad de conocer la duracin de un proyecto como una variable dependiente de los recursos a emplear. Se propone la combinacin de las tcnicas de Puntos de Funcin y COCOMO (Constructive Cost Model) con la finalidad de obtener una estimacin dependiente de un conjunto de variables consideradas en un proyecto para establecer una estimacin ms precisa del mismo.
Conceptos Clave
Ambito Describe las funciones y caractersticas que se entregarn a los usuarios finales, los datos que son de entrada y salida, el contenido que se presenta a los usuarios como consecuencia de emplear el software, as como el desempeo, las restricciones, las interfaces y la confiabilidad que acotan el sistema. COCOMO (CONSTRUCTIVE COST MODEL) El mtodo COCOMO permite determinar los valores de las siguientes dos variables: Meses/hombre a aplicar al proyecto Meses totales del proyecto (dependiendo de factores tales como los atributos de fiabilidad requerida del software, tamao de la base de datos, complejidad del producto, limitaciones en el tiempo de ejecucin, limitaciones de memoria principal, volatilidad de la mquina virtual, frecuencia de cambio en el modelo de explotacin del ordenador, capacitacin de los analistas, experiencia en aplicaciones, capacitacin de los programadores, experiencia en la mquina virtual, experiencia en el lenguaje de programacin, prcticas modernas de programacin, uso de herramientas para el desarrollo del software y limitaciones en la planificacin). En la figura se presenta un esquema de estimacin que proporciona adems de las horas hombre a emplear el tiempo total del proyecto (basndose para ello en el conocimiento previo de la cantidad de sentencias de cdigo del proyecto) lo que permite determinar el plazo de entrega. Mostrndose, adems, como a partir de estos dos valores (horas hombre y tiempo total) y simplemente por el cociente de ambos se obtiene la cantidad de recursos (personas) para llevarlo a cabo. A partir de all se puede elaborar el costo mediante la aplicacin de ratios, de igual forma que en las metodologas tradicionales.
2
PRIMER BIMESTRE
Determinar lneas de cdigo
Estimar horas hombre
Estimar tiempo total
Establecer plazo de entrega
Determinar el personal involucrado
Estimar el costo
Complejidad
La construccin de software puede involucrar elementos de gran complejidad, que en muchos de los casos no son tan evidentes como los que se pueden ver en otras ingenieras. Un puente, un edificio, una mina, una red de ferrocarriles son ejemplos de sistemas complejos de otras ingenieras, pero el ingeniero de software construye sistemas cuya complejidad puede parecer que permanece oculta. El usuario siempre supone que en informtica todo es fcil (apretar un botn y ya est)
Estimacin basada en LCD

La medida ms utilizada para determinar el tamao de un proyecto informtico ha sido, durante mucho tiempo, la de las lneas de cdigo del software final obtenido. A menudo, en la literatura especializada se utilizan diversas denominaciones segn las interpretaciones de cada uno respecto de la definicin de stas. A continuacin presentamos algunas de stas: a. b. c. LDC: lneas de cdigo. Es la ms habitual y antigua. KLDC: miles de lneas de cdigo. Es la unidad de medida que adoptan la mayora de modelos clsicos de estimacin de costes en la calificacin de un proyecto informtico. DSI: instrucciones de cdigo fuente realmente entregadas, y su mltiplo KDSI, que surgieron para que se tuviera en cuenta que, en los nuevos entornos de desarrollo y construccin de software, buena parte de las lneas de cdigo no siempre las ha escrito el equipo del proyecto, sino que las han generado las herramientas de productividad del entorno de programacin. NCSS: lneas de cdigo fuente sin tener en cuenta los comentarios, y su mltiplo KNCSS, por el hecho de considerar que en un buen proceso de construccin los programas incluyen lneas de comentario o que una lnea de tratamiento se puede escribir en diferentes lneas de cdigo para aumentar la legibilidad y mejorar la mantenibilidad del software.
d.
2
PRIMER BIMESTRE
e.
NSLDC: nuevas lneas de cdigo fuente, tal como se realiza en el modelo COCOMO 2 para que se tenga en cuenta que slo deben contarse las lneas de cdigo nuevas sin contar las que incorpore automticamente el entorno de programacin, o, lo ms importante en este caso, el hecho de que parte del cdigo final puede proceder de la reutilizacin de rutinas u objetos ya disponibles que no se han de volver a escribir, pero que se incorporan al proyecto informtico en curso.
Las diferentes denominaciones de la medida de las lneas de cdigo Las diferentes denominaciones que existen cuando se habla de las lneas de cdigo recogen el hecho de que tenemos bastantes dificultades y dudas a la hora de medirlas. stos son algunos de los planteamientos que hacen difcil la valoracin: Debemos contar o no las lneas de comentario? Qu ocurre cuando una nica instruccin se escribe, por legibilidad, en dos o ms lneas de cdigo fuente? Se deben tener en cuenta las lneas que haya generado automticamente el entorno de programacin (gestor de formularios de pantalla, gestor de acceso a la base de datos, etc.)? Se deben tener en cuenta las lneas de cdigo de rutinas o los objetos reutilizados procedentes de otras aplicaciones? Es la medida basada en las lneas de cdigo indiferente al lenguaje de programacin utilizado? Qu pasa con las ratios de productividad establecidas cuando cambian los lenguajes de programacin utilizados?
Estimacin basada en PF Existen diferentes modelos de estimacin de las cargas de un proyecto informtico. La mayora utilizan como medida de las primitivas de salida las lneas de cdigo en cualquiera de las versiones posibles. Otra alternativa, cada da ms utilizada, es la medida de los puntos de funcin que defini Albrecht en un primer artculo del ao 1979 y que fue revisado (y relacionado tambin con la mtrica de las lneas de cdigo) en el ao 1983 por el mismo Albrecht, ayudado por Gaffney. El recuento de los puntos de funcin, deja algunos aspectos a la interpretacin de quien lleva a cabo la medida y ello ha generado diferentes artculos y trabajos que, manteniendo la idea central de Albrecht, intentan ayudar a adaptar el recuento de puntos de funcin a la realidad cambiando la informtica de gestin: bases de datos relacionales, nuevos lenguajes y entornos de programacin, nuevas herramientas de programacin visual, orientacin a objetos, etc. Desde el ao 1984, el denominado grupo internacional de usuarios de los puntos de funcin, IFPUG (de la denominacin inglesa International Function Points User Group) publica peridicamente la manera correcta de evaluar los diferentes aspectos discrecionales del recuento de puntos de funcin de Albrecht. La versin 3.0, fechada en el ao 1990, y la 4.0, que es de 1994, son las ms utilizadas hoy y la diversa literatura tcnica actual sobre puntos de funcin hace referencia a ellas a menudo. Actualmente, la mayora de especialistas estaran de acuerdo en afirmar que la mtrica de los puntos de funcin es la ms utilizada. El trabajo del IFPUG la pone en cierta manera al da, mientras que las mtricas basadas en las lneas de cdigo no siempre se han adaptado bien a los nuevos lenguajes de programacin o a las herramientas RAD.
2
PRIMER BIMESTRE
A pesar de todo, contina vivo el problema de que la mtrica fue pensada durante los aos setenta, cuando la informtica era bastante diferente de lo que es hoy en lenguajes, tipo de aplicaciones, importancia de las bases de datos, en el papel decisivo de las comunicaciones y de la distribucin de sistemas, etc. EL IFPUG ha decidido mantener inalterada la estructura de la mtrica, lo que no facilita su utilizacin actual. En concreto, el IFPUG recomienda, siguiendo las directrices que establece, construir procedimientos normalizados y uniformes en cada instalacin para proceder al recuento de los puntos de funcin siempre de una misma manera homognea. Estimacin basada en el proceso La tcnica ms comn para estimar un proyecto es basar la estimacin en el proceso que se emplear. Esto es, el proceso se descompone en un conjunto relativamente pequeo de tareas y se estima el esfuerzo para lograr cada tarea. Estimacin basada en casos de uso Los casos de uso permiten que un equipo de software comprenda el mbito del software y los requisitos. Sin embargo desarrollar un enfoque de estimacin con casos de uso es problemtico. Por esta razn antes que los casos de uso se emplean en la estimacin, se establece el nivel de estructura jerrquica, se determina la longitud promedio (en pginas) de cada caso de uso, se define el tipo de software (tiempo real, de negocios, de ingeniera, cientfico, anidado) y se considera una arquitectura comn del sistema. Planificacin del proyecto El objetivo de la planificacin del proyecto es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Adems, las estimaciones deben definir los escenarios de mejor y peor caso de modo que los resultados del proyecto se puedan acotar. Recursos La segunda tarea en la planificacin es la estimacin de los recursos necesarios para completar el esfuerzo de desarrollo del software. Las tres grandes categoras de los recursos en de ingeniera: personal, componentes de software reutilizables y el entorno de desarrollo (hardware y herramientas de software).
Esquema de estudio
2
PRIMER BIMESTRE
23.1 Observaciones acerca de la estimacin
Describe una panormica acerca del proceso de estimacin de proyectos de software. Revisar puntos 23.2, 23.3, y 23.4 interesa que se adquiera un conocimiento general del tema.
ACTIVIDADES RECOMENDADAS ANOTACIONES:
Realice un cuadro en donde se renan las principales caractersticas de los recursos utilizados para completar el esfuerzo de desarrollo de software
REQUIERO TUTORA?
TEMA A REVISAR
23.6 Tcnicas de descomposicin
La estimacin del proyecto de Software es una buena forma de resolver problemas, en la mayora de las cosas el problemas que debe resolverse es muy complejo para considerarlo en una solo pieza. Por esta razn se descompone el problema, recaracterizandolo como un conjunto de problemas ms pequeos. Revise los ejemplos de estimacin basada en LCD de la Pg. 701 Analice el ensayo HOGAR SEGURO de la pgina 702 comente acerca de los puntos tratados por los actores. Revise los ejemplos de estimacin basada en Puntos de Funcin de la Pg. 703 Revise la informacin proporcionada en la Pg. 709 Tcnicas de estimacin automatizada para proyectos de software
ANOTACIONES:
REQUIERO TUTORA?
23.7 Modelos empricos de estimacin Un modelo emprico de estimacin utiliza formulas para predecir el esfuerzo como una funcin de LDC o PF. Los datos empricos que apoyan la mayora de los modelos de estimacin proceden de una muestra lmitada de proyectos. Investigue acerca de la evolucin Constructuve Cost Model (COCOMO) Revisar los puntos 23.8, 23.9 y 23.10 interesa que se adquiera un conocimiento general de los temas planteados. Investigue las herramientas para la estimacin de esfuerzo y costo descritas en la Pg.: 716
REQUIERO TUTORA?
2
PRIMER BIMESTRE
23.9 Tcnicas de estimacin especializadas. Permiten realizar estimaciones para proyecto de duracin extremadamente corta, que probablemente tengan una continua corriente de cambios la planificacin del proyecto en general y la estimacin se debe abreviar. Revisar puntos 23.9.1 y 23.9.2 interesa que se adquiera un conocimiento general del tema. Recopile informacin de metodologas extremas XP AUP, que le permitan obtener un enfoque claro de cmo aplicar la estimacin
REQUIERO TUTORA?
No. 1. 2. 3. 4. 5.
Cuestin Cmo se mide el tamao del software que se desea construir? Cmo se calcula el valor esperado para el tamao de software? Por qu es difcil desarrollar una tcnica de estimacin con casos de uso? Qu es un punto objeto? Cmo se desarrollan las estimaciones cuando se aplica un proceso gil?
Malo
Medio
Muy bien

Ejercicios
Para reforzar el nivel de conocimientos del presente captulo se deben realizar las siguientes actividades. Desarrolle los problemas: 23.1 a 23.11
30
PRIMER BIMESTRE
DESCRIPCIN Este trabajo presenta la combinacin de las tcnicas de Puntos de Funcin y COCOMO para establecer una estimacin dependiente de un conjunto de variables consideradas en un proyecto para establecer una estimacin ms precisa del mismo. Archivo disponible en UTPLONLINE
Combinacin de alternativas para la estimacin de proyect...
Este documento suministra una estructura que permita al estudiante hacer estimaciones razonables de recursos, costes y agendas.
Apuntes de Ingeniera del Software (Parte I)
Este artculo presenta las primeras etapas de la gestin de un proyecto informtico: la estimacin previa de los posibles costes en la construccin de software de aplicacin en la informtica de gestin. Este documenta presenta como la construccin de software puede involucrar elementos de gran complejidad, que en muchos de los casos no son tan evidentes como los que se pueden ver en otras ingenieras.
Mtricas de productividad y modelos estimacin de costes
Complejidad del software
31
PRIMER BIMESTRE
Captulo 4
Calendarizacin del Proyectos de Software
Datos Generales:
Texto base Captulos Pginas Pressman Roger S. Ingeniera del Software. Un enfoque prctico 6ta edicin. McGrawHill Interamericana Mxico. 2005. 24 Calendarizacin de Proyectos de Software 724 746 Horas de estudio empleadas para el desarrollo del contenido 5 horas
Propsito
La calendarizacin de preoyectos de software tiene com finalidad el segmentar un proyecto en tareas individuales y estimar el tiempo y recursos requeridos para completarlas, adems de organizar las tareas concurrentemente para hacer uso de la fuerza de trabajo. La calendarizacin depende de la institucin y la experiencia de los administadores de proyectos.
Conceptos Clave
AVG Anlisis de Valor Ganado, proporciona una escala de valor comn para cualquier tarea (de proyecto de software), sin importar el tipo de trabajo que se realiza. Se estiman las horas totales para realizar todo el proyecto y a cada tarea se le da un valor ganado con base a su porcentaje estimado del total. Calendarizacin Implica crear una red de tareas de ingeniera de software que permitan tener el trabajo listo a tiempo. Esto es posible si se han definido previamente un modelo de procesos adecuado, se han definido las tareas de ingeniera de software a realizar, se ha estimado la cantidad de trabajo y el nmero de personas; se conoce la fecha lmite; se han considero riesgos. CPM (Critical Path Method) Mtodo de Ruta Crtica (Critical Path Method) mtodo de calendarizacin de proyectos que se puede aplicar al desarrollo de software. En administracin y gestin de proyectos, una ruta crtica es la secuencia de los elementos terminales de la red de proyectos con la mayor duracin entre ellos, determinando el tiempo ms corto para completar el proyecto. La duracin de la ruta crtica determina la duracin del proyecto entero. Cualquier retraso en un elemento de la ruta crtica afecta la fecha de trmino planeada del proyecto, y se dice que no hay holgura en la ruta crtica. Cronograma Consiste en una lista de todos los elementos terminales de un proyecto con sus fechas previstas de comienzo y final.
32
PRIMER BIMESTRE
Diagrama de GANTT Resuelve el problema de la programacin de actividades, es decir, su distribucin conforme a un calendario, de manera tal que se pudiese visualizar el periodo de duracin de cada actividad, sus fechas de iniciacin y terminacin e igualmente el tiempo total requerido para la ejecucin de un trabajo. El instrumento que desarroll permite tambin que se siga el curso de cada actividad, al proporcionar informacin del porcentaje ejecutado de cada una de ellas, as como el grado de adelanto o atraso con respecto al plazo previsto Hito Un hito es una tarea de duracin cero que simboliza el haber conseguido un logro importante en el proyecto. Los hitos son una forma de conocer el avance del proyecto sin estar familiarizado con el proyecto y constituyen un trabajo de duracin cero porque simbolizan un logro, un punto, un momento en el proyecto. PERT (Program Evaluation and Review Technique) Tcnica de revisin y evaluacin de programa, mtodo de calendarizacin de proyectos que se puede aplicar al desarrollo de software. Est orientado hacia la evaluacin del progreso del proyecto hacia sus objetivos, concentra la atencin sobre los problemas potenciales o reales del proyecto, proporciona a los responsables informes frecuentes y precisos del estado del mismo, predice la verosimilitud de alcanzar los objetivos y determina el menor espacio de tiempo en el que puede realizarse el proyecto.
Esquema de estudio
TEMA A REVISAR PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)
24.1 Conceptos bsicos La calendarizacin de proyectos de software es vital a la hora de planificar la ejecucin de un proyecto, en esta se deber incluir la estimacin de la cantidad de trabajo, esfuerzo, fechas lmite, etc., con la finalidad de entregar el producto en el tiempo establecido. Pero existen diversas circunstancias que impiden que el producto se entregue a tiempo; en este punto se identifican algunos de los motivos que originan retraso y las consideraciones que se deberan tener en cuenta para mitigarlos. Revisar el capitulo 23. Estimacin de Proyectos de Software, es la base de la calendarizacin. De acuerdo a experiencia propia o de algn grupo de desarrollo de software que usted conozca, recabe informacin de los principales problemas que causan retraso en la entrega de los proyectos y contrstelos con el planteado en el libro. De acuerdo a lo analizado en el punto anterior verifique si las recomendaciones planteadas en la pgina 726, son solucin a los problemas encontrados.
ANOTACIONES:
REQUIERO TUTORA?
33
PRIMER BIMESTRE
TEMA A REVISAR
24.2 Calendarizacin de proyectos
Describe las actividades que el gestor deber tomar en cuenta a la hora de definir las tareas del proyecto. Plantea los principios bsicos que guan a la calendarizacin y que se aplican de acuerdo al avance de la misma. Adems se analiza la relacin entre el personal y el esfuerzo, el esfuerzo aplicado y el tiempo de entrega para un proyecto de software utilizando la Curva Putman-Norden-Rayleigh. Defina en sus palabras las actividades que considera ms importantes a la hora definir las taras un proyecto. Tome las tareas de un proyecto de software en el que usted haya estado involucrado o el que ejecute un grupo de desarrollo de software que conozca y aplique la curva de PNR. Revisar el punto 23.7.3 - captulo 23, pgina 712 - La ecuacin del software.
REQUIERO TUTORA?
ANOTACIONES:
TEMA A REVISAR
24.3. Definicin de una red de tareas.
La definicin de un conjunto de tareas no es apropiada por si slo para un sistema complejo y grande que para un sistema pequeo y relativamente simple. La red de tareas debe satisfacer las necesidades de los diferentes tipos de proyectos que se abordan por parte de las organizaciones. Revisar el punto 24.4 Definicin de una red de tareas. Describa de acuerdo a su experiencia cuales deben ser las principales tareas que se deben planificar para un sistema grande y complejo y para un sistema pequeo y simple. Ver figura 24.3 como ejemplo.
REQUIERO TUTORA?
TEMA A REVISAR
24.5 Calendarizacin Describe las principales tcnicas de calendarizacin de un proyecto como PERT, y CPM que se aplican a un proyecto de software. Adems se analizan tcnicas para la construccin de cronogramas y la forma de hacer seguimiento a la calendarizacin a travs de la definicin de tareas e hitos que se deben seguir y controlar de acuerdo al avance del proyecto. Analizar las tcnicas PERT y CPM Realice un cronograma de acuerdo a las tareas planteadas en el punto anterior utilizando las herramientas analizadas, adems desarrolle una tabla de recursos como la que se plantea en la pgina 739.
REQUIERO TUTORA?
34
PRIMER BIMESTRE
24.6 Anlisis del valor Ganado.
Tcnica que permite realizar un anlisis cuantitativo de progreso de un proyecto de acuerdo a las tareas de calendarizacin definidas por el equipo de desarrollo. Desarrolle el ejercicio 24.12 de la pgina 745. Aplique esta tcnica a proyectos que usted manejo o que pueda tener acceso.
REQUIERO TUTORA?
No. 1. 2. 3. 4. 5. 6.
Cuestin Cul es el objetivo de la calendarizacin de proyectos? Cul es la funcin de un gestor de proyecto de software durante la calendarizacin? La calendarizacin para proyectos de ingeniera de software se puede ver desde dos perspectivas, ndique cuales con estas? Indique cuales son los principios de la calendarizacin. Qu es una red de tareas? Cul es el objetivo de realizar un anlisis cuantitativo de progreso?
Malo
Medio
Muy bien

Ejercicios
Para reforzar el nivel de conocimientos del presente captulo se deben realizar las siguientes actividades.
3
PRIMER BIMESTRE
Desarrolle los problemas: 24.1, 24.2, 24.3, 24.5, 24.12
DESCRIPCIN No disponible Archivo disponible en UTPLONLINE No disponible
3
SEGUNDO BIMESTRE
SEGUNDO BIMESTRE
Objetivos especficos
Conocer y palicar tcnicas que permitan dentificar, analizar y gestionar los riesgos de un proyecto de software. Conocer como se gestionan los cambios durante el desarrollo de software y durante la entrega del cliente. Conocer como se emplea la ingeniera del software basada en componentes para crear sistemas a partir de componentes reutilizables. Conocer que actividades tcnicas se requieren para la reingeniera del software.
Contenidos
CAPTULO 5 GESTIN DEL RIESGO DATOS GENERALES: PROPSITO CONCEPTOS CLAVE ESQUEMA DE ESTUDIO CUESTIONES DE REPASO INTERACTIVIDAD A TRAVS DE LOS FOROS DE CAMPUS VIRTUAL EJERCICIOS DOCUMENTACIN ADICIONAL
CAPTULO 6 GESTIN DEL CAMBIO DATOS GENERALES: PROPSITO CONCEPTOS CLAVE ESQUEMA DE ESTUDIO CUESTIONES DE REPASO INTERACTIVIDAD A TRAVS DE LOS FOROS DE CAMPUS VIRTUAL EJERCICIOS DOCUMENTACIN ADICIONAL
3
SEGUNDO BIMESTRE
CAPTULO 7 INGENIERA DE SOFTWARE BASADA EN COMPONENTES DATOS GENERALES: PROPSITO CONCEPTOS CLAVE ESQUEMA DE ESTUDIO CUESTIONES DE REPASO INTERACTIVIDAD A TRAVS DE LOS FOROS DE CAMPUS VIRTUAL EJERCICIOS DOCUMENTACIN ADICIONAL CAPTULO 8 REINGENIERA DATOS GENERALES: PROPSITO CONCEPTOS CLAVE ESQUEMA DE ESTUDIO CUESTIONES DE REPASO INTERACTIVIDAD A TRAVS DE LOS FOROS DE CAMPUS VIRTUAL EJERCICIOS DOCUMENTACIN ADICIONAL
3
SEGUNDO BIMESTRE
Desarrollo del aprendizaje

Captulo 5 Gestin del Riesgo
Datos Generales:
Texto base Captulos Pginas Pressman Roger S. Ingeniera del Software. Un enfoque prctico 6ta edicin. McGrawHill Interamericana Mxico. 2005. 25 Gestin de Riesgo 747 766 Horas de estudio empleadas para el desarrollo del contenido 5 horas
Propsito
Este captulo pretende dar una visin general de cmo afrontar a los riesgos de un proyecto de software, tomando en consideracin una serie de pasos que permitirn manejar la incertidumbre. La ocurrencia de un riesgo es incierta, pero debemos estar preparados para identificarlos, evaluar la probabilidad de que ocurra y establecer planes de mitigacin ante la presencia de estos. En este captulo se tratar de abordar tres preguntas bsicas planteadas por [Charette, 1989] en la gestin del riesgo qu riesgos causaran que el proyecto salga mal?, cmo afectarn la actualidad y el xito global, los cambios en los requisitos del cliente, las tecnologas de desarrollo, los entornos que se tienen como objetivo y todas las otras entidades vinculadas al proyecto?, qu mtodos herramientas se deben usar, cuantas personas deben estar involucradas, cuanto nfasis sobre la calidad es suficiente?
Conceptos Clave
Riesgos del proyecto Amenazan el plan del proyecto. Es decir, si los riesgos del proyecto se vuelven reales s probable que la calendarizacin del proyecto se altere y que los costo aumenten, Los riesgos del proyecto identifican potenciales problemas en presupuesto, calendarizacin, personal (plantillas y organizacin), recursos, participantes y requisitos, y su impacto sobre un proyecto de software. Riesgos tcnicos Amenazan la calidad, y actualidad del software que se producir. Si un riesgo tcnico se vuelve real, la implementacin se torna difcil o imposible. Los riesgos tcnicos identifican potenciales problemas en diseo, implementacin, interfaz, verificacin y mantenimiento. Adems son factores de riesgo la ambigedad de la especificacin, la incertidumbre tcnica, la obsolescencia tcnica y la tecnologa de punta. Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que en un principio se pens que sera. Riesgos del negocio Amenazan la viabilidad del software que se construir. Estos riesgos ponen con frecuencia en peligro el proyecto o el producto. Se pueden identificar cinco mayores riesgos 1) la construccin de un producto o sistema excelente que en realidad nadie quiere(riesgo de mercado), 2) la construccin de
3
SEGUNDO BIMESTRE
un producto que ya no encaja en la estrategia comercial global de la compaa (riesgo de estrategia), 3) la construccin de un producto que la fuerza de ventas no sabe cmo vender (riesgo de ventas), 4) la prdida del apoyo de los altos ejecutivos debido a un cambio en el enfoque o en el personal (riesgo administrativo), y 5) la prdida presupuestaria o del personal asignado (riesgo presupuestal) Riesgos conocidos Son aquellos susceptibles de descubrirse despus de una evaluacin cuidadosa del plan del proyecto, del entorno de negocios y tcnico dentro de los cuales se desarrollar el proyecto y otras fuentes de informacin confiables (fechas de entrega irreales, falta de requisitos documentados o de mbito del software, pobre entorno de desarrollo). Riesgos Predecibles Se extrapolan de la experiencia con proyectos previos (por ejemplo, cambios en el personal, mala comunicacin con el cliente, disminucin del esfuerzo del personal conforme se atienden las solicitudes de mantenimiento). Riesgos impredecibles Son aquellos que son extremadamente difciles de identificar con antelacin Proyeccin del riesgo Tambin llamada estimacin del riesgo, clasifica a cada riesgo de dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real, y 2) las consecuencias d los problemas asociados con el riesgo en caso de que ocurra. Prueba estadstica de uso La prueba estadstica de uso equivale a probar software en la forma que los usuarios intentaran usarlo. Esto se logra si los equipos de prueba de sala limpia determinan una distribucin de probabilidad de uso para el software. Plan RSGR (Plan de Reduccin, supervisin y gestin del riesgo) Documenta todo el trabajo realizado como parte dl anlisis del riesgo y el gestor del proyecto lo emplea como parte del plan global del proyecto. HIR (Hoja de informacin del riesgo) Permite documentar individualmente cada riesgo, en la mayora de los casos las HIR se mantiene empleando un sistema de base de datos Planificacin de la Gestin de Riesgos: Decidir cmo enfocar, planificar y ejecutar las actividades de gestin de riesgos para un proyecto. Identificacin de Riesgos Determinar qu riesgos pueden afectar al proyecto y documentar sus caractersticas. Anlisis Cualitativo de Riesgos: Priorizar los riesgos para realizar otros anlisis o acciones posteriores, evaluando y combinando su probabilidad de ocurrencia y su impacto.
40
SEGUNDO BIMESTRE
Anlisis Cuantitativo de Riesgos: Analizar numricamente el efecto de los riesgos identificados en los objetivos generales del proyecto. Planificacin de la Respuesta a los Riesgos: Desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Seguimiento y Control de Riesgos: Realizar el seguimiento de los riesgos identificados, supervisar los riesgos residuales, identificar nuevos riesgos, ejecutar planes de respuesta a los riesgos y evaluar su efectividad a lo largo del ciclo de vida del proyecto.
Esquema de estudio
25.2 Riesgos del software
Cuando se analizan los riesgos es importante cuantificar el grado de incertidumbre y el grado asociado con cada riesgo; en este punto se analizarn las diferentes categoras de riesgos que se pueden presentar en el desarrollo de un proyecto de software. Analice el punto 25.1 Estrategias de Riesgo Reactivas y Proactivas.
REQUIERO TUTORA?
TEMA A REVISAR
25.3 Identificacin de riesgos En esta seccin se analizarn los principales riesgos que se presentan en las categoras analizadas en la seccin 25.2. Adems se presenta un subconjunto de riesgos conocidos y predecibles con los cuales se realiza una lista de verificacin que permitir al planificador estimar el impacto del riesgo. En la seccin 25.3.1 se presenta un cuestionario de preguntas obtenidos de diversas entrevistas realizadas a gestores de proyectos en el mundo y que permiten realizar una evaluacin general a un proyecto. La seccin 25.3.2 describe algunas directrices para la identificacin y supresin del riesgo del software. Analizar 25.1 Evaluacin del Impacto pg. 753
REQUIERO TUTORA?
41
SEGUNDO BIMESTRE
TEMA A REVISAR
25.4 Proyeccin del Riesgo.
En esta seccin, en base a una clasificacin del riesgo, se establecen cuatro pasos en la proyeccin del mismo, que conducen al establecimiento de prioridades, y a partir de estas, asignar los recursos donde tengan el mayor impacto. En la seccin 25.4.1 se expone el desarrollo de una tabla de riesgos que ofrece al gestor del proyecto, una tcnica simple para la proyeccin del riesgo, apoyada por una lista de verificacin planteada en 25.3. Para finalizar en la seccin 25.4.2 se plantea la evaluacin del riesgo y se analizan las consecuencias probables si un riesgo ocurre a partir de su naturaleza, mbito y tiempo De acuerdo a su experiencia o a informacin relevante construya una tabla de riegos como la planteada en la pgina 754. Analice el ensayo HOGAR SEGURO de la pgina 813 comente acerca de los puntos tratados por los actores.
REQUIERO TUTORA?
25.5 Refinamiento del Riesgo
En esta seccin se analiza como un riesgo definido de manera muy general puede ser refinado en un conjunto de riesgos ms detallados en base al conocimiento que se adquiere del proyecto en un periodo de tiempo, para esto se utiliza el formato CTC (condicin -transicin - consecuencia). Analizar ejemplo propuesto en pagina 759 y plantearse algunos adicionales que permita mejorar en entendimiento de esta estrategia.
REQUIERO TUTORA?
TEMA A REVISAR
25.6 Reduccin, supervisin y gestin del riesgo. Esta seccin presenta una estrategia para luchar contra los riesgos, en esta se intenta reducir el riesgo evitando la movilidad del personal y para esto se consideran algunos pasos que involucra la creacin de equipos de proyecto, definicin de estndares de documentacin, revisin por pares y asignar personal de respaldo por cada tecnologa crtica; con esto, el siguiente paso ser la supervisin del riesgo, el gestor supervisa los factores que puedan proporcionar un indicio de si el riesgo se est volviendo probable. Por ltimo y los planes de contingencia suponen que los esfuerzos de reduccin del riesgo han fracasado y que el riesgo se ha vuelto una realidad. En la seccin 25.7 se habla del plan de RSGR en donde se realiza una explicacin general para su implementacin. Desarrolle una tabla de informacin del riesgo como la planteada en la pg. 762, tome como base la tabla constriuda en el punto 25.4.
REQUIERO TUTORA?
42
SEGUNDO BIMESTRE
No. 1. 2. 3. 4. 5. 6. 7. 8.
Cuestin Cules son las principales categoras de riesgos? Cules son las principales estrategias de riesgo? Cundo considerarnos a la gestin del riesgo como proactiva? Qu es un riesgo genrico? Indique cuales son los componentes de un riesgo? Indique como se clasifica al riesgo al momento de hacer su proyeccin? Describa cuales son los pasos a seguir en la proyeccin del riesgo? Cules son los factores a tomar en cuenta ante la ocurrencia de un riesgo?
Malo
Medio
Muy bien

Ejercicios
Para reforzar el nivel de conocimientos del presente captulo se deben realizar las siguientes actividades. Desarrolle los problemas: 25.1, 25.2, 25.4, 25.5, 25.6, 25.7, 25,8, 25.9, 25.11, 25.12
DESCRIPCIN Este artculo desarrollado por el Software Engineering Institute (SEI), presenta una visin holstica de las metodologas para la gestin de riesgos (Software Risk Management SRM) y que comprenden todo el ciclo de vida del software: analisis, diseo, desarrollo y mantenimiento. Archivo disponible en UTPLONLINE
Software Risk Management Project SEI.pdf
43
SEGUNDO BIMESTRE
Captulo 6
Gestin del Cambio
Datos Generales:
Texto base Captulos Pginas Pressman Roger S. Ingeniera del Software. Un enfoque prctico 6ta edicin. McGrawHill Interamericana Mxico. 2005. 27 Gestin del Cambio 797 825 Horas de estudio empleadas para el desarrollo del contenido 8 horas
Propsito
La gestin de configuracin del software es una actividad protectora que se aplica a lo largo del proceso de software. La gestin de configuracin del software permitir al estudiante identificar, controlar, auditar e informar modificaciones que invariablemente ocurren mientras se desarrolla software y despus de que se libera a un cliente.
Conceptos Clave
Auditorias La identificacin, el control de la versin y el control del cambio ayudan al desarrollador del software a mantener orden en lo que de otro modo sera una situacin catica e inestable Cambio El cambio es inevitable cuando se construye software de computadora. Y el cambio aumenta el grado de confusin entre los ingenieros de software que trabajan en un proyecto. La confusin se origina cuando los cambios no se analizan antes de implementarlos, no se reportan a quienes deben saberlo o no se controlan en una forma que mejorar la calidad y reducir el error. Control de la versin Combina procedimientos y herramientas para gestionar diferentes versiones de objetos de configuracin que se crean durante el proceso del software. Un sistema de control de la versin implementa o est directamente integrado en cuatro grandes capacidades: 1. 2. 3. Una base del proyecto (depsito) que guarda todos los objetos de configuracin relevantes. Una capacidad de gestin de la versin que almacena todas las versiones de un objeto de configuracin Una facilidad de hechura que permita al ingeniero de software recopilar todos los objetos de configuracin relevantes y construir una versin especifica de software.
44
SEGUNDO BIMESTRE
Control del cambio El control del cambio es vital. Nos preocupamos por los cambios porque una pequea perturbacin en el cdigo puede crear una gran falla en el producto. Pero tambin puede resolver una gran falla o permitir maravillosas nuevas capacidades. El control de cambios es una actividad de procedimiento que asegura la calidad y la consistencia conforme los cambios se realizan en un objeto de configuracin. El proceso de control de cambios comienza con una peticin de cambio, conduce a una decisin para aceptar o rechazarla y culmina con una actualizacin controlada del ECS que se cambiar. Depsito Es un conjunto de mecanismos y estructuras de datos que permite que un equipo de software maneje el cambio de una forma eficaz. Proporciona las funciones obvias de un sistema de gestin de base de datos pero, adems el depsito realiza o impulsa las siguientes funciones: ECS Un elemento de configuracin del software (ECS) es informacin que se crea como parte del proceso de ingeniera de software. Se puede considerar que un ECS es una sola seccin de una gran especificacin o un caso de prueba de un gran conjunto de pruebas. Un ECS es un documento, un conjunto completo de casos de prueba o un componente de un programa dado (por ejemplo: una funcin C++ o un applet de Java) Gestin del contenido Se relaciona con la gestin de la configuracin en el sentido en que un sistema de gestin de contenido (SGC) establece un proceso (apoyado por herramientas) que adquiere contenido existente (de un amplio ordenamiento de objetos de configuracin de la Webapp), los estructura en una forma que permite presentarlos a un usuario final y luego los ofrece al entorno del lado del cliente para su despliegue. Identificacin El control y la gestin de elementos de configuracin del software requiere nombrar cada uno por separado y luego organizarlo mediante un enfoque orientado a objetos. El esquema de identificacin para los objetos de configuracin debe reconocer que los objetos evolucionan a lo largo del proceso de software. La integridad de datos Compartir informacin La integracin de herramientas La integracin de los datos El fortalecimiento de la metodologa Estandarizacin de los documentos.
4
SEGUNDO BIMESTRE
Informe de estado El informe de estado de la configuracin (a veces llamado contabilidad de estado) es una tarea de GCS que responde a las siguientes preguntas: 1) qu ocurri? 2) quin lo hizo? 3) cundo ocurri? 4) qu otra cosa ser afectada? Lneas base Una especificacin o producto que se ha revisado formalmente y se est de acuerdo con los resultados, y que a partir de ah se sirve como la base para el desarrollo ulterior y que puede cambiarse slo por medio de procedimientos formales de control de cambio. En el contexto de la ingeniera del software, una lnea base es un hito en el desarrollo del software. Se marca un alinea base para la entrega de uno o ms elementos de configuracin del software (ECS) que se han aprobado como consecuencia de una revisin tcnica formal. Por ejemplo, los elementos de un modelo de diseo se han documentado y revisado. Se han encontrado errores y se han corregido. Una vez que todas las partes del modelo se han revisado, corregido y luego aprobado, el modelo de diseo se convierte en una lnea base.
Esquema de estudio
TEMA A REVISAR DESCRIPCIN DEL CONTENIDO A REVISAR PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)
27.1Gestin de la configuracin del software. Describe un conjunto de actividades que se han desarrollado para gestionar el cambio a lo largo del ciclo de vida del software, Defina un escenario particular para la Gestin de la Configuracin del software, identificando cada uno de los involucrados, luego compare su trabajo con el especificado en el libro para esto revise el punto 27.1.1 Describa las actividades que tienen que cumplir cada uno de los elementos de las GCS Identifique las principales actividades que involucra el levantamiento de una lnea base para GCS, para esto tome como referencia el punto 27.1.3 y la figura 27.1
ANOTACIONES:
REQUIERO TUTORA?
4
SEGUNDO BIMESTRE
27.2 El depsito de la ECS
Proporciona una descripcin de la manera cuantitativa de evaluar la calidad de los atributos internos de un producto. Determine cul es el principal beneficio de un depsito de ECS. Fundamente este tema con la lectura de los puntos 27.2.2 y 27.2.3 Analice el sistema de versiones concurrentes (SVC) descrito en la Pg.: 809.
REQUIERO TUTORA?
TEMA A REVISAR
27.3 El proceso de la GCS
Define una serie de tareas que permiten: identificar los elementos que definen la configuracin del software, gestionan los cambios a uno o ms de dichos elementos, facilitan la construccin de diferentes versiones de una misma aplicacin y garantizan que la calidad del software se conserve conforme la configuracin evoluciona a lo largo del tiempo Realice un anlisis de cada una de las cinco tareas de la gestin de configuracin del software. Analice el ensayo HOGAR SEGURO de la pgina 813 comente acerca de los puntos tratados por los actores. Investigue las herramientas de soporte a la Gestin de Configuracin de Software descritas en la Pg.: 815.
REQUIERO TUTORA?
ANOTACIONES:
TEMA A REVISAR
27.4 Gestin de la configuracin para ingeniara Web La gestin de la configuracin para la ingeniera Web es similar en muchos aspectos a la GCS para el software convencional, sin embargo, cada una de las tareas principales de la GCS se deben destacar para hacerla tan simples como sea posible, y se deben aplicar provisiones especiales para la gestin del contenido. Realice un anlisis de los temas que se deben tratar en la gestin de configuracin de la WebApp. Pg. 816 Detalle el funcionamiento de la funcin de la gestin del contenido para WebApp. Investigue las herramientas de gestin del contenido descritas en la Pg.: 819 - 820. Detalle el funcionamiento de la funcin de la gestin del cambio para WebApp. Investigue las herramientas de gestin del cambio descritas en la Pg.: 822. Detalle el funcionamiento de la funcin de la gestin del cambio para WebApp. Detalle el funcionamiento del control de la versin para WebApp. Investigue acerca de cada uno de los estndares de GCS descritos en la Pg.: 824.
ANOTACIONES:
REQUIERO TUTORA?
4
SEGUNDO BIMESTRE
No. 1. 2. 3. 4. 5. 6. 7.
Cuestin Cul es el origen de los cambios que se requieren para el software? Cules son las metas de las actividades realizadas por cada uno de los participantes involucrados en la gestin del cambio? Qu funciones implementa un depsito de ECS? Cules la finalidad de una auditoria de configuracin? Qu impacto tiene un cambio descontrolado sobre una WebApp? Cul es la relacin entre la gestin de contenido y la GC de la WebApp.? Cules son los elementos de un sistema de la gestin de la configuracin?
Malo
Medio
Muy bien

Ejercicios
Para reforzar el nivel de conocimientos del presente captulo se deben realizar las siguientes actividades. Desarrolle los problemas: 27.1, 27.2, 27.3, 27.4, 27.7 a 27.8, 27.12
4
SEGUNDO BIMESTRE
DESCRIPCIN Este documento describe los elementos que componen toda la informacin producida como parte del proceso de ingeniera del software se denominan colectivamente configuracin del software.. Este documente describe como la gestin de la configuracin permite mantener la integridad de los productos que se obtienen a lo largo del desarrollo de los sistemas de informacin, garantizando que no se realizan cambios incontrolados y que todos los participantes en el desarrollo del sistema disponen de la versin adecuada de los productos que manejan. Este documento es una presentacin que presenta el proceso de la gestin de configuracin del software. Archivo disponible en UTPLONLINE
Gestin de la configuracin del Software - 1
gestin de la configuracin del Software - 2
Gestin de la configuracin - proceso
4
SEGUNDO BIMESTRE
Captulo 7
Ingeniera de Software basada en componente
Datos Generales:
Texto base Captulos Pginas Pressman Roger S. Ingeniera del Software. Un enfoque prctico 6ta edicin. McGrawHill Interamericana Mxico. 2005. 30 Ingeniera de Software Basada en Componentes 879 899 Horas de estudio empleadas para el desarrollo del contenido 8 horas
Propsito
Este captulo presenta los modelos, conceptos y mecanismos fundamentales sobre los que se apoya actualmente el desarrollo de aplicaciones de software basado en componentes reutilizables. En primer lugar, las arquitecturas software y los marcos de trabajo intentan ofrecer soluciones de diseo desde el punto de vista estructural de las aplicaciones, y de las relaciones entre sus componentes. A otro nivel se encuentra la programacin orientada a componentes, un paradigma que propugna la construccin de componentes reutilizables en entornos abiertos y distribuidos, con el objetivo de lograr un mercado global de software.
Conceptos Clave
Adaptacin En un contexto ideal, la ingeniera del dominio creara una biblioteca de componentes que podran integrarse fcilmente a una arquitectura de aplicacin. Calificacin Garantiza que el componente candidato realiza la funcin requerida, encajar adecuadamente en el estilo arquitectnico que especifica el sistema y mostrar las caractersticas de calidad (por ejemplo: desempeo, fiabilidad, facilidad de uso) que requiere la aplicacin. Componentes Las propiedades caractersticas de un componente son: Es una unidad de implementacin independiente. Es una unidad compuesta por terceras partes. No cuenta con un estado observable desde el exterior.
Un componente encapsula las caractersticas que lo constituyen. Un componente nuca deber ser desarrollado parcialmente. En este contexto una tercera parte no debe esperar tener acceso a los detalles de construccin de todo lo que involucra a los componentes. Para que un componente pueda funcionar con otros componentes de terceras partes, ste necesita ser suficientemente independiente, y tener sus especificaciones de que es lo que requiere y que es lo que provee, lo suficientemente detalladas. En otras palabras, un componente necesita encapsular su implementacin e interactuar con su ambiente a travs de interfaces bien definidas.
0
SEGUNDO BIMESTRE
Finalmente un componente no debe tener ningn posible estado observable desde el exterior. Esto quiere decir que se requiere que el componente no pueda ser distinguido de copias de s mismo. Una posible excepcin a esta regla son los atributos que no inciden en el funcionamiento del componente, como lo es el nmero de serie del componente. Debido a la naturaleza de los componentes en ningn proceso deber haber a lo ms una sola copia de un componente en particular. Por lo tanto no es significativo hablar acerca de un nmero de copias disponibles de un componente. Los componentes son unidades de peso pesado con exactamente una instancia en el sistema. Algunas definiciones ms sobre componentes y que ayudaran a dar una visin ms amplia son las siguientes: Para Booch, un componente reutilizable de software es un mdulo lgicamente cohesivo y con poco acoplamiento que denota una sola abstraccin. Los componentes de software reutilizables son elementos auto contenidos, claramente identificables que describen y/o realizan funciones especficas, tienen interfaces claras, documentacin apropiada y un propsito de rehso bien definido. Los componentes de software son bloques reutilizables de construccin de sistemas de software. Encapsulan aplicaciones o servicios tcnicos con sentido semntico. Difieren de otros tipos de mdulos reutilizables en que pueden modificarse, al tiempo de diseo, en sus ejecutables binarios, mientras los dems lo hacen en su nivel de programa fuente. Los componentes restringen acceso va una o ms interfaces pblicas que definen propiedades, mtodos y eventos que permiten comunicacin. Las propiedades y mtodos representan una API tpica. Los componentes existen y operan en contenedores que les brindan contexto compartido para interactuar con otros componentes y acceso a servicios del sistema. DBC El desarrollo basado en componentes (DBC) es una actividad de ISBC que ocurre en paralelo con la ingeniera del dominio. Al aplicar los mtodos del diseo del anlisis y arquitectnico el equipo de software refina un estilo arquitectnico para el modelo de anlisis creado para la aplicacin que se construir. Una vez que la arquitectura se ha establecido, deben agregarse componentes que 1) estn disponibles en bibliotecas de reutilizacin, 2) sean diseadas para satisfacer las necesidades personales del cliente. Entorno de reutilizacin La reutilizacin de componentes de software debe apoyarla un entorno que incluya los siguientes formatos: Una base de datos de componentes capaz de almacenar componentes de software, as como la informacin de clasificacin necesaria para recuperarlos. Un sistema de gestin de bibliotecas que ofrezca acceso a la base de datos. Un sistema de recuperacin de componentes de software que permita que una aplicacin cliente recupere componentes y servicios del servidor de la biblioteca. Herramientas de ISBC que apoyen la integracin de los componentes reutilizados en un nuevo diseo o implementacin.
1
SEGUNDO BIMESTRE
Ingeniera del dominio Permite identificar, construir, catalogar y diseminar un conjunto de de componentes de software que sean aplicables para el software existente y futuro en un dominio de aplicacin particular. La ingeniera del dominio trata de encontrar los aspectos comunes entre los sistemas para identificar los componentes que sea posible aplicar en muchos sistemas, y para identificar familias de programas que se posicionen para sacar la mayor ventaja de dichos componentes. ISBC La ingeniera de software basada en componentes (ISBC), es un proceso que concede particular importancia al diseo y la construccin de sistemas basados en computadoras que utilizan componentes de software reutilizables Una afirmacin que puede ser establecida con certeza es la siguiente: los componentes son para composicin. La composicin habilita cosas prefabricadas para ser rehusadas posteriormente en nuevas composiciones cualesquiera. Ms all de esta observacin trivial, hay muchas cosas que no estn claras. Para convertir un elemento en reusable, no es suficiente iniciar con un diseo monoltico de una solucin completa y entonces particionarla en fragmentos. Las descripciones de los componentes deben estar generalizadas cuidadosamente para permitir la reusabilidad en un nmero suficiente de diferentes contextos. Una sobre generalizacin tiene que ser evitada para mantener las descripciones suficientemente ligeras con el fin de rehusarlas y que permanezcan tiles. Los componentes de software son unidades ejecutables de produccin independiente, adquisicin e implementacin que pueden formar parte de un sistema funcional. Para permitir la composicin, un componente de software se adhiere a un modelo de componentes particular y apunta a una plataforma de componentes particular. Los sistemas compuestos integrados por componentes de software conforman el software de componentes. El requerimiento de la independencia y la forma ejecutable elimina muchas abstracciones del software; tales como declaraciones de tipo, macros de C, plantillas de C++, o bloques de Smalltalk. Otras abstracciones, como procedimientos, clases, mdulos, o an aplicaciones enteras, pueden formar componentes, mientras estn en una forma ejecutable que siga siendo integrable. El motivo por el cual producir, distribuir, comprar y usar componentes de software, es porque los componentes son el camino a seguir, debido a que todas las dems disciplinas de ingeniera han introducido componentes desde que han llegado a ser maduras. Ejemplo del diseo de un componente .NET A continuacin se describir los distintos tipos de componentes que se pueden encontrar en una aplicacin o servicio distribuido .NET, se muestra un ejemplo de una aplicacin comercial: El anlisis de la mayora de las soluciones empresariales basadas en modelos de componentes por capas muestra que existen varios tipos de componentes habituales. En la siguiente figura se muestran los tipos de componentes para el ejemplo de una aplicacin comercial.
2
SEGUNDO BIMESTRE
Componentes identificados en el ejemplo

Componentes de interfaz de usuario (IU). La mayor parte de las soluciones necesitan ofrecer al usuario un modo de interactuar con la aplicacin. En el ejemplo de aplicacin comercial, un sitio Web permite al cliente ver productos y realizar pedidos, y una aplicacin basada en el entorno operativo Microsoft Windows permite a los representantes de ventas escribir los datos de los pedidos de los clientes que han telefoneado a la empresa. Las interfaces de usuario se implementan utilizando formularios de Windows Forms, pginas Microsoft ASP.NET, controles u otro tipo de tecnologa que permita procesar y dar formato a los datos de los usuarios, as como adquirir y validar los datos entrantes procedentes de stos. Componentes de proceso de usuario. En un gran nmero de casos, la interaccin del usuario con el sistema se realiza de acuerdo a un proceso predecible. Por ejemplo, en la aplicacin comercial, podramos implementar un procedimiento que permita ver los datos del producto. De este modo, el usuario puede seleccionar una categora de una lista de categoras de productos disponibles y, a continuacin, elegir uno de los productos de la categora seleccionada para ver los detalles correspondientes. Para facilitar la sincronizacin y organizacin de las interacciones con el usuario, resulta til utilizar componentes de proceso de usuario individuales. De este modo, el flujo del proceso y la lgica de administracin de estado no se incluyen en el cdigo de los elementos de la interfaz de usuario, por lo que varias interfaces podrn utilizar el mismo motor de interaccin bsica. Componentes de flujos de trabajo empresariales Una vez que el proceso de usuario ha recopilado los datos necesarios, stos se pueden utilizar para realizar un proceso empresarial. Por ejemplo, tras enviar los detalles del producto, el pago y el envo a la aplicacin comercial, puede comenzar el proceso de cobro del pago y preparacin del envo. Gran parte de los procesos empresariales conllevan la realizacin de varios pasos, los cuales se deben organizar y llevar a cabo en un orden determinado. Por ejemplo, el sistema empresarial necesita calcular el valor total del pedido, validar la informacin de la tarjeta de crdito, procesar el pago de la misma y preparar el envo del producto.
3
SEGUNDO BIMESTRE
Componentes empresariales Independientemente de si el proceso empresarial consta de un nico paso o de un flujo de trabajo organizado, la aplicacin requerir probablemente el uso de componentes que implementen reglas empresariales y realicen tareas empresariales. Por ejemplo, en la aplicacin comercial, deber implementar una funcionalidad que calcule el precio total del pedido y agregue el costo adicional correspondiente por el envo del mismo. Los componentes empresariales implementan la lgica empresarial de la aplicacin. Agentes de servicios Cuando un componente empresarial requiere el uso de la funcionalidad proporcionada por un servicio externo, tal vez sea necesario hacer uso de cdigo para administrar la semntica de la comunicacin con dicho servicio. Por ejemplo, los componentes empresariales de la aplicacin comercial descrita anteriormente podran utilizar un agente de servicios para administrar la comunicacin con el servicio de autorizacin de tarjetas de crdito y utilizar un segundo agente de servicios para controlar las conversaciones con el servicio de mensajera. Los agentes de servicios permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicacin y pueden proporcionar servicios adicionales, como la asignacin bsica del formato de los datos que expone el servicio al formato que requiere la aplicacin. Interfaces de servicios Para exponer la lgica empresarial como un servicio, es necesario crear interfaces de servicios que admitan los contratos de comunicacin (comunicacin basada en mensajes, formatos, protocolos, seguridad y excepciones, entre otros) que requieren los clientes. Por ejemplo, el servicio de autorizacin de tarjetas de crdito debe exponer una interfaz de servicios que describa la funcionalidad que ofrece el servicio, as como la semntica de comunicacin requerida para llamar al mismo. Las interfaces de servicios tambin se denominan fachadas empresariales. Componentes lgicos de acceso a datos La mayora de las aplicaciones y servicios necesitan obtener acceso a un almacn de datos en un momento determinado del proceso empresarial. Por ejemplo, la aplicacin empresarial necesita recuperar los datos de los productos de una base de datos para mostrar al usuario los detalles de los mismos, as como insertar dicha informacin en la base de datos cuando un usuario realiza un pedido. Por tanto, es razonable abstraer la lgica necesaria para obtener acceso a los datos en una capa independiente de componentes lgicos de acceso a datos, ya que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuracin y el mantenimiento de la misma. Componentes de entidad empresarial La mayora de las aplicaciones requieren el paso de datos entre distintos componentes. Por ejemplo, en la aplicacin comercial es necesario pasar una lista de productos de los componentes lgicos de acceso a datos a los componentes de la interfaz de usuario para que ste pueda visualizar dicha lista. Los datos se utilizan para representar entidades empresariales del mundo real, como productos o pedidos. Las entidades empresariales que se utilizan de forma interna en la aplicacin suelen ser estructuras de datos, como conjuntos de datos, DataReader o secuencias de lenguaje de marcado extensible (XML), aunque tambin se pueden implementar utilizando clases orientadas a objetos personalizadas que representan entidades del mundo real necesarias para la aplicacin, como productos o pedidos.
4
SEGUNDO BIMESTRE
Componentes de seguridad, administracin operativa y comunicacin. La aplicacin probablemente utilice tambin componentes para realizar la administracin de excepciones, autorizar a los usuarios a que realicen tareas determinadas y comunicarse con otros servicios y aplicaciones. Proceso Se caracteriza de tal forma que no slo identifica los componentes candidatos sino que tambin cualifica la interfaz de cada componente, adapta los componentes para eliminar las equivocaciones arquitectnicas, ensambla los componentes en un estilo arquitectnico seleccionado y actualiza los componentes conforme los requisitos cambian. Puntos de estructura Es una abstraccin que debe tener un nmero limitado de instancias. Adems la abstraccin debe recurrir a travs de las aplicaciones en el dominio. De otro modo no se justifica el costo de verificar, documentar y diseminar el punto de estructura.
Esquema de estudio
TEMA A REVISAR
30.1 Ingeniera componentes
de
Sistemas
basada
en
Ingeniera de software basada en componentes ofrece beneficios inherentes a la calidad del software, la productividad del desarrollador y el costo global del sistema. En la actualidad los sistemas de alta calidad basados en computadoras se deben construir en un tiempo muy corto y demanda un enfoque ms organizado de reutilizacin. Cul es la concepcin que usted tiene de la ingeniera de software basada en componentes. Indique si es posible construir sistemas complejos mediante el ensamblado de componentes de software reutilizables provenientes de un catlogo, realice un anlisis.
REQUIERO TUTORA?

SEGUNDO BIMESTRE
30.2 El proceso ISBC
El proceso de ISBC caracteriza de tal forma que no slo identifica los componentes candidatos sino que tambin cualifica la interfaz de cada componente. Destaca dos procesos concurrentes: la ingeniera del dominio y el desarrollo basado en componentes En base a la figura 30.1 analice el proceso de ISBC. Fundamente el proceso de la ISBC con la lectura de los puntos 30.3 y 30.4 Destaque en una tabla las principales caractersticas de la ingeniera del dominio y el desarrollo basado en componentes Analice la informacin presentada en la Pg.: 890 en donde se describe la Arquitectura comn e distribucin de objetos. Obtenga un resumen con ideas principales.
ANOTACIONES:
REQUIERO TUTORA?
TEMA A REVISAR
30.5 Clasificacin y recuperacin de componentes
Los esquemas de clasificacin permiten que un desarrollador encuentre y recupere componentes reutilizables y se ajuste a un modelo que identifica concepto, contenido y contexto. La clasificacin enumerada, la clasificacin por facetas y la clasificacin de valores y atributos son representativas de muchos esquemas de clasificacin de componentes Conceptualice un esquema de clasificacin de componentes de acuerdo a su experiencia en desarrollo, una vez que lo haya realizado contraste su trabajo con el planteado en la Pg.: 893 Describa un entorno para la reutilizacin de componentes y constaste su trabajo con la informacin descrita en la Pg.:894 Investigue las herramientas de software para el desarrollo basado en componentes descritas en la Pg.: 895.
ANOTACIONES:
REQUIERO TUTORA?
TEMA A REVISAR
30.6 Economa de la ISBC La economa de la reutilizacin se aborda con una sola pregunta es efectivo en costo el construir menos y reutilizar ms? En general la respuesta es s, pero un planificador de software debe considerar los costos importantes asociados con la calificacin, adaptacin e integracin de los componentes reutilizables Emita un criterio personal sobre el impacto de la calidad, la productividad y el costo en un ambiente de reutilizacin. Defina un punto de estructura adicional al planteado el libro para el anlisis de costos
REQUIERO TUTORA?

SEGUNDO BIMESTRE
No. 1. 2. 3. 4. 5. 6. 7. 8.
Cuestin Cules son los pasos del proceso de anlisis de dominio? Qu es un punto de estructura y cules son sus caractersticas? Qu factores se consideran durante la calificacin de componentes? Qu ingredientes se necesitan para lograr la composicin de componentes? Indique cuales son las principales herramientas en las que se basa la ingeniera basada en componentes Cul es la finalidad de la ingeniera del dominio? Cul es el fundamento del modelado estructural? Cules son las caractersticas de un componente?
Malo
Medio
Muy bien

Ejercicios
Para reforzar el nivel de conocimientos del presente captulo se deben realizar las siguientes actividades. Desarrolle los problemas: 30.1, 30.2, 30.3, 30.4, 30.5, 30.6, 30.7, 30.8

SEGUNDO BIMESTRE
DESCRIPCIN Este documento presenta los modelos, conceptos y mecanismos fundamentales sobre los que se apoya actualmente el desarrollo de aplicaciones de software basado en componentes reutilizables. Archivo disponible en UTPLONLINE
Desarrollo de software basado en componente
En este artculo se discuten precisamente los aspectos de calidad relativos a los componentes software y a las aplicaciones que con ellos se construyen, con especial nfasis en los estndares internacionales que los definen y regulan, y en los problemas que se plantean en este Calidad desarrollo de software basado en componentes tipo de entornos. Este artculo presenta el trabajo destinado a la obtencin de un sistema de componentes de software en el dominio del CSCL(Computer Supporte Collaborative Learning Aprendizaje colaborativo apoyado Sistema de componentes de software por ordenador) Este artculo presenta el trabajo desarrollado por los autores para habilitar el uso de las infraestructuras de computacin grid como soporte de aplicaciones de Aprendizaje Colaborativo Apoyado por Ordenador (Computer Supported Collaborative Learning, CSCL) desarrolladas de Computacin Girl e Ingeniera del acuerdo con los principios de la Ingeniera del Software Basada en Software basada en co... Componentes (ISBC)

SEGUNDO BIMESTRE
Captulo 8
Reingeniera
Datos Generales:
Texto base Captulos Pginas Pressman Roger S. Ingeniera del Software. Un enfoque prctico 6ta edicin. McGrawHill Interamericana Mxico. 2005. 29 Reingeniera 902 924 Horas de estudio empleadas para el desarrollo del contenido 8 horas
Propsito
El propsito de este captulo es el de desarrollar en el estudiante habilidades para comprender los modelos de negocio con el propsito de efectuar cambios para mejorar la competitividad en alguna rea del negocio. Examinar sistemas y aplicaciones de informacin con la finalidad de reestructurarlos o reconstruirlos de manera que presenten mayor calidad y se adapten a los nuevos cambios tecnolgicos.
Conceptos Clave
Anlisis de inventarios Las organizaciones de software deberan tener un inventario de todas sus aplicaciones. Al ordenar esta informacin de acuerdo con la importancia para el negocio, antigedad, facilidad actual para el mantenimiento y otros criterios localmente importantes, aparecen los candidatos para reingeniera. Entonces se pueden asignar los recursos a las aplicaciones candidatas para el trabajo de reingeniera. Economa La reingeniera demanda de recursos que pueden utilizarse para otros propsitos del negocio. En consecuencia, antes de que una organizacin intente someter a reingeniera una aplicacin existente, debe realizar un anlisis costo beneficio. Procesos de negocio Conjunto de tareas lgicamente relacionadas que se ejecutan para lograr resultados de negocios especifico. Dentro del proceso de negocio, la gente, el equipo, los recursos materiales y los procedimientos del negocio, se combinan para producir un resultado especfico. Ingeniera directa Reconstruye un programa empleando modernas prcticas de ingeniera de software y la informacin aprendida en la ingeniera inversa. A partir de los productos de ingeniera inversa se construye el programa mediante tcnicas de ingeniera directa. Re especificacin: Se re especifican las especificaciones recuperadas del sistema heredado para incluir los nuevos requisito, modificar las funcionalidades existentes o aadir nuevas.

SEGUNDO BIMESTRE
Rediseo: Se refinan los modelos creados en el paso anterior, definiendo la arquitectura que tendr el sistema, obteniendo un nuevo diseo. En este paso, hay que tener ya en cuenta los requisitos no funcionales (como el lenguaje de implementacin, plataforma de explotacin, etc.). Una vez que tanto los requisitos funcionales como los no funcionales se han tratado, se puede comenzar la generacin de cdigo Re implementacin: La generacin de cdigo puede ser llevada a cabo mediante herramientas CASE de manera automtica, partiendo de los modelos desarrollados del sistema heredado. Puesta en marcha.
Ingeniera inversa Puede obtener informacin de diseo a partir de cdigo fuente, pero el grado de abstraccin, la completitud de la documentacin, el grado en que las herramientas y un analista humano trabajen en conjunto, y la direccionalidad de proceso son enormemente variables. El proceso de ingeniera inversa debe ser capaz de derivar representaciones de diseo de procedimiento (un grado de abstraccin bajo), informacin de estructura de programa y datos (un grado de abstraccin ms elevado), modelos de objeto, modelos de flujo de datos o de control (un grado de abstraccin relativamente alto) y clases UML, diagramas de estado y despliegue (un grado alto de abstraccin) Muchos sistemas tienen el cdigo fuente como la nica representacin fiable. Esto es ms comn en sistemas muy antiguos que han tenido muchos cambios durante su ciclo de vida. Estos sistemas tienen un crecimiento substancial desde su inicio, y generalmente no han tenido actualizaciones de su documentacin. Aqu es donde la ingeniera inversa es la tcnica recomendada para re documentar el sistema. El primer documento que se necesita para navegar fcilmente en el sistema y encontrar la localizacin de un problema a nivel de anlisis del Mantenimiento del Sistema es el esquema del programa. Los pasos a seguir para realizar la ingeniera inversa son: a. b. c. d. e. f. Diseccin del cdigo fuente en unidades formales. Descripcin semntica de las unidades formales y declaracin de unidades funcionales. Creacin de esquemas de entrada/salida de unidades. Declaracin y descripcin semntica de circuitos lineales. Declaracin y descripcin semntica de aplicaciones del sistema. Creacin de la anatoma del sistema.
Mantenimiento de software La distincin entre las actividades asociadas con el desarrollo y aquellas asociadas con el mantenimiento, estn basadas en la visibilidad de los problemas del sistema y la forma de transmitrselo a los usuarios, grupo de pruebas y desarrolladores. Antes del desarrollo, la visibilidad de los problemas del sistema para los usuarios y el grupo de pruebas podra ser relativamente baja, ya que la reparacin de algunos problemas puede ser manejada de una manera informal por el grupo de desarrollo. Sin embargo, una vez que el sistema ha sido liberado, es necesario un proceso de seguimiento ms formal. Esta
0
SEGUNDO BIMESTRE
formalidad es necesaria debido a que muchos grupos dentro de la organizacin influyen en la informacin transmitida de los problemas del sistema. Por ejemplo, el personal de soporte al usuario necesita saber sobre los problemas para que a su vez puedan describrselos a los usuarios. El grupo de pruebas necesita saber sobre los problemas ya que pueden ser requeridos rpidamente para generar un plan de pruebas enfocado sobre las reas problemticas. Tambin los gerentes necesitan conocerlos para poder priorizar el trabajo que se est haciendo. Una simple definicin de mantenimiento es: el proceso de registro y seguimiento de problemas y la peticin y gestin de respuestas. Un problema no necesariamente implica un defecto del software. Los problemas aparecen simplemente porque el comportamiento esperado del sistema no coincide con el comportamiento actual. Esto puede ser el resultado de un defecto del software, pero puede ser fcilmente el resultado de un desconocimiento de las capacidades del sistema, o de la utilizacin incorrecta del flujo de trabajo, o de una documentacin pobre, o de cambios en las directrices de la empresa, o de otras tantas razones. La gestin de las respuestas a los problemas del sistema cubre un millar de posibles actividades. Algunas de las posibles respuestas a los problemas del sistema podran incluir: liberacin de nuevas versiones, sesiones de planificacin, identificacin de la formacin necesaria, actualizacin de la documentacin, etc. Desde el punto de vista del grupo de desarrollo, el aspecto ms significativo de un problema ser si es causa de un defecto del software. La calidad de la informacin comunicada desde el usuario al grupo de desarrollo es crucial para poder determinarlo y para su rpida resolucin. Estndares de mantenimiento Existen diversos estndares de otros tantos organismos internacionales de estandarizacin que tienen una relacin directa o indirecta con el Mantenimiento del Software: Para los procesos del ciclo de vida del software: IEEE 1074 e ISO 12207. Para la calidad del software y sus mtricas: IEEE 1061 e ISO 9126. Para el Mantenimiento del Software: IEEE 1219 e ISO/IEC 14764
Los estndares para los procesos del ciclo de vida del software nos permiten encajar y asociar el proceso de mantenimiento con los dems procesos existentes para el software. Los estndares de calidad del software interesan en mantenimiento del software porque los factores de calidad del software (especialmente la complejidad y la mantenibilidad) inciden directamente sobre el esfuerzo de mantenimiento necesario. Modelo de proceso RPN Define metas del negocio, identifica y evala los procesos de negocios existentes, especifica y disea procesos revisados y elabora prototipos, los refina y particulariza dentro de un negocio. Permite la definicin de las formas en las cuales las tecnologas de la informacin Reestructuracin Modifica el cdigo fuente o los datos con la finalidad de adecuarlos para futuros cambios. En general, la reestructuracin no modifica la arquitectura global del programa. Tiende a enfocarse sobre los detalles de diseo de los mdulos individuales y en las estructuras de datos locales definidos dentro de los mdulos. Si el trabajo de reestructuracin se extiende ms a la de las fronteras de mdulo, y abarca la arquitectura del software, la reestructuracin se convierte en ingeniera avanzada.
1
SEGUNDO BIMESTRE
Reestructura de datos Antes de comenzar la reestructuracin de datos se debe llevar a cabo una actividad e ingeniera inversa denominada anlisis de cdigo fuente, una vez completado este se comienza con el rediseo de datos. En su forma ms simple, un paso de estandarizacin de registro de datos clarifica las definiciones para lograr la consistencia entre los nombres de elementos de datos o formatos de registros fsicos dentro de una estructura de datos existentes o formato de archivo.
Esquema de estudio
31.1 Reingeniera de procesos de negocio
Describe, que el mbito de la reingeniera se centra en el proceso de negocio con el propsito de efectuar los cambios para mejorar la competitividad en alguna rea del negocio Revisar los puntos 31.1.1,y 31.1.2, interesa que se adquiera un conocimiento general de los tipos de los procesos de negocio y el modelo RPN
Considere una actividad de desarrollo en la cual a participado, describa el proceso de negocio utilizado y utilice la RPN descrita en el libre para recomendar cambios al proceso con la finalidad de hacerlo ms eficiente Investigue las herramientas de software para la Reingeniera de procesos de negocio descritas en la Pg.: 895
ANOTACIONES:
REQUIERO TUTORA?
TEMA A REVISAR
31.2 Reingeniera del software Una aplicacin que ha cubierto las necesidades de negocio de una compaa durante mucho tiempo indica que ha tenido correcciones y adaptaciones de mejora en muchas ocasiones, el personal se enfrent a esto con las mejores intenciones y las buenas prcticas de la ingeniera de software fueron omitidas, tornando a la aplicacin inestable, la aplicacin tiene que evolucionar. El software al cual no se le puede dar mantenimiento no es un problema nuevo, de hecho cada vez ms se le concede mayor importancia a la reingeniera de software, en la resolucin de estos problemas. Revisar los puntos 31.2.1, interesa que se adquiera un conocimiento general acerca del mantenimiento del software. En base a la figura 31.2 haga un anlisis del modelo de procesos de la reingeniera del software descritos en el punto 31.2.2.
REQUIERO TUTORA?
2
SEGUNDO BIMESTRE
TEMA A REVISAR
31.3 Ingeniera Inversa
El objetivo de la ingeniera inversa es el de obtener informacin de diseo a partir de cdigo fuente, pero el grado de abstraccin, la completitud de la documentacin, el grado en que las herramientas y un analista humano trabajan en conjunto, y la direccionalidad del proceso son enormemente variables. En este punto se ilustran las principales caractersticas de la ingeniera inversa y lo que tiene que ver a la comprensin de los datos, procesamiento de la informacin y las interfaces de usuario. Revisar los puntos 31.3.1, 31.3.2 y 31.3.3 interesa que se adquiera un conocimiento general del tema. Investigue las herramientas de software para la ingeniera inversa descritas en la Pg.: 916
REQUIERO TUTORA?
31.5 Ingeniera directa
La ingeniera directa no slo recupera la informacin de diseo a partir de software existente, tambin utiliza esta informacin para alterar o reconstruir el sistema existente con la finalidad de mejorar su calidad global.
Revisar los puntos 31.5.1, 31.5.2 y 31.5.3 interesa que se adquiera un conocimiento general del tema.
REQUIERO TUTORA?
No. 1. 2. 3. 4. 5.
Cuestin Indique cuales son los elementos que se combinan para lograr un resultado especifico dentro del proceso de negocio Identifique las actividades de la reingeniera de procesos de negocio RPN Indique cuales son los componentes del modelo de procesos de la reingeniera del software Indique cual es el fundamento de la ingeniera inversa. Qu debe hacer una organizacin antes de someter a reingeniera una aplicacin existente?
Malo
Medio
Muy bien
3
SEGUNDO BIMESTRE

Ejercicios
Para reforzar el nivel de conocimientos del presente captulo se deben realizar las siguientes actividades. Desarrolle los problemas: 31.1, 31.2, 31.6, 31.7, 31.8, 31.9, 31.10, 31.12.
DESCRIPCIN Este estndar describe un proceso iterativo para la gestin y ejecucin de las actividades de Mantenimiento del Software. Esta presentacin, muestra una visin general de la reingeniera de software y sus diferentes ambitos Archivo disponible en UTPLONLINE
Estndar IEEE1219 Mantenimiento del software
Presnentacin reingeniera de software
4
GLOSARIO/SOLUCIONARIO
Solucionario
Cuestiones de repaso captulo 1 No.
1.
Cuestin
Defina proceso de software.
Respuesta
Proporciona el marco de trabajo desde el cual se puede establecer un plan detallado de desarrollo de software.
2.
Qu buscara usted en la persona que va a Habilidad para alentar al personal dirigir un proyecto de software. Habilidad para adecuar los procesos existentes en un producto final Eficiencia para diagnosticar los conflictos tcnicos y organizativos ms relevantes y la manera de estructurar una solucin Tener confianza de asumir el control del proyecto cuando es necesario. Recompensar la iniciativa y los logros para optimizar la productividad del equipo. Mantener el control en situaciones de alta tensin emocional
3.
Qu factores usted considera indispensables La dificultad del problema que se resolver al elegir una estructura de un equipo de El tamao del programa resultante en lneas de software cdigo o puntos de funcin El tiempo que el equipo estar junto La calidad y confiabilidad requeridos del sistema que se construir La rigidez de la fecha de entrega El grado de sociabilidad que requiere el proyecto
4.
Que opciones se tienen cuando se define la Paradigma cerrado estructura de un equipo de software Paradigma aleatorio Paradigma abierto Paradigma sincrnico

No.
5.
Cuestin
Respuesta
Cules son las seales de que un proyecto El personal de software no entiende las necesidades de software est en peligro. de sus clientes El mbito del producto est mal definido Los cambios se gestionan mal La tecnologa elegida cambia Las necesidades comerciales cambian Los plazos de entrega no son realistas Los usuarios se resisten Se pierde el patrocinio El equipo de proyecto carece de personal con las habilidades apropiadas. Los gestores evitan las mejores prcticas y las lecciones aprendidas.
6.
Cules son las actividades de gestin que Medidas y mtricas. abarca un proyecto de software? Estimacin y planificacin Anlisis de Riesgos Seguimiento y control
7.
Que se debe hacer el equipo de software Definir un plan de proyecto preliminar con base en cuando ya se ha seleccionado un modelo el conjunto de actividades del marco de trabajo del de proceso. proceso.

1.
Cuestin
Indique determinantes para la calidad del Producto, software y la eficacia organizacional. Proceso Personal Tecnologa
Respuesta
2.
Qu lineamientos se deben aplicar cuando Aplique sentido comn y sensibilidad organizativa se recopilan mtricas del software? cuando interprete datos mtricos. Ofrezca retroalimentacin regular a los individuos y equipo que recopilan medidas y mtricas. No utilice mtricas para evaluar a los individuos Trabaje con profesionales y equipos para establecer metas claras y las mtricas que se emplearn para conseguirlas. Nunca utilice mtricas para amenazar a los individuos o equipos Los datos mtricos que indican un rea problema no deben considerarse negativos. No se obsesione con una sola mtrica y excluya otras mtricas importantes.

No.
3.
Cuestin
Respuesta
Cmo se emplean las mtricas durante un Primero: se emplean para minimizar el tiempo de proyecto? desarrollo haciendo los ajustes necesarios para evitar demoras y reducir los problemas y riesgos potenciales Segundo: Se utilizan para valorar la calidad del producto sobre una base actual. Que es una lnea base de mtricas y que Sirve como fundamento para la estimacin y beneficios proporciona. consiste en datos recopilados en proyectos previos de desarrollo de software; proporciona beneficios en los mbitos de proceso, proyecto y producto Indique cuales es el proceso de recopilacin Recopilacin de datos Medidas de mtricas de software Calculo de mtricas - Mtricas Evaluacin de mtricas - Indicadores Indique cual es la forma racional de mejorar Medir sus atributos especficos, desarrollar un un proceso. conjunto de mtricas significativas con base en dichos atributos y luego emplear las mtricas para ofrecer indicadores que conducirn a una estrategia de mejora. Por qu las mtricas del proyecto se utilizan Porque se emplean las mtricas del proyecto y los con propsitos estratgicos? indicadores que se deducen de ellas para adaptar el flujo de trabajo del proyecto a las actividades tcnicas. Indique cuales son las medidas de calidad Correccin Facilidad de mantenimiento Integridad Facilidad de uso
4.
5.
6.
7.
8.

1.
Cuestin
Respuesta
Cmo se mide el tamao del software que En un enfoque directo en lneas de cdigo (LCD). se desea construir. En un enfoque indirecto mediante puntos de funcin (PF) Cmo se calcula el valor esperado para Se calcula como un promedio ponderado de las el tamao de software? estimaciones optimista, ms probable y pesimista para cada funcin o cuenta para cada valor del dominio de la informacin.
2.

No.
3.
Cuestin
Respuesta
Por qu es difcil desarrollar una tcnica de Los casos de uso se describen utilizando muchos estimacin con casos de uso? formatos y estilos diferentes; no existe un formato estndar. Representan una visin externa del software No abordan las la complejidad de las funciones ni de las caractersticas que de describen No describen el comportamiento complejo (interacciones) que involucran muchas funciones y caractersticas
4.
Qu es un punto objeto?
Es una medida indirecta de software que se calcula mediante el conteo de nmeros de: pantalla, reportes, componentes que requiera construir la aplicacin.
5.
Cmo se desarrollan las estimaciones Mediante un enfoque de estimacin informal, cuando se aplica un proceso gil? aunque razonablemente disciplinado y significativo dentro del contexto de la planificacin de proyectos para cada incremento de software.

1.
Cuestin
Respuesta
Cul es el objetivo de la calendarizacin de Es una actividad que distribuye estimaciones de proyectos? esfuerzo a travs de la estimacin planificada del proyecto al asignar el esfuerzo a tareas especficas de ingeniera de software. Cul es la funcin de un gestor de proyecto Definir todas las tareas, construir una red que de software durante la calendarizacin? bosqueje sus interdependencias, identificar tareas cruciales dentro de la red y luego seguir su proceso para garantizar que la demora se reconoce un da a la vez La calendarizacin para proyectos de La primera: Se ha establecido (irrevocablemente) una ingeniera de software se puede ver desde fecha final para la liberacin de un sistema basado dos perspectivas: en computadora. La organizacin de software esta restringida a distribuir el esfuerzo dentro del marco temporal prescrito. La segunda: Se han comentado lmites cronolgicos aproximados, pero que la fecha final la establece la organizacin de ingeniera de software. El esfuerzo se distribuye para utilizar mejor los recursos y la fecha final se define despus de un anlisis cuidadoso del software.
2.
3.

No.
4.
Cuestin
Respuesta
Indique cuales son los principios de la Compartimentacin, calendarizacin. Interdependencia Asignacin de tiempo Validacin del esfuerzo Definicin de responsabilidades Definicin de hitos Es una representacin grfica del flujo de tareas en un proyecto, se utiliza como un mecanismo mediante el cual la secuencia y dependencias de las tareas son la entrada de una herramienta automatizada de calendarizacin. Cul es el objetivo de realizar un anlisis Permite valorar el porcentaje realizado de un cuantitativo de progreso? proyecto re empleando el anlisis cuantitativo en lugar de apoyarse en una opinin personal. Qu es una red de tareas?
5.
6.

1.
Cuestin
Respuesta
Cules son las principales categoras de Riesgos del proyecto riesgos? Riesgos Tcnicos Riesgos de Negocios Riesgos conocidos Riesgos predecibles Riesgos impredecibles
2. 3.
Cules son las principales estrategias de Reactivas y, riesgo? Proactivas Cundo considerarnos a la gestin del Cuando se comienza mucho antes de que se riesgo como proactiva? inicio el trabajo tcnico. Se identifican los riesgos potenciales, se valora su probabilidad e impacto y se clasifica segn su importancia. Qu es un riesgo genrico? Es aquel que es una amenaza potencial para todo el proyecto de software.
4. 5.
Indique cuales son los componentes de un Riesgo de desempeo riesgo? Riesgo de costo Riesgo de soporte Riego de calendarizacin.
6.
Indique como se clasifica al riesgo, al 1) De acuerdo a la posibilidad o probabilidad de momento de hacer su proyeccin? que el riesgo sea real. 2) De acuerdo a las consecuencias de los problemas asociados con el riesgo en caso de que ocurra.

No.
7.
Cuestin
Respuesta
Describa cuales son los pasos a seguir en la Establecimiento de una escala que refleje la proyeccin del riesgo? posibilidad percibida de un riesgo. Delinear las consecuencias de un riesgo Estimacin del impacto del riesgo en el proyecto y el producto Tomar nota de la precisin global de la proyeccin del riesgo de modo que no haya malas interpretaciones. Cules son los factores a tomar en cuenta Naturaleza ante la ocurrencia de un riesgo? mbito Tiempo
8.

1.
Cuestin
Respuesta
Cul es el origen de los cambios que se Nuevas condiciones del negocio requieren para el software? Nuevas necesidades del cliente La reorganizacin o el crecimiento o reduccin del negocio Restricciones presupuestarias o de calendarizacin Cules son las metas de las actividades Gestor de proyectos: garantiza que el producto se realizadas por cada uno de los participantes entregue dentro de cierto perodo. involucrados en la gestin del cambio? Gestor de configuracin: garantiza el seguimiento de los procedimientos y polticas para crear, cambiar y poner a prueba el cdigo. Ingenieros de software: responsables del desarrollo y mantenimiento del producto de software. Cliente: emplea el producto Que funciones implementa un depsito de Integridad de datos ECS? Compartir informacin Integracin de herramientas Integracin de datos Fortalecimiento de la metodologa Estandarizacin de documentos Cules la finalidad de una auditoria de Ayuda a garantizar que la calidad se conserva configuracin? conforme se realizan los cambios. Qu impacto tiene un cambio descontrolado Conducirn a la difusin no autorizada de sobre una WebApp? informacin de un nuevo producto; funcionalidad errnea o pobremente probada que frustra a los visitantes de un sitio web.
2.
3.
4. 5.
0
No.
6.
Cuestin
Respuesta
Cul es la relacin entre la gestin de La gestin de contenido se relaciona con la GC contenido y la GC de la WebApp. en el sentido de que establece un proceso que adquiere contenido existente, lo estructura en una forma que permite presentarlos a un usuario final y luego los ofrece al entorno del lado del cliente para su despliegue. Cules son los elementos de un sistema de Elementos de componentes la gestin de la configuracin? Elementos de proceso Elementos de Construccin Elementos humanos.
7.

1.
Cuestin
Respuesta
Cules son los pasos del proceso de anlisis Definir el dominio que se investigar de dominio? Categorizar los elementos extrados del dominio Recopilar una muestra representativa de las aplicaciones del dominio. Analizar cada aplicacin en la muestra y definir las clases de anlisis Desarrollar un modelo de anlisis para las clases. Qu es un punto de estructura y cules son Es una estructura distinta dentro de un modelo sus caractersticas? estructural. Caractersticas: Es una abstraccin que debe tener un nmero limitado de instancias. Las reglas que rigen su uso deben comprenderse con facilidad. Debe implementar la ocultacin de la informacin al aislar toda la complejidad dentro del mismo punto de estructura. Qu factores se consideran durante la Interfaz de programacin de la aplicacin calificacin de componentes? Herramientas de desarrollo e integracin Requisitos de tiempos de ejecucin Requisito de servicio Caractersticas de seguridad Manejo de excepciones Qu ingredientes se necesitan para lograr Modelo de intercambio de datos la composicin de componentes? Automatizacin Almacenamiento estructurado Modelo de objeto subyacente
2.
3.
4.
1
No.
5
Cuestin
Respuesta
Indique cuales son las principales Ingeniera del dominio herramientas en las que se basa la ingeniera Desarrollo basado en componentes. basada en componentes Cul es la finalidad de la ingeniera de la Identificar, construir, catalogar y diseminar un dominio conjunto de componentes que sean aplicables para el software existente y futuro en un dominio de aplicacin en particular. Cul es el fundamento del modelado Es un enfoque de ingeniera del dominio basada estructural? en patrones que funciona bajo la premisa de que cualquier dominio de aplicacin tiene patrones repetitivos (de funcin, de datos, de comportamiento) que tienen un potencial de reutilizacin. Cules son las caractersticas de un Es una unidad de implementacin componente? independiente. Es una unidad compuesta por terceras partes. No cuenta con un estado observable desde el exterior.
6.
7.
8.

1.
Cuestin
Respuesta
Indique cuales son los elementos que La gente se combinan para lograr un resultado El equipo especifico dentro del proceso de negocio: Los recursos materiales Los procedimientos de negocio Identifique las actividades de la reingeniera Definicin del negocio de procesos de negocio RPN Identificacin del proceso Evaluacin del proceso Especificacin y diseo de proceso Elaboracin de prototipos Refinamiento y particularizacin. Indique cuales son los componentes del Anlisis de inventarios modelo de procesos de la reingeniera del Reestructuracin de documentos software? Ingeniera inversa Reestructuracin del cdigo Reestructuracin de los datos Ingeniera avanzada Indique cual es el fundamento de la Es el proceso de analizar un programa con ingeniera inversa. la finalidad de crear una representacin del programa un mayor grado de abstraccin que el cdigo fuente. Qu debe hacer una organizacin antes Realizar un anlisis costo-beneficio, esto es el de someterse a reingeniera una aplicacin costo asociado con el soporte y mantenimiento. existente? AC/sd-09-02-09-72
2.
3.
4.
5.
2

G18701

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

G18701

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TCNICA PARTICULAR DE LOJA

La Universidad Catlica de Loja

MODALIDAD ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS DE LA COMPUTACIN

I NGENIERA DEL SOFTWARE

CARRERA: Ingeniera en Informtica AUTOR: Armando Cabrera Silva

Reciba asesora virtual en: www.utpl.edu.ec

OCTUBRE 2009 - FEBRERO 2010

INGENIERA DEL SOFTWARE

ISBN - 978 - 9942 - 00 - 619 - 9

Gua didctica: Ingeniera del Software

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

Plan de desarrollo de contenidos

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

Desarrollo del aprendizaje

Gua didctica: Ingeniera del Software

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

21.1 El espectro de la gestin

PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)

TEMA A REVISAR DESCRIPCIN DEL CONTENIDO A REVISAR

PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)

TEMA A REVISAR DESCRIPCIN DEL CONTENIDO A REVISAR ACTIVIDADES RECOMENDADAS ANOTACIONES:

PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

TEMA A REVISAR DESCRIPCIN DEL CONTENIDO A REVISAR ACTIVIDADES RECOMENDADAS ANOTACIONES:

PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)

TEMA A REVISAR DESCRIPCIN DEL CONTENIDO A REVISAR ACTIVIDADES RECOMENDADAS ANOTACIONES:

PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)

TEMA A REVISAR DESCRIPCIN DEL CONTENIDO A REVISAR ACTIVIDADES RECOMENDADAS ANOTACIONES:

PLANIFICACIN PERSONAL DE ESTUDIO (FECHA)

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

DESPUS DE RESPONDER, EL DESEMPEO HA SIDO:

Interactividad a travs de los Foros de Campus Virtual

Gestin de proyectos de Software

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

Mtricas del Proceso, Proyecto y Producto

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

Mtricas de casos de uso

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

Mtricas orientadas a la funcin

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja

Gua didctica: Ingeniera del Software

Gua didctica: Ingeniera del Software

PF = T * (0.65 + 0.01 * F).

Mtricas orientadas a objetos

Mtricas orientadas al tamao

UNIVERSIDAD TCNICA PARTICULAR DE LOJA La Universidad Catlica de Loja