SlideShare una empresa de Scribd logo
METODOLOGÍA DE DESARROLLO DE SOFTWARE
Período académico: junio 2022 – octubre 2022
Docente Ing. Martin Luzon
METODOLOGÍA DEL DESARROLLO DE SOFTWARE
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
OBJETIVO DE LA ASIGNATURA:
Aplicar una metodología de desarrollo de software durante el ciclo de vida de una
aplicación de manera autónoma.
OBJETIVO DE LA CLASE:
Al final de la clase usted podrá:
Analizar los conceptos referentes a las metodologías de desarrollo de un software
Temática
 Presentación
 Puntos relevantes de la
asignatura(Syllabus,
dosificación)
 Evaluación diagnóstica
 Metodologías de desarrollo
tradicionales.
 Metodología RUP
 Actividad en clase
 Trabajo autónomo
 Preguntas
OBJETIVOS DE UNA METODOLOGÍA
Asegurar la
uniformidad y
calidad tanto
del desarrollo
como del
sistema en sí.
Satisfacer las
necesidades
de los usuarios
del sistema.
Conseguir un
mayor nivel de
rendimiento y
eficiencia del
personal
asignado al
desarrollo.
Ajustarse a los
plazos y costes
previstos en la
planificación.
Facilitar el
mantenimiento
posterior de
los sistemas.
OBJETIVOS DE UNA METODOLOGÍA
Definir
actividades a
llevarse a cabo
en un Proyecto
de Sistema de
Información.
Unificar criterios
en la
organización
para el
desarrollo del
Sistema de
Información.
Proporcionar
puntos de
control y
revisión.
Permitir
construir un
sistema
documentado y
que sea fácil de
mantener.
Ayudar a
identificar, lo
antes posible,
cualquier
cambio que sea
necesario
realizar dentro
del proceso de
desarrollo.
METODOLOGÍAS DE DESARROLLO TRADICIONALES
Desarrollar un software implica muchas cosas, desde su
planificación hasta su utilización se deben de seguir un
sinnúmero de pasos o actividades. Hoy en día existen diversas
metodologías para hacerlo, sin embargo es necesario definir
primero la naturaleza del software antes de elegir un
determinado ciclo de vida.
 Las metodologías tradicionales imponen una disciplina de
trabajo sobre el proceso de desarrollo del software, con el fin
de conseguir un software más eficiente.
CARACTERÍSTICAS
 Una Metodología de desarrollo de software,
consiste en hacer uso de diversas herramientas,
técnicas, métodos y modelos para el desarrollo.
 Este tipo de metodología, tienen la necesidad de
ser documentadas, para que los programadores
que estarán dentro de la planeación del proyecto,
comprendan la metodología utilizada.
 Seguimiento detallado en cada una de las fases.
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
TIPOS DE METODOLOGÍAS
TRADICIONALES
CASCADA ESPIRAL PROTOTIPO
VENTAJAS
 Evaluación en cada fase que permite
cambios de objetivos.
 Es sencillo al momento de aplicar al
desarrollo de software.
 Tiene un proceso de seguimiento detallado
en cada una de las fases.
DESVENTAJAS
 La evaluación de riesgos es compleja.
 Con esto se puede poner al cliente en una situación
que puede ser muy incómoda para él.
 El cliente deberá ser capaz de describir y entender a
un gran nivel de detalle para poder acordar un
alcance del proyecto con él.
METODOLOGÍAS TRADICIONALES
VS
METODOLOGÍAS ÁGILES
 Con el paso del tiempo, las metodologías tradicionales,
simplemente no se iban a acoplar con las nuevas tecnologías, los
nuevos lenguajes y sobretodo los programadores modernos. Es por
ello que se han desarrollado lo que son las metodologías ágiles.
 Una metodología ágil, consiste principalmente en trabajar con
menos documentación de la que, como vimos, las metodologías
tradicionales utilizan en todo momento.
METODOLOGÍAS ÁGILES
 Son aquellas que permiten adaptar la forma de
trabajo a las condiciones del proyecto,
consiguiendo flexibilidad e inmediatez en la
respuesta para acoplar el proyecto y su desarrollo a
las circunstancias específicas del entorno.
 Las empresas que optan por esta metodología
consiguen gestionar sus proyectos de forma flexible,
autónoma y eficaz reduciendo los costes e
incrementando su productividad.
POR QUÉ EMPLEAR METODOLOGÍAS ÁGILES EN SU
EMPRESA
 Mejoran la satisfacción del cliente dado que se involucrará y comprometerá
a lo largo de todo el proyecto.
 En cada etapa se informará al cliente de los logros y progresos del mismo,
con la visión de involucrarlo directamente para sumar su experiencia y
conocimiento.
 Optimizar las características del producto final obteniendo en todo momento
una visión completa de su estado.
POR QUÉ EMPLEAR METODOLOGÍAS ÁGILES EN SU
EMPRESA
 Mejora de la motivación e implicación del equipo de desarrollo, las metodologías
ágiles permiten a todos los miembros del equipo conocer el estado del proyecto
en cualquier momento, con esto se logra que todos los miembros del equipo
acepten los compromisos del mismo.
 Permite ahorrar tiempo y costes el desarrollo ágil trabaja de un modo más
eficiente y rápido, con esto se logra cumplir de forma estricta el presupuesto y
los plazos pactados dentro de un proyecto.
Taller sobre las Metodologías Tradicionales
 Defina a cada Metodología
 Detalle 2 características por cada
metodología tradicional
 Mencione los roles de cada una de las
metodologías y elija un rol el cual usted
considere el mas importante dentro del
proceso
Preguntas sobre el tema tratado
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
METODOLOGÍA TRADICIONAL RUP
 Entre las principales metodologías tradicionales tenemos los
modelos conocidos como RUP y MSF, que centran su atención en
llevar una documentación exhaustiva de todo el proyecto y además
en cumplir con un plan de proyecto, definido todo esto, en la fase
inicial del desarrollo del proyecto.
RUP es un proceso formal: Provee un acercamiento disciplinado para
asignar tareas y responsabilidades dentro de una organización de
desarrollo.
CARACTERÍSTICAS DE LA METODOLOGÍA RUP
 Forma disciplinada de asignar tareas y responsabilidades.
 Desarrollo iterativo.
 Administración de requisitos.
 Verificación de calidad de software.
 Pretende utilizar las mejores prácticas de desarrollo de software.
FASES DE LA METODOLOGÍA RUP
 RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones
en número variable según el proyecto y en las que se hace un mayor o menor
esfuerzo en los distintas actividades.
FASES DE LA METODOLOGÍA RUP
01
02
03
04
INICIO ELABORACIÓN
TRANSICIÓN CONSTRUCCIÓN
FASE 1: INICIO
 Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión
muy general de la arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
 La fase de iniciación contiene los flujos de trabajo necesarios para el acuerdo de las
partes interesadas con los objetivos, la arquitectura y la planificación del proyecto.
FASE 1: INICIO
 En esta etapa, los requisitos esenciales del sistema se transforman en los casos
de uso, esto conlleva a un proceso corto y se utiliza para definir si es factible para
continuar con el proyecto y definir los riesgos y el coste del proyecto.
 En esta fase se establece el caso del negocio para el sistema y se
delimita el alcance del proyecto. Para lograrlo, es necesario identificar
todas las entidades con las que el sistema va a interactuar (actores)
y se define la naturaleza de esta interacción a alto nivel. Lo que
implica identificar todos los casos de uso y describir algunos (los más
significativos).
 El caso de negocio incluye criterio de éxito, evaluación de riesgos y
estimación de recursos necesarios, y un plan de fase que muestre las
fechas de las etapas principales.
ENTREGABLES AL FINAL DE LA FASE
 Documento de visión: Visión general de requerimientos, características
clave y restricciones principales.
 Modelo de casos de uso inicial
 Glosario de proyecto inicial
 Caso de negocio Inicial: Incluye contexto del negocio, criterio de éxito y
pronóstico financiero
 Evaluación de riesgos inicial
 Modelo de negocio, en caso de ser necesario
Los criterios de evaluación para la fase de Inicio son:
 Concurrencia de las partes interesadas en la definición de alcance y estimación de
costos/programas (horarios).
 Evidencia de entendimiento de los requerimientos mediante la comprobación de los
casos de uso primarios.
 Credibilidad de los estimados de costos/programas, prioridades, riesgos y proceso
de desarrollo.
 Detalle y extensión de cualquier prototipo arquitectónico que se ha desarrollado.
 Gastos actuales Vs. Gastos planeados.
FASE 2: ELABORACIÓN
 La elaboración consiste en la preparación para el diseño del sistema, como
complemento de la documentación de casos de uso, frente a la arquitectura del
sistema, revisar el modelo de negocio para el proyecto e iniciar la versión del
manual del usuario y se debe tener las siguientes aceptaciones:
 Descripción del producto si es estable ? El plan del proyecto es fiable?; Los costos
son elegibles?
 El propósito de la fase de elaboración es analizar el dominio del problema,
establecer un fundamento arquitectónico, desarrollar el plan del proyecto y eliminar
los elementos de mayor riesgo para el proyecto. Para lograr estos objetivos, se
debe tener una vista del cuadro completo del sistema. Las decisiones sobre la
arquitectura se deben hacer entendiendo el sistema completo: su alcance,
requerimientos funcionales y no funcionales como requerimientos de rendimiento.
El resultado de la fase de elaboración es:
 Un modelo de caso de uso (completo por lo menos el 80%), en donde todos los
casos de uso y actores han sido identificados y más casos de uso han sido
elaborados.
 Requerimientos suplementarios capturando lo requerimientos no funcionales y
cualquier requerimiento que no esté asociado con un caso de uso específico.
 Descripción de una Arquitectura de Software.
 Prototipo arquitectónico ejecutable.
 Lista de riesgos y casos de negocio revisados.
 Un plan de desarrollo para el proyecto global, incluyendo el plan del proyecto
desglosado, mostrando iteraciones y criterios de evaluación para cada iteración.
 Un caso de desarrollo actualizado especificando el proceso que se usará.
 Un manual de usuario preliminar
Al final de la fase de elaboración se da el segundo mayor hito
del ciclo de vida. En este punto se examina los objetivos y
alcance detallados del sistema, la selección de la arquitectura
y la resolución de los mayores riesgos.
Los criterios de evaluación para esta fase deben responder las
siguientes preguntas:
• ¿La visión del producto es estable?
• ¿La arquitectura es estable?
• ¿La demostración ejecutable muestra que los elementos de mayor riesgo
han sido direccionados y realmente resueltos?
• ¿El plan para la construcción de la fase fue lo suficientemente detallado y
preciso? ¿Está respaldado con una base de estimaciones creíble?
• ¿Todas las partes interesadas están de acuerdo en que la visión actual
puede ser alcanzada si el plan actual se ejecuta para desarrollar el sistema
completo, en el contexto de la arquitectura actual?
• ¿Los gastos actuales vs. los gastos planeados son aceptables?
FASE 3: CONSTRUCCIÓN
 En la fase de construcción, el desarrollo físico del software se inicia, códigos
de programación y las respectivas pruebas.
 Se debe aceptar las pruebas para un proceso estable, y el código del
sistema puesto que son líneas base para su desarrollo.
En la fase de construcción, todos los componentes que faltan y las
características de la aplicación se desarrollan e integran en el
producto, y todas las características se prueban.
La fase de construcción es de cierto modo un proceso de manufactura
que pone énfasis en manejar los recursos y controlar las operaciones
para optimizar costos, programaciones y calidad.
Como mínimo consiste de:
• Producto de software integrado
en la plataforma adecuada.
• Manuales de usuario.
• Descripción de la versión actual.
El criterio de evaluación para la fase de construcción debe
responder las siguientes preguntas:
• ¿La versión del producto es suficientemente estable y madura para
ser desplegada a la comunidad de usuarios?
• ¿Están todas las partes interesadas listas para la transición en la
comunidad de usuarios?
• ¿Los costos actuales vs. los costos planeados siguen siendo
aceptables?
FASE 4: TRANSICIÓN
 En esta fase es la entrega de software, que se lleva a cabo el plan de
despliegue y entrega, el seguimiento y la calidad del software.
 Es la entrega del producto, se verifica la satisfacción del cliente.
 En esta etapa también se lleva a cabo la formación de los usuarios que viene
