Planificación del Sistema M.C. Juan Carlos Olivares Rojas [email protected] jcolivar/ [email protected]

Planificación del SistemaM.C. Juan Carlos Olivares Rojas

[email protected]://antares.itmorelia.edu.mx/~jcolivar/

[email protected]@jcolivares

Febrero 2010

mailto:[email protected]

http://antares.itmorelia.edu.mx/~jcolivar/

mailto:[email protected]

• Específica: Realiza la planificación de un proyecto de software de una organización

• Genéricas• Instrumentales: Capacidad de análisis y

síntesis, Capacidad de organizar y planificar, Conocimientos básicos de la carrera, Comunicación oral y escrita en su propia lengua, Habilidades de gestión de información, Solución de problemas, Toma de decisiones.

Competencias

• Interpersonales: Capacidad crítica y autocrítica, Capacidad de trabajar en equipo interdisciplinario, Capacidad de comunicarse con profesionales de otras áreas, Compromiso ético.

• Sistémicas: Habilidades de investigación, Capacidad de adaptarse a nuevas situaciones, Capacidad de generar nuevas ideas (creatividad), Liderazgo, Capacidad para diseñar y gestionar proyectos, Iniciativa y espíritu emprendedor, Preocupación por la calidad, Búsqueda del logro.

Competencias

• Planificación del tiempo.

• Evaluación del costo beneficio.

• Estudio de viabilidad.

• Planificación de la documentación.

• Gestión de la configuración del software.

Saberes

• 10% Actividades realizadas en el salón de clases evaluables

• 30% Contracto del Proyecto

• 60% Actividad de Evaluación Final (Teórico-Práctico)

Evidencias

• Para asegurar que un proyecto de software se realice de manera exitosa es necesario realizar la gestión del proyecto.

• La gestión de proyectos se compone como cualquier proceso administrativo de cuatro etapas claves: planeación, organización, control y dirección.

• Entre los recursos disponibles, el tiempo es la principal restricción de un sistema.

Planificación del tiempo

• Aunque la administración del tiempo sea prioritario en el desarrollo de proyectos de software, los recursos humanos y materiales deben ser gestionados de forma adecuada. Todos estos recursos implican el uso de recursos económicos.

• La planeación es el primer acercamiento a la construcción de soluciones. Típicamente se compone de tres fases: Estimación, Itinerario, Seguimiento.


• La estimación es la parte más difícil de la planeación dado que se tiene que definir

• Existen diferentes tipos de planeación en función al tiempo: operativa (táctica) y estratégica.

• ¿qué tipo de planeación se realiza cuando se desarrolla software?

• Planeación operativa.


• La planificación de proyectos de software es complicada por que es un producto intangible y no hay un “proceso” estándar definido.

• La planeación parte del pleno entendimiento de lo que es el problema.

• La planeación tiene como finalidad el logro de objetivos: en nuestro caso el desarrollo exitoso de productos de software.


• La planeación es un proceso que nos permite ver donde estamos, hacia donde queremos llegar y que se va a hacer para lograrlo (realización de un plan).

• La planeación es todo un arte. En metodologías ágiles como XP se le llama el “juego de la planeación” dado que una vez que se ha planeado es necesario replanear.

• La planeación no tiene un formato estándar.


• Un plan generalmente es un documento escrito que sirve de guía de desarrollo para cumplir las metas del proyecto.

• Es un proceso iterativo el cual termina hasta que el proyecto mismo haya terminado. Esto quiere decir que su revisión es continua, ya que tanto requerimientos como restricciones pueden cambiar a lo largo del desarrollo.


• El éxito o fracaso de un proyecto de software depende en gran parte de la planificación, ya que con ayuda de ésta se pueden evitar problemas como:

• Retraso de tiempo de entrega

• Sobrepasar el presupuesto • Baja calidad del producto

• Alto costo de mantenimiento, etc.


Planificación

GESTION DEPROYECTOS

•Propuesta•Planificación•Supervisión

•Personal•Informal

PLANIFICACIÓN


(calendarización)

Estimación de costos (esfuerzo)

Gestión de riesgos y control de calidad

Gestión de laconfiguración de

sw

• El proceso de gestión de proyectos consiste básicamente en:

Establecer las prioridades de un proyectoHacer la valoración inicial de las

actividades del proyectoDefinir los hitos del proyecto y productos a

entregarMientras el proyecto no se haya terminado

o cancelado repetirBosquejar la programación en el tiempo del

proyectoIniciar actividades conforme a la programación

Gestión de Proyectos

Esperar (por un momento)Revisar el progreso del proyectoRevisar los estimados de los parámetros del

proyectoActualizar la programación del proyectoRenegociar las restricciones del proyecto y los

productos a entregarSi surgen problemas entonces

Iniciar la revisión técnica

Fin si

Fin mientras


• Durante la recolección de requerimientos, se listan todos los elementos que se deben entregar del proyecto: actividades e hitos.

• Los hitos se convierten en la métrica fundamental que permite medir el grado de avance del proyecto. Más que los hitos son los “entregables del proyecto”. Un hito es un punto de control.


Planificación del Proyecto

• Ejemplo de una actividad de planeación: Instalar un Sistema de cómputo.

• ¿Qué se puede Observar?• Que es incorrecta

• ¿Por qué? Cada actividad realizada debe tener asignada un recurso humano responsable de hacerlo, recursos materiales (infraestructura) y financieros para llevarlo acabo.


• Reformulando la actividad: Instalar un sistema de control computarizado en el Departamento de Control Escolar de cada Escuela, Unidad o Centro para el 31 de diciembre de 2006, que no requiera más de 500 horas de trabajo de análisis de sistemas y operaciones con más de 10% de paro durante los tres primeros meses. El responsable de esta actividad es el Ing. Fernando Martínez


• En sus equipos de trabajo realicen la planeación de su proyecto.

Actividades

• Existen varias formas de representar una planeación:

• Pueden representarse como una lista de actividades priorizadas, como un programa de actividades, como un calendario de actividades, como una matriz de responsabilidades, etc.

• Lo importante es la especificación de las actividades a realizar así como los recursos utilizados y productos esperados.


