INGENIERÍA DEL SOFTWARE

Presentación del tema: "INGENIERÍA DEL SOFTWARE"— Transcripción de la presentación:

1 INGENIERÍA DEL SOFTWARE
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE ACI491 – 482

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37 ¿Qué es una Metodología Ágil? www.agilealliance.com
Metodologías ágiles ¿Qué es una Metodología Ágil?

38 Las Metodologías Ágiles (AMs) valoran:
Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las herramientas Desarrollar software que funciona más que conseguir una buena documentación  Minimalismo respecto del modelado y la documentación del sistema La colaboración con el cliente más que la negociación de un contrato Responder a los cambios más que seguir estrictamente una planificación

39 ¿Por qué surgen las Metodologías Ágiles (AMs)?
Dificultad para implantar metodologías tradicionales. Sofisticadas herramientas CASE y notaciones (UML) Una solución a medida para un segmento importante de proyectos de desarrollo de software Pugna entre comunidades/gurús “Aceptar el cambio” ... Gestión del Conocimiento

40 Costo de los Cambios en SW
Tradicional Costo del cambio Suposición AMs tiempo

41 Manifiesto de las AMs agilemanifesto.org
Principios: La prioridad principal es satisfacer al cliente mediante tempranas y continuas entregas de software que le reporte un valor Dar la bienvenida a los cambios. Los AMs capturan los cambios para que el cliente tenga una ventaja competitiva Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente

42 … Manifiesto de las AMs La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto Construir proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir el trabajo El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo El software que funciona es la medida principal de progreso

43 … Manifiesto de las AMs Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante La atención continua a la calidad técnica y al buen diseño mejora la agilidad La simplicidad es esencial Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos En intervalos regulares, el equipo reflexiona respecto de cómo llegar a ser más efectivo, y según esto ajusta su comportamiento

44 Comparación Metodología Ágil Metodología No Ágil Pocos Artefactos
Más Artefactos Pocos Roles Más Roles No existe un contrato tradicional o al menos es bastante flexible Existe un contrato prefijado Cliente es parte del equipo de desarrollo (además in-situ) El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio Grupos grandes Menos énfasis en la arquitectura La arquitectura es esencial

45 Limitaciones Proporcionan una ayuda limitada en equipos de trabajo dispersos físicamente Proporcionan una ayuda limitada en equipos de trabajo grandes Consideran una ayuda limitada al tratamiento de subcontratos No privilegian la reutilización de componentes Proporcionan una ayuda limitada para desarrollar software de seguridad crítica Proporcionan ayuda limitada para desarrollar software grande y complejo Dificultad en la utilización de herramientas que apoyen el desarrollo

46 Tipos de Proyectos Tradicionales Agiles Grandes
Con requerimientos estables Aplicaciones críticas Grandes equipos de desarrollo Equipo de desarrollo distribuídos geográficamente Tradicionales Ambientes dinámicos, con equipos de trabajo pequeños y produciendo aplicaciones no críticas Requerimientos desconocidos o inestables, garantizando un menor riesgo ante la posibilidad de cambio en los requerimientos Agiles

47 Principales AMs Crystal Methodologies, Alistarir Cockburn,
SCRUM, Ken Schwaber & Jeff Sutherland, DSDM (Dynamic Systems Development Method), Lean Programming, Mary Poppendieck, FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, Extreme Programming, Kent Beck Adaptative Software Development, Jim Highsmith

48 ¿Qué resultado proveen las Metodologías Ágiles?
Hay pocos datos concretos del índice de éxito de proyectos Está teniendo un gran auge Aumento en el número de proyectos ¿Por qué? Tiene el apoyo de muchos gurús en ingeniería de sw Es un proceso para gente que odia los procesos Tiene sentido ¿Política? ... Pugna entre comunidades

