Skip to main content

Ingenieria en software

Page 1

INGENIERIA EN SOFTWARE

¿Qué es SCRUM?

¿Qué es un método informatic o?

¿Para que sirven los métodos informátic os?

¿Qué son los métodos agiles?

¿Qué son los ciclos de vida?

¿Tipos de cliclo de vida?

1

Aquí podemos encontrar diversos datos sobre lo que un ingeniero en software podrá ocupar en un futuro Asi como poder aprender nuevos métodos de ingeniería para la aplicación del software, la creación de nuevos métodos.

Tambien podemos encontrar como las empresas utilizan métodos para la creación de proyecto utilizando métodos que ayudan al equipo a terminar un proyecto lo mas rápido y seguro posible.

1
2 INDICE 1. Descripcion del libro.............................Pag 1 2.-Caracteristicas de la información……..Pag 5 2.1.2. ¿Qué es el conocimiento?.......................Pag 5 2.1.3.-Definicion de dato… Pag 5 2.1.4.-Definicion de Hardawre………………...Pag 5 2.1.5. Definicion de sofrware………………….....Pag 6 2.1.6. Definicion de TIC……….. ………….....Pag 7 2.1.7. Definicion de Ciclo de vida del software.Pag 7 3.-Fases del ciclo de software……………Pag 8 3.1.1.-Tipos de ciclo de software………………Pag 12 4.--¿Qué son las metodologías agiles?………………………………………Pag 16 5.-SCRUM…………..................................Pag 17 5.1.1. Diferentes roles de SCRUM………...…Pag 17 5.1.2. Roles en SCRUM……………………Pag 18 5.1.3. Beneficios de SCRUM………………... Pag 19 5 1 4 -Eventos de SCRUM ……….Pag 22 5 1 5 -Artefactos de SCRUM Pag 24 5.1.6. Conclucion……………………………….Pag 26 6.-¿Qué es Xtreme Programming?..........Pag 26 6 1 1 -Valores de XP Pag 28 6.1.2.-Principios de XP………………………Pag 29 6.1.3. Diferencias entre XP y otras metodologías. Pag 30 6 1 4 -Opinion Pag 30 7.-Referencias……………………………...Pag 32
3
4 INDICE DE FIGURAS Figura 1.- Tipos de Hardware……………..…Pag 6 Figura 2.-Aplicaciones de oficina…………....Pag 6 Figura 3. Modelo de cascada……………… Pag 12 Figura 4.-Modelo Espiral………………………Pag 13 Figura 5 . Modelo prototipos………………….Pag 14 Figura 6.-Modelo en V…………………………Pag 15 Figura 7.- Metodologia Agile………………….Pag 16 Figura 8. Etapas de Scrum……………………Pag 20 Figura 9.- Evaluacion y principios de XP…….Pag 27

2

Características de la información

La información es un conjunto de datos que ya aportan nuevos conocimientos a un individuo o sistema.

2.1.2

Conocimiento

Es la adquisición de información para comprender cierta habilidad o realidad.

2.1.3

Dato

Es un fragmento de una cantidad, fracción, descripción o palabra, Los datos solo sirven después de ser procesados según una intención y relevancia.

2.1.4 Hardware

Elemento físico que compone una computadora.

5
6 Figura 1- Tipos de Hardware 2.1.5 Software Conjunto de programa que realiza una tarea, el software no tiene lugar físicamente. figura 2.- Aplicaciones de Oficina

2.1.6

Tecnologías de Información y Comunicaciones

Es un término para la tecnología de la información que enfatiza el papel de las comunicaciones unificadas son un conjunto de recursos, herramientas, equipos, programas, informáticos, aplicaciones, redes y medios; que permiten la compilación, procesamiento, almacenamiento, para la transmisión de información.

2.1.7

Ciclo de vida del software

El ciclo de vida del desarrollo de software es la estructura que contiene los procesos, actividades y tareas relacionadas con el desarrollo y mantenimiento de un producto de software, abarcando la vida completa del sistema, desde la definición de los requisitos hasta la finalización de su uso.

7

3.Fases del ciclo de vida del software