• Generalmente se inicia con lo que se conoce como diagrama de planeación, el cual es otra técnica de organización en la cual nos centramos en cada tarea. También recibe el nombre de diagrama de actividades.

• En esta etapa se debe definir que actividades se pueden realizar sin depender de ninguna, que actividades para realizarse dependen de otras y finalmente que actividades pueden realizarse simultáneamente (en paralelo).


• Los diagramas de actividades se pueden resumir en una matriz de tiempos, en donde básicamente se debe indicar las tareas, la estimación de tiempo y las relaciones con otras tareas (entregables representados con las letras M).

Diagrama de Planeación

TareaT1 T2 T3

T4 T5 T6 T7 T8 T9 T10 T11 T12

Duración (días) 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)

• La matriz del tiempo debe contener al menos los siguientes campos: EDT/WBS (Código de la actividad), el nombre de la actividad y la duración en días.

• La duración del tiempo puede ser estimada o fija. Se considera que un tiempo es fijo aquel que no puede realizarse en menos tiempo o que tiene que realizarse en una fecha indicada.

Matriz de Tiempo

• El tiempo puede ser calculado en base a la siguiente fórmula:

• En donde:– te = Tiempo estimado– to = Tiempo optimista– tm = Tiempo promedio– tp = tiempo pesimista

• Esta matriz del tiempo puede ser expresada de mejor forma de forma gráfica y de manera conjunta con un diagrama de Gantt.

Matriz de Tiempo