a ser las capacitaciones al personal encargado del manejo del sistema.
El propósito de la fase de transición es justamente la transición del producto de
software en la comunidad de usuarios.
Una vez que el producto se ha entregado al usuario final, surgen inconvenientes y
requieren nuevas versiones, corregir algunos problemas o terminar las
características que fueron pospuestas.
La fase de transición se da cuando una línea base está suficientemente avanzada
para ser desplegada en el dominio del usuario final.
Esto requiere casi siempre que algunos subconjuntos utilizables del sistema se
hayan completado en un nivel aceptable de calidad y que la documentación de
usuario esté disponible de manera que la transición de resultados positivos para
todas las partes.
En este punto del ciclo de vida la retroalimentación de los usuarios
debe ser tomada primariamente para ajustar, configurar, instalar y
ver las dificultades de usabilidad del producto.
Los objetivos primarios de la fase de transición incluyen:
• Lograr que el usuario pueda usar el producto por sí mismo.
• Lograr que la concurrencia desplegada de las partes interesadas
esté completa y consistente con el criterio de evaluación de la
visión.
• Lograr la línea base del producto final tan rápida y
económicamente efectiva como sea posible.
Al final de la fase de transición se da el cuarto hito mayor del
proyecto.
En este punto se decide si los objetivos fueron logrados y si se
debería empezar otro ciclo de desarrollo.
Los criterios de evaluación para esta fase responden las siguientes
preguntas:
• ¿El usuario está satisfecho?
• ¿Los costos actuales vs. los costos planeados siguen siendo
aceptables?
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
Preguntas sobre el tema tratado
TRABAJO AUTÓNOMO
 De las fases de la metodología RUP revisadas en clases, seleccione los puntos más
relevantes que usted considere y plasme en un organizador gráfico.
 Fecha de presentación: martes 14 de JUNIO del 2022 (19H50)
Nombre del archivo: APELLIDO_NOMBRE_DEBER1
Formato de presentación: PDF
Subir al enlace compartido por el docente.
Palabras
Iteración: Es el acto de repetir un proceso, para generar una
secuencia de resultados, con el objetivo de acercarse a un propósito
o resultado deseado.
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx

Más contenido relacionado

Similar a SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx

Desarrollo de Sistemas de Información
Desarrollo de Sistemas de InformaciónDesarrollo de Sistemas de Información
Desarrollo de Sistemas de Información
Danianny Verónica Senju
 
Metodología tradicional
Metodología tradicionalMetodología tradicional
Metodología tradicional
Jesenia Escobar
 
Metodologia merinde y rup
Metodologia merinde y rupMetodologia merinde y rup
Metodologia merinde y rup
Reinaldo Betancourt Garcia
 
metodologia agil.ppt
metodologia agil.pptmetodologia agil.ppt
metodologia agil.ppt
brian roa
 
Proyectos I
Proyectos IProyectos I
Metodologia casacad y msf convertir a pdf
Metodologia casacad y msf convertir a pdfMetodologia casacad y msf convertir a pdf
Metodologia casacad y msf convertir a pdf
WENDY GAVILANEZ ESPINOZA
 
Administracion de proyectos software i estudiantes
Administracion de proyectos software i estudiantesAdministracion de proyectos software i estudiantes
Administracion de proyectos software i estudiantes
Cyber Brel'R
 
Metodologias
MetodologiasMetodologias
Metodologias
Norerod
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
mireya2022
 
Modelos de Desarrollo
Modelos de DesarrolloModelos de Desarrollo
Modelos de Desarrollo
ALLSOFT
 
metodologia
metodologiametodologia
metodologia
mariasantiago24
 
METODOLOGIAS.pptx
METODOLOGIAS.pptxMETODOLOGIAS.pptx
METODOLOGIAS.pptx
juan gonzalez
 
Ingeniería de Software - Isummit 2010
Ingeniería de Software - Isummit 2010Ingeniería de Software - Isummit 2010
Ingeniería de Software - Isummit 2010
acmedinaj
 
Rup
RupRup
SEMANA 4-5-6.pptx
SEMANA 4-5-6.pptxSEMANA 4-5-6.pptx
SEMANA 4-5-6.pptx
J Martin Luzon
 
Las metodologías usadas en el Desarrollo de SW en el Perú
Las metodologías usadas en el Desarrollo de SW en el PerúLas metodologías usadas en el Desarrollo de SW en el Perú
Las metodologías usadas en el Desarrollo de SW en el Perú
Pagina web Peru - F5mas
 
Fase 7. Proyecto Final
Fase 7. Proyecto FinalFase 7. Proyecto Final
Fase 7. Proyecto Final
elecramirez
 
Rup
RupRup
Clase_iso12207.pptx
Clase_iso12207.pptxClase_iso12207.pptx
Clase_iso12207.pptx
Eduar Samuel Posada Giraldo
 
Metodologias de desarrollo de software
Metodologias de desarrollo de softwareMetodologias de desarrollo de software
Metodologias de desarrollo de software
hernandezcris
 

Similar a SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx (20)

Desarrollo de Sistemas de Información
Desarrollo de Sistemas de InformaciónDesarrollo de Sistemas de Información
Desarrollo de Sistemas de Información
 
Metodología tradicional
Metodología tradicionalMetodología tradicional
Metodología tradicional
 
Metodologia merinde y rup
Metodologia merinde y rupMetodologia merinde y rup
Metodologia merinde y rup
 
metodologia agil.ppt
metodologia agil.pptmetodologia agil.ppt
metodologia agil.ppt
 
Proyectos I
Proyectos IProyectos I
Proyectos I
 
Metodologia casacad y msf convertir a pdf
Metodologia casacad y msf convertir a pdfMetodologia casacad y msf convertir a pdf
Metodologia casacad y msf convertir a pdf
 
Administracion de proyectos software i estudiantes
Administracion de proyectos software i estudiantesAdministracion de proyectos software i estudiantes
Administracion de proyectos software i estudiantes
 
Metodologias
MetodologiasMetodologias
Metodologias
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Modelos de Desarrollo
Modelos de DesarrolloModelos de Desarrollo
Modelos de Desarrollo
 
metodologia
metodologiametodologia
metodologia
 
METODOLOGIAS.pptx
METODOLOGIAS.pptxMETODOLOGIAS.pptx
METODOLOGIAS.pptx
 
Ingeniería de Software - Isummit 2010
Ingeniería de Software - Isummit 2010Ingeniería de Software - Isummit 2010
Ingeniería de Software - Isummit 2010
 
Rup
RupRup
Rup
 
SEMANA 4-5-6.pptx
SEMANA 4-5-6.pptxSEMANA 4-5-6.pptx
SEMANA 4-5-6.pptx
 
Las metodologías usadas en el Desarrollo de SW en el Perú
Las metodologías usadas en el Desarrollo de SW en el PerúLas metodologías usadas en el Desarrollo de SW en el Perú
Las metodologías usadas en el Desarrollo de SW en el Perú
 