Comunicación: Este es el momento en el que un cliente solicita un producto de software determinado. Nos contacta para plasmar sus necesidades concretas y presenta su solicitud de desarrollo de software.

Planificacion y analizis

El desarrollo de software comienza con una fase inicial de planificación incluyendo un análisis de requisitos. Nos fijamos en los requisitos que piden los clientes para estudiar cuales están poco claros, incompletos, ambiguos o contradictorios. Se indaga en profundidad y se hacen demostraciones prácticas incluyendo a los usuarios clave. Los requisitos se agrupan en requisitos del usuario, requisitos funcionales y requisitos del sistema. La recolección de todos los requisitos se lleva a cabo: estudiando el software actual que tengan, entrevistando a usuarios y desarrolladores, consultando bases de datos o mediante cuestionarios.

8

Análisis del sistema

En este paso el equipo del proyecto asigna recursos y planifica el tiempo de duración del proyecto. Se buscan limitaciones del producto y se identifican los impactos del proyecto sobre toda la organización en su conjunto.

Estudio de viabilidad

Después de la recolección de requisitos, se idea un plan para procesar el software. Se analiza que parte del software cubre los requisitos de cada usuario. Se investiga la viabilidad financiera y tecnológica. Se utilizan algoritmos para saber si el proyecto de software es factible o no Diseño

En esta fase ya se comienza a visualizar la solución con la ayuda de las anteriores fases. Se hace un diseño lógico y otro físico. Se crean metadatos, diagramas o pseudocódigos. La duración de esta fase varía de un proyecto a otro.

9

Pruebas

Esta fase junto con la fase de desarrollo entra en un ciclo continuo hasta que se completan el desarrollo y las pruebas. Probamos, probamos y luego volvemos a probar tanto como sea necesario hasta que la funcionalidad sea del 100%.

Además se hacen evaluaciones para evitar errores, incluyendo la evaluación de módulos, programas, productos, y finalmente evaluación con el cliente final. Encontrar errores y su arreglarlos a tiempo es la clave para conseguir un software confiable y eficiente.

Implementación

Aquí se instala el software, se evalúa la integración, la adaptabilidad, la portabilidad y se instalan las configuraciones posteriores necesarias.

10

Mantenimiento y Funcionamiento

Por último, pero no menos importante el mantenimiento es uno de los elementos clave de éxito de cualquier proyecto. En esta fase se minimizan pequeños errores, se confirma el buen funcionamiento del software, su eficiencia y estabilidad. El proyecto ya está completado y necesitamos monitorear y mantener de forma continua para garantizar que el proyecto siga ejecutándose bien.

11
12
Tipos de ciclo de vida Modelo en cascada Las actividades de desarrollo se completan una tras otra. Las actividades de prueba solo ocurren después de que todas las actividades de desarrollo han sido completadas. figura 3.- Modelo de cascada
3.1.1

Modelo en evolutivo

Se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas se eligen en función del análisis de riesgo, comenzando por el bucle interior.

figura 4 Modelo Espiral Modelo de prototipos

El prototipo debe ser construido en poco tiempo y el diseño rápido que se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final.

13

Modelo V

En cada fase de desarrollo se incluye niveles de pruebas asociados. En este modelo las pruebas comienzan lo más pronto posible, para descubrir rápidamente los posibles errores y no esperar al final para mejorarlo

14
figura 5 Modelo Prototipos

figura 6 Modelo en V

Modelo iterativo

Consiste en la iteración de varios ciclos de vida entregando al cliente una versión mejorada al final de cada iteración.

15

figura 7. Metodologia Agile

Las metodologías agiles son un tipo herramienta que se utiliza como enfoque en la toma de decisiones en los proyectos de software, se refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde las soluciones evolucionan con el tiempo según la necesidad del proyecto.

Este tipo de metodología a dado a lugar a que empresas lo utilicen por su comodidad aparte de sus ventajas.

¿Qué ventajas? Una de las ventajas al usar metodología agile es que reducen el tiempo haci como los riesgos de los proyectos de software.

16
4
¿Qué son las metodologías agiles?