49 ¿Cuándo utilizar una Metodología Ágil?
¿Existe ya un proceso? Si ¿Reacciona bien a los cambios? Si ¿Está el equipo contento con él? Si  Mejor esperar Se están recogiendo datos En un futuro se podrán hacer comparaciones sobre lo que es más conveniente

50 ... ¿Cuándo utilizar una Metodología Ágil?
¿Existe ya un proceso? No o existe pero no reacciona bien a los cambios o existe pero el equipo no está contento con él  Una Metodología Ágil puede ser una buena forma de empezar Fácil de financiar A los programadores les gusta A los clientes les gusta el mayor control

51 CONCLUSIONES (i) No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos que tienen estas características. Una de las cualidades más destacables en una metodología ágil es su sencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costos de implantación en un equipo de desarrollo. Esto ha llevado hacia un interés creciente en las metodologías ágiles. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicación, tales como:

52 CONCLUSIONES (ii) están dirigidas a equipos pequeños o medianos (Beck sugiere que el tamaño de los equipos se limite de 3 a 20 como máximo, otros dicen no más de 10 participantes), El entorno físico debe ser un ambiente que permita la comunicación y colaboración entre todos los miembros del equipo durante todo el tiempo Cualquier resistencia del cliente o del equipo de desarrollo hacia las prácticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboración y la relación contractual son claves), el uso de tecnologías que no tengan un ciclo rápido de realimentación o que no soporten fácilmente el cambio, etc. Falta aún un cuerpo de conocimiento consensuado respecto de los aspectos teóricos y prácticos de la utilización de metodologías ágiles, así como una mayor consolidación de los resultados de aplicación.

53 Desarrollo individual v/s Grupal
Los proyectos de desarrollo de software de manera individual, es decir abordados por una sola persona, son frecuentes en contextos particulares. Cuando se tiene poco presupuesto Se requiere automatizar pequeñas tareas Esta modalidad exige requisitos de calidad mínimos, por tanto, se requiere contar con una metodología de desarrollo de software. ¿tiene experiencia en desarrollo de proyectos Individuales? Fuente: Universidad de Pamplona

54 PSP (Personal Software Process)
El PSP® es un marco de trabajo de procesos para guiar a los desarrolladores en: •    Definir sus propios procesos •    Planear y dar seguimiento a su propio trabajo •    Administrar la calidad de sus propios productos de trabajo El PSP® es un proceso personal que al estar basado en los principios de mejora,  ayuda a la gente a establecer sus metas personales, identificar qué métodos utilizarán, medir sus trabajo y analizar los resultados, para ajustar los métodos que utilizan para cumplir sus metas. En conclusión, el PSP® es un proceso definido para ayudar a realizar mejor el trabajo, cuyo objetivo es obtener y reportar datos precisos y completos del trabajo que se realiza a nivel individual, con el fin de mejorar el proceso individual, afectando de esta manera al desempeño de todo el equipo.

55 TSP (Team Software Process) (i)
Es un modelo de referencia de ingeniería de software que provee un énfasis en los procesos, los productos y el trabajo en equipo. El TSP® toma de base los principios de PSP para realizar los procesos y principios de ingeniería de software en un ambiente de trabajo en equipo.  El TSP® enfatiza el trabajo en equipo porque: •    Los equipos no se forman mágicamente, •    Los pasos para formar un equipo no son obvios, •    Se deben entender las fortalezas/debilidades de cada miembro del equipo y cómo estas soportan el desempeño del mismo. Los equipos no son un accidente, se requiere una estrategia definida para trabajar juntos de manera coordinada, establecer responsabilidades y dar seguimiento al avance. Esto se logra teniendo metas comunes, acordando planes de acción y con un liderazgo apropiado.