Fase 7. Proyecto Final
Fase 7. Proyecto FinalFase 7. Proyecto Final
Fase 7. Proyecto Final
 
Rup
RupRup
Rup
 
Clase_iso12207.pptx
Clase_iso12207.pptxClase_iso12207.pptx
Clase_iso12207.pptx
 
Metodologias de desarrollo de software
Metodologias de desarrollo de softwareMetodologias de desarrollo de software
Metodologias de desarrollo de software
 

Más de J Martin Luzon

USO DEL MODELO DE CAPAS TCP/IP Y MODELO OSI
USO DEL MODELO DE CAPAS TCP/IP Y MODELO OSIUSO DEL MODELO DE CAPAS TCP/IP Y MODELO OSI
USO DEL MODELO DE CAPAS TCP/IP Y MODELO OSI
J Martin Luzon
 
SEMANA 13-14.pptx
SEMANA 13-14.pptxSEMANA 13-14.pptx
SEMANA 13-14.pptx
J Martin Luzon
 
SEMANA 11.pptx
SEMANA 11.pptxSEMANA 11.pptx
SEMANA 11.pptx
J Martin Luzon
 
SEMANA 12 PENSAMIENTO CRÍTICO.pptx
SEMANA 12 PENSAMIENTO CRÍTICO.pptxSEMANA 12 PENSAMIENTO CRÍTICO.pptx
SEMANA 12 PENSAMIENTO CRÍTICO.pptx
J Martin Luzon
 
SEMANA 10 EL PENSAMIENTO LATERAL.pptx
SEMANA 10 EL PENSAMIENTO LATERAL.pptxSEMANA 10 EL PENSAMIENTO LATERAL.pptx
SEMANA 10 EL PENSAMIENTO LATERAL.pptx
J Martin Luzon
 
SEMANA 7-8_metodologia (1).pptx
SEMANA 7-8_metodologia (1).pptxSEMANA 7-8_metodologia (1).pptx
SEMANA 7-8_metodologia (1).pptx
J Martin Luzon
 
LOGICA
LOGICA LOGICA
SEMANA 2 INTELIGENCIAS MÚLTIPLES.pdf
SEMANA 2 INTELIGENCIAS MÚLTIPLES.pdfSEMANA 2 INTELIGENCIAS MÚLTIPLES.pdf
SEMANA 2 INTELIGENCIAS MÚLTIPLES.pdf
J Martin Luzon
 
SEMANA 1 LA AUTOESTIMA Y SUS COMPONENTES.pdf
SEMANA 1 LA AUTOESTIMA Y SUS COMPONENTES.pdfSEMANA 1 LA AUTOESTIMA Y SUS COMPONENTES.pdf
SEMANA 1 LA AUTOESTIMA Y SUS COMPONENTES.pdf
J Martin Luzon
 
normativa-que-rige-el-comercio-electrnico.pptx
normativa-que-rige-el-comercio-electrnico.pptxnormativa-que-rige-el-comercio-electrnico.pptx
normativa-que-rige-el-comercio-electrnico.pptx
J Martin Luzon
 
comercio electrónico
comercio electrónicocomercio electrónico
comercio electrónico
J Martin Luzon
 
Formulas EXCEL
Formulas EXCELFormulas EXCEL
Formulas EXCEL
J Martin Luzon
 
Metodologías agiles
Metodologías agiles Metodologías agiles
Metodologías agiles
J Martin Luzon
 
Ciclo de-vida-del-software-80150943
Ciclo de-vida-del-software-80150943Ciclo de-vida-del-software-80150943
Ciclo de-vida-del-software-80150943
J Martin Luzon
 
paradigmas de programación
paradigmas de programaciónparadigmas de programación
paradigmas de programación
J Martin Luzon
 
tipos de comercio electronico
tipos de comercio electronicotipos de comercio electronico
tipos de comercio electronico
J Martin Luzon
 
SISTEMA DE NUMERACION
SISTEMA DE NUMERACION SISTEMA DE NUMERACION
SISTEMA DE NUMERACION
J Martin Luzon
 
01. teoria de conjuntos
01. teoria de conjuntos01. teoria de conjuntos
01. teoria de conjuntos
J Martin Luzon
 
TIPO DE REDES
TIPO DE REDESTIPO DE REDES
TIPO DE REDES
J Martin Luzon
 

Más de J Martin Luzon (20)

USO DEL MODELO DE CAPAS TCP/IP Y MODELO OSI
USO DEL MODELO DE CAPAS TCP/IP Y MODELO OSIUSO DEL MODELO DE CAPAS TCP/IP Y MODELO OSI
USO DEL MODELO DE CAPAS TCP/IP Y MODELO OSI
 
SEMANA 13-14.pptx
SEMANA 13-14.pptxSEMANA 13-14.pptx
SEMANA 13-14.pptx
 
SEMANA 11.pptx
SEMANA 11.pptxSEMANA 11.pptx
SEMANA 11.pptx
 
SEMANA 12 PENSAMIENTO CRÍTICO.pptx
SEMANA 12 PENSAMIENTO CRÍTICO.pptxSEMANA 12 PENSAMIENTO CRÍTICO.pptx
SEMANA 12 PENSAMIENTO CRÍTICO.pptx
 
SEMANA 10 EL PENSAMIENTO LATERAL.pptx
SEMANA 10 EL PENSAMIENTO LATERAL.pptxSEMANA 10 EL PENSAMIENTO LATERAL.pptx
SEMANA 10 EL PENSAMIENTO LATERAL.pptx
 
SEMANA 7-8_metodologia (1).pptx
SEMANA 7-8_metodologia (1).pptxSEMANA 7-8_metodologia (1).pptx
SEMANA 7-8_metodologia (1).pptx
 
LOGICA
LOGICA LOGICA
LOGICA
 
SEMANA 2 INTELIGENCIAS MÚLTIPLES.pdf
SEMANA 2 INTELIGENCIAS MÚLTIPLES.pdfSEMANA 2 INTELIGENCIAS MÚLTIPLES.pdf
SEMANA 2 INTELIGENCIAS MÚLTIPLES.pdf
 
SEMANA 1 LA AUTOESTIMA Y SUS COMPONENTES.pdf
SEMANA 1 LA AUTOESTIMA Y SUS COMPONENTES.pdfSEMANA 1 LA AUTOESTIMA Y SUS COMPONENTES.pdf
SEMANA 1 LA AUTOESTIMA Y SUS COMPONENTES.pdf
 