Para este tipo de metodologías tenemos muchos tipos de métodos esta, SCRUM, SCRUMBAN, MANYMORE, XTREME PROGRAMMING, KANBAN. Los mas utilizados son scrum, xtreme programming y kanban.

5

SCRUM

Se refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde las soluciones evolucionan con el tiempo según la necesidad del proyecto 5.1.1. Diferentes roles en Scrum

En Scrum, el equipo se centra en construir un software de calidad. El propietario de un proyecto Scrum se centra en definir cuáles son las características que debe tener el producto a construir (qué construir, qué no y en qué orden) y en superar cualquier obstáculo que pueda dificultar la tarea del equipo de desarrollo.

17

5.1.2

El equipo Scrum está formado por los siguientes roles:

Scrum master: Es la persona que dirige al equipo guiándolo para que cumpla con las reglas y procesos de la metodología. El Scrum master gestiona la reducción de impedimentos del proyecto y trabaja con el Propietario de Producto para maximizar el ROI. El Scrum Master se encarga de mantener Scrum al día, proporcionando coaching, mentoring y formación a los equipos en caso de que lo necesite.

Propietario de Producto o Product owner (PO): Es el representante de las partes interesadas y de los clientes que utilizan el software. Se centra en la parte de negocio y es responsable del ROI del proyecto. Traduce la visión del proyecto al equipo, valida los beneficios en historias para incorporarlas al Product Backlog y las prioriza de forma regular.

Equipo: Grupo de profesionales con los conocimientos técnicos necesarios que desarrollan el proyecto de forma conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint.

18

5.1.3

Algunos de los beneficios de SCRUM es Beneficios de la metodología Scrum Scrum tiene muchas ventajas sobre otras metodologías de desarrollo ágil. Actualmente es el marco de referencia más utilizado y fiable en la industria del software. A continuación se presentan algunos de los beneficios conocidos de Scrum:

Fácilmente escalable: Los procesos de Scrum son iterativos y se manejan dentro de períodos de trabajo específicos, lo que facilita que el equipo se concentre en funcionalidades definidas para cada período. Esto no sólo tiene el beneficio de lograr mejores entregables en línea con las necesidades del usuario, sino que también da la capacidad a los equipos de escalar los módulos en términos de funcionalidad, diseño, alcance y características de una manera ordenada, transparente y sencilla.

19

figura 8.

Etapas de Scrum

Cumplimiento de expectativas: El cliente establece sus expectativas indicando el valor que aporta cada requisito/historia del proyecto, el equipo las estima y con esta información el Propietario de Producto establece su prioridad. De forma periódica, en las demos de los sprints, el Propietario de Producto verifica que se han cumplido los requisitos y transmite el feedback al equipo. Flexibilidad ante los cambios: Reacción rápida a los cambios en los requisitos generados por las necesidades del cliente o la evolución del mercado. La metodología está diseñada para adaptarse a los requisitos cambiantes que conllevan los proyectos complejos.

20

Reducción del tiempo de comercialización: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que el producto esté completamente listo.

Mayor calidad del software: El método de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a obtener un software de mayor calidad.

Predicción oportuna: Con esta metodología se conoce la velocidad media del equipo por sprint (puntos de historia), con lo que, en consecuencia, se puede estimar cuándo estará disponible una determinada funcionalidad que aún está en el backlog.

Reducción de riesgos: El hecho de realizar las funcionalidades más valiosas en primer lugar y de conocer la velocidad con la que el equipo avanza en el proyecto, permite despejar los riesgos de forma eficaz y anticipada.

21

5.1.4

Eventos en Scrum

Cada uno de los eventos de Scrum facilita la adaptación de alguno de los aspectos del proceso, el producto, el progreso o las relaciones.

Sprint: El sprint es la unidad básica de trabajo de un equipo Scrum. Es la principal característica que marca la diferencia entre Scrum y otros modelos de desarrollo ágil.

Planificación del Sprint: El objetivo del Sprint Planning es definir qué se va a hacer en el Sprint y cómo se va a hacer. Esta reunión se realiza al inicio de cada Sprint y se define cómo se va a enfocar el proyecto a partir de las etapas y plazos del Product Backlog. Cada Sprint se compone de diferentes características.

