Upload
ikari-shinji
View
10
Download
0
Embed Size (px)
DESCRIPTION
Software-UNI
Citation preview
1PLANIFICACIN DE PROYECTOS DE
SOFTWARE
Dr. Ing. CELEDONIO MNDEZ
TCNICAS DE DOCUMENTACIN Y ARCHIVO
4
Contenido
4.1. Planificacin del tiempo
4.2. Evaluacin del costo beneficio
4.3. Estudio de viabilidad
4.4. Planificacin de la documentacin
4.5. Gestin de la configuracin del software
Gestin de proyectos La gestin de proyectos de software se hace
necesaria ya que todo proyecto esta sujeto arestricciones de presupuesto y tiempos.
La gestin permite asegurar que el software selleve a cabo a tiempo y de acuerdo con losrequerimientos especificados.
Gestin de proyectosLa gestin de proyectos de software son particularmente difciles, algunas de las razones son:
El producto de software es intangible. No hay un proceso estndar. A menudo los proyectos de software grandes son
nicos.
Gestin de proyectos
Las actividades comunes de la gestin de proyectos software son:
Redaccin de la propuesta. Planificacin del proyecto
Estimaciones de costo, tiempo y esfuerzo. Supervisin y revisin del proyecto. Seleccin y evaluacin del personal. Redaccin y presentacin de informes.
Que es la Planificacin
Es una gua de desarrollo para cumplir las metasdel proyecto.
Es un proceso iterativo el cual termina hasta queel proyecto mismo haya terminado. Esto quieredecir que su revisin es continua, ya que tantorequerimientos como restricciones puedencambiar a lo largo del desarrollo
2Importancia de la Planificacin
El xito o fracaso de un proyecto de softwaredepende en gran parte de la planificacin, ya quecon ayuda de sta se pueden evitar problemas alos que un proyecto est sujeto, tales como: Retraso de tiempo de entrega Sobrepasar el presupuesto Baja calidad del producto Alto costo de mantenimiento, etc.
Actividades de la Gestin y la Planificacin
GESTION DE
PROYECTOS
Propuesta Planificacin Supervisin Personal Informal
Planificacin del tiempo
(calendarizacin)
Estimacin de costos (esfuerzo)
Gestin de riesgos y control de calidad
Gestin de la
configuracin de sw
PLANIFICACION
4.1
PLANIFICACIN DEL TIEMPO
4.1. Planificacin del tiempo
El factor tiempo es muy importante en eldesarrollo de software ya que ganaremos operderemos a un cliente si este no es entregadoen los tiempos establecido o ya negociados.
La planificacin de tiempo se puede definircomo una actividad en la cual se debe estimarel tiempo que requerir para llevar a cabo unatarea y los recursos necesarios para surealizacin.
Actividades e Hitos
Durante la recoleccin de requerimientos, se listantodos los elementos que se deben entregar delproyecto (actividades e hitos), que son los temsque los clientes esperan ver durante el desarrollodel proyecto.
La descomposicin en hitos y actividades beneficia: Tanto a clientes como desarrolladores para
entender el desarrollo y mantenimiento del sistema.
Al gestor para juzgar el progreso del software y puede entonces actualizar costos y el calendario.
Actividades e Hitos en el desarrollo de software
3Calendarizar el proyecto Una vez definidas las actividades y hitos se debe
calendarizar el proyecto (dividir el trabajo en actividadeso tareas complementarias y considerar el tiempo querequiere cada una).
Generalmente se representa con grficos de barras ygrafos o redes de actividades que muestran lasactividades, los responsables, la dependencia entereactividades y la asignacin de recursos.
El gestor debe coordinar las tareas del trabajo, asignarlespersonal y otros recursos de tal manera que seaprovechen de manera ptima. Las actividades por logeneral duran al menos una semana, la cantidad detiempo mxima sugerida es de 8 a 10 semanas.
4.1.1 Mtodos de Planificacin temporal
Existen varios mtodos para la planificacin :
La tcnica de revisin y evaluacin del
programa(PERT)
CPM la ruta crtica
Tambin existen varias representaciones grficas
como son:
Redes de actividades
Grficos de barras
Diagrama de Actividades
Por, medio de una red de actividades se muestra ladependencia entre las diferentes actividades y se estima eltiempo en que tardar cada tarea, se debe considerar quealgunas de stas se podrn realizar en paralelo.
Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
Duracin (das) 8 15 15 10 10 5 20 25 15 15 7 10
Dependencias
T1 (M1)
T2,T4(M2)
T1,T2(M3)
T1 (M1)
T4(M5)
T3, T6(M4)
T5, T7(M7)
T9(M6)
T11 (M8)
M representa un Hito
Diagrama de Actividades
1
2
3
4 5
6
8
7
9
10
11
12
Es el tiempo mnimo requerido para
finalizar el proyecto
Diagramas Gantt Diagramas Gantt
En un diagrama Gantt las actividades son seguidaspor una barra sombreada (azul) y cuya longitud escalculada por una herramienta de calendarizacin.
La barra azul indica que hay flexibilidad en la fechade terminacin para dichas actividades. Entonces laruta crtica se ve afectada solamente si:
Las actividades que no tienen barra azul no secompletan a tiempo.
Las actividades con barra azul pasa del lmite detiempo marcado por sta.
4Personas asignadas a diferentes Actividades en el Proyecto
Tarea Ingeniero
T1 Jos
T2 Ana
T3 Jos
T4 Jorge
T5 Mara
T6 Ana
T7 Ral
T8 Jorge
T9 Jos
T10 Ana
T11 Jorge
T12 Jorge
Jos
Ana
Mara
Ral
Jorge
Mtodos PERT (Program Evaluation and Review Technique) y CPM(Crtical Path Method)
Ambos mtodos aportaron los elementos
administrativos necesarios para formar el mtodo del
camino crtico actual, utilizando el control de los tiempos
de ejecucin y los costos de operacin, para buscar que
el proyecto total sea ejecutado en el menor tiempo y al
menor costo posible.
Tanto PERT como CPM hacen uso de diagramas o redes
de actividades.
El mtodo PERT
El mtodo PERT se desarroll para proyectos conincertidumbre en el tiempo de las actividades(usualmente debido a que el proyecto nunca se habaintentado antes y por tanto no haba bases de datos,para los tiempos de las actividades). Esto condujo alenfoque probabilstico que se tom.
La principal desventaja es que no es funcional paragrandes proyectos, debido a los tres estimados detiempo que se requieren en cada actividad. Adems, elcosto de actualizar y mantener la informacin delproyecto con el tiempo en ambientes tan dinmicos,puede ser excesivamente prohibitivo.
Pasos en el planteamiento de PERT
1. Identificar las actividades y su interdependencia
2. Determinar la secuencia de actividades3. Construir el diagrama de red4. Tiempos estimados de actividades5. Determinar la trayectoria crtica6. Actualizar segn el progreso del proyecto
El mtodo CPM
El CPM se desarroll para manejar proyectosrepetitivos o similares (ej., mantenimiento deplantas qumicas).Obviamente, se gana gran cantidad deexperiencia con el tiempo en talescircunstancias, aun cuando dos proyectospuede que no sean iguales.
Pasos en CPM
1. Especificar las actividades individuales.
2. Determinar la secuencia de esas actividades.
3. Dibujar el diagrama de la red. 4. Estimar el tiempo de terminacin para cada
actividad.
5. Identificar la ruta crtica (la trayectoria ms larga a travs de la red)
6. Actualizar el diagrama del CPM
5Mtodo del camino crtico
No solamente se llama camino crtico almtodo sino tambin a la serie de actividadescontadas desde la iniciacin del proyectohasta su terminacin, que no tienenflexibilidad en su tiempo de ejecucin, por loque cualquier retraso que sufriera alguna delas actividades de la serie provocara unretraso en todo el proyecto.
Mtodo del camino crtico
Desde otro punto de vista, camino crtico esla trayectoria crtica de mayor duracin atravs de la red. Debido a su impacto en elproyecto entero, el anlisis de trayectoriacrtica es un aspecto importante delplaneamiento del proyecto.
Diferencias entre PERT y CPM
PERT es un mtodo Probabilstico.
CPM es un mtodo Determinstico.
Considera que la variable de tiempo es una variable desconocida de la cual solo se tienen datosestimados.
Considera que los tiempos de las actividades se conocen y se pueden variar cambiando el nivel de recursos utilizados.
Considera tres tiempos estimados: o El ms probableo Optimista,o Pesimista.
Considera tiempos normales y acelerados de una determinada actividad, segn la cantidad de recursos aplicados en la misma.
4.2EVALUACIN DE COSTO-BENEFICIO
4.2.1. Mtricas de Software4.2.2. Estimacin del proyecto del software
4.2.2.1. Tcnicas para la estimacin de Software4.2.2.2. Modelos de estimacin4.2.2.3. La decisin a desarrollar o comprar4.2.2.4. Herramientas automticas de estimacin
4.2.3. Evaluacin del costo beneficio4.2.3.1. Mtodos para el anlisis Costo/Beneficio
4.2 Evaluacin del costo-beneficio
Actualmente el Software es el elemento ms caro enla mayora de los sistemas de informacin, por lo quela estimacin debe realizarse cuidadosamente ya queun gran error en la estimacin del costo puede definirla diferencia entre beneficios y prdidas tanto paraclientes y la empresa desarrolladora de software.
Evaluacin del costo-beneficio
Algunas razones por las cuales es crucialcomprender cual ser el costo aproximado son :
Los costos sobredimensionados pueden causarque los clientes cancelen el proyecto.
Los costos subestimados pueden no compensarel tiempo invertido por el equipo del proyecto.
No se debe olvidar que la estimacin es unaactividad compleja que se vale de modelos y detcnicas y estos a su vez se basan en mtricas,por lo que es necesario profundizar sobre stas.
64.2.1. Mtricas de software
Cuando se puede medir lo que se esta
diciendo y expresarlo con nmeros, significa
que tenemos conocimientos sobre ese tema,
cuando esto no ocurre significa que nuestro
conocimiento es precario y deficiente.
Porque medir el Software Nos indica la calidad del producto
Nos ayudan a evaluar
la productividad de la gente que desarrolla el producto
los beneficios de utilizar nuevos mtodos y herramientas de ingeniera de software justificando el
uso de stos.
Esta evaluacin permite una mejora continua al proceso de desarrollo de software.
Nos ayuda a establecer una lnea base para la estimacin
Que es una medida?
Cuando se recopila un solo aspecto de los datos se esthablando de medidas. Ejemplo: nmero de lneas de cdigo onmero de errores.
Una MEDIDA nos indica cuantitativamente:
Capacidad, tamao, extensin, dimensin, cantidad, etc.
De algunos atributos
Que posee un proceso o producto
Que es una mtrica?
MTRICA: es una medida cuantitativa
Indica en que grado
Posee un atributo
Un sistema o componente de sistema
Qu es un Indicador?
Un ingeniero de software recopila medidas ydesarrolla mtricas para obtener indicadores.
Un indicador: es una mtrica o una combinacinde mtricas que proporcionan un visin profundadel proceso y proyecto del software o del productoen si mismo.
Hay dos tipos de indicadores o mtricas:Indicadores de proceso e indicadores delproyecto
Indicadores de proceso
Brindan una visin profunda sobre la eficacia deun proceso ya existente.
Permiten evaluar lo que est funcionando.
Su propsito es mejorar los procesos desoftware a largo plazo y conducir a estrategiasque permitan mejorar la calidad del proceso.
7Indicadores del proyecto
Son utilizadas para supervisar el progreso duranteel desarrollo de software y controlar la calidad delproducto, adems se utilizan para realizar lasestimaciones de tiempo y esfuerzo. Permiten algestor de proyecto: Evaluar el estado del proyecto Seguir las pistas de los riesgos potenciales Detectar las reas de problemas para evitar reas
crticas Ajustar el flujo y las tareas del trabajo Evaluar la habilidad del equipo del proyecto para
controlar la calidad del producto de software.
Mtricas de Software
Aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una informacin de gestin significativa y a tiempo.
Mtricas de Software
Podemos definir las Mtricas de Software oMedidas de Software como: La aplicacin continua de tcnicas basadas en
las medidas de los procesos de desarrollo delsoftware y sus productos, para producir unainformacin de gestin significativa y a tiempo.Esta informacin se utilizar para mejorar esosprocesos y los productos que se obtienen deellos.
Mtricas de Software
Estas medidas son aplicables a todo el ciclode vida del desarrollo, desde la iniciacin,cuando debemos estimar los costos, alseguimiento y control de la fiabilidad de losproductos finales, y a la forma en que losproductos cambian a travs del tiempodebido a la aplicacin de mejoras.
Mtricas de Software
Esencialmente, las Mtricas de Software seaplican al producto Software y a los procesosmediante los que se desarrolla.Por tanto, las medidas del software y losmodelos de medida son entonces tiles paraestimar y predecir costos y para medir laproductividad y la calidad del producto.
Caractersticas de las mtricas de Software
Una medida ideal debera ser: Objetiva. Sencilla, definible con precisin para que pueda
ser evaluada. Fcilmente obtenible (a un coste razonable). Valida, la mtrica debera medir exactamente lo
que se quiere medir y no otra cosa. Robusta. Debera de ser relativamente
insensible a cambios poco significativos en elproceso o en el producto.
8Clasificacin de las Mtricas de Software
Mtricas de Producto
Mtricas de Proceso
Mtricas de producto
Son medidas del producto software durantecualquier fase de su desarrollo, desde losrequisitos hasta la instalacin.Las Mtricas de Producto pueden medir lacomplejidad del diseo, el tamao del productofinal (fuente u objeto) o el nmero de pginas dedocumentacin producida.
Mtricas de proceso
Son medidas del proceso dedesarrollo del software talescomo tiempo de desarrollo total,esfuerzo en das/hombre omeses/hombre de desarrollo delproducto, tipo de metodologautilizada o nivel medio deexperiencia de losprogramadores.
OTRAS CLASIFICACIONES DE MTRICAS
POR LAS PROPIEDADES OBJETIVAS Y SUBJETIVAS
Por ejemplo, el tamao del producto medido enlneas de cdigo (LOC) es una medida objetiva delproducto, y una medida subjetiva sera laclasificacin del software segn el modelo deestimacin de costos de Bohem (COCOMO) enorgnico, semilibre o rgido.Para medida de procesos, el tiempo de desarrollo esuna medida objetiva y el nivel de experiencia de unprogramador es una medida subjetiva.
Mtricas de Productos
Mtrica orientadas al tamao
Lneas de Cdigo
Mtricas orientadas a la funcin
Puntos de Funcin
Mtricas de calidad
Mtricas de Procesos
Conclusiones (mtricas)
Mtricas orientadas al Tamao:Lneas de cdigo
La medida ms utilizada de la longitud del cdigo fuente deun programa es el Nmero de Lneas de Cdigo (Lines ofCode en ingles, abreviado LOC). La definicin ms comnes la siguiente:
Una lnea de cdigo es cualquier lnea de un texto de unprograma que no es un comentario o lnea en blanco, sintener en cuenta el nmero de instrucciones o parte deinstrucciones en la lnea. Esta medida se suelerepresentar por NCLOC (No Comentary Lines of Code).
9 Mtricas orientadas al Tamao:Lneas de cdigo
Si queremos conocer la longitud real del programa
esta sera:
LOC = NCLOC + CLOC
Donde CLOC (Comentary Lines of Code) es el nmero
de lneas de comentarios.
Una medida indirecta de la densidad de comentarios
sera:
CLOC / LOC
Problemas
a) No se tiene en cuenta el concepto dereutilizacin.
b) No se tiene en cuenta el concepto de costesfijos ni tareas que se desarrollan que noproducen instrucciones. Por ello, no debe serutilizada esta medida directamente en laestimacin de esfuerzo o productividad.
Problemas
Cuando se est buscando la nocin pura de longitudexisten dos alternativas aceptables si se quiere utilizarbajo el concepto de tasa (ratio): Medir la longitud en trminos de nmero de bytes
de almacenamiento requerido para contener el textodel programa.
Medir la longitud en trminos de nmero decaracteres en el texto del programa (char).
Si se conoce el nmero medio de caracteres por lneade texto, NL; el nmero de lneas sera:
LOC = CHAR/NL
Ventajas y desventajas
Ventajas:
Que son fciles de calcular en cualquier proyecto
Existen varias herramientas de estimacin basadas en las lneas de cdigo
Ventajas y desventajas
Desventajas: La falta de una definicin universal de lnea de cdigo Las lneas de cdigo dependen de los lenguajes de
programacin y por lo tanto perjudica a los programas ms cortos pero bien diseados.
El estilo de programacin depender de cada persona. Comparar la productividad utilizando lenguajes diferentes de programacin puede llevar a conclusiones errneas respecto a la productividad de los programadores.
El decidir que lneas de cdigo se contabilizaran ya sean nuevas, lneas modificadas, reutilizadas ms definiciones de datos y comentarios.
Dificultad de estimar en fases tempranas del desarrollo la cantidad de lneas que tendr una aplicacin.
Mtricas de Productos
Mtrica orientadas al tamao
Lneas de Cdigo
Mtricas orientadas a la funcin
Puntos de Funcin
Mtricas de calidad
Mtricas de Procesos
Conclusiones (mtricas)
10
Mtricas orientadas a la Funcin
Es un mtodo para cuantificar el tamao y lacomplejidad de un sistema software en trminosde las funciones que el usuario desarrolla odesarrollar.Se entiende por funciones a las entradas, salidas,archivos, etc.
Mtricas Funcionales
Un punto de funcin es una mtrica sinttica quese compone de la suma ponderada de los totalesde las entradas, las salidas, las consultas, losarchivos lgicos, e interfaces que se identificanen la aplicacin.
Metodologa Original de Puntos de Funcin
La proposicin de puntos de funcin tuvo los siguientesobjetivos:
Medir lo que el usuario pide y recibe.
Medir independientemente de la tecnologa utilizadaen la implantacin del sistema.
Poder ser aplicados tempranamente en el ciclo devida del producto.
Proporcionar una mtrica de tamao que d soporteal anlisis de la calidad y la productividad.
Ser independientes de cdigo fuente o lenguaje.
PARMETROSInicialmente consider solo 4 parmetros bsicos y
un factor de ajuste de complejidad.
La siguiente tabla ilustra el mtodo original.
Metodologa Revisada de Puntos de Funcin
Revisin de la mtrica Puntos de Funcin realizada por IBM
Ejemplos de entradas:Formatos de datos llenadas por usuarios en pantallas, discos
magnticos, entradas en pantallas sensibles al tacto, clicks de
mouse.
Entradas: Pantallas o formularios a travs de los cualesusuarios de una aplicacin agregan nuevos datos o actualizan
datos existentes. Si una pantalla de entrada es muy grande para
ser desplegada de una vez (asumiendo 80 columnas y 25 lneas) y
requiere de una segunda pantalla, el conjunto cuenta como una
(1) sola entrada. Se deben considerar entradas que requieren
procesamiento nico.
11
Ejemplos de salidas:Pantallas de datos de salidas, informes impresos, archivos endisco, sets de cheques, facturas impresas. En general,contabilizar como una salida entidades que son referencialespor un nombre; contabilizar independientemente salidas quecomparten los datos pero varan en formato. Por ejemplo, unatabla y un histograma.
Salidas: Pantallas o informes que la aplicacin produce parauso humano o para otros programas. En una aplicacin deremuneraciones una funcin de salida que genere 100 chequescontara como una sola salida.
Ejemplos de archivos lgicos internos: Coleccin
lgica de registro que la aplicacin modifica o
actualiza. Un archivo puede ser una base de datos en
PC, una rama de una base de datos jerrquica, una
tabla de una base de datos relacional.
Ejemplos de (archivos externos lgicos de) interfaz:
bases de datos compartidas, archivos lgicos
direccionables desde o hacia otra aplicacin.
Interfaces: Archivos compartidos con otras aplicaciones,
como archivos en que vienen o que van, bases de
datos compartidas, o listas de parmetros.
Las consultas se dividen en dos partes: la porcin deentrada y la porcin de salida. Ejemplos de consultas:consulta de un usuario sin actualizar un archivo,mensajes de ayuda, mensajes de seleccin. Unaconsulta tpica sera una relacionada con unareservacin area.
La porcin de entrada sera la pregunta (por ejemplo:qu vuelos de Lan salen de Lima a Trujillo despus delas 5 pm?) y la porcin de salida la respuesta (porejemplo: Vuelo 143 a las 6:05 pm).
Consultas: Pantallas que le permiten a los usuariosinterrogar una aplicacin y solicitar asistencia oinformacin, tal como pantallas de ayuda (HELP).
14 factores de influencia
C1 Comunicacin de datos
C2 Funciones distribuidas
C3 Objetivos de performance
C4 Configuracin usada fuertemente
C5 Tasa de transacciones
C6 Entrada de datos en lnea
C7 Eficiencia del usuario final
C8 Actualizacin en lnea
C9 Procesamiento complejo
C10 Reusabilidad
C11 Facilidad de instalacin
C12 Facilidad operacional
C13 Sitios mltiples
C14 Facilitamiento del cambio
La escala de evaluacin tiene el siguiente significado:
0 factor no presente o sin influencia1 influencia insignificante2 influencia moderada3 influencia promedio4 influencia significativa5 influencia fuerte
Comunicacin de datos:
Implica que datos y/o informacin de control son
enviadas o recibidas sobre facilidades de
comunicacin. La evaluacin se reflejara en un 0
para aplicaciones batch, y un 5 para aplicaciones
interactiva.
Funciones distribuidas:
Analiza si una aplicacin es monoltica y opera en
un solo procesador o si es distribuida entre varios
procesadores. La evaluacin arrojara un 0 para
aplicaciones monolticas puras, y un 5 para
aplicaciones que se ejecutan dinmicamente en
varios procesadores.
12
Objetivos de performance: la evaluacin sera un 0 sino hay establecido ningn criterio especial de
performance por los usuarios, y un 5 si los usuarios
insisten en objetivos de performance muy rigurosos que
requieren un esfuerzo considerable para ser logrados.
Configuracin usada fuertemente: la evaluacinsera un 0 si la aplicacin no tiene restricciones
especiales de uso, y un 5 si el uso anticipado requiere
especial esfuerzo para ser logrado.
Tasa de transacciones: la evaluacin sera un 0 si elvolumen de transacciones no es significativo, y
un 5 si el volumen es lo suficientemente
significativo como para producir stress en la
aplicacin y requerir un esfuerzo especial para
alcanzar throughputs deseados.
Entrada de datos en lnea: la evaluacin sera un 0si menos del 15% de las transacciones son
interactivas, y un 5 si ms del 50% de las
transacciones son interactivas.
Entrada de datos en lnea: la evaluacin sera un 0 simenos del 15% de las transacciones son interactivas, y un
5 si ms del 50% de las transacciones son interactivas.
Eficiencia del usuario final: la evaluacin sera un 0 si nohay usuarios finales o no hay requerimientos especiales
para los usuarios finales, y un 5 si los requerimientos de
eficiencia de usuarios finales son lo suficientemente
rgidos como para requerir un esfuerzo
Actualizacin en lnea: la evaluacin sera un 0 si no hay,y un 5 si las actualizaciones son obligatorias y
especialmente difciles, quizs debido a la necesidad de
proteger datos de cambios accidentales.
Procesamiento complejo: la evaluacin sera un 0 sino hay, y un 5 en casos que requieren decisiones
lgicas extensas, matemtica compleja,
procesamiento truculento de excepciones, o
esquemas de seguridad elaborados.
Reusabilidad: la evaluacin sera un 0 si lafuncionalidad se planifica para permanecer local a
la aplicacin actual, y un 5 si mucha de la
funcionalidad y los artefactos del proyecto se
pretende que sean usados ampliamente por otras
aplicaciones.
Facilidad de instalacin: la evaluacin sera un 0si este factor es insignificante, y un 5 si la
instalacin es importante y tan restrictiva que
requiere un esfuerzo especial para cumplirla
satisfactoriamente.
Facilidad operacional: la evaluacin sera un 0 sieste factor es insignificante, y un 5 si la facilidad
operacional es tan restrictiva que requiere un
esfuerzo especial para alcanzarla.
Sitios mltiples: la evaluacin sera un 0 si haysolo un sitio planificado de uso, y un 5 si el
proyecto y sus artefactos se pretenden sean
usados en muchos lugares.
Facilitamiento del cambio: la evaluacin sera un0 si el cambio no ocurre, y un 5 si la aplicacin se
desarrolla especficamente para permitir a los
usuarios finales el hacer cambios rpidos para
controlar datos o tablas que ellos mantienen con
la ayuda de la aplicacin.
13
El procedimiento para calcular el factor de ajuste es el siguiente:
Asignar una evaluacin individual a cada uno de los 14
factores
Sumar las evaluaciones (esta dar un valor entre 0 y 70)
Multiplicar la suma de evaluaciones por 0.01 para
obtener un valor decimal
Sumar 0.65 al valor decimal para crear un factor de
complejidad (un valor entre 0.65 y 1.35)
Ejemplo
Suponga una aplicacin con 10 entradas, 10
salidas, 10 consultas, 1 archivo de datos y 1
archivo de interfaz, todos ellos de complejidad
promedio.
Suponga que los factores de influencia se
determinaron de la siguiente manera:
Conversin de Puntos de Funcin a lneas de Cdigo
LENGUAJE FACTORES DE CONVERSIN
Ada 75
Basic Compilado 90
Basic Interpretado 128
Ensamblador 320
C 128
C++ 29
Visual Basic 30
Cobol80 96
Prolog 61
Pascal 90
Lisp 61
Modula2 80
Ejemplo
Por ejemplo, si al aplicar el procedimiento de clculopara puntos de funcin sin ajustar se obtiene unresultado de 165 UNFP (Puntos de Funcin sinAjustar) y el proyecto va a desarrollarse en ellenguaje de programacin C++:
165 UNFP x 29 = 4785 SLOC (Lneas de CdigoFuente)
Haciendo la conversin mencionada anteriormente:
4785/1000= 4.785 KSLOC (Miles de Lneas deCdigo Fuente).
14
Mtricas de Productos
Mtrica orientadas al tamao
Lneas de Cdigo
Mtricas orientadas a la funcin
Puntos de Funcin
Mtricas de calidad
Mtricas de Procesos
Conclusiones (mtricas)
Mtricas de Calidad
Cualquier proyecto de ingeniera del software tienecomo objetivo principal obtener sistemas y productosde alta calidad
La calidad es difcil medirla directamente, no obstantehay indicadores que nos pueden dar una idea sobre lamisma. Estos indicadores se basan en los siguientesaspectos:
Correccin
Facilidad de mantenimiento
Integridad
Facilidad de uso
Correccin
Es el grado en el que el software
lleva a cabo su funcin. Se mide
en defectos por KLDC (miles delneas de cdigo), entendindose
por defecto cualquier falta de
concordancia con los requisitos.
Facilidad de Mantenimiento
Se mide por la facilidad de:
Corregir defectos encontrados,
Adaptar ese programa a nuevos entornos, y
Mejorar el programa si el cliente desea cambios.
La facilidad de mantenimiento se mide indirectamente
por medio de una mtrica orientada al tiempo: tiempo
medio del cambio (TMC), es decir, por el tiempo que se
tarda en analizar la peticin del cambio, disear la
modificacin, implementarla, probarla y distribuir la
notificacin del cambio a los usuarios.
Integridad
Mide la habilidad de un sistema para resistir ataques contra su seguridad. El proteger los datos, programas y documentacin debe ser una prioridad. Para medirla se consideran dos atributos adicionales:
Amenaza, que es la probabilidad estimada o deducida de que se produzca un ataque de un tipo determinado.
Seguridad, probabilidad estimada o deducida de el nuestro sistema pueda repeler dichos ataques.
Facilidad de uso
Entendindose como tal lo amigable que resulta alusuario el sistema. Es un intento de cuantificar losamigable que es el sistema. Se puede deducir apartir de cuatro caractersticas: Habilidad intelectual o fsica requerida para
aprender el sistema. El tiempo requerido para llegar a ser
moderadamente eficiente en el uso del sistema. El aumento de productividad de alguien que usa
el sistema. Valoracin subjetiva de la disposicin de los
usuarios hacia el sistema.
15
Tcnicas de Estimacin de Costos
4.2.2. Estimacin del proyecto de software
Estimacin de Proyectos
La primer tarea en la gestin de proyectos es la
estimacin.
La estimacin se define como el proceso que proporciona
un valor a un conjunto de variables para la realizacin de
un trabajo, dentro de un rango aceptable de tolerancia.
Podemos definirlo tambin como la prediccin de
personal, del esfuerzo, de los costos y de la planificacin
que se requerir para realizar todas las actividades y
construir todos los productos asociados con el proyecto.
Uno de los parmetros crticos de la estimacin es
determinar su exactitud. La estimacin puede realizarse
a partir de datos histricos o con herramientas.
Tareas crticas en la Gestin de Proyectos
Hay tres tareas que son crticas y que deben ser
desarrolladas correctamente si se desea que el proyecto
termine bien, estas son:
Estimacin de duracin, costo y esfuerzo necesariospara construir el producto.
Planificacin de tareas a realizar, asignacin depersonas, tiempos, etc. para construir el producto.
Seguimiento durante la realizacin del trabajo, paraasegurar el cumplimiento de lo planificado en
cuanto a costes, fechas, etc. En caso de
desviaciones del plan, se deben tomar las medidas
pertinentes.
Relacin entre las actividades clavede la Gestin de Proyectos
4.2.2.1.
Tcnicas para la estimacin del software
Tcnicas de Estimacin
Existen cuatro tcnicas bsicas y comunes
La opinin de los expertos: se basa en la experienciaprofesional de los participantes en el proyecto de estimacin.
La analoga: Es una aproximacin ms formal que laexperiencia de los expertos y se basa en la comparacin
directa de uno o ms proyectos pasados.
La descomposicin: Consiste en la descomposicin de unproducto en componentes ms pequeos, o descomponer un
proyecto en tareas de nivel inferior.
Las ecuaciones de estimacin: Frmulas matemticasque establecen la relacin de algunas medidas de entrada
(que normalmente es la medida del tamao del producto) y
determinan el esfuerzo que se requerir.
16
La opinin de los expertos
Se emplea la opinin de ms
de un experto para obtener
una mayor fiabilidad en la
estimacin. En algunos
casos, simplemente se
calcula la media de los
valores ofrecidos por las
distintas personas.
La tcnica ms utilizada es la Delphi, Bohem la refin en 1981 (Delphi de banda ancha)
Se basa en:
Experiencia
Objetividad
Del estimador
Estimacin por Analoga Constituye un complemento a la de juicio de expertos.
En esta la personas involucradas no slo trabajan con suexperiencia acumulada, sino que disponen tambin de datosde proyectos acabados relativamente similares al que hayque estimar. As por comparacin, se pueden evaluar lasdiferencias entre el nuevo proyecto y los antiguos yextrapolar su costo.
La ventaja de esta tcnica est en que es precisa si estdisponible la informacin del proyecto con el cul se va a
comparar.
La desventaja es que es imposible de comparar si elproyecto ha sido abordado. Trae consigo costos de
mantenimiento de la base de datos.
Estimacin por descomposicin
En esta tcnica el responsable de cada
componente del software que hay que construir
estima el costo de su desarrollo.
La estimacin para el proyecto completo se calcula
mediante la suma de las cantidades parciales
4.2.2.2. Modelos de estimacin
Modelos deEstimacin
ModelosAlgortmicos
ModelosEmpricos
Paramtricos
No paramtricos
MODELOS ALGORTMICOS
Son modelos que expresan la relacin entre elesfuerzo y los factores que lo influencian. Utilizanecuaciones donde el esfuerzo es la variabledependiente y varios factores como laexperiencia, tamao (que es el de mayorinfluencia) y tipo de sistema, son las variablesindependientes.
Estos modelos suelen basarse en el tamao delsoftware.
MODELOS EMPRICOS
Los Modelos empricos se dividen en:
Paramtricos. Los cuales tiene una formulafuncional explcita, relacionando una variable
dependiente con una o ms variables.
No paramtricos. No tiene una formula funcionalexplcita, por ejemplo, un modelo desarrollado usando
la tcnica de aprendizaje mquina como una red
neuronal.
17
MODELOS PARMETRICOS EMPRICOS
Los modelos de estimacin ms comunes son los
Modelos paramtricos empricos.
Utilizan frmulas derivadas empricamente para
predecir el esfuerzo como una funcin de LDC o PF.
Utilizan datos empricos obtenidos de una muestra de
proyectos:
Son difciles de usar para todas las clases de software y
todos los entornos de desarrollo
Se deben calibrar para las condiciones especficas de
una organizacin
MODELOS PARMETRICOS EMPRICOS
E = A + B X (ev) c
Donde:
A y B son constantes obtenidas empricamente
E esfuerzo en meses/persona
ev variable de estimacin (LDC o PF)
EL MODELO COCOMO(Constructive Cost Model)
COCOMO: Constructive Cost Model. Desarrollado en la dcada del 70 por Boehm. Revisado con una nueva
revisin en 1995.
Es una coleccin de tres modelos:
Bsico: aplicable cuando se conoce muy poco del proyecto
Intermedio: aplicable luego de la especificacin de requerimientos
Avanzado: aplicable cuando se termina el diseo.
EL MODELO COCOMO(Constructive Cost Model)
Todos utilizan la misma frmula:
E = aSbFA
Donde:
E: esfuerzo en personas mes
S: tamao medido en KLDC
FA: Factor de ajuste (igual a 1 en el modelo bsico)
a, b: s/tablas del modelo en funcin del tipo de sistema
EL MODELO COCOMO(Constructive Cost Model)
Por otro lado, COCOMO define tres modos de desarrollo o tipos de proyectos:
1. Orgnico. Proyectos relativamente sencillos, menores de 50KDLC,en los
cules se tiene experiencia de proyectos similares.
2. Semi-acoplado. Proyectos intermedios en complejidad y tamao (menores
de 300KDLC), donde la experiencia en este tipo de proyectos es variable.
3. Empotrado. Proyectos bastante complejos, en los que apenas se tiene
experiencia y se engloban en un entorno de gran innovacin tcnica.
Bsico Intermedio
Modo a b c d a b c d
Orgnico 2.4 1.05 2.5 0.38 3.2 1.05 2.5 0.38
Semi-acoplado 3.0 1.12 2.5 0.35 3.0 1.12 2.5 0.35
Empotrado 3.6 1.2 2.5 0.32 2.8 1.2 2.5 0.32
EL MODELO COCOMO(Constructive Cost Model)
Cuando se conoce un poco mas: el lenguaje, herramientas a
utilizar se puede aplicar COCOMO intermedio. Se eligen los
conductores de costos de una tabla que presenta 15.
La importancia de cada conductor de costo es clasificada en
una escala ordinal con seis puntos: Muy Baja, Baja, Media,
Alta, Muy Alta, Extra Alta.
A cada punto le corresponde un valor de factor de ajuste
Ejemplo: Si se estim la Capacidad de Anlisis como Muy Baja,
el factor es 1.46, quiere decir que se debe aumentar
el esfuerzo calculado previamente en un 46%.
18
MODELO BSICO
Modelo Orgnico, Semi Acoplado y Empotrado
Para determinar el esfuerzo del personal
E = aSbFA
Para determinar el tiempo de desarrollo
T=c Ed
MODELO INTERMEDIOEn este modelo se introducen 15 atributos de coste para
tener en cuenta el entorno de trabajo. Estos atributos se
utilizan para ajustar el coste nominal del proyecto al entorno
real, incrementando la precisin de la estimacin.
Para determinar el esfuerzo del personal: E = aSbFA
Para determinar el tiempo de desarrollo: T=c Ed
Para determinar la productividad: PR=LDC/E
Para calcular el Personal promedio: P=E/T
EL MODELO COCOMO II(Constructive Cost Model)
Es un modelo de estimacin de tiempo y de costo delsoftware de acuerdo con los ciclos de vida utilizados enlos 90 y en la primera dcada del 2000.
Desarrolla bases de datos con costos de software yherramientas de soporte para la mejora continua delmodelo.
Proporcionar un marco analtico cuantitativo y unconjunto de herramientas y tcnicas para la evaluacinde los efectos de la mejora tecnolgica del software encostes y tiempo del ciclo de vida software.
Modelos de COCOMO II
El modelo de Composicin de Aplicaciones.
Indicado para proyectos construidos con herramientas modernas
de construccin de interfaces grficos para usuario.
El modelo de Diseo anticipado.
Este modelo puede utilizarse para obtener estimaciones
aproximadas del costo de un proyecto antes de que est
determinada por completo su arquitectura. Utiliza un pequeo
conjunto de drivers de costo nuevo y nuevas ecuaciones de
estimacin. Est basado en Punto de Funcin sin ajustar o KSLOC
(Miles de Lneas de Cdigo Fuente).
El modelo Post-Arquitectura.
Este es el modelo COCOMO II ms detallado. Se utiliza una vez
que se ha desarrollado por completo la arquitectura del proyecto.
Tiene nuevos drivers de costo, nuevas reglas para el recuento de
lneas y nuevas ecuaciones.
Modelo de Putnam Modelo SLIM
Surge en 1978 como solucin a un requerimiento de la marina
de EEUU para proveer un mtodo para estimar esfuerzo y
tiempo. Fue desarrollado por Putnam y lo llam modelo SLIM.
Se utiliza para proyectos con mas de 70.000 LOC
Puede ser ajustado para proyectos mas pequeos
Asume que el esfuerzo para proyectos de desarrollo de
software es distribuido en forma similar a una coleccin de
curvas de Rayleigh, una para cada una de las actividades
principales del desarrollo.
Curvas de Rayleigh para el modelo SLIM
19
Modelo SLIMPutnam utiliza observaciones empricas sobre niveles de productividad para derivar su ecuacin de software a partir de la frmula bsica de la curva de Rayleigh
Donde:
Tamao: Medido en LOC
C : Factor tecnolgico que incluye 14 conductores de costos
y puede tomar hasta 20 valores distintos
K : Total del esfuerzo del proyecto calculado en personas
ao
Td : Tiempo transcurrido para la entrega, medido en aos. tdes el punto en el cual la curva alcanza un mximo.
4.2.2.3. Desarrollar o comprar?
En muchas ocasiones es ms aconsejable adquirir unproducto de software que desarrollarlo. Los gestores sonlos que tienen que tomar esta decisin y deben tener encuenta lo siguiente:
Comprar/alquilar el software ya desarrollado con licencia yque se ajuste a las especificaciones.
Comprar componentes de software parcial o totalmenteexperimentados y luego modificarlos para ajustarse con lasespecificaciones.
Encargar la construccin del software a una empresaexterna.
En cualquiera de las tres alternativas, un factorimportantsimo es la disponibilidad de recursos humanos,Tcnicos/hardware/ software.
4.2.2.4. Herramientas automticas de estimacin
Implementan tcnicas de descomposicin y modelos
empricos. Permiten al planificador estimar costos y esfuerzos,
as como llevar a cabo anlisis del tipo, que pasa si, con
importantes variables del proyecto, tales como la fecha de
entrega o la seleccin del personal.
Dependiendo de los datos, el modelo implementado por la
herramienta proporciona estimaciones del esfuerzo requerido
para llevar a cabo el proyecto, los costos, la carga de personal,
la duracin, y en algunos casos la planificacin temporal de
desarrollo y riesgos asociados.
Herramientas automticas de Estimacin
Qu datos necesitan:
Datos cuantitativos sobre el tamao del proyecto (LDC, PF)
Caractersticas cualitativas del proyecto.
Datos relacionados con el entorno y personal dedesarrollo.
En resumen el planificador del Proyecto de Software tiene queestimar tres cosas antes de que comience el proyecto: cuantodurara, cuanto esfuerzo requerir y cuanta gente necesitarpara su realizacin.
La estimacin del proyecto de software nunca ser unaciencia precisa, pero la combinacin de buenos datoshistricos y tcnicas puede mejorar la precisin de laestimacin.
4.2.3. Evaluacin del costo-beneficio
El anlisis econmico incluye lo que se llama, el anlisis o
evaluacin de costobeneficio, significa una valoracin de la
inversin econmica comparado con los beneficios que se
obtendrn en la comercializacin y utilidad del producto o
sistema.
El anlisis econmico sirve para :
Valorar la necesidad de la realizacin de un proyecto.
Seleccionar la alternativa ms beneficiosa para la
realizacin del proyecto.
Estimar adecuadamente los recursos econmicos
necesarios en el plazo de realizacin del proyecto.
Evaluacin del costo-beneficio
Algunos costos y beneficios pueden
cuantificarse fcilmente: ahorros en costos,
tales como una disminucin en costos de
operacin y aumentos en las utilidades directas.
Otros ejemplos de beneficios tangibles son :
Disminucin de errores
Incremento de rentabilidad
Reduccin de costos anteriores (fijos o
variables)
20
Evaluacin del costo-beneficio
Beneficios intangibles son aquellos que en elmomento del anlisis, no se pueden cuantificar y
con frecuencia estn relacionados a la calidad de
la informacin que proporciona el sistema, tales
como los listados a continuacin:
Satisfaccin en el servicio al cliente
En las actividades administrativas, mejora en la
toma de decisiones
4.2.3.1 Mtodos para el anlisis Costo / Beneficio
Diferentes mtodos pueden ser utilizados para calcular la
relacin costobeneficio. Los mtodos ms sofisticados
consideran el tiempovalor del dinero como parte del
anlisis costo beneficio.
Los mtodos comunes para el anlisis de costo beneficio
incluyen:
Punto de equilibrio
Periodo de devolucin
Valor presente neto
Tasa interna de retorno
Punto de equilibrio
Es el tiempo que tomara para que el total de los ingresosincrementados y/o la reduccin de gastos sea igual al costototal.
Es una de las formas ms sencillas de hacer el anlisis decosto beneficio.
La desventaja es que no toma en cuenta el valor del dineroen el tiempo.
Frmula:
PE = (Costo / Total de ingresos incrementados y/o reduccinde gastos) x 12 meses
Perodo de devolucinEs el tiempo requerido para recuperar el monto inicial deuna inversin de capital.
Evala el tiempo que se tomara para lograr un flujo decaja positivo igual a la inversin total. Toma en cuentabeneficios, tales como el valor asegurado.
Indica fundamentalmente la liquidez del esfuerzo pormejorar un proceso en vez de su rentabilidad. Al igualque el anlisis del punto de equilibrio, el anlisis delperiodo de devolucin no tiene en cuenta el valor deldinero en el tiempo.
Frmula:
PD = [(Costo Valor Asegurado) / Total de ingresosincrementados y/o reduccin de gastos] x 12 meses
Valor presente neto
El NVP representa el Valor Presente (PV) de los flujos salientesde caja menos la cantidad de la inversin inicial (I).
Simplemente NPV = PV I
El valor presente del flujo de caja futuro es calculadoutilizando el costo del capital como un factor de descuento.El propsito del factor de descuento es contar el Valor Futurodel dinero en Valor Presente (dlares futuros a dlarespresentes) y se expresa como 1 + la tasa de inters (i).
Frmula
PV = ((ingresos + Valor Asegurado) / Factor de descuento)
NPV = PV inversin (I)
Tasa interna de retorno La tasa interna de retorno es la tasa de inters que hace
la ecuacin de la inversin inicial (I) con el Valor presente(PV) de los futuros flujos de caja entrantes .
Cuando se calcula la TIR, el NPV se fija en cero y seresuelve para un inters (i). en este caso, el factor dedescuento es (1 + i) ya que no conocemos el intersverdadero, solamente conocemos el inters deseado.
Frmula
PV = ((ingresos + Valor Asegurado) / Factor dedescuento)
NPV = PV inversin (I)
21
Tasa interna de retorno
Datos Descripcin
-70.000 Costo inicial de un negocio
12.000 Ingresos netos del primer ao
1 15.000 Ingresos netos del segundo ao
2 18.000 Ingresos netos del tercer ao
3 21.000 Ingresos netos del cuarto ao
4 26.000 Ingresos netos del quinto ao
5 Frmula Descripcin (Resultado)
6 =TIR(A2:A6)Tasa interna de retorno de la inversin despus de cuatro aos (-2%)
7 =TIR(A2:A7)Tasa interna de retorno despus de cinco aos (9%)
4.3
ESTUDIO DE FACTIBILIDAD
4.3. Estudio de factibilidad El proceso de ingeniera de requerimientos comienza con
un estudio de viabilidad. Este es un estudio corto queayuda a resolver si un nuevo sistema de software es o nocandidato para desarrollarse de acuerdo a los recursos yrestricciones impuestas por al organizacin.
Llevar a cabo un estudio de factibilidad comprende laevaluacin y recoleccin de informacin y la redaccin deinformes.
ViablidadTcnica
ViabilidadEconmica
ViabilidadOperativa
4.3.1. Viabilidad Econmica
Es una evaluacin de costo beneficio del sistema que se
quiere desarrollar, para saber que tan efectivo resultar su
desarrollo, si contribuye o no a los objetivos del negocio, lo
que determinar si vale la pena o no la inversin econmica.
4.3.2. Viabilidad Tcnica
Es un estudio de funciones, rendimiento y
restricciones que puedan afectar la realizacin de un
sistema aceptable.
Las restricciones adems de presupuesto y tiempo
incluyen los recursos humanos, hardware y software.
Con este estudio se determina si con la tecnologa
existente se puede implementar el nuevo sistema, o si
hay que adquirir nueva tecnologa.
4.3.3. Viabilidad Operativa
Se trata de averiguar si el nuevo sistema es el
adecuado para la organizacin.
Tambin se debe establecer si el nuevo sistema es
flexible y puede integrarse a otros ya existentes en
la organizacin.
22
4.4
PLANIFICACIN DE LA DOCUMENTACIN
4.4. Planificacin de la documentacin
Para mantener informado al cliente acerca de los riesgos, de laplanificacin de tiempo y de la organizacin usualmente seprepara un documento llamado plan de proyecto.
El plan del proyecto de software se produce como culminacinde la etapa de planificacin. Es un documento breve, dirigido auna diversa audiencia y debe :
Comunicar el alcance y recursos a los gestores del Software,personal tcnico y clientes.
Definir los riesgos y sugerir planes de contingencia
Definir el costo y el plan temporal para la revisin de lagestin.
Proporcionar una aproximacin global del desarrollo delsoftware para todo el personal involucrado en el proyecto.
Describir cmo se garantizar la calidad y la gestin decambios.
4.5GESTIN DE LA CONFIGURACIN
DEL SOFTWARE
4.5.1. Planificacin de la GCS
4.5.2. El proceso de gestin de la configuracin del software
4.5 Gestin de la configuracin del software (GCS)
Los cambios durante el proceso de construccin
de un software:
Son inevitables
Provocan confusin e incertidumbre
Pueden ocurrir en cualquier momento
Estos cambios aumentan conforme avanza el
tiempo.
Que es la gestin de la configuracin
El arte de coordinar el desarrollo de software para
minimizarla confusin, se denomina gestin de la
configuracin. La gestin es el arte de identificar,
organizar y controlar las modificaciones que sufre
el softwarela meta es maximizar la productividad
minimizando errores.
Babich
4.5.1 Planificacin de la GCS La planificacin de la GCS empieza durante las primeras
fases del proyecto y debe definir el o los documentos quese controlarn. Aquellos documentos que puedanrequerirse para el futuro mantenimiento del software,debern ser identificados y especificados comodocumentos de control.
El plan de la GCS incluye:
La asignacin de responsabilidades
Las polticas de la GCS
La definicin de archivos de la GCS que deben ser
controladas.
La definicin de la base de datos
Puede incluir informacin de software externo, proceso
de auditora, etc.
23
4.5.2 El proceso de gestin de la configuracin del software
La GCS es un elemento importante de garanta de
calidad, ya que es responsable de controlar los
cambios.
El proceso se puede definir en cinco tareas de GCS:
1. Identificacin
2. Control de versiones
3. Control de cambios
4. Auditorias de configuracin
5. Generacin de informes