56 TSP (Team Software Process) (ii)
El Team Software Process no es una capacitación, usa los principios de PSP® para poner en práctica lo aprendido en el mismo y ayudar a formar y poner en marcha equipos de alto desempeño para producir productos de clase mundial, de manera cíclica, es decir al término de cada ciclo, el equipo debe entregar una versión del producto que pueda ser probada (que sea un subconjunto del producto final), de tal manera que los productos de los ciclos combinados generan el producto final. Cada miembro del equipo, en un desarrollo TSP® planea sus actividades, da seguimiento a su trabajo y reporta su avance, controla sus propios procesos,  se involucra en la planeación y decisiones de todo el equipo y tiene roles y responsabilidades explícitas. 

57 Artefactos de un proceso
de desarrollo

58 Artefactos de un proceso de desarrollo
Dentro del Proceso de Desarrollo Unificado se denomina artefacto a todo producto o subproducto resultante del proceso. Dentro de esto se encuentra desde el propio código fuente hasta la documentación aportada por el cliente y la entregada al completarse cada hito dentro del proyecto. Para su mejor comprensión hemos agrupado todos los artefactos posibles del proceso en tres grandes grupos: Artefactos entregados por el cliente, Artefactos internos del proceso y Artefactos entregables al cliente No siempre en todo proyecto se crean los mismos artefactos, esto dependerá de las características del proyecto y los requisitos del cliente, siendo tarea de la gestión de la configuración el definir qué artefactos específicos y con qué nivel de formalidad se crearán para el proyecto en cuestión.

59 Artefactos de un proceso de desarrollo
Glosario de Términos: Sólo existe uno para todo el sistema, que contiene un conjunto de definiciones concisas para favorecer la comunicación y evitar malos entendidos entre todos los involucrados. Los miembros del proyecto utilizarán el glosario inicialmente para comprender sus términos específicos. Especificaciones de los casos de uso: Es una colección de documentos que recogen la especificación completa de cada caso de uso. Cada uno contiene los campos: nombre, descripción, actores, precondiciones, postcondiciones, flujo básico, flujos alternativos, puntos de extensión, entre otros que describen en detalle un caso de uso. Modelo de casos de uso: Es un modelo de las funciones concebidas del sistema y su entorno. Es una entrada importante a actividades de análisis, diseño y prueba. Incluye todos los actores y casos de uso del sistema con sus descripciones. Puede ser entregado directamente en el formato que utilice la herramienta de modelación o gestión empleada, o mediante un informe de este modelo que contenga toda esta información que se complementará con las Especificaciones de los casos de uso.

60 Artefactos de un proceso de desarrollo
Especificaciones suplementarias: Este artefacto captura los requerimientos del sistema que no fueron recogidos en el Modelo de casos de uso. Generalmente contiene los requerimientos no funcionales del sistema. Especificación de requisitos del software: En los casos en que la empresa cliente no desee utilizar el enfoque de casos de uso para la gestión de requisitos, podrá entregar en lugar de los 3 artefactos descritos anteriormente un solo documento que recoja las características, requisitos funcionales y no funcionales del sistema, así como otra información útil como por ejemplo: restricciones en el diseño e implementación, componentes comprados a terceros, interfases de hardware o software, etc. Documento de arquitectura del software: Este documento brinda un resumen de la arquitectura utilizando varias vistas diferentes que muestran distintos aspectos del sistema. Es un medio de comunicación entre el arquitecto de software y otros miembros del equipo del proyecto, acerca de las decisiones significativas que han sido tomadas para la arquitectura.

61 Artefactos de un proceso de desarrollo
Modelo de diseño: Es una abstracción de la implementación del sistema que normalmente se utiliza para concebir y documentar su diseño. Es un artefacto compuesto que contiene todas las clases, subsistemas, paquetes, colaboraciones y las relaciones entre ellas. También contiene las realizaciones de los casos de uso. Modelo de datos: Describe la representación física y lógica de los datos persistentes utilizados por la aplicación. Se utilizará siempre que se necesiten manejar datos persistentes. Usualmente describirá los diferentes elementos componentes de la estructura de una base de datos relacional. Mapa de navegación: Expresa la estructura de los elementos de la interfaz de usuario del sistema, junto a los caminos de navegación principales. Existirá solamente uno de estos artefactos en el sistema y por lo general será empleado para aplicaciones Web.

