1) El documento describe varios modelos de procesos de desarrollo de software, incluyendo modelos secuenciales, en cascada, DRA, de prototipos, concurrente y ágiles como Scrum y DSDM.
2) Cada modelo se caracteriza por un conjunto de fases, roles, herramientas y principios que definen su enfoque para el desarrollo de software.
3) Los modelos ágiles como Scrum y DSDM enfatizan la colaboración continua con el cliente y la entrega iterativa e incremental de funcionalidades.
Presentación de las características, ventajas y desventajas de los modelos en la ingeniería de software. Posee una conclusión final acerca de cual es el mejor modelo de acuerdo a los criterios expuestos en la presentación.
Presentación de las características, ventajas y desventajas de los modelos en la ingeniería de software. Posee una conclusión final acerca de cual es el mejor modelo de acuerdo a los criterios expuestos en la presentación.
Desarrollo en cascada vs desarrollo agile scrumtbaires
Exposición dada por la Ing. Marcela Andrea Alvarez
ar.linkedin.com/pub/ing-marcela-andrea-alvarez/21/16a/ba3
durante el "6to Encuentro Online de Testers"
organizado por TestingBaires (www.testingbaires.com)
Tema a debatir: Agile Testing
El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios.
El proceso de desarrollo de software “es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo".
Se considera que cada etapa debe ir a continuación de la anterior. Que pone énfasis en la documentación que resulta de cada una y que es la entrada de la siguiente.
Desarrollo en cascada vs desarrollo agile scrumtbaires
Exposición dada por la Ing. Marcela Andrea Alvarez
ar.linkedin.com/pub/ing-marcela-andrea-alvarez/21/16a/ba3
durante el "6to Encuentro Online de Testers"
organizado por TestingBaires (www.testingbaires.com)
Tema a debatir: Agile Testing
El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios.
El proceso de desarrollo de software “es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo".
Se considera que cada etapa debe ir a continuación de la anterior. Que pone énfasis en la documentación que resulta de cada una y que es la entrada de la siguiente.
Los Modelos Prescriptivos de Proceso definen un conjunto distinto de actividades, acciones, tareas, flujo de trabajo, fundamentos y productos de trabajo que se requieren para software de alta calidad.
Sesión 3: Modelos prescriptivos de proceso de softwareLuis Fernández
Los Modelos Prescriptivos de Proceso definen un conjunto distinto de actividades, acciones, tareas, flujo de trabajo, fundamentos y productos de trabajo que se requieren para software de alta calidad.
A partir de este paso y en adelante el equipo de desarrollo software trabaja para tirar adelante el proyecto. El equipo se reúne con varios depositarios de dominio del problema, e intentan conseguir la máxima cantidad de información posible sobre lo que requieren. Los requisitos se contemplan y agrupan en requisitos del usuario, requisitos funcionales y requisitos del sistema. La recolección de todos los requisitos se lleva a cabo como se especifica a continuación
Estudio de viabilidad
Después de la recolección de requisitos, el equipo idea un plan para procesar el software. En esta fase, el equipo analiza si el software puede hacerse para cubrir todos los requisitos del usuario y si hay alguna posibilidad de que el software ya no sea necesario.
Un libro sin recetas, para la maestra y el maestro Fase 3.pdfsandradianelly
Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestr
1. MODELOS DE PROCESO
DE SOFTWARE
INTEGRANTES:
Chipana Lovera Mayra
Fernandez Romero Katherine Fernanda
Mamani Nina Diego Vladimir
Maquera Castaño Erick
Parisaca Nina Juan Gabriel
Quispe Alanoca Rosario Verónica
2. MODELOS DE PROCESOS
DEL SOFTWARE
DEFINICION DE MODELOS DE PROCESOS DE SOFTWARE
Un modelo de proceso de software es una descripción del
conjunto de tareas, actividades, procesos y resultados. Las
actividades de los procesos que pertenecen a un modelo
determinado son parte tanto de los procesos como del
producto software, incluyendo a las personas involucradas en
la ingeniería de software, cada uno con su respectivo papel.
Algunos ejemplos de estos tipos de modelos que se pueden
producir son:
3. Modelo secuencial lineal
Es un modelo que lleva un desarrollo
incremental, esto nos dice que se
desarrolla el software en etapas y que
después del término de una etapa no
es posible regresar a ella.
Ventajas
● Se debe tener en cuenta que fue
el primer modelo empleado, y por lo
tanto es mejor que ninguno.
● Facilita la gestión del desarrollo.
Desventajas
● En general, establecer todos los
requisitos al principio del proceso de
desarrollo es un mito inalcanzable,
Los usuarios no pueden imaginarse lo
que quieren hasta que no ven un
sistema funcionando.
● Los requisitos no se pueden
congelar mientras dura el desarrollo.
El mercado cambia, todo cambia.
4. MODELO EN CASCADA
El primer modelo de desarrollo de software que se publicó se derivó de otros
procesos de ingeniería. Éste toma las actividades fundamentales del proceso
de especificación, desarrollo, validación y evolución y las representa como
fases separadas del proceso.
Fases:
Fase de ingeniería y análisis del sistema
Fase de análisis de los requisitos
Fase de diseño
Fase de codificación
Fase de pruebas
Fase de mantenimiento
5. MODELO DRA
El modelo DRA, es un modelo de proceso del desarrollo del software lineal
secuencial que enfatiza un ciclo de desarrollo extremadamente corto (Es una
adaptación a alta velocidad del modelo lineal secuencial). El proceso DRA
permite al equipo de desarrollo crear un sistema completamente funcional
dentro de periodos muy cortos de tiempo.
VENTAJAS DE DRA DESVENTAJAS DEL DRA
Comprar puede ser más caro que construir.
● Costo de herramientas integradas y equipo
necesario.
● Progreso más difícil de medir.
● Menos eficiente.
● Menor precisión científica.
● Riesgo de revertirse a las prácticas sin control
de antaño.
● Más fallas (por síndrome de "codificar a lo
bestia").
● Prototipos pueden no escalar, un problema
mayúsculo.
● Funciones reducidas (por "timeboxing").
● Dependencia en componentes de terceros:
funcionalidad de más o de menos, problemas
legales.
● Comprar puede ahorrar dinero en
comparación con construir.
● Los entregables pueden ser fácilmente
trasladados a otra plataforma.
● El desarrollo se realiza a un nivel de
abstracción mayor. Visibilidad temprana.
● Mayor flexibilidad.
● Menor codificación manual.
● Mayor involucramiento de los usuarios.
● Posiblemente menos fallas.
● Posiblemente menor costo.
● Ciclos de desarrollo más pequeños.
● Interfaz gráfica estándar.
6. MODELO DE PROTOTIPOS
El Modelo de prototipos, en Ingeniería de software,
pertenece a los modelos de desarrollo evolutivo. El
prototipo debe ser construido en poco tiempo, usando los
programas adecuados y no se debe utilizar muchos
recursos.
Etapas
• Plan rápido.
• Modelado, diseño rápido
• Construcción del Prototipo
• Desarrollo, entrega y retroalimentación
• Comunicación
• Entrega del desarrollo final
Conclusiones
La clave es definir las reglas del juego
desde el principio; es decir, el cliente y
el desarrollador se deben poner de
acuerdo en:
Que el prototipo se construya y sirva
como un mecanismo para la definición
de requisitos.
Que el prototipo se descarte, al menos
en parte.
Que después se desarrolle el software
real con un enfoque hacia la calidad.
7. MODELO DE DESARROLLO CONCURRENTE
El modelo de desarrollo concurrente es un modelo de tipo de red donde todas las personas actúan
simultáneamente o al mismo tiempo. Este tipo de modelo se puede representar a manera de
esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
La concurrencia se logra de dos formas:
1. Las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse
con el enfoque orientado a objetos.
2. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los
cuales se pueden diseñar y realizar concurrentemente.
Ventajas
Excelente para proyectos en los que se conforman grupos de trabajo independientes.
Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
Si no se dan las condiciones señaladas no es aplicable.
Si no existen grupos de trabajo no se puede trabajar
8. Roles
• Cliente
• Programador
• Encargado de Pruebas (Tester)
• Encargado de Seguimiento
(Tracker)
• Entrenador (Coach)
. Gestor (Big Boss) Etapas o fases
• Fase de exploración
• Fase de planificación
• Fase de iteraciones
• Fase de puesta en producción
Las Metodologías o Modelos Agiles son aquellas que permiten adaptar la forma de trabajo a las
condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar
el proyecto y su desarrollo a las circunstancias especificas del entorno.
9. Definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80.
En 1995, Ken Schwaber presentó “Scrum Development Process” en OOPSLA 95 (Object-Oriented
Programming Systems & Applications conference) (SCRUM Development Process), un marco de
reglas de desarrollo de software basado en los principios de scrum.
Actividades
- Planificación de la iteración
- Ejecución de la iteración (sprint)
- Reunión diaria de sincronización del
equipo (Scrum daily meeting)
- Demostración de requisitos completados
(Sprint Demonstration)
- Retrospectiva (Sprint Retrospective)
- Re planificación del proyecto
Roles
•Cliente (Product Owner)
•Facilitador (Scrum Master) Equipo (Team)
•Equipo(team)
Herramientas
•Lista de requisitos priorizada (Product
•Backlog)
•Lista de tareas de la iteración (Sprint
•Backlog)
•Gráficos de trabajo pendiente
•(Burndown)
10. Método que provee un framework para el desarrollo ágil de software, apoyado por su continua implicación del usuario en un
desarrollo iterativo y creciente.
Desarrollado en el Reino Unido en los años 90 por un consorcio de proveedores y de expertos en la materia del desarrollo de
Sistemas de Información.
La primera versión fue terminada en 1995 y publicada en febrero del mismo año.
DSDM se centra en los proyectos de sistemas de información que son caracterizados por presupuestos y agendas apretadas.
Fases
• Fase del Pre-Proyecto
• Fase del ciclo de vida del Proyecto
- Estudio de Viabilidad
- Estudio de la Empresa
- Iteración del Modelo Funcional
- Diseño e iteración de la estructura
- Implementación
• Fase del Post-Proyecto Principios
Involucrar al cliente es la clave
El equipo de proyecto debe tener el poder
Entrega frecuente de productos
Entregar un sistema que satisface las actuales necesidades de negocio
El desarrollo es iterativo e incremental
Todos los cambios son reversibles
Alcance de alto nivel y requerimientos base-lined
Pruebas durante todo el ciclo de vida del proyecto