1. Qu es ingeniera? Aplicacin de principios cientficos para: Disear o desarrollar estructuras, mquinas, aparatos o procesos (industriales, informticos, etc.

tc.) que los utilizan por separado o en combinacin. Construir u operar dichos desarrollos con conocimiento de su diseo Pronosticar su comportamiento bajo condiciones de funcionamiento especficas.

2. La crisis del software: dcadas, problemticas La dificultad en escribir programas libres de defectos, fcilmente comprensibles, y que sean verificables. Primera Fase. Los Albores (1945-1955): Programar no es una tarea diferenciada del diseo de una mquina. Uso del Lenguaje Mquina y Ensamblador.

Segunda Fase. El Florecimiento (1955-1965): Aparecen una multitud de lenguajes. Es posible hacer todo.

Tercera Fase. La Crisis (1965-1970): Desarrollo inalcanzable de grandes programas. Ineficiencia, errores, costo impredecible. Nada es posible.

Cuarta Fase. Innovacin Conceptual (1970-1980): Fundamentos de Programacin. Verificacin de Programacin. Metodologas de Diseo.

Quinta Fase. El Diseo del Problema (1980-200?): Entornos de programacin. Especificacin Formal. Programacin Automtica.

Sntomas: El software no es fiable y necesita de un mantenimiento permanente. Baja calidad del software generado: Software que no cumple las especificaciones. Los proyectos no terminaban en plazo: El software se entrega muy a menudo con retrasos. Los proyectos no se ajustaban al presupuesto inicial. El software se entrega con unos costos superiores a los presupuestados. Cdigo inmantenible que dificultaba la gestin y evolucin del proyecto. A menudo el software es imposible de mantener, carece de trasparencia y no se puede modificar ni mejorar.

Causas: La complejidad que supone la tarea de programar. Los cambios que tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios. No existen todava herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cul es el esfuerzo que se necesitar para desarrollar un programa. La mayora de las veces no sea posible estimar cunto tiempo llevar un proyecto, ni cunto personal ser necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. En muchas ocasiones el personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecucin. Las aplicaciones de hoy en da son programas muy complejos, inabordables por una sola persona. En sus comienzos se valor como causa tambin la inmadurez de la ingeniera de software; aunque todava hoy en da no es posible realizar estimaciones precisas del costo y tiempo que necesitar un proyecto de software.

3. Definicin de software Es el conjunto de: Programas de cmputo, Procedimientos, Reglas, Documentacin y Datos asociados

Que forman parte de las operaciones de un sistema de computacin.

4. Definicin de "ingeniera de software" La aplicacin de un enfoque sistemtico, disciplinado, y cuantificable al desarrollo, operacin y mantenimiento del software; estos es, la aplicacin de la ingeniera al software. El establecimiento y uso de principios de ingeniera para generar software en forma econmica, que sea confiable y que trabaje en forma eficiente en mquinas reales. 5. Disciplinas relacionadas con la ingeniera de software Matemticas Ingeniera de usabilidad Interaccin humano-computadora Ciencias de la computacin Ingeniera de la informacin Ingeniera del conocimiento Ingeniera de sistemas Ingeniera de producto Ingeniera de computadoras Administracin Sociologa Psicologa 6. Requerimientos a. Que es un requerimiento Una condicin, necesidad o capacidad que debe estar presente en un sistema o componentes del sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. b. Tipos de requerimientos Functionality (Funcionalidad) Usability (Usabilidad) Reliability (Confiabilidad) Performance (Rendimiento) Supportability (Soporte) Diseo (FURPS+) Implementacion (FURPS+) Interfaz (FURPS+) Fisicos (FURPS+)

c. Atributos de calidad de un requerimiento Necesario Conciso Completo Consistente No ambiguo Verificable Atmico d. Problemas con los requerimientos Inexactos Incorrectos Ambiguos Omisin de detalles Validaciones no previstas Cambio de requerimientos 7. Tcnicas de recoleccin de requerimientos a. La entrevista Muy til para obtener informacin Necesita preparacin Se puede llevar a cabo en cualquier nivel de la organizacin Pueden responder errneamente Los usuarios dicen lo que el entrevistador quiere escuchar Boicot de informacin b. Lluvia de ideas Independiente del cliente c. Observacin de campo Revisin de documentos en la base de conocimientos de la organizacin. d. Cuestionarios tiles cuando hay muchos usuarios finales. Su diseo requiere tiempo y dedicacin Debe ser fcil de procesar Es importante la seleccin de usuarios a realizar el cuestionario.