Scrum Diario: El objetivo del Scrum Diario es evaluar el progreso y la tendencia hasta el final

22

del Sprint, sincronizando las actividades y creando un plan para las próximas 24 horas. Se trata de una breve reunión que tiene lugar diariamente durante el periodo del Sprint. Se responden tres preguntas de forma individual: ¿Qué hice ayer? ¿Qué voy a hacer hoy? ¿Qué ayuda necesito? El Scrum Master debe tratar de resolver los problemas u obstáculos que surjan.

Revisión del sprint: El objetivo de la revisión del sprint es mostrar qué trabajo se ha completado con respecto al backlog del producto para futuras entregas. Se revisa el sprint terminado, y ya debe haber un avance claro y tangible en el producto para presentarlo al cliente.

Retrospectiva del sprint: El equipo revisa los objetivos cumplidos del sprint terminado, anota lo bueno y lo malo, para no volver a repetir los errores. Esta etapa sirve para implementar mejoras desde el punto de vista del proceso de desarrollo. El objetivo de la retrospectiva del sprint es identificar las posibles mejoras del

23

proceso y generar un plan para implementarlas en el siguiente Sprint. 5.1.5 Artefactos de Scrum Los artefactos de Scrum están diseñados para garantizar la transparencia de la información clave en la toma de decisiones.

Product Backlog (PB): El backlog del producto es una lista que recoge todo lo que el producto necesita para satisfacer a los potenciales clientes. Lo elabora el propietario del producto y las funciones se priorizan en función de lo que es más y menos importante para el negocio. El objetivo es que el propietario del producto responda a la pregunta «¿Qué hay que hacer?».

Sprint Backlog (SB): Es un subconjunto de ítems del product backlog, que son seleccionados por el equipo para realizar durante el sprint en el que van a trabajar. El equipo establece la duración de cada Sprint. Por lo general, el sprint backlog se muestra en tableros físicos llamados Tableros Scrum – que hace que el proceso de desarrollo sea visible

24

para todos los que entran en el área de desarrollo.

Incremento: El Incremento es la suma de todas las tareas, casos de uso, historias de usuario, backlogs de producto y cualquier elemento que se haya desarrollado durante el sprint y que se pondrá a disposición del usuario final en forma de Software.

5.1.6

CONCLUCION

Scrum fue hecho por Incremento Jeff Sutherland y su equipo de Easel Corporation crearon el proceso Scrum para ser utilizado en los procesos de desarrollo de software, tiene la función de ser muy rápida y con menor riesgo, hoy en dia el mercado exige calidez y rapidez y SCRUM es una buena forma de lograrlo, es una metodología muy flexible gracias a sus objetivos y controles que tiene.

25

XTREME PROGRAMMING (XP)

La programación ágil es un proceso de desarrollo de software que forma parte de lo que se conoce colectivamente como metodologías ágiles. XP se basa en valores, principios y prácticas, y su objetivo es permitir que los equipos pequeños y medianos produzcan el mejor software y se adapten a las necesidades cambiantes.

Lo que distingue a XP de otros métodos ágiles es que enfatiza los aspectos técnicos del desarrollo de software. La programación extrema es exactamente cómo trabajan los ingenieros, ya que seguir las prácticas de ingeniería permite a los equipos entregar un código de alta calidad a un ritmo constante.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

26 6

figura 9. Evaluacion y principios de XP

27

6.1.1

Valores de XP

Comunicación: La falta de comunicación impide que los conocimientos fluyan dentro de un equipo. A menudo, cuando hay un problema, alguien ya sabe cómo resolverlo. Pero la falta de comunicación les impide conocer el problema o contribuir a su solución. Así, el problema acaba resolviéndose dos veces, generando residuos.

Simplicidad: La simplicidad dice que siempre hay que esforzarse por hacer lo más sencillo que funcione. A menudo se malinterpreta y se interpreta como lo más sencillo y punto, ignorando la parte de «que funciona».

