Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Ingeniería del Software: 
 Rango de actividades que antes se conocía como análisis de sistemas y programación. 
 Es el p...
 ¿Por qué cuesta tanto? 
 ¿Por qué quedan errores sin localizar? 
El Software 
Características 
 Se desarrolla, no se f...
Tiempo: indicador de que el software está bien desarrollado en el mantenimiento del software. 
Basándose en la calidad 
 ...
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 16 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (19)

Ähnlich wie titulo de pdf (20)

Anzeige

Aktuellste (20)

titulo de pdf

  1. 1. Ingeniería del Software:  Rango de actividades que antes se conocía como análisis de sistemas y programación.  Es el producto y el proceso, es decir el software como producto.  Serie de Actividades para la realización de tareas y resolver el problema del software  Tecnología usada para crear productos de alta calidad. Se controla el proceso del desarrollo.  Enfoque disciplinado sistemático y cuantificable hacia el desarrollo, operación y mantenimiento del software.  Disciplina desarrollada con la producción y mantenimiento de productos de software desarrollado en el tiempo preciso y dentro del tiempo estimado. ¿Por qué la ingeniería de software? Por errores costosos por fallas en el software como problemas para estimar tiempo, esfuerzo y costos de los sistemas. Importancia de la ingeniería de software Es muy importante ya que con ella se puede analizar, diseñar, programar y aplicar un software de manera correcta y organizada, cumpliendo con todas las especificaciones del cliente y el usuario final. Lo anterior es posible gracias a los objetivos que esta propone Historia Ingeniería de software.  1959-1965 Orientación por lote, Distribución limitada y Software a medida  1965-1975 Multiusuario, Tiempo Real, Base de Datos, Software como producto, Mayor gasto de mantenimiento  1975-1989 Sistemas distribuidos, Inteligencia Artificial, Hardware bajo coste, impacto con el consumo, gran demanda.  Primera década: Hardware más importante, Reducir coste de procesamiento y almacenamiento.  Actualmente: Mejorar la calidad de las soluciones, Realizar aplicaciones en el menor tiempo. Ingeniería del software como producto: Software, programas, archivos de configuración, documentos de la estructura del sistema, manuales de instalación y uso, sitio web con información y actualización. Tipos de software:  Producto genérico: sistema producido por una organización y para vender en mercado abierto; en este caso la organización controla las especificaciones. Ejemplo: sistema de gestión de BD, procesadores de texto, paquetes gráficos.  Producto personalizado: desarrollado específicamente para un cliente, en este caso el cliente controla las especificaciones. Ejemplo: aplicaciones de negocio, sistema de control de fabricación. Evolución de la ingeniería de software  Herramienta y producto  Cambio marcado de rol en las últimas décadas  El valor del software de “elemento añadido” a principal elemento de costo.  La importancia sube ya que las necesidades cambian.  Desarrollo individual a grupal. Si el desarrollo ahora es grupal  ¿Por qué se tarda tanto?  ¿Por qué la productividad es tan baja? Análisis Diseño Implementación Pruebas Mantenimiento
  2. 2.  ¿Por qué cuesta tanto?  ¿Por qué quedan errores sin localizar? El Software Características  Se desarrolla, no se fabrica.  No se estropea  Construcción a la medida Problemas que aparecen en el desarrollo del software al desarrollar, mantener y atender la demanda de nuevas aplicaciones:  Planificación y estimaciones imprecisas  Sin tiempo para recoger datos históricos  Baja productividad  Calidad  Insatisfacción del cliente  Dificultad de mantener el software existente. Aplicaciones del software  Contenido de la información que se maneja.  Determinismo, predecibilidad del orden y tiempo de llegada de los datos. Potencialidades aplicaciones del software  Software de sistemas sirven a otros programas  De tiempo real  De gestión (Comercial, Nomina, BD)  Empotrado (memoria solo lectura)  De computadora personal  Basado en web, red, PC de capacidad ilimitada  IA, algoritmos no numéricos, resolución de problemas complejos. Proceso:  Marco de trabajo que permite la realización de tareas para el desarrollo de software de alta calidad.  Conjunto de actualidades que contiene tareas, hilos, entregas. Aplicando actividades de protección.  Conjunto ordenado de tareas, una serie de pasos que involucran actividades restricciones y recursos que producen una salida determinada.  Ingeniería de software como una visión de solución de problema, se encarga del desarrollo de proyecto tomando en consideración tres etapas: ¿Qué?, ¿Cómo? y cambio. o ¿Qué?: Definición, Ingeniería de Software + Planificación + Análisis de requisitos. o ¿Cómo?: Desarrollo, Diseño + codificación+ Pruebas o Cambio: Mito, Corrección-Mejoras. Características del proceso:  Serie de actividades principales  Utiliza recursos, está sujeto a restricciones y genera producto internos y finales  Compuesto por sub-procesos que se encadenan de alguna forma  Cada actividad tiene sus criterios de Entrada y Salida que permiten conocer cuando comienza y termina la actividad.  Cuando implica construcción. Aspectos de Producción: comprenden procesos técnicos del desarrollo como la administración de proyecto, desarrollo de herramientas, métodos y teorías.
  3. 3. Tiempo: indicador de que el software está bien desarrollado en el mantenimiento del software. Basándose en la calidad  Métodos completos en todas las fases  Herramientas para automatizar los métodos.  Mejores elementos de programación  Filosofía de coordinación y gestión de proceso. Actividades de Protección (son especificaciones del proyecto)  Seguimiento y control  Gestión de riesgo  Documentación  Garantía de Calidad  Reutilización  Medición  Configuración Actividades estructurales: son las del esquema se pueden aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad, además permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Objetivo del proceso:  Mejorar calidad-proyectos  Fechas y costos predecibles-guiar Actividad o fase de desarrollo Conjunto de tareas que se realiza con un propósito específico (obtención de requisitos, entrega, administración), puede componerse de otras. Tarea: Unidad elemental del trabajo que puede ser administrada, consume recursos, dan como resultado producto de trabajo y depende de productos de trabajo producido por otras tareas. Tareas cuando se desarrolla software  Formular el problema  Analizar el problema  Buscar soluciones  Decidir la solución mas adecuada  Especificar Solución Recursos: Bienes que se utilizaran para realizar el trabajo (tiempo, equipamiento y recurso humano). Actividades Básicas del desarrollo  Obtención de los requerimientos  Análisis  Diseño del sistema  Implementación Otras Actividades  Revisiones del análisis  Revisiones del diseño  Pruebas
  4. 4.  Administración del proyecto. Niveles de madurez de un producto. Modelo de capacidad asociada al conjunto de tareas realizadas.  Nivel 1 (inicial): proceso según caso a resolver, puede ser caótico, pocos procesos definidos, éxito individual.  Nivel 2 (repetible): gestión de proyecto según costo, planificación y funcional.  Nivel 3(definido): gestión e ingeniería documentada, integrado ha organizado, estándares aprobados y documentados que rigen todos los proyectos.  Nivel 4 (gestionado): se recogen medidas del proceso y la calidad, se usan para comprender y controlar.  Nivel 5 (Optimización): se retroalimenta cuantitativamente el proceso, nuevas tecnologías e ideas. Niveles de madurez integrados 1. Incompleto: el proceso no se realiza o no se ejecuta el objetivo. 2. Ejecutado: el proceso se ejecuta y el objetivo se logra 3. Gestionado 4. Definido 5. Cuantitativamente gestionado 6. Optimizado. Calidad (existen dos tipos de calidad)  Externo (clúster): corrección, robustez, modificabilidad, reusabilidad, compatibilidad, eficiencia, portabilidad, verificabilidad, integralidad, facilidades de uso.  Interno: modularidad y legalidad. PLAN  Se realiza el plan y se genera el programa que contiene tareas y tiempos realistas  El proceso de las actividades deben ser monitoreadas  Se pueden utilizar herramientas y técnicas usadas en otras disciplinas Ciclo de vida del desarrollo de software: es una estructura aplicada al desarrollo de un producto de software Modelos de Proceso  Modelo de desarrollo Ad-hoc: desarrollo de sistemas de forma caótica o fortuita dependiendo enteramente de habilidades y experticias de los que realizan el trabajo. Características:  El proceso es impredecible, cambiado o modificado con el trabajo.  Programas, presupuesto, funcionalidad y calidad del producto.  Seguir teniendo resultados depende en contar con el mismo grupo de trabajo.  Modelo en Cascada: es de los más antiguos y utilizados. Conceptualiza el sistema, análisis del sistema, diseño del sistema, codificación, prueba, mito. Características:  El diseño es rígido  Dificultad de establecer requisitos concretos al comienzo.  Puede ser largo y tedioso el desarrollo  Raramente siguen la secuencia del modelo  Una fase comienza cuando la anterior termina  Si hay errores en los requerimientos, eleva el costo  Se rebaza la localización y corrección de errores. Modelos Iterativos  Modelo incremental: es dividido en partes más pequeñas, los resultados se ven temprano y se obtiene valiosa retroalimentación del usuario. Características:
  5. 5.  Cada iteración es un mini proceso en cascada  El producto obtenido al final de cada iteración puede ser puesto en producción inmediatamente  Los usuarios tienen que estar activamente involucrados durante todo el desarrollo del proyecto.  Requerimientos informales para mejoras después de cada fase, puede generar confusión.  Modelo DRA: desarrollo rápido de aplicaciones, adaptación de alta velocidad del modelo en cascada. Basado en componentes, conociendo requisitos, los ciclos son de 6+0a 90 días. Características:  Modular  Cada función es atacada por un equipo DRA  Proyectos grandes necesitan mucha gente  Riesgos técnicos no apropiados.  Modelo Prototipos: permite un desarrollo que obtiene algunos resultados sin requerir toda la información desde el inicio. Características:  El desarrollador presenta una versión simplificada  El cliente proporciona feedback para refinar el sistema.  A veces el prototipo es desechado para construir otro. Pasos:  Definición y análisis  Creación del prototipo  Evalúa el cliente  Refinamiento del prototipo  Diseño  Implementación  Modelo exploratorio: se utiliza cuando no se identifican los requerimientos. Se usa en áreas como IA, a que la investigación es basada en estimaciones. Características:  El sistema se desarrolla según como se cree que debe funcionar.  No hay especificaciones precisas  La validación está basada en adecuaciones de los resultados y no en concordancia con preconcebidos procedimientos. Pasos  Especificaciones iniciales  Construcción o modificación  Prueba  Implementación. Problemas: limitada para usar con leguaje de alto nivel, pobre diseño difícil de predecir su costo- efectividad. NOTA: EL MODELO QUE SE VA A ESCOGER DEPENDE DEL FACTOR TIEMPO QUE EL CLIENTE DE COMO REQUERIMIENTO.  Modelo espiral: utiliza lo mejor de cascada y prototipo añadiendo un nuevo componente valoración de riesgo. Características:  Se desarrolla como una versión inicial y es repetidamente revisada por el cliente.  A medida que avanza se va obteniendo versiones mejoradas. Proceso: BUSCARLO  Modelo de desarrollo concurrente: actividades del marco de trabajo con un estado de desarrollo asociado. Funciona para cualquier modelo evolutivo.  Modelo de Rehúso: fue concebido bajo la premisa de que un sistema debe ser construido utilizando componentes existentes. Características
  6. 6.  Se tienen librerías de módulos de programas  Si no existe algún modulo el desarrollador lo construye y lo guarda como una librería. Actividades:  Definición de requerimientos  Definición de objetos  Colección de objetos  Creación de objetos del usuario  Ensamblado del prototipo  Evaluación del prototipo  Refinamiento de requerimientos  Refinamiento de objetos. Metodologías para el desarrollo del software: es el proceso del software detallado y completo. Se basan en una combinación de modelos de procesos genéricos. La comparación no es una tarea sencilla. Clasificación de las metodologías:  Por productos de análisis y diseño: estructurado y orientadas a objetos.  Por planificación, control, modelado, generación de código: tradicionales y agiles. Modelado Ágil:  Priorizan el personal, es decir no se le sobrecarga al personal  Darle entrenamiento  También el software en funcionamiento  La interrelación con el cliente para definir los requerimientos El modelado ágil Prioriza el personal, software en funcionamiento, interrelación con el cliente, rápida respuesta al cambio sobre procesos y herramientas, documentación extensa, negociación con el cliente, planes rígidos. Proceso Ágil: es una filosofía y tiene ciertas directrices, diseñadas y utilizadas para entregar software útil de forma rápida. Diferencia entre un incremento y una versión BUSCAR NOTA: CUANDO EL PRODUCTO YA ES ENTREGADO EN VEZ DE ERROR SE LE DICE DEFECTO La diferencia entre las metodologías agiles es q unas priorizan versiones y otro incrementos. Características del Modelado Ágil:  Es iterativo con actividades concurrentes(especificación, diseño, pruebas, mantenimiento)  No se desarrolla por completo en las primeras iteraciones  Incrementos incluyen nuevas funcionalidades  Mantiene la simplicidad. Métodos Agiles:  Cristal  Programación extrema  Desarrollo software adaptable  Método de desarrollo de sistemas dinámicos  Scrum  Desarrollo dirigido por características  Diseño dirigido por características  Diseño hibrido (convencional + agiles)
  7. 7. Programación Extrema (1991): es un desarrollo incremental, los ciclos son de 1 a 3 semanas, el cliente es responsable de los requisitos, prioridades y pruebas tienen un planificación, el trabajo es en parejas, el código es compartido y el horario no excesivo, los cambios son a través de los incrementos, el diseño sencillo, se basan en tarjetas de escenario CRC (clases, colaboración)  Es el más conocido y usado  Requerimientos expresados como escenarios (entradas, procesos, salidas). Se le asigna un nombre y una prioridad.  Trabajo en equipo (parejas). Potencia relaciones interpersonales propiciando buen clima de trabajo. El cliente es parte del equipo.  Historias como parte de incrementos  Programación rápida, coro espacio entre entregas.  Los escenarios son la base para la planeación. Historias de la programación extrema:  Técnica usada para especificación de requisitos.  Se descomponen en tareas de programación  Se planifica su inclusión en los incrementos. Ventajas de la programación extrema  Realimentación continua: cliente-equipo  Adecuado para requisitos imprecisos.  Evita problemas  Proyectos de medios a pequeños.  Implica esfuerzo e interés del cliente  Código=documentación  Salto grande en abstracción entre requisitos y código impide un entendimiento sencillo. SCRUM:  Es la tendencia más utilizada ya que la interesa al desarrollador porque le facilita el trabajo  Proviene de las prácticas más usadas japonesas.  Proporciona un marco para la gestión de proyectos.  Propone elevar al máximo la productividad de equipo y la realimentación ; (corrección/riesgos temprano)  Reducir burocracia y actividades no orientadas a producir software.  Resultados máximos cada 30 días. Iteraciones llamadas Sprint.  Componentes: pila de productos (cosas por hacer de todo el producto), pila del sprint (cosas por hacer en cada iteración), incremento.  Reuniones consisten en planificación del sprint, revisión diaria, son de 15 min a 4horas.  Roles de equipo: propietarios, equipo, Scrum master. Selección Historias División historias en tareas Planeación Desarrollar/integrar Probar Entrega de software Evaluación Sistema
  8. 8. Ventajas – Desventajas del SCRUM  Ideal para cambio de requerimientos  Orientado hacia la gestión mas que en el desarrollo  Puede combinarse con otras metodologías (XP)  Fácil de aprender y utilizar  No propone practicas de desarrollo  Equipos auto gestionados (requisitos)  Delega en equipo total responsabilidad de decisión de trabajo para la productividad. Por qué se puede combinas con XP?: Porque no especifican como se toman los requerimientos, por ejemplo se puede utilizar con requerimientos basados en historias. Crystal Methodologies –CM :  se diferencia por colores las metodologías.  Centrado en las personas reducción de artefactos producidos.  Tamaño del equipo. Codificación de colores Ej. Blacon3-8  Espacio físico  Comunicación cara a cara. .---------------------------------------------------------------------------------------------------------------------------------. Gestión de Proyectos: Plan para la supervisión y control de proyecto La gestión de proyecto debe tener un alcance, una descripción técnica del sistema propuesto, estándares, procedimientos y técnicas y herramientas propuestas, calendario, organización del equipo.  Documento para comunicar es decir el Plan de trabajo este se le debe distribuir al cliente y equipo de trabajo.  Organización  Estimaciones de duración y costo  Calendario de actividades e hitos del proyecto  Gestión y análisis de riesgo Reunión Pila del Sprint Selección de la pila de productos Nueva funcionalidad Pila de producto Requisitos priorizados Visión Versiones Hitos Revisiones diarias Iteraciones
  9. 9.  Planificación: Supervisión y control de personal, proceso y eventos  La gestión la lleva a cabo los encargados del proyecto.  Es importante ya que permite el control de todo.  Consiste en cuatro puntos de vista : o Personal (cliente, requisitos, alcance) o Producto o Proceso (adecuarlos al personal y producto) o Proyecto (planificar calidad y control)  Personal: o Como nos organizamos, es decir elegir el jefe si es un caso vertical, y si es un caso horizontal no hay jefe solo se le asigna algo a cada quien. o Gestión de personal, estructuradas de proyectos de software.  Producto: o objetivos y ámbito, datos primarios, funciones, comportamiento o Identificar dificultades técnicas o Estimación de costos o Subdividir el proyecto (WBS división funcional modular)  Proceso: o Actividades estructurales + protección  Proyecto: o Planificar y controlar es decir manejar la complejidad Gestión de Personal: Objetivos o Composición de equipos (habilidades, experiencias) o Cohesión (trabajo en equipo o individual) o Comunicación o Organización Como lograr la gestión del personal o Respeto al personal o Asignación de niveles de responsabilidad o Compensaciones Personas involucradas en la gestión de Personal o Gestores superiores: aspecto de negocio o Gestores de proyecto: planificación, motivar, organizar y controlar o Profesionales: desarrolladores o Clientes o Usuarios Finales Estructura de grupos de trabajo Jerárquicas
  10. 10. Estructuras informalmente 1. Paradigma cerrado a. Jerárquica tradicional b. Bien para proyectos similares c. Sin mucha innovación 2. Aleatorio a. Estructura interna definida libremente b. Bien para innovación no para desarrollo planificado c. Depende de individualidades 3. Abierto a. Combina las anteriores b. Debe existir buena comunicación c. Decisiones en consenso 4. Sincrónico a. Modularización, poca interactividad Para organizar la estructura depende de la dificultad del problema, el tamaño, tiempo, modularidad, calidad, fecha, comunicación requerida. Equipos Agiles: o asociado al desarrollo del software ágil. o Se concreta en satisfacción temprana del cliente y entrega incremental. o Planificación al mínimo y escoge enfoque propio, auto organizado. o Autonomía para la gestión de decisiones técnicas. o Pueden escoger enfoque propio (restringido por necio estándar organizado. o Breves reuniones diarias, adaptación hacia logros incrementales o Equipos motivados al logro. Comunicación dentro de equipos: se define con la intención de atacar problemas como: o Inteoperatividad o Incertidumbre o Escalamiento del problema. La comunicación puede ser: o Formal: escrita (memorandos, informes, reuniones), es impersonal o Informal: reuniones de grupo, es personal. Gestión del Producto: es para estimar duración-costo o Se necesita un plan para analizar el requerimiento y establecer ámbito y delimitar. 1. Ámbito: Debe ser entendible a nivel de gestión y técnico. Enunciado delimitado no ambiguo.  Contexto: cómo encaja, relación con otros entes  Objetivo de información : datos visibles al cliente, entradas y salidas  Función y rendimientos: rendimiento, transformación entrada y salida. 2. Descomposición del problema: se usa un pequeño grado de descomposición útil para estimación.
  11. 11.  Funcionalidad  Proceso para entregarlos Gestión del Proceso: funciones y actividades estructurales Ejemplo: planificación-modelado-construcción-soporte. Se debe tomar en cuenta la madurez, aplicar las actividades correspondientes y descomponer el proceso. En la gestión de proceso se debe:  Escoger Paradigma (Clientes y desarrollo, producto, entorno.)  Plan de Proyecto (basado en las actividades estructurales funcionales)  Descomposición del proceso (tareas definidas, personas.) Gestión de proyecto:  Predecir que va mal y buscar cómo evitarlo  Seguimiento y control del proyecto. Análisis de resultados.  El último 10% lleva 90% del esfuerzo. Métricas en ingeniería de software Medidas, Métricas e indicadores  Medidas: dato básico delo que se esté tratando.  Métricas: visión profunda del proceso. Las métricas del producto son una medida cuantitativa que permite a la gente del software tener una visión profunda de la eficacia del proceso del software y de los proyectos que dirigen, utilizando el proceso como un marco de trabajo. Proceso de recopilación de métricas de software: ¿Para qué medimos?  Caracterizar: comprender los procesos, productos recursos y entornos. Establecer líneas base.  Evaluar: determina estado del proyecto respecto al diseño. Ver el impacto de la tecnología y las mejoras del proceso.  Predecir: para poder planificar, anticipar eventualidades.  Mejorar: cuando recogemos información que ayuda a identificar obstáculos y oportunidades para mejorar la calidad y rendimiento del proceso. Proceso Proyecto Producto Recopilación de datos Calculo de Métricas Evaluación de Métricas Medidas Métricas Indicadores
  12. 12. ¿Por qué medir?  La única forma racional de mejorar cualquier proceso es medir atributos del proceso, desarrollar las métricas significativas según estos atributos y proporcionar indicadores que conducirán a una estrategia de mejora. Análisis riguroso de errores en la organización:  Caracterización de fallos por origen (diseño, codificación, análisis)  Registro y ordenación por coste  Calculo global de costes  Análisis de categorías de mayor peso monetario para la organización  Desarrollo de planes de modificación de procesos para ELIMINAR o REDUCIR frecuencia de fallos. Mediciones de Software.  Directas: líneas de código, errores por cada líneas de código  Indirectas. Directas:  Métricas orientadas al tamaño: errores por miles de líneas de código, defectos por KLDC, $ por LDC, páginas de documentos por KLDC, Errores por persona.  Métricas orientadas a la función: o Número de entradas de usuario o Número de salidas de usuario o Número de peticiones de usuario o Numero de archivos o Números de interfaces extremas. Características:  Independiente del lenguaje  Utiliza inmediatamente características contables del dominio de información del problema  No penaliza implementaciones que requieren menos LOCS que otras  Facilitan el reúso y favorecen a las iniciativas orientadas al objeto.  Analizar el dominio de la información.  Métricas para la calidad del software: o Medida de la calidad: Proceso Producto Condiciones del negocio Características del Cliente Entorno de desarrollo Personas Tecnología
  13. 13.  Corrección (defecto por líneas de KLDC)  Facilidad de mantenimiento (tiempo medio de cambio)  Integridad  Facilidad de uso (amigable al usuario)  Planificación o Objetivos de la planificación del proyecto o Ámbito del software o Recursos (tecnología, tiempo recursos) o Estimaciones del proyecto de software o Técnicas de descomposición o Módulos empíricos de estimación. Métricas Orientadas a la Función Analizar el Dominio de la Información Factor de Ponderación Parámetro de medida conteo simple Prom. Compl. # de entradas de usuario X 3 4 6 = # de salidas de usuario X 4 5 7 = # de consultas X 3 4 6 = # de archivos X 7 10 15 = # de interfaces ext. X 5 7 10 = Conteo total Factor de complejidad Puntos función Modelo de Procesos Modelo de proceso Funciona con requisitos y arquitectura no definidos Produce software altamente factible Gestión de riesgo Permite correcciones sobre la marcha Visión del proceso por el cliente y el jefe del proyecto Codificar y corregir Bajo Bajo Bajo Alto Medio Cascada Bajo Alto Bajo Bajo Bajo Evolutivo exploratorio Medio ó Alto Medio ó Alto Medio Medio ó Alto Medio ó Alto Evolutivo prototipado Alto Medio Medio Alto Alto Desarrollo Bajo Alto Bajo ó Bajo Bajo
  14. 14. formal de sistemas Medio Desarrollo orientado a reutilización Medio Bajo a Alto Bajo ó Medio Alto Alto Incremental Bajo Alto Medio Bajo Bajo Espiral Alto Alto Alto Medio Medio Cuenta Peso Sub_total S(o) S(m) S(p) VE Numero de Entradas 7 8 10 8 4 32 Numero de Salidas 4 5 7 5 5 25 Numero de Peticiones 5 7 9 7 4 28 Numero de Archivos 1 1 2 1 10 10 Numero de Interfaces Externas 1 1 2 1 7 7 Total T 102 Factor Valor Copia de seguridad y recuperación 4 Comunicación de datos 2 Proceso distribuido 0 Rendimiento critico 4 Entorno operativo existente 3 Entrada de datos en línea 4 Transacciones de entrada en múltiples pantallas 5 Archivos maestros actualizados en línea 2 Complejidad de valores del dominio de información 5 Complejidad del procesamiento interno 5 Código diseñado para ser rehusado 4 Conversión /instalación en diseño 3 Instalaciones múltiples 5 Aplicaciones diseñadas para el cambio 5 Total F 51 Modelos Empíricos de Estimación E = 5.2 * KLDC0.91 Modelo de Walston-Felix E = 5.5 + 0.73 * KLDC1.16 Modelo de Bailey-Basisli E = 3.2 * KLDC1.05 Modelo simple de Boehm E = 5.288 * KLDC1.047 Modelo Doty para KLDC >9 E = -13.39 +0.054* PF Modelo de Albretch-Gaffney E = 60.62 * 7.728 * 10-8 * PF3 Modelo de Kemerer E = 585.7 + 15212 * PF Modelo de Matson-Barnett-Mellichamp
  15. 15. Procesos Ágiles: Resumen Ágiles Tradicional Responden a exigencias de negocios modernas Requerimientos Entrega tempranas Entrega tardía y sobre el costo Incorpora clientes Seguimiento de calidad pobre Mejora retornos de inversión Entregas no siguen exigencias modernas Reduce riesgos Costosos y con procesos burocráticos Mejora la calidad Mejora el manejos de proyectos Fácil de comenzar y parar
  16. 16. Universidad Nacional Experimental de Guayana Ingeniería de Software y Control de Proyecto Semestre 2014-I Trabajo Práctico Tomando en cuenta los eventos ocurridos en materia de seguridad en los últimos tiempos, una compañía se ha propuesto desarrollar software que contribuya a mejorar la forma de alertar estos sucesos en tiempo real, ayudar a la recuperación de información y de ser posible el (los) objetos mismos que hayan caído en manos de personas dedicadas al delito. Es así como esta compañía los contrata a uds, para que desarrollen un software con el cual se pueda bloquear/desbloquear dispositivos, hacer seguimiento de ubicación, recuperación de todo tipo de información, seguimiento al uso/aplicaciones que se este usando en el dispositivo y acceso a la información saliente y entrante a dispositivo (llamadas, mensajes, redes sociales, etc.). Todo lo anterior debe hacerse sin que el usuario note la actividad llevada a cabo en el dispositivo. Finalmente, se debe programar un botón de pánico que envíe mensajes de auxilio automáticamente. Los grupos deben ser conformados por 3 integrantes, y se deben entregar avances cada dos semanas hasta completar el trabajo.

×