← My collections
Ingeniería y Arquitectura · Informática / Ingeniería del Software
It's copied to your library with every feature (audio, generate more, ask the teacher) without spending AI again on flashcards/quizzes. "Add the whole unit" also brings in the other topics in this category.
Informática / Ingeniería del Software
Universidad
Introducción a la Ingeniería del Software. Fuente: Wikipedia (CC BY-SA 4.0).
40 flashcards24 quiz questions10 summary sections
Sign up to open «Informática / Ingeniería del Software»
Browsing the syllabus and its units is open to all. Opening the full topic — summary, quiz, flashcards and audio — is free but requires an account, so we can save your progress and keep this sustainable for everyone.
Summary by section
Scored quiz
Review flashcards
Audio
What you need to know
Read the full theory →Definición y fundamentos de la Ingeniería de Software
- Definición: Aplicación de métodos y técnicas de ingeniería para crear software confiable y de calidad.
- Componentes: Integra ciencias de la computación, ciencias aplicadas y ciencias básicas.
- Objetivos clave: Reducir costo y complejidad, aumentar confiabilidad y modificabilidad.
- Enfoque: Debe ser sistemático, disciplinado y cuantificable.
- Cifra: 1.895.500 ingenieros de software en EE. UU. (2024).
- Debate terminológico: El término "desarrollo de software" puede ser más preciso para procesos con menos rigor de prueba.
- Propósito: Sistematizar la creatividad para reducir el riesgo de fracaso.
- Producto industrial: El software debe regirse por metodologías y buenas prácticas para ser un producto eficaz.
- Impacto empresarial: La calidad de la infraestructura tecnológica define el nivel de la empresa.
Evolución histórica y crisis de la ingeniería de software
- Crisis del software: periodo comprendido entre las décadas de 1960 y 1980
- Accidente Therac-25: causó la muerte de 6 personas por fallos de software
- Bases de la ingeniería de software: ciencias de la computación, matemáticas, psicología, ergonomía y administración
- Costo de mantenimiento (años 80): dos veces más caro que el desarrollo
- Incremento de costos (años 90): aumento del 30% respecto a la década anterior
- Fallas de proyectos (1995): el 75% de los grandes productos tenían fallas graves o no cumplían requerimientos
- Desviación de tiempo (1995): el proyecto medio sobrepasaba la estimación en un 50%
- Aporte económico por Internet: 90.000 millones de dólares al año
- Objetivo de metodologías actuales: crear soluciones de software funcional a bajo costo
Objetivos, Recursos, Implicaciones y Notaciones de la Ingeniería de Software
- Objetivo: Adaptar el software a las necesidades organizacionales y mejorar la calidad.
- Objetivo: Lograr exactitud en costos y tiempos de desarrollo.
- Recursos humanos: El número de personal depende de la estimación del esfuerzo de desarrollo.
- Recursos de entorno: El hardware es el medio físico indispensable para el software.
- Impacto económico (EE. UU. años 90): Contribución de 1/8 del incremento del PIB.
- Impacto económico (EE. UU. años 90): Crecimiento total de US$ 1 billón en economía y productividad.
- Impacto social: Mejora de servicios en salud, bomberos y gobierno.
- UML: Lenguaje de modelado (no modelo estándar) con reglas sintácticas, semánticas y pragmáticas.
- BPMN: Simula diagramas de flujo para procesos de negocios; incluye objetos de flujo, conexión, swimlanes y artefactos.
- DFD: Representa flujos de datos, procesos de transformación y almacenamientos (Larry Constantine).
- Herramientas CASE: Software para asistir en el ciclo de vida del desarrollo.
- Metodología: Procesos sistemáticos, predecibles y repetibles para mejorar productividad.
- Ciclo de vida: Conjunto de etapas que componen el proceso de ingeniería de software.
Ingeniería de Requisitos en el Desarrollo de Software
- Identificar tema principal y recursos humanos/materiales
- Analizar contexto del negocio para definir requisitos
- Dominar datos externos, de salida y de almacenamiento persistente
- Identificar puntos críticos y causas de insatisfacción
- Definir funciones y comportamiento ante situaciones inesperadas
- Especialistas deben detectar requisitos ambiguos o contradictorios
- Resultado del análisis: documento ERS (Especificación de Requisitos del Sistema)
- Estándar de estructura: CMMI
- Norma de especificación: IEEE Std. 830-1998
- Finalidad: control de costes, tiempos y reducción de riesgos
- Modelo de estimación de costes: COCOMO
- Limitación: el software es mecánico y no emula el pensamiento humano
- Técnicas de especificación: Casos de uso (formales) e Historias de usuario (ágiles)
Rol del Arquitecto y Fases del Desarrollo de Aplicaciones
- Arquitecto: responsable de integrar infraestructura, aplicaciones y bases de datos
- Arquitectura de sistemas: actividad de planeación de hardware, red y software
- Diseño de salidas: incluye requerimientos, funciones visibles, comportamiento y clases de requerimientos
- Arquitectura de software: diseño de componentes mediante patrones de arquitectura
- Diagramas mínimos para codificación: diagrama de clases y diagrama de base de datos
- Herramientas CASE: Enterprise Architect y Microsoft Visio for Enterprise Architects
- Programación: complejidad ligada a los lenguajes y al diseño previo
- Fase 1: Desarrollo de infraestructura (organización de elementos base)
- Fase 2: Adaptación del paquete (inspección detallada y rendimiento)
- Fase 3: Unidades de diseño interactivas (diálogo usuario-sistema y pruebas unitarias/integración)
- Fase 4: Unidades de diseño batch (diagramas de flujo, estructuras y tablas de decisiones)
- Fase 5: Unidades de diseño manuales (procedimientos administrativos)
Pruebas, Implementación, Documentación y Mantenimiento en Ingeniería de Software
- Pruebas unitarias: verifican módulos por separado
- Pruebas de integración: verifican el sistema de manera integral
- Práctica recomendada: pruebas realizadas por personal independiente
- Enfoque personal inexperto: evalúa calidad de documentación y claridad
- Enfoque programadores expertos: detecta fallos técnicos y detalles complejos
- Roger S. Pressman: pruebas de procesos lógicos internos y externos funcionales
- Requisito: pruebas con sujetos reales para obtener retroalimentación
- Implementación: conversión de especificaciones en sistemas ejecutables
- Modelo de implementación: incluye ficheros ejecutables y de código fuente
- Documentación: incluye UML, diagramas de casos de uso y manuales
- Mantenimiento: ocupa 2/3 del ciclo de vida del proyecto
- Lehman: 80% del mantenimiento es mejora de funcionalidad (no correctivo)
- Mantenimiento: incluye reformar, adaptar y reutilizar software existente
- Ventajas gestión: seguimiento, recursos, comunicación y evaluación
- Ventajas ingeniería: comprensión, reutilización, mantenimiento y optimización
- Ventajas cliente: calidad, plazos y confianza
- Ciclo de vida: proceso desde la concepción hasta el retiro del sistema
Ciclo de vida y modelos de desarrollo de software
- Definición de objetivos: Alineación con la estrategia global
- Análisis de requisitos: Recopilación de necesidades y restricciones del cliente
- Diseño general: Arquitectura de la aplicación
- Diseño en detalle: Definición precisa de subconjuntos
- Programación: Implementación de funciones diseñadas
- Prueba de unidad: Verificación de subconjuntos individuales
- Integración: Unión de módulos mediante pruebas documentadas
- Prueba beta: Validación contra especificaciones originales
- Documentación: Información para usuarios y desarrollos futuros
- Mantenimiento correctivo: Procedimientos de reparación
- Mantenimiento continuo: Actualizaciones secundarias
- Modelo en cascada: Enfoque secuencial y sistemático
- Modelo de prototipos: Desarrollo evolutivo para reducir incertidumbre y aclarar requisitos
- Modelo en espiral: Propuesto por Barry Boehm (1986), basado en ciclos evolutivos y análisis de riesgo
- Modelo por etapas: Desarrollo de capacidades importantes en versiones refinadas sucesivas
- Modelo incremental/iterativo: Secuencias lineales repetitivas que producen un producto operacional en cada incremento
Modelos de desarrollo de software
- Modelo estructurado: Diferencia procesos y datos mediante jerarquías
- Modelo estructurado: Técnica entidad-relación para datos y diagrama de flujo de datos para procesos
- Modelo estructurado: Desventaja de datos repetidos y complejidad en código extenso
- Modelo orientado a objetos: Gira en torno al concepto de clase
- Modelo orientado a objetos: Permite reutilización de software y usa notación UML
- Modelo RAD: Creado por James Maslow en 1980
- Modelo RAD: Basado en ciclos cortos, técnicas CASE y enfoque por componentes
- Modelo concurrente: Modelo de red con actividades simultáneas
- Modelo concurrente: Utilizado frecuentemente en arquitecturas cliente/servidor
- Modelo concurrente: Los sucesos disparan transiciones de estado en la red de actividades
- Proceso unificado: Enfoque genérico para diversos tamaños y tipos de proyectos
- Proceso unificado: Meta de alta calidad bajo presupuesto y calendario predecibles
Estructura del Proceso Unificado, Naturaleza de la Ingeniería de Software y Roles
- Dimensión dinámica: representa el tiempo (fases, iteraciones, hitos)
- Dimensión estática: representa disciplinas, componentes, flujos y roles
- Proceso Unificado: marco de trabajo extensible (RUP es su refinamiento)
- Productos genéricos: destinados a la venta masiva
- Productos a medida: desarrollados bajo pedido específico
- Requisito de mantenibilidad: capacidad de evolución del software
- Requisito de confiabilidad: no producir daños ante errores
- Requisito de eficiencia: no desperdiciar recursos
- Requisito de utilización adecuada: interfaz y documentación correctas
- Diferencia de producto: para el ingeniero son datos/programas; para el usuario es la información
- Métodos formales: uso de matemáticas para probar algoritmos
- Creación: secuencia de pasos tipo línea de ensamblaje
- Gestión de proyecto: control de presupuestos, tiempos, equipos y recursos
- Participantes: personas involucradas en el proyecto
- Roles: funciones y responsabilidades asociadas a tareas
- Cliente: responsable de especificar los requisitos
- Usuario final: responsable de operar el sistema y conocer el problema
- Desarrolladores: encargados de investigación, diseño, implementación, pruebas y depuración
- Gestores: coordinan recursos, procesos y estrategia ante la dirección
Código ético y organizaciones de la ingeniería de software
- Objetivo: Ingeniería de software como profesión benéfica y respetada
- Sociedad: Priorizar el interés social y la veracidad
- Cliente/Empresario: Respetar confidencialidad y evitar software ilegal
- Producto: Garantizar alta calidad, costos aceptables y objetivos alcanzables
- Juicio: Mantener integridad, independencia y objetividad
- Administración: Procedimientos para reducir riesgos y proteger datos
- Profesión: Promover el conocimiento público y la reputación del sector
- Colegas: Apoyo mutuo, reconocimiento de méritos y revisiones documentadas
- Personal: Aprendizaje de por vida en todas las fases del desarrollo
- Organizaciones clave: IEEE, ACM, SEI, BCS, RUSSOFT, SES y CONCITI
Flashcard preview (6 of 40)
- 01
Según Zelkowitz (1978), ¿qué dos factores busca reducir la ingeniería de software?
Costo y complejidad.
- 02
Según Boehm (1976), ¿a qué se aplica el conocimiento científico en la ingeniería de software?
Diseño, construcción y documentación de programas.
- 03
Según Bauer (1971), ¿qué tipo de software busca obtener la ingeniería de software?
Económicamente viable, confiable y eficiente.
- 04
Según el Standard Glossary, ¿qué tres características definen el enfoque de la ingeniería de software?
Sistemático, disciplinado y cuantificable.
- 05
¿Cuál es el objetivo de la ingeniería de software al tratar el proceso creativo de creación de software?
Sistematizarlo para acotar el riesgo de fracaso.
- 06
En qué década apareció por primera vez el término 'ingeniería del software':
Finales de la década de 1950.
+ 34 more flashcards, 24 quiz questions and audio when you sign up (free).