Planificación del Sistema

Planificación del Sistema
M.C. Juan Carlos Olivares Rojas @jcolivares Febrero 2010

Competencias 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.

Saberes 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.

Evidencias 10% Actividades realizadas en el salón de clases evaluables
30% Contracto del Proyecto 60% Actividad de Evaluación Final (Teórico-Práctico)

Planificación del tiempo
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.

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 Planificación del tiempo (calendarización) GESTION DE
PROYECTOS Propuesta Planificación Supervisión Personal Informal PLANIFICACIÓN Estimación de costos (esfuerzo) Gestión de riesgos y control de calidad Gestión de la configuración de sw

Gestión de Proyectos El proceso de gestión de proyectos consiste básicamente en: Establecer las prioridades de un proyecto Hacer la valoración inicial de las actividades del proyecto Definir los hitos del proyecto y productos a entregar Mientras el proyecto no se haya terminado o cancelado repetir Bosquejar la programación en el tiempo del proyecto Iniciar actividades conforme a la programación

Gestión de Proyectos Fin mientras Esperar (por un momento)
Revisar el progreso del proyecto Revisar los estimados de los parámetros del proyecto Actualizar la programación del proyecto Renegociar las restricciones del proyecto y los productos a entregar Si surgen problemas entonces Iniciar la revisión técnica Fin si Fin mientras

Gestión de Proyectos 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

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

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).

Diagrama de Planeación
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). Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duración (días) 8 15 10 5 20 25 7 Dependencias (M1) T2,T4 (M2) T1,T2 (M3) (M5) T3, T6 (M4) T5, T7 (M7) (M6) (M8)

Matriz de Tiempo 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.

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

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

Ruta Crítica 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.

Se deben considerar siempre la asignación de recursos humanos a las actividades. Tarea Ingeniero T1 Jane T2 Anne T3 T4 Fred T5 Mary T6 T7 Jim T8 T9 T10 T11 T12

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

Actividad 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.

Time Boxing 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.

TimeBoxing 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.

WBS 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.

Instalar LotusNotes para apoyar el desarrollo de un proyecto
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 1 Instalar LotusNotes para apoyar el desarrollo de un proyecto Instalar servidor Instalar cliente local Instalar cliente remoto 2 Diseñar BD Programar BD 3

Administración de Proyectos

Herramientas Admon. Proyectos
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.

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.

Actividad 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.

Evaluación del costo beneficio
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.

Métricas del Software 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.

Métricas del Software 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

Indicadores del Proceso
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 Proyecto
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.

Métricas del Software 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.

Métricas del 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.

Métricas del Software • 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.

Métricas del Software 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.

Métricas Orientadas al Tamaño
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).

• 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.

Actividad 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?

Otras métricas 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. Visión Diagrama Elemento básico Funcional Diagrama de FD Burbuja Diccionario de datos Dato elemental Datos Diagrama E/R Objetos y Relac. Estado Diagrama de Trans. Estados Estado y transiciones

Otras métricas 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: Nombre del proyecto Nº de Personas Costo $ Nº de errores Nº de páginas de documentación Esfuerzo empleado (días/hombre) Líneas de código (LDC) Proy1 15 20Mil 520 320 1200 3220 Proy2 10 17Mil 380 450 1000 2800

Otras métricas 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.

Mét. Orientadas a la Función
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.

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

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.

Factores de Ajuste 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

Escala 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)

Ejemplo • 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 * = 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 KLOC y si fuera C++ de KLOC.

Conversión de Líneas de Código
Ada Basic Compilado Basic Interpretado Ensamblador C C++ Visual Basic Cobol80 Fortran77 Prolog Pascal Lisp Modula2 75 90 128 320 29 30 96 185 61 80

Ejercicio 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

Tarea 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++.

Más Métricas 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ón x x x Hacer ... hasta x
Mientras x hacer... Secuencia Si x entonces...

Más Métricas 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?

Ejemplo Abrir archivos Leer archivo ventas Limpiar línea de impresión WHILE (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

Más Métricas ELSE sumar venta extranjero a total extranjero ENDIF Leer archivo de ventas ENDWHILE Escribir linea de listado Limpiar área de impresión ENDWHILE; 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)

Estimación 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: E = A + B X (ev) c

Estimación 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

Actividad 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.

Replaneación ¿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.

