1 M.C. Juan Carlos Olivares RojasUnidad 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 Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

10 Construcción de una casaI. Introducción: Modelado de SW Construcción de una casa Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

11 Construcción de un rascacielosI. 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 Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difícil eludir un proceso y modelado más rigurosos, debido por ejemplo a relaciones contractuales, envergadura del proyecto en tiempo y participantes, etc. Una lectura interesante: Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."

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 prototiposEspiral 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 proyectoHacer 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 Fin mientras 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álisisLo 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álisisEs 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álisisSe 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álisisPara 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álisisLos 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álisisEn 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álisisEn 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álisisLa 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álisisEn 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?