normativa-que-rige-el-comercio-electrnico.pptx
normativa-que-rige-el-comercio-electrnico.pptxnormativa-que-rige-el-comercio-electrnico.pptx
normativa-que-rige-el-comercio-electrnico.pptx
 
comercio electrónico
comercio electrónicocomercio electrónico
comercio electrónico
 
Formulas EXCEL
Formulas EXCELFormulas EXCEL
Formulas EXCEL
 
excel
excelexcel
excel
 
Metodologías agiles
Metodologías agiles Metodologías agiles
Metodologías agiles
 
Ciclo de-vida-del-software-80150943
Ciclo de-vida-del-software-80150943Ciclo de-vida-del-software-80150943
Ciclo de-vida-del-software-80150943
 
paradigmas de programación
paradigmas de programaciónparadigmas de programación
paradigmas de programación
 
tipos de comercio electronico
tipos de comercio electronicotipos de comercio electronico
tipos de comercio electronico
 
SISTEMA DE NUMERACION
SISTEMA DE NUMERACION SISTEMA DE NUMERACION
SISTEMA DE NUMERACION
 
01. teoria de conjuntos
01. teoria de conjuntos01. teoria de conjuntos
01. teoria de conjuntos
 
TIPO DE REDES
TIPO DE REDESTIPO DE REDES
TIPO DE REDES
 

Último

SEP. Presentación. Taller Intensivo FCD. Julio 2024.pdf
SEP. Presentación. Taller Intensivo FCD. Julio 2024.pdfSEP. Presentación. Taller Intensivo FCD. Julio 2024.pdf
SEP. Presentación. Taller Intensivo FCD. Julio 2024.pdf
GavieLitiumGarcia
 
