Unidad I Repaso

1. Unidad I Repaso M.C. Juan Carlos Olivares Rojas

2. Agenda 1.1 Panorama General 1.2 Gestión del Proyecto 1.3 Principio de Análisis 1.4 Herramientas CASE

3. 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.

4. 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.

5. 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.

6. 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).

7. 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?

8. 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.

9. Construcción de una casa para “wendo” Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples

10. I. Introducción: Modelado de SW Construcción de una casa Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

11. I. Introducción: Modelado de SW Construcción de un rascacielos No cualquier persona o grupo de persona lo realiza. Imposible sin técnicas de Ingeniería

12. 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.

13. 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.

14. 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

15. 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.

16. 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:

17. 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í.

18. 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?

19. 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.

20. 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?

21. 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.

22. 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.

23. 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.

24. 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 repetir Bosquejar la programación en el tiempo del proyecto Iniciar actividades conforme a la programación

25. Gestión de Proyectos Esperar (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 entonces Iniciar la revisión técnica Fin si Fin mientras

26. 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.

27. 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.

28. 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).

29. 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.

30. 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.

31. 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

32. 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:

33. 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.

34. 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.

35. 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.

36. 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.

37. 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.

38. 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.

39. 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.

40. 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.

41. 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.

42. 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

43. 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).

44. 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.

45. 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.

46. 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.

47. 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.

48. ¿Preguntas, dudas y comentarios?