8. Validacin de requerimientos Evaluacin de calidad (atributos de calidad) (No) Se sabe Evaluacin de la factibilidad tcnica de implementacin (No) Se sabe Implementabilidad (No) Se sabe 9. Diseo de software a. Niveles de diseo Alto nivel: Provee una vista de todo el sistema, identificando sus elementos con un nivel de abstraccin, arquitectura del sistema y diseo de la base de datos. Incluye la relacin entre mdulos, adems de flujo de datos, diagramas de flujo y estructuras de datos. Bajo nivel Expone el diseo detallado de cada elemento descrito en el diseo de alto nivel. Define la lgica para cada componente del sistema, lo que sera un diagrama de clases con todos los mtodos y relaciones entre clases. b. Arquitectura lgica Define los procesos que realizan funciones y el flujo de informacin compartida entre procesos. No incluye nombres de componentes fsicos o direcciones fsicas, pero si los servicios y nombres de aplicacin. c. Arquitectura fsica Incluye los componentes y entidades entre componentes fsicos y ubicaciones. Detalles como sistemas operativos, numero de versin, adems de limitantes fsicas. d. Diseo de la GUI (No) Se sabe 10. Tipos de prueba a. Tipos de pruebas: a. Estticas Sin ejecutar el software, ya sea manual o automticamente. b. Dinmicas Ejecucin del software. Basado en entradas y salidas esperadas. Caja negra y caja blanca. c. Funcionales Cumplir con las funciones finales del sistema. Desarrolladas por analistas de pruebas y usuarios finales.

d. Estructurales Prueba ramas especficas y puntos especficos del software. e. Manuales Descubrir defectos en la usabilidad. f. Automticas Programa que prueba programas. g. Unitaria Prueba mdulos por separado. h. Integracin Prueba la integracin de mdulos. i. Aceptacin (por el cliente) Revela problemas en los requerimientos. b. Mtodos de pruebas a. Caja negra Validar los resultados en base a las entradas. No importa lo que sucede dentro del programa. b. Caja blanca Realizada por el programador. Se prueba la implementacin. c. Caja gris Caja negra pero realizada por alguien que conoce el cdigo fuente. 11. Planes de prueba 1. (No) Se sabe. 12. Modelos de ciclo de vida a. Cascada Completar una fase antes de continuar a la siguiente etapa. nfasis en la documentacin Enfoque sencillo Ms disciplinado. Errores u omisiones pueden ser muy costosos. b. Espiral Iterativo, prototipos + cascada c. Agiles SCRUM Acepta el cambio en requerimientos Enfoque emprico. Equipos auto-organizados nfasis en comunicacin entre integrantes

Maximizar la habilidad del equipo en entregas rpidas y responder apropiadamente a requerimientos repentinos. Las etapas son sprints. Todos los das hay un SCRUM (junta de 15 mins.) 13. Modelos y metodologas 1. PSP i. Qu es? Proceso que su intencin es ayudar a los ingenieros a entender y mejorar su rendimiento, y prepararlos para TSP. ii. Principios Cada ingeniero es esencialmente diferente, por lo que deben planear su trabajo y basar sus planes en sus propios trminos. Para mejorar su funcionamiento se deben utilizar procesos bien definidos y medidos de forma personal. Los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos. Para que lleguen a entender su funcionamiento deben: Medir los tiempos que pasan en cada proceso Medir los defectos que inyectan y remueven. Medir los tamaos de los productos que producen. iii. Cundo es til? (No) Se sabe. iv. Mediciones Tiempos Defectos Tamaos 2. TSP i. Qu es? Metodologia para dirigir el trabajo de mejora y desarrollo de software, adems de establecer un entorno donde el trabajo efectivo en equipo sea normal y natural. ii. Principios El objetivo es importante, definido, visible y realista. Los miembros son habilidosos. Los miembros cooperan y se apoyan mutuamente. Los miembros son disciplinados en su trabajo. Los recursos son adecuados para el trabajo. Los miembros se sienten motivados y comprometidos a cumplir con la meta. Los integrantes participan en la elaboracin del plan

 Los integrantes definen un proceso comn para su trabajo Cada miembro conoce su rol. El equipo negocia el plan de trabajo con la administracin. La administracin revisa y acepta las negociaciones del plan. Los miembros se comunican libremente y continuamente. Tienen un lder que los mantiene motivados. iii. Cundo es til? (No) Se sabe. iv. Formacin de equipos Compromiso Planes agresivos Calidad propia Objetivos del proyecto Plan propio Plan detallado Roles Recursos v. Importancia del rol de lder Responsable de guiar y motivar. Direccin de trabajo diario. Proteccin de los recursos Resolucin de problemas Realizar reuniones. 3. CMMI i. Qu es? Una coleccin de las mejores prcticas para ayudar a las organizaciones a mejorar sus procesos. ii. Cules son las tres orientaciones? Desarrollo Adquisicin Servicios iii. Cuantas reas de proceso tiene CMMI-Dev? CM - Configuration Management MA - Measurement and Analysis PMC - Project Monitoring and Control PP - Project Planning PPQA - Process and Product Quality Assurance REQM - Requirements Management SAM - Supplier Agreement Management DAR - Decision Analysis and Resolution

 IPM - Integrated Project Management OPD - Organizational Process Definition OPF - Organizational Process Focus OT - Organizational Training PI - Product Integration RD - Requirements Development RSKM - Risk Management TS - Technical Solution VAL - Validation VER - Verification OPP - Organizational Process Performance QPM - Quantitative Project Management CAR - Causal Analysis and Resolution OPM - Organizational Performance Management iv. Componentes del modelo rea de proceso Metas especificas i. Practicas especificas 1. Sub practicas 2. Ejemplos de productos Metas genricas i. Practicas genricas 1. Sub practicas 2. Elaboraciones genricas de prctica. Motivos Notas introductorias reas relacionadas al proceso