Retroalimentación: La retroalimentación en las metodologías de desarrollo de software más tradicionales, tipo cascada, a menudo es «demasiado pequeña, demasiado tarde».

28

6.1.2

Principios de XP

Humanidad: Los humanos crean software para los humanos, un hecho que a menudo se pasa por alto. Pero tener en cuenta las necesidades básicas, los puntos fuertes y los puntos débiles de los humanos crea productos que los humanos quieren utilizar. Y un entorno de trabajo que te da la oportunidad de lograr y crecer, el sentimiento de pertenencia y la seguridad básica, es un lugar donde es más fácil tener en cuenta las necesidades de los demás.

Economía: En XP, los equipos prestan atención a las realidades económicas del desarrollo de software todo el tiempo, evalúan constantemente los riesgos económicos y las necesidades del proyecto.

Beneficio mutuo: Siguiendo a XP, se evitan las soluciones que benefician a una parte en detrimento de otra. Por ejemplo, las especificaciones extensas pueden ayudar a otra persona a entenderlo, pero te aleja de la implementación y lo retrasa para tus usuarios.

29

6.1.3

¿En qué se diferencia XP de las metodologías tradicionales no ágiles?

La programación extrema, que forma parte de Ágil, consiste en aceptar y dar la bienvenida al cambio en lugar de seguir planes rígidos. Se trata de un diseño iterativo en lugar de un gran diseño por adelantado.

XP se diferencia radicalmente de las metodologías tradicionales -por ejemplo, la cascada- al evitar las fases de larga duración.

6.1.4

Opinion: Scrum es un marco para ayudar a los equipos a desarrollar proyectos complejos de manera adaptativa. Scrum no dicta cómo los desarrolladores hacen el trabajo. XP, como se mencionó, pone mucho énfasis en las buenas prácticas de programación.

La mayoría de los marcos y metodologías ágiles se centran en la gestión de proyectos o productos y la organización de personas y trabajo.

30

XP acepta cambios en sus componentes. Se permite a los equipos a modificar las prácticas de acuerdo con sus necesidades específicas. Scrum, por otro lado, no es flexible. Además, Scrum es un marco que debe completar con metodologías y prácticas para hacer el trabajo. Eso significa que no solo es posible usar XP y Scrum juntos, sino que es extremadamente recomendable.

31

REFERENCI

32
ollo+de+software&bih=730&biw=1137&rlz=1C1CHB D_esMX1023MX1023&hl=es&ei=5M5sY5vlB7OekPI P6uKGwAs&ved=0ahUKEwib56G_sKP7AhUzD0QIH WqxAbgQ4dUDCA8&uact=5&oq=modelo+V+desarro llo+de+software&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQAz IFCAAQgAQyCAgAEAgQBxAeMggIABAIEAcQHjIIC AAQCBAHEB4yCAgAEAgQBxAeMggIABAIEAcQHjII CAAQCBAHEB4yCAgAEAgQBxAeMggIABAIEAcQH jIICAAQCBAHEB46CggAEEcQ1gQQsAM6BwgAEIA EEA06BggAEAcQHkoECEEYAEoECEYYAFDFNljU S2CKTmgDcAF4AIABhwKIAckRkgEGMC4xMS4xm AEAoAEByAEIwAEB&sclient=gws wiz serp What
principles,
programming
Granada, S. (2021, noviembre 10). Diferente modelos de ciclo de vida de un softwareinlogiQ. inlogiQ - InlogiQ. https://inlogiq.com/diferentes-modelos-de-ciclos-devida del software/ modelo V desarrollo de software Buscar con Google. (s/f). Google.com. Recuperado el 22 de noviembre de 2022, de https://www.google.com/search?q=modelo+V+desarr
is extreme programming (XP)? values,
and practices. (2021, junio 9). Digite; Digite Inc. https://www.digite.com/agile/extreme
xp/
33 Libro creado por Angel Izumy Tominaga Montoya Hecho el dia 23/11/2022 ITSON.GUAYMAS Guaymas,Sonora Mexico

Turn static files into dynamic content formats.

Create a flipbook
Ingenieria en software by Izumy Tominaga - Issuu