Pm u2

Planificaci贸n del Sistema M.C. Juan Carlos Olivares Rojas jcolivar@itmorelia.edu.mx

http://antares.itmorelia.edu.mx/~jcolivar/ juancarlosolivares@hotmail.com @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óricoPrá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.

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.

Planificación del tiempo

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

Planificación del tiempo

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

Planificación del tiempo

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

Planificación del tiempo

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

Planificación del tiempo

• 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

Planificación

GESTION DE PROYECTOS

PLANIFICACIÓ N

Planificación del tiempo (calendarización) Estimación de costos (esfuerzo)

•Propuesta •Planificación •Supervisión •Personal •Informal

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

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

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.

Planificación del Proyecto

• 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 planeaciรณn de su proyecto.

realicen

la

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

Planificación del Proyecto

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

T1

T2

T3

8

15

15 T1 (M1)

Dependencias

T4

T5

T6

T7

T8

T9

T10

T11

T12

10

10

5

20

25

15

15

7

10

T3, T6 (M4)

T5, T7 (M7)

T2,T4 (M2)

T1,T2 (M3)

T1 (M1)

T4 (M5)

T9 (M6)

T11 (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: (to + 4t m + t p ) te = 6 • 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.

Diagrama de Planeación

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

3

10

1 6

2

4

7

11

5

9 8

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.

Diagrama de Planeaciรณn

โ ข 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

Diagrama PERT

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

Programación GUI

Prueba de usabilidad

8

10

7 days

7 days

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

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

Revisión del diseño

Escribir manual de usuario

Entrenamiento de usuarios

12

10 days

5

14

15

Mon 2/1/99

Fri 2/12/99

Diseño GUI 6

14 days Prueba del sistema

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

1 day

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

7 days

5 days

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

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

Diseño Base de datos

Programación BD

Prueba de la BD

7

9

11

7 days

Thu 1/21/99

Fri 1/29/99

21 days

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

21 days

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

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.

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 2 3

Instalar LotusNotes para apoyar el desarrollo de un proyecto Instalar servidor

Instalar cliente local

Instalar cliente remoto

Diseñar BD

Programar BD

WBS

Administraci贸n de Proyectos

WBS

WBS

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.

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.

Herramientas Admon. Proyectos

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

Herramientas Admon. Proyectos

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

Herramientas Admon. Proyectos

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

lo

que

está

y

no

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

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

Métricas Orientadas al Tamaño

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

Métricas Orientadas al Tamaño

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.

Métricas Orientadas al Tamaño

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: Visión

Diagrama

Elemento básico

Funcional

Diagrama de FD Diccionario de datos Diagrama E/R Diagrama de Trans. Estados

Burbuja Dato elemental Objetos y Relac.

Estado y transiciones

Datos Estado

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

Nº

del

de

Costo Nº de $

proyect Person o

Nº de

Esfuerzo

error páginas de empleado es

Líneas de

documenta (días/hom código

as

ción

bre)

(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

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:

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

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

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

Factores de Ajuste

• C1 comunicación de datos

• C2 funciones distribuidas • C3 objetivos de performance • C4 configuración usada fuertemente • C5 tasa de transacciones

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

Escala de Ajuste

• 0 factor no presente o sin influencia • 1 influencia insignificante • 2 influencia moderada • 3 influencia promedio • 4 influencia significativa

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

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 128 29 30 96 185 61 90 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 complejidad.

de

back-up

de

poca

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

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.

Más Métricas

• Estructuras de Decisión

x x

x

Secuencia

Si x entonces...

Hacer ... hasta x

Mientras x hacer...

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

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

ELSE

Más Métricas

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 estándares para la medición estimación del software:

y y

• 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

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

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: c EE==AA ++BBXX (ev) (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:

E = aSbFA

COCOMO

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

Modo

Básico

a

Intermedio

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

Tabla COCOMO Modelo

COCOMO Bรกsico

COCOMO

COCOMO Intermedio

Modelo de desarrollo

Esfuerzo nominal (En) en personasmes

Tiempo de desarrollo (Td)

Esfuerzo nominal (En) en personasmes

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

Bรกsico/intermedio

COCOMO

â&#x20AC;˘ 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. â&#x20AC;˘ Si por ejemplo en la capacidad de anĂĄlisis se escoge el factor de 1.46, indica

Manejadores de Costo COCOMO Manejadores de Costo

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

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

-

Manejadores de Costo COCOMO

• 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

Manejadores de Costo COCOMO

• 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

Manejadores de Costo COCOMO

• 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

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.

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 PR=LDC/E

la

productividad:

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

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

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,

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

Estudio de viabilidad

Viablidad Viabilidad Viabilidad T茅cnica Econ贸micaOperativa

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 humanos (capacidades).

tecnológicos,

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

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

• Todos estos recursos implican costos.

al

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

Gestiรณn configuraciรณn software

โ ข 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 configuración software

• 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

Gestión configuración software

• 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

• 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

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

Nivel de Riesgo

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

Nivel Riesgode • Ladeforma

Gestión de Riesgos

estimar Impacto la frecuencia esFrecuencia si no se tiene valores

estadísticos es a través de manejar una tabla de valoración

Muy Alto entre

Alto las amenazas yAltolas vulnerabilidades basadas en la

misma Alto Alto Medio • El

los Medio

Medio

controles implementados.

Medio Medio

Alto

Medio Bajo

Bajo Alto de dinero aunque impacto se cuantifica en cuestión

Medio queda Bajo

Medio

Alto valor de las vulnerabilidades va Bajo a estar en respuesta a

Medio Medio • El

tabla anterior.Alto

Medio representado enBajo forma cualitativa.

Bajo

Bajo

Gestión de Riesgos

• Una vez obtenida el riesgo se puede cuantificar

Nivel de Riesgo

Impacto

Frecuencia

un % en relación al nivel cualitativo dado.

Muy Alto

Alto

Alto

Alto

Alto

Medio

Medio

Alto

Bajo

Medio

Medio

Medio

Medio

Medio

Bajo

Medio

Bajo

Alto

Por ejemplo: si se dan escalas de alto, medio y

bajo. Salió un riesgo estar entre el Medio alto deberá Alto

Alto

67% y 100%

• Al igual que otros recursos que se estiman como el tiempo, las actividades y elMedio dinero; los riesgos Bajo

Medio

tienen que ser re-estimados enBajo todo momento.

Bajo

Bajo

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.

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 Prog y equipo

Elaborar calendario

Calendario

No El calendario satisface las necesidades?

Si

Hacer sistema real

estimación

Comparación (base de casos)

Resumen de Planeación Necesidades del cliente

Definir requerimientos

Hacer diseño conceptual

Estimar el tamaño del producto

Base de datos histórica de tamaño

Cliente

Producto final

Estimar los recursos a utilizar

Base de datos histórica de productividad

Hacer el calendario de actividades

Recursos disponibles

Desarrollar el producto

Tamaño, recursos y calendario

Administración

Proceso de análisis

Reporte de seguimiento

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.

Dudas