3. Nuestro equipo
● Mallo Quispe Jhulen Mauricio
● Mendoza Tarqui Gerardo Enrique
● Rojas Murga Andres Miguel
● Sangueza Alarcon Ivan Limberth
● Tomicha Villarroel Luis David
5. Introducción
Un proceso de software es un conjunto de actividades que conducen a
crear un producto de software, ya sea desde cero o ampliando y
modificando sistemas existentes, el producto resultante del proceso de
software debe satisfacer las exigencias del cliente, este proceso es
complicado y no existe una forma única e infalible para hacerlo ya que
cada producto tiene necesidades específicas.
7. Modelos de tipo
secuencial
Llamado algunas veces «ciclo de vida básico» o modelo en cascada»,
el modelo lineal secuencial sugiere un enfoque sistemático, secuencial,
para el desarrollo del software que comienza en un nivel de sistemas y
progresa con el análisis, diseño, codificación, pruebas y mantenimiento.
8. Modelo en cascada
Definición Análisis Diseño
El desarrollo en cascada es un
procedimiento lineal que se
caracteriza por dividir los procesos
de desarrollo en sucesivas fases de
proyecto. Al contrario que en los
modelos iterativos, cada una de
estas fases se ejecuta tan solo una
vez. Los resultados de cada una de
las fases sirven como hipótesis de
partida para la siguiente. se utiliza,
especialmente, en el desarrollo de
software.
Aquí se hace un estudio de
viabilidad se evalúan los costes,
la rentabilidad y la factibilidad
del proyecto de software y
además se reúnen los
requisitos que debe cumplir el
software para satisfacer las
necesidades que requiere el
cliente
El diseño del software se enfoca
en cuatro atributos distintos del
programa: la estructura de los
datos, la arquitectura del
software, el detalle
procedimental y la
caracterización de la interfaz. El
proceso de diseño traduce los
requisitos en una
representación del software
con la calidad requerida antes
de que comience la
codificación.
9. Modelo de desarrollo rápido de aplicaciones (RAD)
Definición
Modelado de
gestión
Modelado de
datos
El modelo de desarrollo rápido de
aplicaciones (RAD) es un modelo
que se caracteriza por tener un
ciclo de desarrollo corto, permite al
equipo de desarrollo crear un
sistema completamente funcional
dentro de períodos cortos de
tiempo (De 60 a 90 días)
El flujo de información entre las
funciones de gestión se modela
de forma que responda a las
siguientes preguntas: ¿Qué
información conduce el
proceso de gestión? ¿Qué
información se genera? ¿Quién
la genera? ¿A dónde va la
información? ¿Quién la
proceso?
El flujo de información definido
como parte de la fase de
modelado de gestión se refina
como un conjunto de objetos
de datos necesarios para
apoyar la empresa. Se definen
las características (llamadas
atributos) de cada uno de los
objetos y las relaciones entre
estos objetos.
10. Modelo de desarrollo rápido de aplicaciones (RAD)
Modelado de
proceso
Generación de
aplicaciones
Pruebas de
entrega
Los objetos de datos definidos en
la fase de modelado de datos
quedan transformados para lograr
el flujo de información necesario
para implementar una función de
gestión. Las descripciones del
proceso se crean para añadir,
modificar, suprimir, o recuperar un
objeto de datos. Es la
comunicación entre los objetos.
El RAD asume la utilización de
técnicas de cuarta generación.
En lugar de crear software con
lenguajes de programación de
tercera generación, el proceso
DRA trabaja para volver a
utilizar componentes de
programas ya existentes
(cuando es posible) o a crear
componentes reutilizables
(cuando sea necesario). En
todos los casos se utilizan
herramientas automáticas para
facilitar la construcción del
software.
El flujo de información definido
como parte de la fase de
modelado de gestión se refina
como un conjunto de objetos
de datos necesarios para
apoyar la empresa. Se definen
las características (llamadas
atributos) de cada uno de los
objetos y las relaciones entre
estos objetos.
11. Modelo de desarrollo Incremental
Definición
Definición de las
tareas y las
iteraciones
Diseño de los
incrementos
La principal diferencia del modelo
incremental con los modelos
tradicionales es que las tareas
están divididas en iteraciones, es
decir, pequeños lapsos en los
cuales se trabaja para conseguir
objetivos específicos. Con los
modelos tradicionales no pasaba
esto; era necesario esperar hasta el
final del proceso.
El flujo de información entre las
funciones de gestión se modela
de forma que responda a las
siguientes preguntas: ¿Qué
información conduce el
proceso de gestión? ¿Qué
información se genera? ¿Quién
la genera? ¿A dónde va la
información? ¿Quién la
proceso?
El flujo de información definido
como parte de la fase de
modelado de gestión se refina
como un conjunto de objetos
de datos necesarios para
apoyar la empresa. Se definen
las características (llamadas
atributos) de cada uno de los
objetos y las relaciones entre
estos objetos.
12. Modelo de desarrollo Incremental
Desarrollo del
incremento
Validación de
incrementos
Integración de
incrementos
Posteriormente se realizan las
tareas previstas y se desarrollan los
incrementos establecidos en la
etapa anterior.
Al término de cada iteración, los
responsables de la gestión del
proyecto deben dar por buenos
los incrementos que cada una
de ellas ha arrojado. Si no son
los esperados o si ha habido
algún retroceso, es necesario
volver la vista atrás y buscar las
causas de ello.
Una vez son validados, los
incrementos dan forma a lo
que se denomina línea
incremental o evolución del
proyecto en su conjunto. Cada
incremento ha contribuido al
resultado final.
13. Modelo de desarrollo Incremental
Desarrollo del
incremento
Validación de
incrementos
Integración de
incrementos
Posteriormente se realizan las
tareas previstas y se desarrollan los
incrementos establecidos en la
etapa anterior.
Al término de cada iteración, los
responsables de la gestión del
proyecto deben dar por buenos
los incrementos que cada una
de ellas ha arrojado. Si no son
los esperados o si ha habido
algún retroceso, es necesario
volver la vista atrás y buscar las
causas de ello.
Una vez son validados, los
incrementos dan forma a lo
que se denomina línea
incremental o evolución del
proyecto en su conjunto. Cada
incremento ha contribuido al
resultado final.
15. Modelos de tipo
evolutivo
Se reconoce que el software, al igual que todos los sistemas complejos,
evoluciona con el tiempo. Los requisitos de gestión y de productos a
menudo cambian conforme a que el desarrollo proceda haciendo que el
camino que lleva al producto final no sea real; las estrictas fechas tope
del mercado hacen que sea imposible finalizar un producto completo,
por lo que se debe introducir una versión limitada para cumplir la
presión competitiva y de gestión; se comprende perfectamente el
conjunto de requisitos de productos centrales o del sistema, pero
todavía se tienen que definir los detalles de extensiones del producto o
sistema.
16. Modelo Espiral
Definición Planificación
Análisis de
Riesgo
El modelo en espiral es una
combinación entre el modelo lineal
o de cascada y el modelo iterativo o
basado en prototipos que
habíamos mencionado
anteriormente. Se utiliza con éxito
en proyectos donde el coste de un
fallo es un gran riesgo, de ahí que
su principal aportación sea
considerar la gestión de esos
riesgos, algo que en los modelos
anteriores ni siquiera se menciona.
Se determinan los objetivos y el
alcance del ciclo que comienza,
tras un necesario ejercicio de
investigación. Con cada
iteración, se irá incrementando
el tamaño de software
entregado y la funcionalidad
cubierta.
Se evalúa todo aquello que
pueda afectar al proyecto
según el estado en que se
encuentre y su grado de
avance. Para ello, se diseñarán
los prototipos que deberán ser
validados en el ciclo.
17. Modelo Espiral
Implementación Evaluación Evaluación
Se desarrolla y valida el software
según el alcance acordado, el cual
está íntimamente relacionado y
condicionado con el análisis de
riesgos anterior.
Antes de proceder a realizar
otra vuelta en la espiral, se debe
prestar atención a lo que
sucedió en la vuelta anterior. Se
debe analizar en detalle si los
riesgos detectados
anteriormente ya tuvieron
solución. Básicamente, esta
fase servirá para determinar el
avance del proyecto y dar pistas
de hacia dónde debe enfocarse
la próxima iteración.
18. Modelo de desarrollo concurrente
Definición Fase de
definición
Fase conceptual
El modelo de proceso
concurrente define una serie de
acontecimientos que dispararon
transiciones de estado a estado
para cada una de las actividades de
la ingeniería del software
Donde se establecen los
objetivos y las funcionalidades
del nuevo producto. Aquí es
habitual incluir un análisis
comparativo de la
competencia, para ver en qué
se puede mejorar la oferta
existente en el mercado.
Una vez definido qué
queremos, pasamos a cómo lo
hacemos. Una de las técnicas
más habituales es el
brainstorming, idealmente con
representantes de los distintos
departamentos implicados.
19. Modelo de desarrollo concurrente
Fase de detalle y
simulación
Fase de
producción
Fase de
comercialización
El diseño se realiza gracias a
herramientas informáticas. En
ALTERTECNIA usamos BIM
(Building Information Modeling),
que nos permite no solo trabajar
en 3D sino integrar las distintas
fases del proyecto y la puesta en
común entre varios departamentos
que trabajan de forma paralela. Al
realizar simulaciones se detectan
posibles problemas antes de que
surjan físicamente.
Primero se realiza un prototipo
y una vez esté conforme se
integra la fabricación en el
proceso de producción de la
fábrica, bien adaptando
maquinaria y procesos, bien
creando una nueva línea de
producción.
Con el espíritu de mejora
continua, una vez el producto
llegue al mercado es
importante analizar el feedback
y las reacciones del consumidor
final, para poder realizar los
cambios necesarios
20. MODELO INCREMENTAL
Definición Requerimientos
Definición de las
tareas y las
iteraciones
El modelo incremental es una
unión de las mejores
funcionalidades del modelo de
cascada y del modelo de
prototipos. A medida que se
presenta un prototipo se produce
un “incremento”, que es una
iteración del proceso anterior pero
aplicando las experiencias
aprendidas del proceso anterior.
son los objetivos generales y
específicos que persigue el
proyecto.
teniendo en cuenta lo que se
busca, el siguiente paso es
hacer una lista de tareas y
agruparlas en las iteraciones
que tendrá el proyecto. Esta
agrupación no puede ser
aleatoria. Cada una debe
perseguir objetivos específicos
que la definan como tal.
21. MODELO INCREMENTAL
Diseño de los
incrementos
Desarrollo del
incremento
Validación de
incrementos
establecidas las iteraciones, es
preciso definir cuál será la
evolución del producto en cada
una de ellas. Cada iteración debe
superar a la que le ha precedido.
Esto es lo que se denomina
incremento.
posteriormente se realizan las
tareas previstas y se desarrollan
los incrementos establecidos
en la etapa anterior.
al término de cada iteración, los
responsables de la gestión del
proyecto deben dar por buenos
los incrementos que cada una
de ellas ha arrojado. Si no son
los esperados o si ha habido
algún retroceso, es necesario
volver la vista atrás y buscar las
causas de ello.
23. MODELO SCRUM
Definición Planificación del
sprint
Etapa de
desarrollo
Scrum es una metodología ágil y
flexible para gestionar el desarrollo
de software, cuyo principal objetivo
es maximizar el retorno de la
inversión para su empresa (ROI). Se
basa en construir primero la
funcionalidad de mayor valor para
el cliente y en los principios de
inspección continua, adaptación,
auto-gestión e innovación.
Si entendemos el significado
del sprint como un
miniproyecto dentro del
proyecto principal, cada uno de
ellos tiene un objetivo en
particular. Por ejemplo, el
primer intervalo puede ser
plantear cuál será el
presupuesto general a utilizar,
por lo que se necesitará de un
equipo de profesionales
expertos en el tema económico.
Cuando el trabajo del sprint
está en curso, los encargados
deben garantizar que no se
generen cambios de último
momento que puedan afectar
los objetivos del mismo.
Además, se asegura el
cumplimiento de los plazos
establecidos para su término.
24. MODELO SCRUM
Revisión del
sprint
Retroalimentación
Scrum Master
Al final del desarrollo del intervalo,
es posible analizar y evaluar los
resultados. Si es necesario, todo el
equipo colaborará para saber qué
aspectos necesitan ser cambiados.
En esta fase se fomenta la
colaboración y retroalimentación
entre todos.
Los resultados pueden ser
entregados para recibir un
feedback no solo por parte de
los profesionales dentro del
proyecto, sino también de las
personas que utilizarán
directamente lo que se desea
lograr; es decir, los clientes
potenciales. Las lecciones
aprendidas durante esta etapa
permitirán que el siguiente
sprint pueda ser mucho más
efectivo y ágil.
El Scrum Master tiene dos
funciones principales dentro
del marco de trabajo: gestionar
el proceso Scrum y ayudar a
eliminar impedimentos que
puedan afectar a la entrega del
producto. Además, se encarga
de las labores de mentoring y
formación, coaching y de
facilitar reuniones y eventos si
es necesario.
25. MODELO SCRUM
Definición Exploración
Planificación de
la Entrega
La metodología XP o
Programación Extrema es una
metodología ágil y flexible utilizada
para la gestión de proyectos.
Extreme Programming se centra
en potenciar las relaciones
interpersonales del equipo de
desarrollo como clave del éxito
mediante el trabajo en equipo, el
aprendizaje continuo y el buen
clima de trabajo.
.
En esta fase, los clientes
plantean a grandes rasgos las
historias de usuario que son de
interés para la primera entrega
del producto. Al mismo tiempo
el equipo de desarrollo se
familiariza con las
herramientas, tecnologías y
prácticas que se utilizarán en el
proyecto.
En esta fase el cliente establece
la prioridad de cada historia de
usuario, y
correspondientemente, los
programadores realizan una
estimación del esfuerzo
necesario de cada una de ellas.
Se toman acuerdos sobre el
contenido de la primera
entrega y se determina un
cronograma en conjunto con el
cliente. Una entrega debería
obtenerse en no más de tres
meses. Esta fase dura unos
pocos días.
26. MODELO SCRUM
Iteraciones Producción
Mantenimiento
Esta fase incluye varias iteraciones
sobre el sistema antes de ser
entregado. El Plan de Entrega está
compuesto por iteraciones de no
más de tres semanas. En la primera
iteración se puede intentar
establecer una arquitectura del
sistema que pueda ser utilizada
durante el resto del proyecto.
La fase de producción requiere
de pruebas adicionales y
revisiones de rendimiento antes
de que el sistema sea
trasladado al entorno del
cliente. Al mismo tiempo, se
deben tomar decisiones sobre
la inclusión de nuevas
características a la versión
actual, debido a cambios
durante esta fase.
Mientras la primera versión se
encuentra en producción, el
proyecto XP debe mantener el
sistema en funcionamiento al
mismo tiempo que desarrolla
nuevas iteraciones. Para realizar
esto se requiere de tareas de
soporte para el cliente. De esta
forma, la velocidad de
desarrollo puede bajar después
de la puesta del sistema en
producción.