-
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