6

)4( pmoe

tttt

• Al ser un grafo se pueden aplicar muchas técnicas para optimizar los proyectos.


1

2

3

4 5

6

8

7

9

10

11

12

Es el tiempo mínimo requerido para finalizar el

proyecto

• Se recomienda usarlos cuando son menos de 20 actividades y el tiempo es breve.

Diagrama de Gantt

• Los métodos de optimización de planeación como CPM (Método de la ruta crítica) y PERT (Program Evaluation and Review Technice) ayudan a encontrar las mejores alteranativas de soluciónde un proyecto.

• ¿Qué diferencias existente?• CPM es estático en PERT se toman

tiempos de inicio y fin optimistas y pesimistas.

Ruta Crítica

• Se deben considerar siempre la asignación de recursos humanos a las actividades.


Tarea Ingeniero

T1 Jane

T2 Anne

T3 Jane

T4 Fred

T5 Mary

T6 Anne

T7 Jim

T8 Fred

T9 Jane

T10 Anne

T11 Fred

T12 Fred

• El manejo de redes de actvidades con PERT permite utilizar mejores modelos matemáticos de estimación.

Diagrama PERT

Diseño GUI

6 14 days

Tue 11/24/98 Fri 12/11/98

Diseño Base de datos

7 21 days

Tue 11/24/98 Tue 12/22/98

ProgramaciónBD

9 21 days

Wed 12/23/98Wed 1/20/99

Prueba de usabilidad

10 7 days

Wed 12/23/98Thu 12/31/98

Prueba de la BD

11 7 days

Thu 1/21/99 Fri 1/29/99

Prueba del sistema

12 10 days

Mon 2/1/99 Fri 2/12/99

Escribir manual deusuario

14 7 days

Mon 12/14/98Tue 12/22/98

Entrenamientodeusuarios

15 5 days

Wed 12/23/98Tue 12/29/98

ProgramaciónGUI

8 7 days

Mon 12/14/98Tue 12/22/98

Revisión del diseño

5 1 day

Mon 11/23/98Mon 11/23/98

• Tarea: próximo viernes 19 de Febrero traer una laptop por equipo con un software de administración de proyectos como MS-Project, Mr. Project, WinProject, etc.

• Crear una cuenta en google calendar.

• Para ahorita determinar un diagrama de planeación y su matriz del tiempo incluyendo: actividad, dependencias, desgloce de tiempos estimados.

Actividad

• Se tiene bien definido las fechas de entrega y a partir de allí se realiza una planeación hacia atrás.

• El producto final se entregará el viernes 4 de junio. En caso de retraso hasta el miércoles 9 de junio se considerará nivelación, hasta el viernes 11 de junio se considerará extraordinario.

• Habrá un hito de revisión el viernes 7 de mayo.

Time Boxing

• El contrato ya negociado se entregará el viernes 5 de marzo por lo que el inicio formal del proyecto es el lunes 8 de marzo.

• El seguimiento del proyecto se reportará hasta el tercer parcial.

TimeBoxing

• Es una técnica de planeación en la cual se puede describir y cuantificar la cantidad de trabajo a realizar.

• Es una estructura tipo árbol en la cual se esquematizan y jerarquizan cada una de las actividades a realizar.

• Es muy parecido a un organigrama con la diferencia que aquí los nodos son tareas.

WBS

• Se debe cumplir la regla de que todas los nodos hijos de un padre la suma de sus ponderaciones dan 100% las actividades del padre.

• Las tareas de WBS llevan una numeración que indica su orden y anidamiento, muy parecido a un índice temático.

WBS

• Las ramas de cada árbol se les llama paquete y deben ser totalmente independientes de otros paquetes.

• Las actividades de mayor nivel (de preferencias todas) deben ser medibles para poder cuantificar el grado de avance.

• Las actividades deben presentar resultados tangibles.

WBS

• El trabajar con WBS hace fácil y comprensible las actividades de desarrollo así como la asignación de personal a las actividades del proyecto en base a un organigrama

WBS

Instalar LotusNotes para apoyar el desarrollo de un proyecto

Instalar servidor

Instalar cliente local

Instalar cliente remoto Diseñar BD Programar BD

1

2

3

WBS

Administración de Proyectos

WBS

WBS

• Existen muchas herramientas para la administración de proyectos que en esencia tienen las mismas carácterísticas básicas.

• La primera actividad consiste en determinar las fechas de inicio y fin del proyecto así como especificar opciones del calendario, como días y horas laborales, etc.

Herramientas Admon. Proyectos

• Se pueden tener varias vistas del proyecto, de manera predeterminada se pone el diagrama de Gantt.

• Para obtener el CPM se puede utilizar el Asistente para Diagrama de Gantt el cual permite especificar la ruta crítica.

• El avance se puede realizar con una curva del proyecto indicando objetivos cumplidos y en que tiempo.


• Cuando se inserta un recurso se asume que existe un 100% del recurso, es decir, existe un solo recurso para el proyecto.

• Para asignar recursos se puede utilizar el asistente o la hoja de recursos.

• Existen diversos tipos de costos: por uso (que dependen del tiempo) y fijos (que son constantes en la duración del proyecto).


• También se pueden considerar tasas estándar y tasas por hora extra.

• El project nos permite recalcular tiempos, asignación de recursos e hitos cuando ocurren cambios de manera muy similar a una hoja de cálculo.

• La fórmula mágica de la gestión de proyectos es: Trabajo = Duración * Unidades.


• Lo importante es llevar un control sobre el % de las actividades completadas y guiarnos con el tiempo.

• Se pueden realizar informes y reportes más llamativos del proyecto.


• Realizar el WBS del proyecto por equipo de trabajos. El WBS tendrá un anidamiento máximo de tres niveles (1.1.1)

• Se mostrará en forma de árbol o de glosario, para cada nodo hoja se hará la estimación del tiempo esperado y se definirá el entregable de cada paquete.

Actividad

• En todo proyecto que se desarrolle siempre es importante conocer si es realmente es costo-efectivo el desarrollo de software tanto a nivel de cliente como a nivel de desarrollo.

• Para poder evaluar un proyecto se necesita que esté terminado. Generalmente la evaluación se da antes de que comience el proyecto de allí la importancia que tiene la estimación en el desarrollo de software

Evaluación del costo beneficio

• El costo de los sistemas de información actualmente es del 90% por lo que una mala estimación puede originar que un proyecto se cancele, salga más costoso o requiera de más tiempo de desarrollo.

• Para poder estimar, se necesita medir. Para poder medir se necesita de un patrón de comparación denominado métrica. Las métricas del software son amplias y variadas.

Evaluación del costo beneficio

• Las métricas además de ayudarnos a medir nos sirve de base para la calidad.

• Las métricas son la base de la estimación.

Métricas del Software

• Cuando se recopila un solo aspecto de los datos se está hablando de medidas. Ejemplo: número de líneas de código o número de errores.


• Un ingeniero de software recopila medidas y desarrolla métricas para obtener indicadores.

• Un indicador: es una métrica o una combinación de métricas que proporcionan un visión profunda del proceso y proyecto del software o del producto en si mismo.

• Hay dos tipos de indicadores o métricas: Indicadores de proceso e indicadores del proyecto


• Brindan una visión profunda sobre la eficacia de un proceso ya existente.

• Permiten evaluar lo que está y no funcionando.

• Su propósito es mejorar los procesos de software a largo plazo y conducir a estrategias que permitan mejorar la calidad del proceso.

Indicadores del Proceso

• Son utilizadas para supervisar el progreso durante el desarrollo de software y controlar la calidad del producto, además se utilizan para realizar las estimaciones de tiempo y esfuerzo. Permiten al gestor de proyecto:

• Evaluar el estado del proyecto

• Seguir las pistas de los riesgos potenciales.

Indicadores del Proyecto

• Detectar las áreas de problemas para evitar áreas críticas

• Ajustar el flujo y las tareas del trabajo

• Evaluar la habilidad del equipo del proyecto para controlar la calidad del producto de software.

Indicadores del Proyecto

• Una métrica del software es la aplicación continua de técnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una información de gestión significativa y a tiempo. Esta información se utilizará para mejorar esos procesos y los productos que se obtienen de ellos.

• Las métricas aplican a todas las etapas del ciclo de vida del desarrollo de software.


• Las carácterísticas deseables para las métricas son:– Objetiva.– Sencilla, definible con precisión para que

pueda ser evaluada.– Fácilmente obtenible (a un coste razonable).– Válida, la métrica debería medir exactamente

lo que se quiere medir y no otra cosa.– Robusta. Debería de ser relativamente

insensible a cambios poco significativos en el proceso o en el producto.


• Las Métricas de producto pueden medir la complejidad del diseño, el tamaño del producto final (fuente u objeto) o el número de páginas de documentación producida.

• Las Métricas de proceso, son tiempo de desarrollo total, esfuerzo en días/hombre o meses/hombre de desarrollo del producto, tipo de metodología utilizada o nivel medio de experiencia de los programadores.


•Existen otras formas de clasificación por ejemplo basadas en propiedades objetivas y subjetivas:.

•Por ejemplo, el tamaño del producto medido en líneas de código (LOC) es una medida objetiva del producto, y una medida subjetiva sería el nivel de experiencia de un programador es una medida subjetiva.


• Las Líneas de Código (LOC) son la medida más utilizada para determinar la longitud del código fuente. La definición más común es la siguiente:

• Una línea de código es cualquier línea de un texto de un programa que no es un comentario o línea en blanco, sin tener en cuenta el número de instrucciones o parte de instrucciones en la línea. Esta medida se suele representar por NCLOC (No Comentary Lines of Code).

Métricas Orientadas al Tamaño

• Si queremos conocer la longitud real del programa esta sería:

LOC = NCLOC + CLOC

• donde CLOC es el número de líneas de comentarios

• Una medida indirecta de la densidad de comentarios sería:

CLOC / LOC


• ¿Es malo tener tantos comentarios?

• No. Se debe tener una buena documentación. Los comentarios deben de ser como notas taquigráficas.

• El problema es considerar los comentarios como métrica para estimar el desarrollo de software. Aunque una buena documentación sea en código o no tiene su costo.


Ventajas:• Que son fáciles de calcular en

cualquier proyecto

• Existen varias herramientas de estimación basadas en las líneas de código

Desventajas:• la falta de una definición universal

de línea de código.


Desventajas:• las líneas de código dependen de los

lenguajes de programación. • El estilo de programación dependerá

de cada persona. • El decidir que líneas de código se

contabilizaran ya sean nuevas, líneas modificadas, reutilizadas más definiciones de datos y comentarios.

• dificultad de estimar en fases tempranas del desarrollo la cantidad de líneas que tendrá una aplicación.


• Dada la siguiente aplicación determinar la cantidad de líneas de texto (total de los archivos) y la cantidad de LOCs. Distinguir las líneas de comentarios de los espacios en blanco.

• En base a las estimaciones anteriores calcular el nivel real de comentarios en el programa.

• ¿cuántas LOCs estiman en su proyecto?

Actividad

• Se pueden tener métricas enfocadas a mejorar la legibilidad del código fuente como número de variables declaradas que no se utilizan, si los nombres de los identificadores son representativos, si se sangra el código, etc.

• PUNTOS EXTRAS: TRES en el parcial. Herramienta gráfica que permita contabilizar LOCs, NCLOCs, CLOCs (separando comentarios de blancos). Para entregar mañana al final de la clase.

Otras métricas

• La métrica de LOC no toma en cuenta el concepto de reutilización ni el concepto de costes fijos ni tareas que se desarrollan que no producen instrucciones. Por ello, no debe ser utilizada esta medida directamente en la estimación de esfuerzo o productividad.

• Una mejor métrica para el tamaño de un software puede estar representado por medir la longitud en términos de número de bytes de almacenamiento requerido para contener el texto del programa.

Otras métricas

• Cuando se habla de otras partes del desarrollo del ciclo de vida del software también se pueden cuantificar su proyecto:

• Realizando un buen modelado los costos son calculados de mejor forma.

Otras métricas

Visión Diagrama Elemento básico

Funcional Diagrama de FD BurbujaDiccionario de datos Dato elemental

Datos Diagrama E/R Objetos y Relac.Estado Diagrama de Trans. Estados Estado y transiciones

• Como se pudo observar una métrica tan sencilla como los LOC (SLOC -Source LOC-) tiene su complejidad algo alta y una eficiencia no del todo buena. Considerese:

Otras métricas

Nombre

del

proyect

o

Nº

de

Person

as

Costo

$

Nº de

error

es

Nº de

páginas de

documenta

ción

Esfuerzo

empleado

(días/hom

bre)

Líneas

de

código

(LDC)

Proy1 15 20Mil 520 320 1200 3220

Proy2 10 17Mil 380 450 1000 2800

• Calcúlese para los dos proyectos:

• Productividad =LDC / persona mes• Costo Unitario = $ / LDC• Grado de errores = Nº de errores /

LDC• Grado de documentación = Nº de

páginas documentadas / LDC• NÓTESE: LAS MEDICIONES SON

DATOS HISTÓRICOS.

Otras métricas

• La tarea de determinar costos de un proyecto de software no es tan fácil como parece.

• En general el costo total de un software está determinado por dos indicadores clave:

• Esfuerzo para completar una actividad• Tiempo calendario se necesita para

completar una actividad.

Otras métricas

• Es un método para cuantificar el tamaño y la complejidad de un sistema software en términos de las funciones que el usuario desarrolla o desarrollará.

• Se entiende por funciones a las entradas, salidas, archivos, etc.

• La métrica por función mejor conocida es el punto de función aunque suelen manejarse muchas métricas como los Puntos de Caso de Uso y Objetos.

Mét. Orientadas a la Función

• Es una métrica sintética que se compone de la suma ponderada de los siguientes parámetros:

Puntos de Función

•Ejemplos de entradas: pantallas de datos llenadas por usuarios, cintas magnéticas, discos flexibles, entradas sensoriales, por lápiz magnético, clicsde ratón.

• Ejemplos de salidas: pantallas de datos de salidas, informes impresos, archivos en disco flexible, sets de cheques, facturas impresas.


•Ejemplos de archivos internos lógicos: Un archivos plano, una tabla de una base de datos relacional.

•Ejemplos de (archivos externos lógicos de) interfaz: bases de datos compartidas, archivos lógicos direccionables desde o hacia otra aplicación.

•Consultas externas: consulta de un usuario sin actualizar un archivo, mensajes de ayuda, mensajes de selección.


•Ejemplos de archivos internos lógicos: Un archivos plano, una tabla de una base de datos relacional.

•Ejemplos de (archivos externos lógicos de) interfaz: bases de datos compartidas, archivos lógicos direccionables desde o hacia otra aplicación.

•Consultas externas: consulta de un usuario sin actualizar un archivo, mensajes de ayuda, mensajes de selección.


• C1 comunicación de datos

• C2 funciones distribuidas

• C3 objetivos de performance

• C4 configuración usada fuertemente

• C5 tasa de transacciones

• C6 entrada de datos en línea

Factores de Ajuste

• C7 eficiencia del usuario final

• C8 actualización en línea

• C9 procesamiento complejo

• C10 reusabilidad• C11 facilidad de instalación• C12 facilidad operacional• C13 sitios múltiples• C14 facilidad del cambio

Factores de Ajuste

• 0 factor no presente o sin influencia

• 1 influencia insignificante

• 2 influencia moderada

• 3 influencia promedio• 4 influencia significativa• 5 influencia fuerte

Escala de Ajuste

•Comunicación de datos: La evaluación se reflejaría en un 0 para aplicaciones batch, y un 5 para aplicaciones en que predomina el teleproceso.

• Funciones distribuidas: La evaluación arrojaría un 0 para aplicaciones monolíticas puras, y un 5 para aplicaciones que se ejecutan dinámicamente en varios procesadores.

Escala de Ajuste

• Objetivos de performance: la evaluación sería un 0 si no hay establecido ningún 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.

•Configuración usada fuertemente: la evaluación sería un 0 si la aplicación no tiene restricciones especiales de uso, y un 5 si el uso anticipado requiere especial esfuerzo para ser logrado.

Escala de Ajuste

•Tasa de transacciones: la evaluación sería un 0 si el volumen de transacciones no es significativo, y un 5 si el volumen es lo suficientemente significativo como para producir stress en la aplicación.

• Entrada de datos en línea: la evaluación sería un 0 si menos del 15% de las transacciones son interactivas, y un 5 si más del 50% de las transacciones son interactivas.

Escala de Ajuste

•Eficiencia del usuario final: la evaluación sería un 0 si no hay 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 rígidos como para requerir un esfuerzo.

•Actualización en línea: la evaluación sería un 0 si no hay, y un 5 si las actualizaciones son obligatorias y especialmente difíciles, quizás debido a la necesidad de proteger datos.

Escala de Ajuste

• Procesamiento complejo: la evaluación sería un 0 si no hay, y un 5 en casos que requieren decisiones lógicas extensas, matemática compleja, o esquemas de seguridad elaborados.

• Reusabilidad: la evaluación sería un 0 si la funcionalidad se planifica para permanecer local a la aplicación actual, y un 5 si mucha de la funcionalidad y los artefactos del proyecto se pretende que sean usados ampliamente por otras aplicaciones.

Escala de Ajuste

• Facilidad de instalación: la evaluación sería un 0 si este factor es insignificante, y un 5 si la instalación es importante.

•Facilidad operacional: la evaluación sería un 0 si este factor es insignificante, y un 5 si la facilidad operacional es tan restrictiva.

• Sitios múltiples: la evaluación sería un 0 si hay solo un sitio planificado de uso, y un 5 si el proyecto y sus artefactos son usados en muchos lugares.

Escala de Ajuste

• Facilitamiento del cambio: la evaluación sería un 0 si el cambio no ocurre, y un 5 si la aplicación se desarrolla específicamente para permitir los cambios rápidos.

• Procedimiento para calcular el factor de ajuste:– Sumar las ponderaciones de los 14 criterios

(valor entre 0 y 70)– Multiplicar la suma por 0.01 para obtener un

valor temporal– Sumar 0.65 al valor temporal para obtener

eñll factor de complejidad (valor entre 0.65 y 1.35)

Escala de Ajuste

• Suponga una aplicación 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: C1, C2 y C10 = 0; C8 = 2; C4, C5 y C9 = 3; C3, C6, C7, C11, C12 y C14 = 4; C13 = 5

• El proyecto se considera de complejidad promedio

Ejemplo

• La suma de los factores de ajuste da 40. Por lo que el factor de complejidad da: 40 * 0.01 + 0.65 = 1.05

• Se calculan los puntos de función no ajustado (NAPF):

Ejemplo

• Finalmente se calcula los puntos de función ajustados: 147 * 1.05 = 154

• En muchas ocasiones los puntos de función necesitan ser expresados en KLOC o KSLOC. Esto depende del lenguaje de programación. Así si el programa fuera en C se requerirían 19.712 KLOC y si fuera C++ de 4.466 KLOC.

Ejemplo

Conversión de Líneas de Código

AdaBasic CompiladoBasic InterpretadoEnsambladorCC++Visual BasicCobol80Fortran77PrologPascalLispModula2

759012832012829309618561906180

• Utilizando puntos de Función, suponga una aplicación con 6 entradas, 15 salidas, 10 consultas, 2 archivo de datos y 2 archivo de interfaz, todos ellos de alta complejidad.

• Por otra parte suponga que los factores de influencia se determinaron de la siguiente manera: C1=1, C2=0, C3=4, C4=2, C5=2, C6=4, C7=4, C8=4, C9=5, C10=2, C11=0, C12=3, C13=4, C14=5.

Ejercicio

• Calcule, los puntos de Función, el factor de complejidad, los puntos de función ajustados y calcule el SLOC si fuese desarrollado en C++ y el KSLOC si fuese desarrollado en JAVA

Ejercicio

• Calcúlese las líneas de código necesarias para implementar una aplicación de control de clientes en lenguaje C estándar para una empresa de distribución que apoya su gestión en dos bases de datos:

• Datos de clientes de gran complejidad.

• Un archivo de back-up de poca complejidad.

Tarea

• Todo el trabajo se realiza mediante tres tipos de transacciones distintas para consultas, altas y bajas de datos. Todas estas operaciones tienen una complejidad alta. Para que el sistema de información esté bien integrado la aplicación deberá transferir dos archivos de complejidad media que contienen datos para otras aplicaciones (contabilidad y dirección por objetivos). Asimismo, el software debe generar hasta tres tipos distintos de informes, de complejidad media, sobre clientes.

Tarea

• Por último, las consultas trabajarán sobre dos posibles transacciones de complejidad baja y una consulta de ayuda, a plena pantalla, de gran complejidad. El desarrollo del proyecto se realizará en un entorno cuyos factores de costos serán todos de tipo medio excepto la entrada de datos on-line (valor 5), la actualización on-line (valor 5) y facilidad de operación (valor 5).

• Una vez calculadas las LDC necesarias en C, hallénse también las LDC necesarias para implementar la aplicación en Java y C++.

Tarea

• Existen otras métricas para determinar el tamaño y la complejidad del software.

• Por ejemplo SIZE1 muestra el número de líneas con “;” que para lenguajes que tienen este terminador de instrucciones funciona de buena forma.

• La métrica más exacta en cuanto al tamaño es la Complejidad Ciclomática

Más Métricas

• La Complejidad Ciclomática de McCabe (V(G)) evalua la complejidad del software en base a considerar el flujo de un programa como un grafo.

• V(G)= A – N + 2

• Donde A es el número de arcos y N el número de nodos del grafo.

• Se deben de tomar en cuenta las condicionales

Más Métricas

• Estructuras de DecisiónMás Métricas

x

x

x

Secuencia Si x entonces...Hacer ... hasta x

Mientras x hacer...

• Se pueden sacar como corolarios las siguientes fórmulas

• V(G) = r, donde r es el número de regiones cerradas del grafo

• V(G) = c + 1, donde c es el número de nodos de condición

• Entre más alto es V(G) mayor es la complejidad. Se recomienda que sea menor que 10.

Más Métricas

• ¿Cuál es el software Simple y cual el complejo?

Más Métricas

Abrir archivosLeer archivo ventasLimpiar línea de impresiónWHILE (haya registro ventas) DO Total nacional = 0; Total extranjero = 0; WHILE (haya reg. ventas) y (mismo

producto) if (nacional) then sumar venta nacional a total

nacional

Ejemplo

ELSE sumar venta extranjero a total

extranjero ENDIF Leer archivo de ventas ENDWHILE Escribir linea de listado Limpiar área de impresiónENDWHILE;Cerrar archivos

Más Métricas

Más Métricas

• NOC (Número de hijos) jerarquía de relaciones en POO.

• CBO (Acoplamiento de Objetos): número de asocianes con respecto a una clase

• Tarea: aplicar puntos de casos de uso al proyecto (leer articulo para ver las referencias de cómo hacerlo). Se necesita desarrollen diagramas de caso de uso.

Más Métricas

• Se tienen algunas metodologías y estándares para la medición y estimación del software:

• GQM (Goal Question Metric) consiste en plantearse una serie de objetivos donde por cada uno de ellos se realizan diversas preguntas que llevan a tener cada una de ellas diversas respuestas.

• PSM (Practical Software Measurament)

Más Métricas

• Es la predicción de los recurso necesarios para desarrollar un proyecto: capitual intelectual, tiempo, esfuerzo, costos, herramientas, etc.

• Existen diversas técnicas de estimación entre las que destacan:

• Opinión de expertos: se basa en la experiencia profesional de un grupo de expertos. La técnica delphi es la más apropiada.

Estimación

• Se recomienda que se consense con varios expertos.

• Analogía: se basa en la experiencia de proyectos anteriores por lo que es una mejor aproximación que la opinión de expertos.

• Descomposición: consiste en dividir el proyecto en pequeños subproyectos a fin de estimar de forma más exacta.

Estimación

• En general se a cuantificado en un 40% el conjunto de actividades que tipicamente no se colocan en una planeación:, leer código, revisar, reunirse, etc.

• Aproximadamente un 30% del tiempo de los programadores se dedican a actividades personales.

• Modelos matemáticos: generalmente basados en ecuaciones.

Estimación

• Los modelos matemáticos pueden ser generalmente algorítmicos y empíricos.

• Los modelos empíricos pueden ser parametrizados y no parametrizados.

• En general los modelos empíricos parametrizados tienen una ecuación de la siguiente forma:

Estimación

E = A + B X (ev) cE = A + B X (ev) c

• Donde • A y B: son constantes obtenidas

empíricamente• E: esfuerzo en meses/persona• ev: variable de estimación (LDC o PF)

• Existen muchos modelos matemáticos para estimar costos de proyectos de software: COCOMO, COSIMO, SLIM, etc. En este curso se describirá COCOMO II

Estimación

• Dado el siguiente código determinar:

• Número de Nodos y Aristas del Grafo• Representación gráfica del grafo• Determinación de la complejidad

ciclomática a través de las tres fórmulas.

Actividad

• ¿Qué no ha cambiado ni cambiará?

• El producto final se entregará el viernes 4 de junio. En caso de retraso hasta el miércoles 9 de junio se considerará nivelación, hasta el viernes 11 de junio se considerará extraordinario.

• Habrá un hito de revisión el viernes 7 de mayo.

Replaneación

• El contrato ya negociado se entregará el jueves 18 de marzo por lo que el inicio formal del proyecto es el lunes 22 de marzo.

• Examen de la segunda unidad viernes 19 de marzo.

• PENDIENTES: Estimación por Casos de Uso.

TimeBoxing

• Examen sobre COCOMO II ejercicio práctico mañana.

• Favor de leer y aclarar dudas antes de comenzar clases.

Tarea

• COnstructive Cost Model es un modelo algorítmico de estimación de costos de proyectos de software desarrollado en 1981 y actualizado en 1999.

• En su primera versión se basa en tres modelos: básico (nulo), intermedio (despues de Ing. De Requerimientos) y avanzado (cuando se termina el diseño). Los tres modelos tienen la misma fórmula base:

COCOMO

E = aSbFA

donde:– E: esfuerzo en personas mes– S: tamaño medido en KLDC– FA: Factor de ajuste (igual a 1 en el

modelo básico)– a, b: s/tablas del modelo en función del

tipo de sistema

• Adicionalmente se cuenta con tres tipos de proyectos:

COCOMO

• Orgánicos: proyectos pequeños de < 50KLDC, en los cuales se tiene experiencia de proyectos similares

• Semi-acoplado: proyectos de complejidad media (< 300 KLDC) donde la experiencia es variable.

• Empotrado: proyectos bastante complejos donde la experiencia es nula y se utiliza tecnología realmente de frontera.

COCOMO

• Se recomienda en general utilizar el modelo intermedio.

Tabla COCOMO Básico

Intermedio

Modo

a b c d a b c d

Orgánico 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

• Se puede representar de esta forma

Tabla COCOMOModelo COCOMO

BásicoCOCOMO

Básico/intermedioCOCOMO Intermedio

Modelo de desarrollo

Esfuerzo nominal (En) en personas-

mes

Tiempo de desarrollo (Td)

Esfuerzo nominal (En) en personas-

mes

Orgánico 2.4 KLOC1.05 2.5 KLOC0.38 3.2 KLOC1.05

Semi-libre 3.0 KLOC1.12 2.5 KLOC0.35 3.0 KLOC1.12

Empotrado 3.6 KLOC1.20 2.5 KLOC0.32 2.8 KLOC1.20

• Es necesario elegir los constructores de costos dentro de 15 factores. Es necesario ajustar dichos factores en una escala ordinal de 6 puntos: muy baja, baja, media, alta, muy alta y extremadamente alta.

• Si por ejemplo en la capacidad de análisis se escoge el factor de 1.46, indica que se debe aumentar el esfuerzo en 46%

COCOMO

Manejadores de Costo COCOMO

Manejadores de Costo Very Low Low Nominal HighVery

HighExtra

High

ACAP Analyst Capability 1.46 1.19 1.00 0.86 0.71 -

AEXP Applications Experience 1.29 1.13 1.00 0.91 0.82 -

CPLX Product Complexity 0.70 0.85 1.00 1.15 1.30 1.65

DATA Database Size - 0.94 1.00 1.08 1.16 -

LEXP Language Experience 1.14 1.07 1.00 0.95 - -

MODP Modern Programming Practices 1.24 1.10 1.00 0.91 0.82 -

PCAP Programmer Capability 1.42 1.17 1.00 0.86 0.70 -

RELY Required Software Reliability 0.75 0.88 1.00 1.15 1.40 -

SCED Required Development Schedule 1.23 1.08 1.00 1.04 1.10 -

STOR Main Storage Constraint - - 1.00 1.06 1.21 1.56

TIME Execution Time Constraint - - 1.00 1.11 1.30 1.66

TOOL Use of Software Tools 1.24 1.10 1.00 0.91 0.83 -

TURN Computer Turnaround Time - 0.87 1.00 1.07 1.15 -

VEXP Virtual Machine Experience 1.21 1.10 1.00 0.90 - -

VIRT Virtual Machine Volatility - 0.87 1.00 1.15 1.30 -

• Los manejadores de costo se clasiican en 4 categorías:

• Software– Fiabilidad– Tamaño de la base de datos– Complejidad del producto

• Hardware– Restricciones de tiempo de ejecución– Restricciones de almacenamiento principal


• Hardware– Volatilidad de Máquina Virtual– Tiempo de respuesta de la computadora

• Personal– Capacidad del analista– Experiencia en la aplicación– Capacidad de los programadores– Experiencia en el Sistema Operativo– Experiencia en el lenguaje de Programación


• Proyecto– Prácticas de Programación modernas– Utilización de herramientas de software– Limitaciones de planificación


• Es una variante del modelo tradicional que cuenta con otros modelos:

• El modelo de Composición de Aplicaciones.– Indicado para proyectos construidos con herramientas modernas de

construcción de interfaces gráficos para usuario.• El modelo de Diseño 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 pequeño conjunto de drivers de costo nuevo y nuevas ecuaciones de estimación. Está basado en Punto de Función sin ajustar o KSLOC (Miles de Líneas de Código Fuente).

• El modelo Post-Arquitectura.• Este es el modelo COCOMO II más 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 líneas y nuevas ecuaciones.

•

COCOMO II

• El modelo de Diseño 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 pequeño conjunto de drivers de costo nuevo y nuevas ecuaciones de estimación.

• El modelo Post-Arquitectura.– Este es el modelo COCOMO II más 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 líneas y nuevas ecuaciones.

COCOMO II

Comparativa COCOMO I y II

Comparativa COCOMO II

• En muchas ocasiones no solamente es necesario calcular el esfuerzo sino que tambien se requiere calcular el tiempo de desarrollo T=c Ed

• Para determinar la productividad: PR=LDC/E

• Para calcular el Personal promedio: P=E/T

• Nótese que para manejar este modelo se necesita de métricas de tamaño como LDC o bien Puntos de Función, etc.

COCOMO

• En base a la tarea de Puntos de función previa determine lo siguiente:

• Determine el costo del proyecto si el modelo es intermedio, el tipo de proyecto semiacoplado, los manejadores de costos todos nominales, asumiendo que el proyecto se realizará en COBOL con un costo nominal $90,000 persona/año.

Actividad 1

• En el mismo proyecto se desea saber quien tuvo mayor productividad para brindarle un aumento de sueldo.

• Cristhian implementó las entradas y salidas del sistema.

• Carreón implementó los archivos externos

• José Alfredo archivos externos y consultas.

Actividad 2

• Considerando los siguientes manejadores de costos, ¿cómo quedan las estimaciones de las métricas del proyecto?

• ACAP alto, CPLX bajo, DATA muy alto, STOR extremedamente alto, todo los demás de complejidad nominal.

Actividad 3

• ¿Qué cambios son necesarios hacer para que el proyecto se entregue en tres meses? ¿y si fuera un solo mes?

• Empezar a desarrollar su estimación de costos de su proyecto. Recordar que se aplicará Puntos de Casos de Uso para estimar la complejidad del software.

Actividad 4

• En muchas ocasiones es más aconsejable adquirir un producto de software que desarrollarlo. Los gestores son los que tienen que tomar esta decisión y deben tener en cuenta lo siguiente:

• Comprar/alquilar el software ya desarrollado con licencia y que se ajuste a las especificaciones.

Desarrollar o Comprar

• Comprar componentes de software parcial o totalmente experimentados y luego modificarlos para ajustarse con las especificaciones.

• Encargar la construcción del software a una empresa externa.

• En cualquiera de las tres alternativas, un factor importantísimo es la disponibilidad de recursos humanos, Técnicos/hardware/ software.

Desarrollar o Comprar

• El proceso de ingeniería de requerimientos comienza con un estudio de viabilidad.

• Este es un estudio corto que ayuda a resolver si un nuevo sistema de software es o no candidato para desarrollarse de acuerdo a los recursos y restricciones impuestas por al organización.

• Llevar a cabo un estudio de factibilidad

comprende la evaluación y recolección de información y la redacción de informes.

Estudio de viabilidad

Estudio de viabilidad

ViablidadTécnica

ViabilidadEconómica

ViabilidadOperativa

• En caminada en verificar si existe el suficiente recurso económico para llevar acabo el proyecto.

• Toma consideraciones como:– VPN (Valor Presente Neto)– TIR (Tasa Interna de Retorno)– TREMA (tasa mínima atractiva de retorno)– ROI (Retorno de Inversión)– Punto de Equilibrio– Estudio de Mercado– Estimación de Costos– Análisis de Sensibilidad

Viabilidad Económica

• En caminada los recursos tecnológicos, humanos (capacidades).

• Los recursos tecnológicos pueden estar dados con respecto al hardware y software.

• Los recursos humanos enfocados al conocimiento y dominio de las tecnologías.

• Todos estos recursos implican costos.

Viabilidad Técnica

• Enfocado a determinar si la organización a la cual va dirigido el desarrollo puede utilizar o no los sistemas.

• En muchas ocasiones los sistemas funcionan de manera adecuada pero no existe el apoyo ni la logística necesaria para que se puedan llevar acabo.

Viabilidad Operativa

• El plan del proyecto de software se produce como culminación de la etapa de planificación.

• El plan del proyecto de software es un documento breve, esta dirigido a una diversa audiencia y debe :– Comunicar el alcance y recursos a los

gestores del Software, personal técnico y clientes.

– Definir los riesgos y sugerir planes de contingencia

Planificación documentación

• Definir el costo y el plan temporal para la revisión de la gestión.

• Proporcionar una aproximación global del desarrollo del software para toda la gente involucrada en el proyecto.

• Describir cómo se garantizará la calidad y la gestión de cambios.

Planificación documentación

• Los cambios durante el proceso de construcción de un software:– Son inevitables– Provocan confusión e incertidumbre– Pueden ocurrir en cualquier momento

• Estos cambios aumentan conforme avanza el tiempo.

Gestión configuración software

• “El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores.” Babich [BAB86].


• La planificación de la GCS empieza durante las primeras fases del proyecto y debe definir el o los documentos que se controlarán. Aquellos documentos que puedan requerirse para el futuro mantenimiento del software, deberán ser identificados y especificados como documentos de control.


• El plan de la GCS incluye:

• La identificación de los ECS • La asignación de responsabilidades• Las políticas de la GCS • La definición de archivos de la GCS que

deben ser controladas. • La definición de la base de datos • Puede incluir información de software

externo, proceso de auditoría, etc.


• El proceso se puede definir en cinco tareas de GCS:

• Identificación• Control de versiones• Control de cambios• Auditorias de configuración• Generación de informes


• La administración de riesgos incluye la detección de riesgos y el control de los mismos.

• ¿Qué es el riesgo?• Es la probabilidad de que una actividad

no deseada ocurra.

• Todas las actividades tienen riesgo. No existe una actividad 100% ni 0% riesgosa.

Gestión de Riesgos

Gestión de Riesgos

• Una vulnerabilidad es un factor interno caracterizado por un hueco de seguridad (una debilidad del sistema) que puede ser aprovechada por una amenaza.

• Son factores externos que pueden aprovechar las vulnerabilidades de un sistema para exponer a un activo de información.

• Los controles tienden a minimizar las amenazas y vulnerabilidades.

Gestión de Riesgos

• Los riesgos se dan cuando se combina una amenaza con una vulnerabilidad.

• Los ataques son cuantificados al impacto que pueden producir, generalmente expresados en dinero.

• El impacto puede darse por ejemplo al no tener un recurso disponible causando pérdidas económicas al no poder trabajar o bien un daño de imagen social.

Gestión de Riesgos

Gestión de Riesgos

• Los riesgos son generalmnete calculados por el producto de la probabilidad de ocurrencia de la amenaza vs los impactos que tendría el activo de materializarse dicha amenaza.

• Los riesgos generalmente son calculados a nivel estadístico como el número de frecuencia en que ha ocurrido un evento contra el número total de eventos disponibles.

Gestión de Riesgos

• Existen muchas metodologías para calcular el riesgo. Todas ellas dependen de los usuarios dado que se estiman.

• Los riesgos se estiman en niveles generalmente: alto, medio y bajo. Aunque las escalas pueden variar.

• Lo más importante es tener un plan de contingencia.

Gestión de Riesgos

Gestión de Riesgos

Gestión de RiesgosNivel de Riesgo Impacto Frecuencia

Muy Alto Alto Alto

Alto Alto Medio

Alto Medio Alto

Medio Alto Bajo

Medio Medio Medio

Medio Medio Bajo

Medio Bajo Alto

Medio Bajo Medio

Bajo Bajo Bajo


Muy Alto Alto Alto

Alto Alto Medio

Alto Medio Alto

Medio Alto Bajo

Medio Medio Medio

Medio Medio Bajo

Medio Bajo Alto

Medio Bajo Medio

Bajo Bajo Bajo

• La forma de estimar la frecuencia es si no se tiene valores estadísticos es a través de manejar una tabla de valoración entre las amenazas y las vulnerabilidades basadas en la misma tabla anterior.

• El valor de las vulnerabilidades va a estar en respuesta a los controles implementados.

• El impacto se cuantifica en cuestión de dinero aunque queda representado en forma cualitativa.


Muy Alto Alto Alto

Alto Alto Medio

Alto Medio Alto

Medio Alto Bajo

Medio Medio Medio

Medio Medio Bajo

Medio Bajo Alto

Medio Bajo Medio

Bajo Bajo Bajo

• Una vez obtenida el riesgo se puede cuantificar un % en relación al nivel cualitativo dado. Por ejemplo: si se dan escalas de alto, medio y bajo. Salió un riesgo alto deberá estar entre el 67% y 100%

• Al igual que otros recursos que se estiman como el tiempo, las actividades y el dinero; los riesgos tienen que ser re-estimados en todo momento.

• La fase de contratos es una actividad indispensable en el desarrollo de cualquier tipo de proyecto.

• En la fase de contratos se realiza un compromiso por escrito de las actividades a desarrollar así como de los productos a entregar.

• Se debe de indicar tanto penalizaciones así como bonificaciones en caso de existir.

Negociación de Contratos

• De acuerdo con Humprey se tiene el siguiente ciclo de vida en la planeación de proyectos de software:

Resumen de Planeación

Requerim.iniciales

Negociarcompromisos

Estimartamaño

Estimarrecursos

Elaborarcalendario

El calendariosatisface las

necesidades?

Hacersistema

Comparación(base de casos)

Detallarrequerim.

No

Si

WBS

NLC

Prog yequipo

Calendario

real

estimación

Resumen de Planeación

Definirrequerimientos

Hacer diseñoconceptual

Estimar el tamañodel producto

Estimar los recursos a utilizar

Hacer el calendariode actividades

Desarrollarel producto

Base de datoshistórica de tamaño

Base de datoshistórica de productividad

Recursosdisponibles

Tamaño, recursos y calendario

Proceso deanálisis

Reporte deseguimiento

Necesidadesdel cliente

Productofinal

Cliente

Administración

• (ITM 2007) Material de Libro de Texto de la materia de Planificación y Modelado, Instituto Tecnológico de Morelia.

• (Sánchez, M. 2009) Material del Curso de Planificación y Modelado.

Referencias

Dudas

Documents

Planificación del Sistema M.C. Juan Carlos Olivares Rojas [email protected] jcolivar/ [email protected]