62 Artefactos de un proceso de desarrollo
Prototipo de la interfaz de usuario: Es un ejemplo de la interfaz de usuario que se construye para validar y/o explorar su diseño. El grado de formalidad y herramientas utilizadas para generarlo puede variar mucho de proyecto en proyecto, pudiendo ir desde solo unas cuantas imágenes de pantallas hasta un esqueleto de interfaz de usuario ejecutable producido en un ambiente de Desarrollo rápido de aplicaciones (RAD : Rapid Application Development) o un conjunto de páginas HTML interactivas. En aplicaciones Web pueden ser las imágenes de las diferentes pantallas creadas por el diseñador gráfico.

63 Artefactos internos del proceso
Plan de gestión de requisitos: Describe los artefactos de la disciplina, tipos de requisitos y sus respectivos atributos. Especifica la información que deberá ser obtenida y los mecanismos de control que deberán ser utilizados para reportar, medir, y controlar los cambios a los requisitos del producto. Plan de pruebas: Contiene la definición de los objetivos de las pruebas, los elementos que deberán ser probados, los métodos que deberán utilizarse, los recursos necesarios y documentos a entregar. Usualmente se tiene uno de estos documentos con alcance global para todo el proyecto y uno por cada iteración del ciclo de vida del producto. Guión de pruebas: Son las instrucciones paso a paso que indican como llevar a cabo una prueba. Pueden ser documentos con información textual que describa cómo realizar la prueba manualmente o archivos de instrucciones legibles por las máquinas que posibiliten la ejecución automatizada de la prueba.

64 Artefactos internos del proceso
Informe resumen de las pruebas: Organiza y muestra un análisis resumido de los resultados de las pruebas que será entregado a los miembros del equipo de calidad para su revisión y evaluación. Adicionalmente puede contener un enunciado general de la calidad relativa y ofrecer recomendaciones para futuros esfuerzos de prueba. Plan de gestión de configuración: Describe todas las actividades de Gestión de configuración y cambios que serán realizadas durante todo el ciclo de vida del proyecto. Brinda planificaciones detalladas de las actividades, responsabilidades asignadas, recursos necesarios que incluyen personal, herramientas y equipamiento. Solicitud de cambio: Los cambios a los artefactos del proyecto se proponen mediante Solicitudes de cambio (Change Requests CR). Estos se utilizan para documentar y controlar defectos, solicitudes de mejoras o cualquier otra solicitud de cambios al proyecto. El beneficio de utilizarlos es que proporcionan un registro de las decisiones y, debido a su proceso evaluativo, se asegura que los impactos de los cambios sean entendidos por todos los miembros del equipo del proyecto.

65 Artefactos internos del proceso
Plan de desarrollo de software: Es un artefacto compuesto que recoge toda la información necesaria para llevar a cabo la dirección del proyecto. Contiene otros planes no menos importantes que, al igual que éste son desarrollados desde la fase de inicio y mantenidos durante todo el ciclo de vida (Aseguramiento de la calidad, Gestión de riesgos, Métricas, Aceptación del producto y Resolución de problemas). Plan de la iteración: Es un plan más refinado que contiene un conjunto secuencial de actividades, tareas y recursos asignados a una iteración, por lo que existirá un artefacto de este tipo por cada iteración del ciclo de vida del producto. Incluye los objetivos de la iteración, que son utilizados como criterio de evaluación y miden diferentes aspectos deseables a su final, como grado de terminación de la funcionalidad planificada, niveles de calidad, rendimiento, etc. Evaluación de la iteración: Se realiza al final de la iteración y captura el grado en que se cumplió el criterio de evaluación, las lecciones aprendidas y los cambios a realizar en la planificación de las subsiguientes iteraciones en función del nuevo conocimiento adquirido. Es un artefacto esencial del enfoque iterativo de desarrollo de software.