Fundamentos del diseño audiovisual para presentaciones y vídeos (2 de julio d...
Fundamentos del diseño audiovisual para presentaciones y vídeos (2 de julio d...Fundamentos del diseño audiovisual para presentaciones y vídeos (2 de julio d...
Fundamentos del diseño audiovisual para presentaciones y vídeos (2 de julio d...
Cátedra Banco Santander
 
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
nelsontobontrujillo
 
Filigramma #17, revista literaria del Círculo de Escritores Sabersinfin
Filigramma #17, revista literaria del Círculo de Escritores SabersinfinFiligramma #17, revista literaria del Círculo de Escritores Sabersinfin
Filigramma #17, revista literaria del Círculo de Escritores Sabersinfin
Sabersinfin Portal
 
PPT: Un día en el ministerio de Jesús.pptx
PPT: Un día en el ministerio de Jesús.pptxPPT: Un día en el ministerio de Jesús.pptx
PPT: Un día en el ministerio de Jesús.pptx
https://gramadal.wordpress.com/
 
Cultura Organizacional con Responsabilidad Social Empresarial.pdf
Cultura Organizacional con Responsabilidad Social Empresarial.pdfCultura Organizacional con Responsabilidad Social Empresarial.pdf
Cultura Organizacional con Responsabilidad Social Empresarial.pdf
JonathanCovena1
 
Toxina Botulínica (Botox)
Toxina Botulínica (Botox)Toxina Botulínica (Botox)
Toxina Botulínica (Botox)
Edwin Daniel Maldonado Domínguez
 
SEMANAS DE GESTION 2024 para trabajo escolar
SEMANAS DE GESTION 2024 para trabajo escolarSEMANAS DE GESTION 2024 para trabajo escolar
SEMANAS DE GESTION 2024 para trabajo escolar
JuanPabloII10
 
CUIDADO INTEGRAL DE SALUD DE LA FAMILIA.pdf
CUIDADO INTEGRAL DE SALUD DE LA FAMILIA.pdfCUIDADO INTEGRAL DE SALUD DE LA FAMILIA.pdf
CUIDADO INTEGRAL DE SALUD DE LA FAMILIA.pdf
JovannyAguilarGestor
 
Curación de contenidos (1 de julio de 2024)
Curación de contenidos (1 de julio de 2024)Curación de contenidos (1 de julio de 2024)
Curación de contenidos (1 de julio de 2024)
Cátedra Banco Santander
 
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
nelsontobontrujillo
 
03. SESION PERSONAL-PRIMEROS POBLADORES DEL PERÚ.docx
03. SESION PERSONAL-PRIMEROS POBLADORES  DEL PERÚ.docx03. SESION PERSONAL-PRIMEROS POBLADORES  DEL PERÚ.docx
03. SESION PERSONAL-PRIMEROS POBLADORES DEL PERÚ.docx
Giuliana500489
 
Matriz de relación mixta DO - Adaptación
Matriz de relación mixta DO - AdaptaciónMatriz de relación mixta DO - Adaptación
Matriz de relación mixta DO - Adaptación
JonathanCovena1
 
Lec. 02 Un día en el ministerio de Jesús.pdf
Lec. 02 Un día en el ministerio de Jesús.pdfLec. 02 Un día en el ministerio de Jesús.pdf
Lec. 02 Un día en el ministerio de Jesús.pdf
Alejandrino Halire Ccahuana
 
Crear infografías: Iniciación a Canva (1 de julio de 2024)
Crear infografías: Iniciación a Canva (1 de julio de 2024)Crear infografías: Iniciación a Canva (1 de julio de 2024)
Crear infografías: Iniciación a Canva (1 de julio de 2024)
Cátedra Banco Santander
 
PLAN DE TRABAJO DIA DEL LOGRO 2024 URP.docx
PLAN DE TRABAJO DIA DEL LOGRO 2024 URP.docxPLAN DE TRABAJO DIA DEL LOGRO 2024 URP.docx
PLAN DE TRABAJO DIA DEL LOGRO 2024 URP.docx
william antonio Chacon Robles
 
Un clavado a tu cerebro - Doctor Eduardo Calixto
Un clavado a tu cerebro - Doctor Eduardo CalixtoUn clavado a tu cerebro - Doctor Eduardo Calixto
Un clavado a tu cerebro - Doctor Eduardo Calixto
XymbyAustin
 
Taller Intensivo de Formación Continua 2024
Taller Intensivo de Formación Continua 2024Taller Intensivo de Formación Continua 2024
Taller Intensivo de Formación Continua 2024
maria larios
 
Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)
Cátedra Banco Santander
 
El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........
DenisseGonzalez805225
 

Último (20)

SEP. Presentación. Taller Intensivo FCD. Julio 2024.pdf
SEP. Presentación. Taller Intensivo FCD. Julio 2024.pdfSEP. Presentación. Taller Intensivo FCD. Julio 2024.pdf
SEP. Presentación. Taller Intensivo FCD. Julio 2024.pdf
 
Fundamentos del diseño audiovisual para presentaciones y vídeos (2 de julio d...
Fundamentos del diseño audiovisual para presentaciones y vídeos (2 de julio d...Fundamentos del diseño audiovisual para presentaciones y vídeos (2 de julio d...
Fundamentos del diseño audiovisual para presentaciones y vídeos (2 de julio d...
 
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
 
Filigramma #17, revista literaria del Círculo de Escritores Sabersinfin
Filigramma #17, revista literaria del Círculo de Escritores SabersinfinFiligramma #17, revista literaria del Círculo de Escritores Sabersinfin
Filigramma #17, revista literaria del Círculo de Escritores Sabersinfin
 
PPT: Un día en el ministerio de Jesús.pptx
PPT: Un día en el ministerio de Jesús.pptxPPT: Un día en el ministerio de Jesús.pptx
PPT: Un día en el ministerio de Jesús.pptx
 
Cultura Organizacional con Responsabilidad Social Empresarial.pdf
Cultura Organizacional con Responsabilidad Social Empresarial.pdfCultura Organizacional con Responsabilidad Social Empresarial.pdf
Cultura Organizacional con Responsabilidad Social Empresarial.pdf
 
Toxina Botulínica (Botox)
Toxina Botulínica (Botox)Toxina Botulínica (Botox)
Toxina Botulínica (Botox)
 
SEMANAS DE GESTION 2024 para trabajo escolar
SEMANAS DE GESTION 2024 para trabajo escolarSEMANAS DE GESTION 2024 para trabajo escolar
SEMANAS DE GESTION 2024 para trabajo escolar
 
CUIDADO INTEGRAL DE SALUD DE LA FAMILIA.pdf
CUIDADO INTEGRAL DE SALUD DE LA FAMILIA.pdfCUIDADO INTEGRAL DE SALUD DE LA FAMILIA.pdf
CUIDADO INTEGRAL DE SALUD DE LA FAMILIA.pdf
 
Curación de contenidos (1 de julio de 2024)
Curación de contenidos (1 de julio de 2024)Curación de contenidos (1 de julio de 2024)
Curación de contenidos (1 de julio de 2024)
 
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
 
03. SESION PERSONAL-PRIMEROS POBLADORES DEL PERÚ.docx
03. SESION PERSONAL-PRIMEROS POBLADORES  DEL PERÚ.docx03. SESION PERSONAL-PRIMEROS POBLADORES  DEL PERÚ.docx
03. SESION PERSONAL-PRIMEROS POBLADORES DEL PERÚ.docx
 
Matriz de relación mixta DO - Adaptación
Matriz de relación mixta DO - AdaptaciónMatriz de relación mixta DO - Adaptación
Matriz de relación mixta DO - Adaptación
 
Lec. 02 Un día en el ministerio de Jesús.pdf
Lec. 02 Un día en el ministerio de Jesús.pdfLec. 02 Un día en el ministerio de Jesús.pdf
Lec. 02 Un día en el ministerio de Jesús.pdf
 
Crear infografías: Iniciación a Canva (1 de julio de 2024)
Crear infografías: Iniciación a Canva (1 de julio de 2024)Crear infografías: Iniciación a Canva (1 de julio de 2024)
Crear infografías: Iniciación a Canva (1 de julio de 2024)
 
PLAN DE TRABAJO DIA DEL LOGRO 2024 URP.docx
PLAN DE TRABAJO DIA DEL LOGRO 2024 URP.docxPLAN DE TRABAJO DIA DEL LOGRO 2024 URP.docx
PLAN DE TRABAJO DIA DEL LOGRO 2024 URP.docx
 
Un clavado a tu cerebro - Doctor Eduardo Calixto
Un clavado a tu cerebro - Doctor Eduardo CalixtoUn clavado a tu cerebro - Doctor Eduardo Calixto
Un clavado a tu cerebro - Doctor Eduardo Calixto
 
Taller Intensivo de Formación Continua 2024
Taller Intensivo de Formación Continua 2024Taller Intensivo de Formación Continua 2024
Taller Intensivo de Formación Continua 2024
 
Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)
 
El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........
 

SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx

  • 1. METODOLOGÍA DE DESARROLLO DE SOFTWARE Período académico: junio 2022 – octubre 2022 Docente Ing. Martin Luzon METODOLOGÍA DEL DESARROLLO DE SOFTWARE
  • 3. OBJETIVO DE LA ASIGNATURA: Aplicar una metodología de desarrollo de software durante el ciclo de vida de una aplicación de manera autónoma. OBJETIVO DE LA CLASE: Al final de la clase usted podrá: Analizar los conceptos referentes a las metodologías de desarrollo de un software
  • 4. Temática  Presentación  Puntos relevantes de la asignatura(Syllabus, dosificación)  Evaluación diagnóstica  Metodologías de desarrollo tradicionales.  Metodología RUP  Actividad en clase  Trabajo autónomo  Preguntas
  • 5. OBJETIVOS DE UNA METODOLOGÍA Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí. Satisfacer las necesidades de los usuarios del sistema. Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo. Ajustarse a los plazos y costes previstos en la planificación. Facilitar el mantenimiento posterior de los sistemas.
  • 6. OBJETIVOS DE UNA METODOLOGÍA Definir actividades a llevarse a cabo en un Proyecto de Sistema de Información. Unificar criterios en la organización para el desarrollo del Sistema de Información. Proporcionar puntos de control y revisión. Permitir construir un sistema documentado y que sea fácil de mantener. Ayudar a identificar, lo antes posible, cualquier cambio que sea necesario realizar dentro del proceso de desarrollo.
  • 7. METODOLOGÍAS DE DESARROLLO TRADICIONALES Desarrollar un software implica muchas cosas, desde su planificación hasta su utilización se deben de seguir un sinnúmero de pasos o actividades. Hoy en día existen diversas metodologías para hacerlo, sin embargo es necesario definir primero la naturaleza del software antes de elegir un determinado ciclo de vida.  Las metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente.
  • 8. CARACTERÍSTICAS  Una Metodología de desarrollo de software, consiste en hacer uso de diversas herramientas, técnicas, métodos y modelos para el desarrollo.  Este tipo de metodología, tienen la necesidad de ser documentadas, para que los programadores que estarán dentro de la planeación del proyecto, comprendan la metodología utilizada.  Seguimiento detallado en cada una de las fases.
  • 12. VENTAJAS  Evaluación en cada fase que permite cambios de objetivos.  Es sencillo al momento de aplicar al desarrollo de software.  Tiene un proceso de seguimiento detallado en cada una de las fases.
  • 13. DESVENTAJAS  La evaluación de riesgos es compleja.  Con esto se puede poner al cliente en una situación que puede ser muy incómoda para él.  El cliente deberá ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con él.
  • 14. METODOLOGÍAS TRADICIONALES VS METODOLOGÍAS ÁGILES  Con el paso del tiempo, las metodologías tradicionales, simplemente no se iban a acoplar con las nuevas tecnologías, los nuevos lenguajes y sobretodo los programadores modernos. Es por ello que se han desarrollado lo que son las metodologías ágiles.  Una metodología ágil, consiste principalmente en trabajar con menos documentación de la que, como vimos, las metodologías tradicionales utilizan en todo momento.
  • 15. METODOLOGÍAS ÁGILES  Son aquellas que permiten adaptar la forma de trabajo a las condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para acoplar el proyecto y su desarrollo a las circunstancias específicas del entorno.  Las empresas que optan por esta metodología consiguen gestionar sus proyectos de forma flexible, autónoma y eficaz reduciendo los costes e incrementando su productividad.
  • 16. POR QUÉ EMPLEAR METODOLOGÍAS ÁGILES EN SU EMPRESA  Mejoran la satisfacción del cliente dado que se involucrará y comprometerá a lo largo de todo el proyecto.  En cada etapa se informará al cliente de los logros y progresos del mismo, con la visión de involucrarlo directamente para sumar su experiencia y conocimiento.  Optimizar las características del producto final obteniendo en todo momento una visión completa de su estado.
  • 17. POR QUÉ EMPLEAR METODOLOGÍAS ÁGILES EN SU EMPRESA  Mejora de la motivación e implicación del equipo de desarrollo, las metodologías ágiles permiten a todos los miembros del equipo conocer el estado del proyecto en cualquier momento, con esto se logra que todos los miembros del equipo acepten los compromisos del mismo.  Permite ahorrar tiempo y costes el desarrollo ágil trabaja de un modo más eficiente y rápido, con esto se logra cumplir de forma estricta el presupuesto y los plazos pactados dentro de un proyecto.
  • 18. Taller sobre las Metodologías Tradicionales  Defina a cada Metodología  Detalle 2 características por cada metodología tradicional  Mencione los roles de cada una de las metodologías y elija un rol el cual usted considere el mas importante dentro del proceso
  • 19. Preguntas sobre el tema tratado
  • 21. METODOLOGÍA TRADICIONAL RUP  Entre las principales metodologías tradicionales tenemos los modelos conocidos como RUP y MSF, que centran su atención en llevar una documentación exhaustiva de todo el proyecto y además en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto. RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo.
  • 22. CARACTERÍSTICAS DE LA METODOLOGÍA RUP  Forma disciplinada de asignar tareas y responsabilidades.  Desarrollo iterativo.  Administración de requisitos.  Verificación de calidad de software.  Pretende utilizar las mejores prácticas de desarrollo de software.
  • 23. FASES DE LA METODOLOGÍA RUP  RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor esfuerzo en los distintas actividades.
  • 24. FASES DE LA METODOLOGÍA RUP 01 02 03 04 INICIO ELABORACIÓN TRANSICIÓN CONSTRUCCIÓN
  • 25. FASE 1: INICIO  Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.  La fase de iniciación contiene los flujos de trabajo necesarios para el acuerdo de las partes interesadas con los objetivos, la arquitectura y la planificación del proyecto.
  • 26. FASE 1: INICIO  En esta etapa, los requisitos esenciales del sistema se transforman en los casos de uso, esto conlleva a un proceso corto y se utiliza para definir si es factible para continuar con el proyecto y definir los riesgos y el coste del proyecto.
  • 27.  En esta fase se establece el caso del negocio para el sistema y se delimita el alcance del proyecto. Para lograrlo, es necesario identificar todas las entidades con las que el sistema va a interactuar (actores) y se define la naturaleza de esta interacción a alto nivel. Lo que implica identificar todos los casos de uso y describir algunos (los más significativos).  El caso de negocio incluye criterio de éxito, evaluación de riesgos y estimación de recursos necesarios, y un plan de fase que muestre las fechas de las etapas principales.
  • 28. ENTREGABLES AL FINAL DE LA FASE  Documento de visión: Visión general de requerimientos, características clave y restricciones principales.  Modelo de casos de uso inicial  Glosario de proyecto inicial  Caso de negocio Inicial: Incluye contexto del negocio, criterio de éxito y pronóstico financiero  Evaluación de riesgos inicial  Modelo de negocio, en caso de ser necesario
  • 29. Los criterios de evaluación para la fase de Inicio son:  Concurrencia de las partes interesadas en la definición de alcance y estimación de costos/programas (horarios).  Evidencia de entendimiento de los requerimientos mediante la comprobación de los casos de uso primarios.  Credibilidad de los estimados de costos/programas, prioridades, riesgos y proceso de desarrollo.  Detalle y extensión de cualquier prototipo arquitectónico que se ha desarrollado.  Gastos actuales Vs. Gastos planeados.
  • 30. FASE 2: ELABORACIÓN  La elaboración consiste en la preparación para el diseño del sistema, como complemento de la documentación de casos de uso, frente a la arquitectura del sistema, revisar el modelo de negocio para el proyecto e iniciar la versión del manual del usuario y se debe tener las siguientes aceptaciones:  Descripción del producto si es estable ? El plan del proyecto es fiable?; Los costos son elegibles?
  • 31.  El propósito de la fase de elaboración es analizar el dominio del problema, establecer un fundamento arquitectónico, desarrollar el plan del proyecto y eliminar los elementos de mayor riesgo para el proyecto. Para lograr estos objetivos, se debe tener una vista del cuadro completo del sistema. Las decisiones sobre la arquitectura se deben hacer entendiendo el sistema completo: su alcance, requerimientos funcionales y no funcionales como requerimientos de rendimiento.
  • 32. El resultado de la fase de elaboración es:  Un modelo de caso de uso (completo por lo menos el 80%), en donde todos los casos de uso y actores han sido identificados y más casos de uso han sido elaborados.  Requerimientos suplementarios capturando lo requerimientos no funcionales y cualquier requerimiento que no esté asociado con un caso de uso específico.  Descripción de una Arquitectura de Software.  Prototipo arquitectónico ejecutable.  Lista de riesgos y casos de negocio revisados.  Un plan de desarrollo para el proyecto global, incluyendo el plan del proyecto desglosado, mostrando iteraciones y criterios de evaluación para cada iteración.  Un caso de desarrollo actualizado especificando el proceso que se usará.  Un manual de usuario preliminar
  • 33. Al final de la fase de elaboración se da el segundo mayor hito del ciclo de vida. En este punto se examina los objetivos y alcance detallados del sistema, la selección de la arquitectura y la resolución de los mayores riesgos.
  • 34. Los criterios de evaluación para esta fase deben responder las siguientes preguntas: • ¿La visión del producto es estable? • ¿La arquitectura es estable? • ¿La demostración ejecutable muestra que los elementos de mayor riesgo han sido direccionados y realmente resueltos? • ¿El plan para la construcción de la fase fue lo suficientemente detallado y preciso? ¿Está respaldado con una base de estimaciones creíble? • ¿Todas las partes interesadas están de acuerdo en que la visión actual puede ser alcanzada si el plan actual se ejecuta para desarrollar el sistema completo, en el contexto de la arquitectura actual? • ¿Los gastos actuales vs. los gastos planeados son aceptables?
  • 35. FASE 3: CONSTRUCCIÓN  En la fase de construcción, el desarrollo físico del software se inicia, códigos de programación y las respectivas pruebas.  Se debe aceptar las pruebas para un proceso estable, y el código del sistema puesto que son líneas base para su desarrollo.
  • 36. En la fase de construcción, todos los componentes que faltan y las características de la aplicación se desarrollan e integran en el producto, y todas las características se prueban. La fase de construcción es de cierto modo un proceso de manufactura que pone énfasis en manejar los recursos y controlar las operaciones para optimizar costos, programaciones y calidad. Como mínimo consiste de: • Producto de software integrado en la plataforma adecuada. • Manuales de usuario. • Descripción de la versión actual.
  • 37. El criterio de evaluación para la fase de construcción debe responder las siguientes preguntas: • ¿La versión del producto es suficientemente estable y madura para ser desplegada a la comunidad de usuarios? • ¿Están todas las partes interesadas listas para la transición en la comunidad de usuarios? • ¿Los costos actuales vs. los costos planeados siguen siendo aceptables?
  • 38. FASE 4: TRANSICIÓN  En esta fase es la entrega de software, que se lleva a cabo el plan de despliegue y entrega, el seguimiento y la calidad del software.  Es la entrega del producto, se verifica la satisfacción del cliente.  En esta etapa también se lleva a cabo la formación de los usuarios que viene a ser las capacitaciones al personal encargado del manejo del sistema.
  • 39. El propósito de la fase de transición es justamente la transición del producto de software en la comunidad de usuarios. Una vez que el producto se ha entregado al usuario final, surgen inconvenientes y requieren nuevas versiones, corregir algunos problemas o terminar las características que fueron pospuestas. La fase de transición se da cuando una línea base está suficientemente avanzada para ser desplegada en el dominio del usuario final. Esto requiere casi siempre que algunos subconjuntos utilizables del sistema se hayan completado en un nivel aceptable de calidad y que la documentación de usuario esté disponible de manera que la transición de resultados positivos para todas las partes.
  • 40. En este punto del ciclo de vida la retroalimentación de los usuarios debe ser tomada primariamente para ajustar, configurar, instalar y ver las dificultades de usabilidad del producto. Los objetivos primarios de la fase de transición incluyen: • Lograr que el usuario pueda usar el producto por sí mismo. • Lograr que la concurrencia desplegada de las partes interesadas esté completa y consistente con el criterio de evaluación de la visión. • Lograr la línea base del producto final tan rápida y económicamente efectiva como sea posible.
  • 41. Al final de la fase de transición se da el cuarto hito mayor del proyecto. En este punto se decide si los objetivos fueron logrados y si se debería empezar otro ciclo de desarrollo. Los criterios de evaluación para esta fase responden las siguientes preguntas: • ¿El usuario está satisfecho? • ¿Los costos actuales vs. los costos planeados siguen siendo aceptables?
  • 43. Preguntas sobre el tema tratado
  • 44. TRABAJO AUTÓNOMO  De las fases de la metodología RUP revisadas en clases, seleccione los puntos más relevantes que usted considere y plasme en un organizador gráfico.  Fecha de presentación: martes 14 de JUNIO del 2022 (19H50) Nombre del archivo: APELLIDO_NOMBRE_DEBER1 Formato de presentación: PDF Subir al enlace compartido por el docente.
  • 45. Palabras Iteración: Es el acto de repetir un proceso, para generar una secuencia de resultados, con el objetivo de acercarse a un propósito o resultado deseado.

Notas del editor

  1. Notas para el moderador: Descripción de lo que ha aprendido con sus propias palabras en un lado. Incluya información sobre el tema También será útil incluir aquí más información sobre el tema. Cuente la historia de su experiencia de aprendizaje. Igual que en cualquier historia, debe haber siempre un principio, una parte central y un final. En la otra cara, puede agregar un gráfico que proporcione una prueba de lo que ha aprendido. No dude en usar más de una diapositiva para reflexionar sobre el proceso. También resulta útil agregar algunos vídeos sobre el proceso.
  2. Notas para el moderador: ¿Qué fue importante sobre esta experiencia de aprendizaje? ¿Cómo es relevante para el curso, usted mismo, o la sociedad o comunidad? ¿Por qué es importante? Este SmartArt le permite agregar imágenes y texto para describir el proceso. Si una imagen vale más que mil palabras, las imágenes y palabras le ayudarán a comunicar esta reflexión de aprendizaje perfectamente. Siempre puede hacer clic en Insertar > SmartArt para cambiar este gráfico o seleccionar el gráfico y hacer clic en el menú contextual de Diseño para cambiar los colores.
  3. Notas para el moderador: ¿Qué pensó al principio? ¿Qué obstáculos encontró sobre la marcha? ¿Cómo superó esos obstáculos? ¿Qué imágenes puede agregar para apoyar el proceso? Este SmartArt le permite agregar imágenes y texto para describir el proceso. Si una imagen vale más que mil palabras, las imágenes y palabras le ayudarán a comunicar esta reflexión de aprendizaje perfectamente. Siempre puede hacer clic en Insertar > SmartArt para cambiar este gráfico o seleccionar el gráfico y hacer clic en el menú contextual de Diseño para cambiar los colores. No dude en usar más de una diapositiva para reflexionar sobre el proceso. También resulta útil agregar algunos vídeos sobre el proceso.