Download - Unidad I Repaso
![Page 1: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/1.jpg)
Unidad I Repaso
M.C. Juan Carlos Olivares Rojas
![Page 2: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/2.jpg)
Agenda
1.1 Panorama General
1.2 Gestión del Proyecto
1.3 Principio de Análisis
1.4 Herramientas CASE
![Page 3: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/3.jpg)
1.1 Panorama General • La Ingeniería de Software (ISw) es un término
difícil de definir de cual hay muchas interpretaciones.
• El desarrollo de software es un proceso artesanal dado que a la programación de computadoras se le denomina arte.
• La ISw permite sistematizar y estructurar el desarrollo de software.
![Page 4: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/4.jpg)
1.1 Panorama General
• ¿Cuál es la diferencia entre un albañil y un ingeniero en construcción?
• La aplicación de conocimiento y la disciplina de desarrollo.
• La ISw es un área tan extensa que prácticamente abarca todas las áreas de la computación.
![Page 5: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/5.jpg)
1.1 Panorama General• El objetivo fundamental de la ISw es lograr la
calidad del software.
• Por calidad se entienden muchas cosas. Para nuestro curso lo entenderemos como realizar 100% bien las cosas en el menor tiempo posible.
• La calidad hace referencia intrínseca a eficacia y eficiencia.
![Page 6: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/6.jpg)
1.1 Panorama General• Eficacia hacer las cosas bien.
• Eficiencia hacer las cosas bien con la menor cantidad de recursos.
• ¿Qué tiene más calidad un “Vochito” o un BMV?
• Los dos tienen igual calidad si cumplen con los requerimientos (checklist).
![Page 7: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/7.jpg)
1.1 Panorama General
• En general la ISw tiene los objetivos de que el software sea correcto, utilizable y costo-efectivo.
• Sinónimos de calidad es que esté libre de errores. Muchas de las metodologías de software actuales se basan en esta premisa.
• ¿Por qué la necesidad de la ISw?
![Page 8: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/8.jpg)
1.1 Panorama General
• El software es cada vez más complejo. A través de la Génesis de la evolución del software, los proyectos informáticos se hicieron tan complejos y costosos como construir edificios.
• En 1968 se da un hito importante al ocurrir la “crisis del software” y definirse la ISw como tal.
![Page 9: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/9.jpg)
Construcción de una casa para “wendo”
Puede hacerlo una sola personaRequiere:
Modelado mínimoProceso simpleHerramientas simples
![Page 10: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/10.jpg)
Construcción de una casa
Construida eficientemente y en un tiempo razonable por un equipoRequiere:
ModeladoProceso bien definidoHerramientas más sofisticadas
I. Introducción: Modelado de SW
![Page 11: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/11.jpg)
Construcción de un rascacielosI. Introducción: Modelado de SW
No cualquier persona o grupo de persona lo realiza.Imposible sin técnicas de Ingeniería
![Page 12: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/12.jpg)
1.1 Panorama General
• El software se define como un conjunto de instrucciones y estructuras de datos que permiten resolver problemas a través de una computadora.
• La principal característica de proyectos informáticos es que el software es un producto intangible y es difícil manejarlo. El desarrollo de software es una actividad mental consumidora de tiempo.
![Page 13: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/13.jpg)
1.1 Panorama General
• El software cuenta con las siguientes características:
• El software se desarrolla, no se fabrica.
• El software no se estropea.
• La mayoría del software es “Tailoring” (a la medida), casi no existe reuso.
![Page 14: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/14.jpg)
1.1 Panorama General
• Se debe tomar en cuenta que existen diversos tipos de software con características específicas:– Software empotrado– Software para PCs– Software de Inteligencia Artificial– Software de Gestión– Software de Tiempo Real– Software Científico– Software de Sistemas
![Page 15: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/15.jpg)
1.1 Panorama General
• La ISw es un conjunto de “mejores prácticas” que si no se llevan a la práctica no sirven de nada.
• El factor humano es el recurso más importante de cualquier proyecto de software. Por ejemplo, la Ley de Brooks: Si se aumenta un programador más se retrasa el proyecto mientras se explica que hay que hacer.
![Page 16: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/16.jpg)
1.1 Panorama General
• El proceso de desarrollo de software implica cuatro etapas:– Especificación– Desarrollo– Evaluación– Evolución
• El desarrollo de software se basa en modelos, siendo los más representativos:
![Page 17: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/17.jpg)
1.1 Panorama General
• Cascada (clásico)
• Construcción de prototipos
• Espiral
• RAD (Desarrollo rápido de aplicaciones)
• Cada uno de estos modelos tiene sus respectivas fases que pueden ser muy similares entre sí.
![Page 18: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/18.jpg)
1.2 Gestión del Proyecto
• La planeación de un proyecto es la parte más importante de la Administración de cualquier proyecto por que es donde se define el problema.
• Imaginemos que somos carpinteros y un cliente nos pide realizar una silla de manera ¿Cómo es que le hacemos al cliente su producto?
![Page 19: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/19.jpg)
Gestión del Proyecto
• La gestión de un proyecto se centra en las 4P’s: Personal, Producto, Proceso y Proyecto en respectivo y riguroso orden.
• El personal que está involucrado en un proyecto de software son: Directivos, Administradores de Proyecto, Profesionales, Clientes y Usuarios Finales, todos juegan roles y subroles muy importantes.
![Page 20: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/20.jpg)
Gestión de Proyectos
• De las tareas más difíciles de la gestión de proyectos se encuentran la motivación del personal y del liderazgo.
• El desarrollo de software se debe realizar en equipos de trabajo y no solamente en grupos. ¿Cuál es la diferencia entre grupos de trabajo y equipos de trabjo?
![Page 21: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/21.jpg)
Gestión de Proyectos
• Un grupo es sólo una asociación de miembros que comparten algo en común.
• Un equipo es un conjunto de personas que trabajan de manera conjunta (colaborativamente) para lograr un fin común. Si uno no realiza bien el trabajo repercute en los demás.
![Page 22: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/22.jpg)
Gestión de Proyectos
• Los equipos de software pueden ser de tres tipos: Descentralizado Democrático, Descentralizado Controlado y Centralizado Controlado.
• Las metodologías ágiles de desarrollo de personas hacen hincapié en equipos de dos personas.
![Page 23: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/23.jpg)
Gestión de Proyectos
• Muchas metodologías de software han cambiando el nombre de Producto al de solución para hacer referencia al “entregable” de un proyecto.
• Toda gestión de Proyecto debe cumplir con cuatro fases: planeación, organización, dirección y control.
![Page 24: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/24.jpg)
Gestión de Proyectos
Establecer las prioridades de un proyecto
Hacer la valoración inicial de las actividades del proyecto
Definir los hitos del proyecto y productos a entregar
Mientras el proyecto no se haya terminado o cancelado repetirBosquejar la programación en el tiempo del proyecto
Iniciar actividades conforme a la programación
![Page 25: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/25.jpg)
Gestión de ProyectosEsperar (por un momento)
Revisar el progreso del proyecto
Revisar los estimados de los parámetros del proyecto
Actualizar la programación del proyecto
Renegociar las restricciones del proyecto y los productos a entregar
Si surgen problemas entoncesIniciar la revisión técnica
Fin si
Fin mientras
![Page 26: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/26.jpg)
Gestión del Proyecto
• La parte más difícil de la Gestión de Proyectos consiste en el proceso de Estimación.
• El proceso de estimación tiene su primera aproximación en el proceso de Presentación de la Propuesta, seguida de la determinación de recursos, planeación y calendarización, costos, gestión de riesgos, supervisión y concluye con la presentación de informes.
![Page 27: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/27.jpg)
Gestión de Proyectos
• Estimar los costos de un proyecto es sumamente complicado. Las métricas que se tienen están enfocadas al tamaño del código (LOC) o bien a la funcionalidad del mismo (puntos de función).
• Los puntos de función toman en cuenta parámetros como las interfaces de E/S, el número de archivos, las interacciones con los usuarios, entre otros.
![Page 28: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/28.jpg)
Gestión de Proyectos
• Las técnicas de estimación pueden ser modelos empíricos como consultar a un experto, estimación por analogía o bien lo que el cliente esté dispuesto a dar; la otra alternativas son los métodos formales de estimación que utilizan algoritmos genéricos como el modelo COCOMO II.
• Se puede hacer uso de la subcontratación (outsourcing).
![Page 29: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/29.jpg)
Gestión de Proyectos
• El análisis de riesgos es una de las actividades que con frecuencia es omitida en el desarrollo de cualquier proyecto.
• Los riesgos nos definen todos aquellos factores que pueden hacer que fracase un proyecto. Se mide en % y puede ser de tres tipos: Riesgo de Proyecto, de Producto y del Negocio.
![Page 30: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/30.jpg)
Gestión de Proyectos
• El análisis de riesgos es uno de los primeros pasos para realizar los estudios de factibilidad, los cuales pueden ser de cuatro tipos: Operativa, Técnica, Cronograma y Económica.
![Page 31: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/31.jpg)
1.3 Principio de Análisis
• El primer paso para realizar el análisis de cualquier proyecto de software consiste en la obtención de requesitos (Ingeniería de Requerimientos) los cuales nos definen lo que se va a producir.
• Un requisito no es otra cosa que una condición o capacidad de un usuario o sistema para satisfacer un objetivo o resolver un problema
![Page 32: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/32.jpg)
Principio de Análisis
• Los requerimientos pueden ser funcionales (explícitos) o no funcionales (implícitos).
• Las características que deben perseguir los requerimientos son: necesario, conciso, completo, consistente, no ambiguo, verificable.
• Los problemas que presenta la Ingeniería de Requerimientos son muchos:
![Page 33: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/33.jpg)
Principio de Análisis
• Los requerimientos no son obvios y provienen de muchas fuentes.
• Son difíciles de expresar en palabras.
• Generalmente están relacionados entre sí.
• Un requerimiento puede cambiar en el transcurso del proyecto.
![Page 34: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/34.jpg)
Principios de Análisis
• Lo que se pretende con una buena Ingeniería de Requerimientos es reducir costos y retrasos del proyecto, mejorar la calidad del software, evitar el rechazo de los usuarios finales entre otras cuestiones.
• El éxito de la obtención de requerimientos consiste en ponernos en los zapatos de nuestros clientes y no desarrollando a nuestros gustos.
![Page 35: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/35.jpg)
Principios de Análisis• Es muy importante definir los límites y alcances
del sistema.
• Se deben evaluar y negociar cada uno de los requerimientos con el fin de priorizar cada uno de los requerimientos.
• Se deben documentar cada uno de los requerimientos obtenidos así como el control del cambio.
![Page 36: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/36.jpg)
Principios de Análisis
• Se recomienda utilizar diagramas de caso de uso ya que nos dan los macrorequisitos de la aplicación. Cada caso de uso debe ser especificado de manera correcta.
• Existen muchos factores que hacen que evolucionen los requerimientos como: cambió el problema a resolver, no se obtuvieron con el método adecuado, por que cambió el modelo de negocio, etc.
![Page 37: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/37.jpg)
Principios de Análisis
• Para obtener requerimientos se siguen muchas técnicas. Las más populares son las entrevistas y cuestionarios.
• Se pueden utilizar técnicas como la Lluvia de Ideas o análisis FODA
• En metodologías ágiles el cliente participa de manera activa en el desarrollo del sistema.
![Page 38: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/38.jpg)
Principios de Análisis
• Los prototipos son una buena técnica para la obtención y validación de requerimientos ya que los usuarios finales pueden dar su opinión al respecto.
• Un modelo es una abstracción de la realidad en versión simplificada. El análisis pretende “descomponer” un problema en sus partes para poder definir de manera adecuada el problema.
![Page 39: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/39.jpg)
Principios de Análisis
• En general durante la etapa de análisis se deben especificar procesos, datos y control. De esta forma surge el patrón MVC (Modelo-Vista-Controlador).
• Los patrones son un conjunto de acciones repetitivas que sirven para solucionar procesos específicos. El patrón MVC se ha utilizado para la migración de aplicaciones legadas y separación de interfaces.
![Page 40: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/40.jpg)
Principios de Análisis
• En análisis estructurado se utiliza la técnica de Diagrama de Flujo de Datos para especificar procesos, Diagrama Entidad-Relación para especificar datos y diagramas de transición de estados para control.
• Para el modelado de datos se recomienda definir todos los objetos (entidades) y definir sus atributos.
![Page 41: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/41.jpg)
Principios de Análisis• La ventaja de utilizar DFDs es que pueden
reducirse procesos en su mínima expresión al ser un grafo de entidades y procesos.
• En general el nivel 0 de un DFD debe reflejar el sistema en general. Cada burbuja del DFD se debe especificar hasta el nivel 7 como máximo.
• El diccionario de datos (DD) es otra forma de especificar los requerimientos de un sistema.
![Page 42: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/42.jpg)
Principios de Análisis• En general un DD son metadatos que contienen
alias, donde se usa/como se usa, descripción e información adicional de los diccionarios de datos.
• Ejemplo:
• Datos de Factura, Datos del Cliente, Facturación(Entradas), Datos de Factura = NombreCliente+ Domicilio+RFC+Tel
![Page 43: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/43.jpg)
1.4 Herramientas CASE
• Las herramientas CASE (Ingeniería de Software Asistida por Computadora) permiten ayudar a las personas en el proceso de desarrollo de software en áreas tales como: análisis de requerimiento, depuración y pruebas.
• No se debe confundir con los términos CAD/CAM (Manufactura y Diseño Asistido por Computadora).
![Page 44: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/44.jpg)
Herramientas CASE
• Existen muchas clasificaciones de las herramientas CASE, a continuación se describirán las más importantes.
• U-CASE (Upper-CASE) es una herramienta que sirve de front-end durante las primeras fases del ciclo de vida: análisis y diseño.
![Page 45: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/45.jpg)
Herramientas CASE
• L-CASE (Lower-CASE) sirve de back-end durantes las últimas fases del ciclo de vida: implementación y pruebas.
• I-CASE (Integrated-CASE) también llamadas workbench CASE son herramientas que ayudan en todas las fases del ciclo de vida.
• Los toolkits son herramientas que solo auxilian durante una fase del ciclo de vida.
![Page 46: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/46.jpg)
Herramientas CASE• Tampoco se debe confundir CASE con las
herramientas de gestión de proyectos que en general ayudan a la planificación y seguimiento de actividades.
• Existen herramientas más genéricas que nos ayudan en distintas fases como entornos de programación, herramientas de diseño de interfaces, herramientas de documentación, herramientas de reestructuración, ingeniería inversa, etc.
![Page 47: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/47.jpg)
Herramientas CASE
• Los componentes básicos de un sistema CASE son: los repositorio (bases de datos con algunas características del proyecto); las herramientas de diagramación y modelamiento, herramientas de prototipado, generación de código, generador de documentación y en la mayoría de los casos un módulo de gestión del proyecto.
![Page 48: Unidad I Repaso](https://reader035.vdocumento.com/reader035/viewer/2022062221/56813ac1550346895da2d2b4/html5/thumbnails/48.jpg)
¿Preguntas, dudas y comentarios?