SlideShare a Scribd company logo
1 of 16
Download to read offline
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
 ¿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.
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
 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:
 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
 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)
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
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
 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
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.
 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
¿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
 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
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
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
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.

More Related Content

What's hot

Curso ingeniería de software parte i
Curso ingeniería de software parte iCurso ingeniería de software parte i
Curso ingeniería de software parte i
parafernalico
 
metricas de software si-504
metricas de software si-504metricas de software si-504
metricas de software si-504
Karl T Orihuela
 
Proceso de Software Una Visión General
Proceso de Software Una Visión GeneralProceso de Software Una Visión General
Proceso de Software Una Visión General
Ruth Hidalgo Tene
 
4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational
Julio Pari
 

What's hot (19)

Gestión de Proyectos de Software - Unidad II: Calidad en el Software
Gestión de Proyectos de Software - Unidad II: Calidad en el SoftwareGestión de Proyectos de Software - Unidad II: Calidad en el Software
Gestión de Proyectos de Software - Unidad II: Calidad en el Software
 
Curso ingeniería de software parte i
Curso ingeniería de software parte iCurso ingeniería de software parte i
Curso ingeniería de software parte i
 
Administración de Proyectos en la Ingeniería de Software
Administración de Proyectos en la Ingeniería de SoftwareAdministración de Proyectos en la Ingeniería de Software
Administración de Proyectos en la Ingeniería de Software
 
METODOLOGIAS AGILES
METODOLOGIAS AGILESMETODOLOGIAS AGILES
METODOLOGIAS AGILES
 
Proceso del software
Proceso del softwareProceso del software
Proceso del software
 
Proceso del software una visión general
Proceso del software una visión generalProceso del software una visión general
Proceso del software una visión general
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
 
Proceso Del Software
Proceso Del SoftwareProceso Del Software
Proceso Del Software
 
metricas de software si-504
metricas de software si-504metricas de software si-504
metricas de software si-504
 
Taller ingernieria de requerimientos
Taller ingernieria de requerimientosTaller ingernieria de requerimientos
Taller ingernieria de requerimientos
 
Proceso desarrollo software
Proceso desarrollo softwareProceso desarrollo software
Proceso desarrollo software
 
Sesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del softwareSesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del software
 
Proceso de Software Una Visión General
Proceso de Software Una Visión GeneralProceso de Software Una Visión General
Proceso de Software Una Visión General
 
4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational
 
Patrones de Proceso BPM
Patrones de Proceso BPMPatrones de Proceso BPM
Patrones de Proceso BPM
 
Métricas del proceso y proyecto - Procesos de Ingeniería de software
Métricas del proceso y proyecto - Procesos de Ingeniería de softwareMétricas del proceso y proyecto - Procesos de Ingeniería de software
Métricas del proceso y proyecto - Procesos de Ingeniería de software
 
Exposicion
ExposicionExposicion
Exposicion
 
Gestión de proyecto de software
Gestión de proyecto de softwareGestión de proyecto de software
Gestión de proyecto de software
 
Metodologías de desarrollo de software
Metodologías de desarrollo de software Metodologías de desarrollo de software
Metodologías de desarrollo de software
 

Similar to titulo de pdf

ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.pptELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
Marko Zapata
 

Similar to titulo de pdf (20)

UNIDAD_I.ppt
UNIDAD_I.pptUNIDAD_I.ppt
UNIDAD_I.ppt
 
Gestion de proyectos de SW
Gestion de proyectos de SWGestion de proyectos de SW
Gestion de proyectos de SW
 
Gestión de Proyectos Informáticos
Gestión de Proyectos InformáticosGestión de Proyectos Informáticos
Gestión de Proyectos Informáticos
 
PROCESO DE DESARROLLO DE SOFTWARE.pptx
PROCESO DE DESARROLLO DE SOFTWARE.pptxPROCESO DE DESARROLLO DE SOFTWARE.pptx
PROCESO DE DESARROLLO DE SOFTWARE.pptx
 
2. El proceso del software
2. El proceso del software2. El proceso del software
2. El proceso del software
 
Sesión 2: El proceso del software
Sesión 2: El proceso del softwareSesión 2: El proceso del software
Sesión 2: El proceso del software
 
Metodologia.rup
Metodologia.rupMetodologia.rup
Metodologia.rup
 
Metodologia.rup
Metodologia.rupMetodologia.rup
Metodologia.rup
 
Rup
RupRup
Rup
 
RUP
RUPRUP
RUP
 
Sesión 3: Modelos prescriptivos de proceso de software
Sesión 3: Modelos prescriptivos de proceso de softwareSesión 3: Modelos prescriptivos de proceso de software
Sesión 3: Modelos prescriptivos de proceso de software
 
Sesión 3: Modelos prescriptivos de proceso
Sesión 3: Modelos prescriptivos de procesoSesión 3: Modelos prescriptivos de proceso
Sesión 3: Modelos prescriptivos de proceso
 
3. modelos prescriptivos de proceso
3. modelos prescriptivos de proceso3. modelos prescriptivos de proceso
3. modelos prescriptivos de proceso
 
Fundamentos del diseno software
Fundamentos del diseno softwareFundamentos del diseno software
Fundamentos del diseno software
 
presentacion_edisleynissilva
presentacion_edisleynissilvapresentacion_edisleynissilva
presentacion_edisleynissilva
 
prueva
pruevaprueva
prueva
 
Procesos de desarrollo de software
Procesos de desarrollo de softwareProcesos de desarrollo de software
Procesos de desarrollo de software
 
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.pptELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
 
Fundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdfFundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdf
 
Investigación de modelos
Investigación de modelos Investigación de modelos
Investigación de modelos
 

Recently uploaded

EPA-pdf resultado da prova presencial Uninove
EPA-pdf resultado da prova presencial UninoveEPA-pdf resultado da prova presencial Uninove
EPA-pdf resultado da prova presencial Uninove
FagnerLisboa3
 
Modulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdfModulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdf
AnnimoUno1
 

Recently uploaded (11)

pruebas unitarias unitarias en java con JUNIT
pruebas unitarias unitarias en java con JUNITpruebas unitarias unitarias en java con JUNIT
pruebas unitarias unitarias en java con JUNIT
 
How to use Redis with MuleSoft. A quick start presentation.
How to use Redis with MuleSoft. A quick start presentation.How to use Redis with MuleSoft. A quick start presentation.
How to use Redis with MuleSoft. A quick start presentation.
 
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdfRefrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
 
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptxPROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
 
Avances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estosAvances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estos
 
EPA-pdf resultado da prova presencial Uninove
EPA-pdf resultado da prova presencial UninoveEPA-pdf resultado da prova presencial Uninove
EPA-pdf resultado da prova presencial Uninove
 
Innovaciones tecnologicas en el siglo 21
Innovaciones tecnologicas en el siglo 21Innovaciones tecnologicas en el siglo 21
Innovaciones tecnologicas en el siglo 21
 
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptxEL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
 
Avances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvanaAvances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvana
 
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
 
Modulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdfModulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdf
 

titulo de pdf

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