TimeBoxing 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.

Tarea Examen sobre COCOMO II ejercicio práctico mañana.
Favor de leer y aclarar dudas antes de comenzar clases.

COCOMO 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 Adicionalmente se cuenta con tres tipos de proyectos: 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.

Tabla COCOMO Se recomienda en general utilizar el modelo intermedio.
Básico Intermedio Modo a b c d Orgánico 2.4 1.05 2.5 0.38 3.2 Semi-acoplado 3.0 1.12 0.35 Empotrado 3.6 1.2 0.32 2.8

Esfuerzo nominal (En) en personas-mes Tiempo de desarrollo (Td)
Tabla COCOMO Se puede representar de esta forma Modelo COCOMO Básico COCOMO Básico/intermedio COCOMO Intermedio Modelo de desarrollo Esfuerzo nominal (En) en personas-mes Tiempo de desarrollo (Td) Orgánico 2.4 KLOC1.05 2.5 KLOC0.38 3.2 KLOC1.05 Semi-libre 3.0 KLOC1.12 2.5 KLOC0.35 Empotrado 3.6 KLOC1.20 2.5 KLOC0.32 2.8 KLOC1.20

COCOMO 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%

Manejadores de Costo COCOMO
Very Low Low Nominal High Very High Extra High ACAP Analyst Capability 1.46 1.19 1.00 0.86 0.71 - AEXP Applications Experience 1.29 1.13 0.91 0.82 CPLX Product Complexity 0.70 0.85 1.15 1.30 1.65 DATA Database Size 0.94 1.08 1.16 LEXP Language Experience 1.14 1.07 0.95 MODP Modern Programming Practices 1.24 1.10 PCAP Programmer Capability 1.42 1.17 RELY Required Software Reliability 0.75 0.88 1.40 SCED Required Development Schedule 1.23 1.04 STOR Main Storage Constraint 1.06 1.21 1.56 TIME Execution Time Constraint 1.11 1.66 TOOL Use of Software Tools 0.83 TURN Computer Turnaround Time 0.87 VEXP Virtual Machine Experience 0.90 VIRT Virtual Machine Volatility

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

COCOMO II 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. El modelo Post-Arquitectura.
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.

Comparativa COCOMO I y II

Comparativa COCOMO II

COCOMO 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.

Actividad 1 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 2 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 3 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 4 ¿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.

Desarrollar o Comprar 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.

Estudio de viabilidad 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 Viablidad Técnica Viabilidad Económica Operativa

Viabilidad Económica 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 Técnica 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 Operativa 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.

Planificación documentación
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.

Gestión configuración software
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 de riesgos

“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]. Gestión de riesgos

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. Gestión de riesgos

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. Gestión de riesgos

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 Gestión de riesgos

Gestión de Riesgos 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 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

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

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 Nivel de Riesgo Impacto Frecuencia Muy Alto Alto
Medio Bajo Gestión de riesgos

Gestión de Riesgos 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. Nivel de Riesgo Impacto Frecuencia Muy Alto Alto Medio Bajo Gestión de riesgos

Gestión de Riesgos 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. Nivel de Riesgo Impacto Frecuencia Muy Alto Alto Medio Bajo Gestión de riesgos

Negociación de Contratos
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. Gestión de riesgos

Resumen de Planeación De acuerdo con Humprey se tiene el siguiente ciclo de vida en la planeación de proyectos de software: Requerim. iniciales Negociar compromisos Detallar requerim. WBS Estimar tamaño NLC Estimar recursos Gestión de riesgos Prog y equipo Elaborar calendario No Calendario El calendario satisface las necesidades? Si Hacer sistema real Comparación (base de casos) estimación

histórica de productividad
Resumen de Planeación Definir requerimientos Hacer diseño conceptual Estimar el tamaño del producto Estimar los recursos a utilizar Hacer el calendario de actividades Desarrollar el producto Base de datos histórica de tamaño histórica de productividad Recursos disponibles Tamaño, recursos y calendario Proceso de análisis Reporte de seguimiento Necesidades del cliente Producto final Cliente Administración Gestión de riesgos

Referencias (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.

Planificación del Sistema

Presentaciones similares

Presentación del tema: "Planificación del Sistema"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Planificación del Sistema

Presentaciones similares

Presentación del tema: "Planificación del Sistema"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback