SlideShare una empresa de Scribd logo
Unidad 4
   Un proceso de software se puede caracterizar
    como se muestra en la Figura:

              Actividades del marco de trabajo

               Conjunto de tareas
                    Tareas
                    Hitos, entregas
                    Puntos SQA


           Actividades de protección
 Se establece un marco común del proceso definiendo:
 Un pequeño número de actividades del marco de trabajo que son
  aplicables a todos los proyectos del software, con independencia
  de su tamaño o complejidad.
 Un número de conjuntos de tareas –cada uno es una colección de
  tareas de trabajo de ingeniería del software, hitos de proyectos,
  productos de trabajo, y puntos de garantía de calidad- que
  permiten que las actividades del marco de trabajo se adapten a las
  características del proyecto del software y a los requisitos del
  equipo del proyecto.
 Finalmente, las actividades de protección -tales como garantía de
  calidad del software, gestión de configuración del software y
  medición-abarcan el modelo de procesos.
 Las actividades de protección son independientes de cualquier
  actividad del marco de trabajo y aparecen durante todo el
  proceso.
   Para resolver los problemas reales de una
    industria, un ingeniero del software o un equipo
    de ingenieros debe incorporar una estrategia de
    desarrollo que acompañe al proceso, métodos y
    capas de herramientas.
   Esta estrategia a menudo se llama modelo de
    proceso o paradigma de ingeniería del software.
   Se selecciona un modelo de proceso para la
    ingeniería del software según la naturaleza del
    proyecto y de la aplicación, los métodos y las
    herramientas a utilizarse, y los controles y
    entregas que se requieren.
Unidad 4 Modelos de Procesos del Software
   Análisis de requerimientos y definición.
   Diseño del sistema y del software.
   Implementación y prueba de unidades
   Integración y prueba del sistema.
   Operación y mantenimiento.
(Tarea investigar cada fase)
    La dificultad en esta modelo reside, en la dificultad de hacer
    cambios entre etapas.
  No refleja realmente el proceso de desarrollo
  del software
 Se tarda mucho tiempo en pasar por todo el
  ciclo
 Perpetua el fracaso de la industria del software
  en su comunicación con el usuario final
 El mantenimiento se realiza en el código
  fuente
 Las revisiones de proyectos de gran
  complejidad son muy difíciles
 Impone una estructura de gestión de
  proyectos
   El modelo espiral para la ingeniería de
    software ha sido desarrollado para cubrir las
    mejores características tanto del ciclo de vida
    clásico, como de la creación de prototipos,
    añadiendo al mismo tiempo un nuevo
    elemento: el análisis de riesgo. El modelo
    representado mediante la espiral define
    cuatro actividades principales:
   Planificación: determinación de objetivos,
    alternativas y restricciones.
   Análisis de riesgo: análisis de alternativas
    e identificación/resolución de riesgos.
   Ingeniería: desarrollo del producto del
    "siguiente nivel",
   Evaluación del cliente: Valorización de los
    resultados de la ingeniería.
Unidad 4 Modelos de Procesos del Software
   Durante la primera vuelta alrededor de la
    espiral se definen los objetivos, las
    alternativas y las restricciones, y se analizan
    e identifican los riesgos. Si el análisis de
    riesgo indica que hay una incertidumbre en
    los requisitos, se puede usar la creación de
    prototipos en el cuadrante de ingeniería
    para dar asistencia tanto al encargado de
    desarrollo como al cliente.
   El cliente evalúa el trabajo de ingeniería
    (cuadrante de evaluación de cliente) y sugiere
    modificaciones. Sobre la base de los
    comentarios del cliente se produce la
    siguiente fase de planificación y de análisis de
    riesgo. En cada bucle alrededor de la espiral,
    la culminación del análisis de riesgo resulta en
    una decisión de "seguir o no seguir".
   Con cada iteración alrededor de la
    espiral (comenzando en el centro y
    siguiendo hacia el exterior), se
    construyen sucesivas versiones del
    software, cada vez más completa y,
    al final, al propio sistema
    operacional.
   El paradigma del modelo en espiral para la
    ingeniería de software es actualmente el
    enfoque más realista para el desarrollo de
    software y de sistemas a gran escala. Utiliza un
    enfoque evolutivo para la ingeniería de software,
    permitiendo al desarrollador y al cliente
    entender y reaccionar a los riesgos en cada nivel
    evolutivo. Utiliza la creación de prototipos como
    un mecanismo de reducción de riesgo, pero, lo
    que es más importante permite a quien lo
    desarrolla aplicar el enfoque de creación de
    prototipos en cualquier etapa de la evolución del
    proyecto .
   El modelo incremental combina
    elementos del modelo lineal secuencial
    (aplicados repetidamente) con la filosofía
    interactiva de construcción de
    prototipos.
Unidad 4 Modelos de Procesos del Software
   El modelo incremental aplica secuencias
    lineales de forma escalonada mientras
    progresa el tiempo en el calendario.
   Cada secuencia lineal produce un
    «incremento» del software.
   Se debería tener en cuenta que el flujo del
    proceso de cualquier incremento puede
    incorporar el paradigma de construcción de
    prototipos.
   El modelo incremento entrega el software en
    partes pequeñas, pero utilizables, llamadas
    ((incrementos).
   En general, cada incremento se construye
    sobre aquél que ya ha sido entregado.
   Cuando se utiliza un modelo incremental, el
    primer incremento a menudo es un producto
    esencial.
   El cliente utiliza el producto central (o sufre la
    revisión detallada).
   Como un resultado de utilización y/o de
    evaluación, se desarrolla un plan para el
    incremento siguiente.
   El plan afronta la modificación del producto
    central a fin de cumplir mejor las necesidades
    del cliente y la entrega de funciones, y
    características adicionales.
   Este proceso se repite siguiendo la entrega de
    cada incremento, hasta que se elabore el
    producto completo.
   El modelo de proceso incremental, es iterativo por
    naturaleza.
   El modelo incremental se centra en la entrega de un
    producto operacional con cada incremento.
   Los primeros incrementos son versiones «incompletas»
    del producto final, pero proporcionan al usuario la
    funcionalidad que precisa y también una plataforma para
    la evaluación.
   El desarrollo incremental es particularmente útil cuando la
    dotación de personal no está disponible para una
    implementación completa en la fecha límite que se haya
    establecido para el proyecto.
   Los primeros incrementos se pueden implementar con
    menos personas.
Unidad 4 Modelos de Procesos del Software
   El Proceso Unificado es un proceso de software
    genérico que puede ser utilizado para una gran
    cantidad de tipos de sistemas de software, para
    diferentes áreas de aplicación, diferentes tipos de
    organizaciones, diferentes niveles de competencia y
    diferentes tamaños de proyectos.
   Provee un enfoque disciplinado en la asignación de
    tareas y responsabilidades dentro de una
    organización de desarrollo.
   Su meta es asegurar la producción de software de
    muy alta calidad que satisfaga las necesidades de los
    usuarios finales, dentro de un calendario y
    presupuesto predecible.
 El Proceso Unificado tiene dos dimensiones (Figura 1):
 Un eje horizontal que representa el tiempo y muestra los aspectos
  del ciclo de vida del proceso a lo largo de su desenvolvimiento
 Un eje vertical que representa las disciplinas, las cuales agrupan
  actividades de una manera lógica de acuerdo a su naturaleza.
   La primera dimensión representa el aspecto
    dinámico del proceso conforme se va
    desarrollando, se expresa en términos de
    fases, iteraciones e hitos (milestones).
   La segunda dimensión representa el aspecto
    estático del proceso: cómo es descrito en
    términos de componentes del proceso,
    disciplinas, actividades, flujos de trabajo,
    artefactos y roles.
 El Proceso Unificado se basa en componentes
  (component-based), lo que significa que el sistema en
  construcción está hecho de componentes de software
  interconectados por medio de interfaces bien definidas
  (well-defined interfaces).
 El Proceso Unificado usa el Lenguaje de Modelado
  Unificado (UML) en la preparación de todos los planos del
  sistema. De hecho, UML es una parte integral del Proceso
  Unificado, fueron desarrollados a la par.
 Los aspectos distintivos del Proceso Unificado están
  capturados en tres conceptos clave: dirigido por casos de
  uso (use-case driven), centrado en la arquitectura
  (architecture-centric), iterativo e incremental. Esto es lo
  que hace único al Proceso Unificado.
   Un sistema de software se crea para servir a
    sus usuarios. Por lo tanto, para construir un
    sistema exitoso se debe conocer qué es lo
    que quieren y necesitan los usuarios
    prospectos.
   El término usuario se refiere no solamente a
    los usuarios humanos, sino a otros sistemas.
    En este contexto, el término usuario
    representa algo o alguien que interactúa con
    el sistema por desarrollar.
   Un caso de uso es una pieza en la funcionalidad del sistema que le
    da al usuario un resultado de valor.
   Los casos de uso capturan los requerimientos funcionales.
   Todos los casos de uso juntos constituyen el modelo de casos de
    uso el cual describe la funcionalidad completa del sistema.
   Este modelo reemplaza la tradicional especificación funcional del
    sistema.
   Una especificación funcional tradicional se concentra en
    responder la pregunta: ¿Qué se supone que el sistema debe hacer?
   La estrategia de casos de uso puede ser definida agregando tres
    palabras al final de la pregunta: ¿por cada usuario?
   Estas tres palabras tienen una implicación importante, nos fuerzan
    a pensar en términos del valor a los usuarios y no solamente en
    términos de las funciones que sería bueno que tuviera.
   Sin embargo, los casos de uso no son solamente una
    herramienta para especificar los requerimientos del
    sistema, también dirigen su diseño, implementación y
    pruebas, esto es, dirigen el proceso de desarrollo.
   Aún y cuando los casos de uso dirigen el proceso, no
    son elegidos de manera aislada.
   Son desarrollados a la par con la arquitectura del
    sistema, esto es, los casos de uso dirigen la
    arquitectura del sistema y la arquitectura del sistema
    influencia la elección de los casos de uso.
   Por lo tanto, al arquitectura del sistema y los casos de
    uso maduran conforme avanza el ciclo de vida.
   El papel del arquitecto de sistemas es similar en
    naturaleza al papel que el arquitecto desempeña
    en la construcción de edificios.
   El edificio se mira desde diferentes puntos de
    vista: estructura, servicios, plomería,
    electricidad, etc.
   Esto le permite al constructor ver una radiografía
    completa antes de empezar a construir.
   Similarmente, la arquitectura en un sistema de
    software es descrita como diferentes vistas del
    sistema que está siendo construido.
   El concepto de arquitectura de software involucra los aspectos estáticos
    y dinámicos más significativos del sistema.
   La arquitectura surge de las necesidades de la empresa, tal y como las
    interpretan los usuarios y otros stakeholders, y tal y como están
    reflejadas en los casos de uso.
   Sin embargo, también está influenciada por muchos otros factores, tales
    como la plataforma de software en la que se ejecutará, la disponibilidad
    de componentes reutilizables, consideraciones de instalación, sistemas
    legados, requerimientos no funcionales (ej. desempeño, confiabilidad).
   La arquitectura es la vista del diseño completo con las características más
    importantes hechas más visibles y dejando los detalles de lado.
   Ya que lo importante depende en parte del criterio, el cual a su vez viene
    con la experiencia, el valor de la arquitectura depende del personal
    asignado a esta tarea.
   Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas
    correctas, tales como claridad (understandability), flexibilidad en los
    cambios futuros (resilience) y reúso.
   ¿Cómo se relacionan los casos de uso con la arquitectura?
    Cada producto tiene función y forma. Uno sólo de los dos
    no es suficiente. Estas dos fuerzas deben estar
    balanceadas para obtener un producto exitoso. En este
    caso función corresponde a los casos de uso y forma a la
    arquitectura. Existe la necesidad de intercalar entre casos
    de uso y arquitectura. Es un problema del “huevo y la
    gallina”. Por una parte, los casos de uso deben, cuando son
    realizados, acomodarse en la arquitectura. Por otra parte,
    la arquitectura debe proveer espacio para la realización de
    todos los casos de uso, hoy y en el futuro. En la realidad,
    ambos arquitectura y casos de uso deben evolucionar en
    paralelo.
 Desarrollar un producto de software comercial es una
  tarea enorme que puede continuar por varios meses o
  años.
 Es práctico dividir el trabajo en pequeños pedazos o
  mini-proyectos.
 Cada mini-proyecto es una iteración que finaliza en un
  incremento.
 Las iteraciones se refieren a pasos en el flujo de
  trabajo, los incrementos se refieren a crecimiento en
  el producto.
 Para ser más efectivo, las iteraciones deben estar
  controladas, esto es, deben ser seleccionadas y
  llevadas a cabo de una manera planeada.
   Los desarrolladores basan su selección de qué
    van a implementar en una iteración en dos
    factores.
   Primero, la iteración trata con un grupo de casos
    de uso que en conjunto extienden la usabilidad
    del producto.
   Segundo, la iteración trata con los riesgos más
    importantes.
   Las iteraciones sucesivas construyen los
    artefactos del desarrollo a partir del estado en el
    que fueron dejados en la iteración anterior.
   En cada iteración, los desarrolladores identifican
    y especifican los casos de uso relevantes, crean
    el diseño usando la arquitectura como guía,
    implementan el diseño en componentes y
    verifican que los componentes satisfacen los
    casos de uso.
   Si una iteración cumple sus metas – y
    usualmente lo hace – el desarrollo continúa con
    la siguiente iteración.
   Cuando la iteración no cumple con sus metas,
    los desarrolladores deben revisar sus decisiones
    previas y probar un nuevo enfoque.
 Los conceptos anteriormente tratados – dirigido
  por casos de uso, centrado en arquitectura,
  desarrollo iterativo e incremental – son
  igualmente importantes.
 La arquitectura provee la estructura sobre la cual
  guiar el trabajo en iteraciones, mientras que los
  casos de uso definen las metas y dirigen el
  trabajo en cada iteración.
 Remover cualquiera de estos conceptos reducirá
  severamente el valor del Proceso Unificado.
Unidad 4 Modelos de Procesos del Software

Más contenido relacionado

La actualidad más candente

Modelo incremental
Modelo incrementalModelo incremental
Modelo incremental
Avelino Felipe Policarpio
 
Fundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdfFundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdf
BibliotecaenlineaUNI
 
Jhostin vasquez modelos de software
Jhostin vasquez   modelos de softwareJhostin vasquez   modelos de software
Jhostin vasquez modelos de software
jhostinvasquez
 
Modelos y capas de la ingenieria de software
Modelos y capas  de la ingenieria de softwareModelos y capas  de la ingenieria de software
Modelos y capas de la ingenieria de software
jhonatanalex
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
kellypt1
 
Modelos de Desarrollo del Software
Modelos de Desarrollo del SoftwareModelos de Desarrollo del Software
Modelos de Desarrollo del Software
GianlucaCastellano1
 
Fase de Elaboración RUP
Fase de Elaboración RUPFase de Elaboración RUP
Fase de Elaboración RUP
Adrian González
 
Fases del Proceso Unificado
Fases del Proceso UnificadoFases del Proceso Unificado
Fases del Proceso Unificado
katano66
 
Unidad 2. metodologías de desarrollo DE SOFTWARE
Unidad 2. metodologías de desarrollo DE SOFTWAREUnidad 2. metodologías de desarrollo DE SOFTWARE
Unidad 2. metodologías de desarrollo DE SOFTWARE
Pablo Daniel Bazan Carmona
 
Proceso ( software )
Proceso ( software )Proceso ( software )
Proceso ( software )
em3marquez
 
El Proceso Unificado
El Proceso UnificadoEl Proceso Unificado
El Proceso Unificado
Sofylutqm
 
El proceso unificado introduccion
El proceso unificado   introduccionEl proceso unificado   introduccion
El proceso unificado introduccion
Jose Diaz Silva
 
02 rup
02 rup02 rup
Modelos de proceso del software
Modelos de proceso del softwareModelos de proceso del software
Modelos de proceso del software
Diego Llusco
 
Etapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del SoftwareEtapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del Software
T.I.C
 
medolos tradicionales de desarrollo de software ( cascada - espiral)
medolos tradicionales de desarrollo de software ( cascada - espiral)medolos tradicionales de desarrollo de software ( cascada - espiral)
medolos tradicionales de desarrollo de software ( cascada - espiral)
Cristhian Aguilar
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
yurikodelcarmen
 
Modelo Incremental, victor mamani catachura, boreasH
Modelo Incremental, victor mamani catachura, boreasHModelo Incremental, victor mamani catachura, boreasH
Modelo Incremental, victor mamani catachura, boreasH
victor mamani
 
Fases del rup
Fases del rupFases del rup
Fases del rup
MaraJosQuilcaguanoTo
 

La actualidad más candente (19)

Modelo incremental
Modelo incrementalModelo incremental
Modelo incremental
 
Fundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdfFundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdf
 
Jhostin vasquez modelos de software
Jhostin vasquez   modelos de softwareJhostin vasquez   modelos de software
Jhostin vasquez modelos de software
 
Modelos y capas de la ingenieria de software
Modelos y capas  de la ingenieria de softwareModelos y capas  de la ingenieria de software
Modelos y capas de la ingenieria de software
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
 
Modelos de Desarrollo del Software
Modelos de Desarrollo del SoftwareModelos de Desarrollo del Software
Modelos de Desarrollo del Software
 
Fase de Elaboración RUP
Fase de Elaboración RUPFase de Elaboración RUP
Fase de Elaboración RUP
 
Fases del Proceso Unificado
Fases del Proceso UnificadoFases del Proceso Unificado
Fases del Proceso Unificado
 
Unidad 2. metodologías de desarrollo DE SOFTWARE
Unidad 2. metodologías de desarrollo DE SOFTWAREUnidad 2. metodologías de desarrollo DE SOFTWARE
Unidad 2. metodologías de desarrollo DE SOFTWARE
 
Proceso ( software )
Proceso ( software )Proceso ( software )
Proceso ( software )
 
El Proceso Unificado
El Proceso UnificadoEl Proceso Unificado
El Proceso Unificado
 
El proceso unificado introduccion
El proceso unificado   introduccionEl proceso unificado   introduccion
El proceso unificado introduccion
 
02 rup
02 rup02 rup
02 rup
 
Modelos de proceso del software
Modelos de proceso del softwareModelos de proceso del software
Modelos de proceso del software
 
Etapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del SoftwareEtapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del Software
 
medolos tradicionales de desarrollo de software ( cascada - espiral)
medolos tradicionales de desarrollo de software ( cascada - espiral)medolos tradicionales de desarrollo de software ( cascada - espiral)
medolos tradicionales de desarrollo de software ( cascada - espiral)
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Modelo Incremental, victor mamani catachura, boreasH
Modelo Incremental, victor mamani catachura, boreasHModelo Incremental, victor mamani catachura, boreasH
Modelo Incremental, victor mamani catachura, boreasH
 
Fases del rup
Fases del rupFases del rup
Fases del rup
 

Destacado

Encuadre de Estructura de Datos
Encuadre de Estructura de DatosEncuadre de Estructura de Datos
Encuadre de Estructura de Datos
rezzaca
 
Conceptos informatica
Conceptos informaticaConceptos informatica
Conceptos informatica
Felipe Rojas
 
Materiales 1 Bases De Datos
Materiales 1 Bases De DatosMateriales 1 Bases De Datos
Materiales 1 Bases De Datos
juancarlos54
 
Estructura de datos
Estructura de datosEstructura de datos
Estructura de datos
René Sosa Arana
 
Estructura de datos Pilas, Colas y Listas.
Estructura de datos Pilas, Colas y Listas.Estructura de datos Pilas, Colas y Listas.
Estructura de datos Pilas, Colas y Listas.
christgch
 
estructuras de datos
estructuras de datosestructuras de datos
Estructura De Datos Registro
Estructura De Datos RegistroEstructura De Datos Registro
Estructura De Datos Registro
Marco Antonio
 
Entendiendo estructura de datos
Entendiendo estructura de datosEntendiendo estructura de datos
Entendiendo estructura de datos
yacomas
 
Estructura de datos I pilas
Estructura de datos I pilasEstructura de datos I pilas
Estructura de datos I pilas
geova666
 
Ergonomía Informática
Ergonomía InformáticaErgonomía Informática
Ergonomía Informática
GabrielaJ
 
Estructura de los datos
Estructura de los datosEstructura de los datos
concepto de estructuras de datos
concepto de estructuras de datosconcepto de estructuras de datos
concepto de estructuras de datos
Eduardo Robayo Castro
 
Estructuras de Datos (Arreglos)
Estructuras de Datos (Arreglos)Estructuras de Datos (Arreglos)
Estructuras de Datos (Arreglos)
Zamantha Gonzalez Universidad Nacional Abierta
 
Bases De Datos "Conceptos Basicos"
Bases De Datos "Conceptos Basicos"Bases De Datos "Conceptos Basicos"
Bases De Datos "Conceptos Basicos"
Cesar David Fernandez Grueso
 
Clase I Estructura de Datos
Clase I Estructura de Datos Clase I Estructura de Datos
Clase I Estructura de Datos
guestc906c2
 
Estructura de datos
Estructura de datosEstructura de datos
Estructura de datos
amartinez_29
 

Destacado (16)

Encuadre de Estructura de Datos
Encuadre de Estructura de DatosEncuadre de Estructura de Datos
Encuadre de Estructura de Datos
 
Conceptos informatica
Conceptos informaticaConceptos informatica
Conceptos informatica
 
Materiales 1 Bases De Datos
Materiales 1 Bases De DatosMateriales 1 Bases De Datos
Materiales 1 Bases De Datos
 
Estructura de datos
Estructura de datosEstructura de datos
Estructura de datos
 
Estructura de datos Pilas, Colas y Listas.
Estructura de datos Pilas, Colas y Listas.Estructura de datos Pilas, Colas y Listas.
Estructura de datos Pilas, Colas y Listas.
 
estructuras de datos
estructuras de datosestructuras de datos
estructuras de datos
 
Estructura De Datos Registro
Estructura De Datos RegistroEstructura De Datos Registro
Estructura De Datos Registro
 
Entendiendo estructura de datos
Entendiendo estructura de datosEntendiendo estructura de datos
Entendiendo estructura de datos
 
Estructura de datos I pilas
Estructura de datos I pilasEstructura de datos I pilas
Estructura de datos I pilas
 
Ergonomía Informática
Ergonomía InformáticaErgonomía Informática
Ergonomía Informática
 
Estructura de los datos
Estructura de los datosEstructura de los datos
Estructura de los datos
 
concepto de estructuras de datos
concepto de estructuras de datosconcepto de estructuras de datos
concepto de estructuras de datos
 
Estructuras de Datos (Arreglos)
Estructuras de Datos (Arreglos)Estructuras de Datos (Arreglos)
Estructuras de Datos (Arreglos)
 
Bases De Datos "Conceptos Basicos"
Bases De Datos "Conceptos Basicos"Bases De Datos "Conceptos Basicos"
Bases De Datos "Conceptos Basicos"
 
Clase I Estructura de Datos
Clase I Estructura de Datos Clase I Estructura de Datos
Clase I Estructura de Datos
 
Estructura de datos
Estructura de datosEstructura de datos
Estructura de datos
 

Similar a Unidad 4 Modelos de Procesos del Software

Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de software
Andhy H Palma
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
Radel Fuentes
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
Brihany Rossell
 
Metodología de desarrollo de software
Metodología de desarrollo de softwareMetodología de desarrollo de software
Metodología de desarrollo de software
Abner Garcia
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
angelicasolishernnde
 
Proceso unificado y modelo v
Proceso unificado y modelo vProceso unificado y modelo v
Proceso unificado y modelo v
VivitaGranizo
 
Proceso unificado y modelo v
Proceso unificado y modelo vProceso unificado y modelo v
Proceso unificado y modelo v
VivitaGranizo
 
Emilio granizo proceso unificado y modelo v
Emilio granizo proceso unificado y modelo vEmilio granizo proceso unificado y modelo v
Emilio granizo proceso unificado y modelo v
VivitaGranizo
 
AMSI
AMSIAMSI
Act18
Act18Act18
Act18
karinaaura
 
conceptos de ingenieria de software
conceptos de ingenieria de softwareconceptos de ingenieria de software
conceptos de ingenieria de software
liliana guadalupe rodriguez
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
Jazmin Cr
 
prueva
pruevaprueva
prueva
1081913395
 
Metodología rup final
Metodología rup finalMetodología rup final
Metodología rup final
MariaC7
 
DiseñO De Sistemas
DiseñO De SistemasDiseñO De Sistemas
DiseñO De Sistemas
Rony Altamirano Anampa
 
Diseño de Sistemas
Diseño de SistemasDiseño de Sistemas
Diseño de Sistemas
Hugo J. L. Romero R.
 
DiseñO De Sistemas
DiseñO De SistemasDiseñO De Sistemas
DiseñO De Sistemas
Rony Altamirano Anampa
 
ciclo_de_vida_software
ciclo_de_vida_softwareciclo_de_vida_software
ciclo_de_vida_software
ArielAlexanderRavest
 
Modelo de software en espiral
Modelo de software en espiralModelo de software en espiral
Modelo de software en espiral
Nando Lopez
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
mendez45
 

Similar a Unidad 4 Modelos de Procesos del Software (20)

Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de software
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 
Metodología de desarrollo de software
Metodología de desarrollo de softwareMetodología de desarrollo de software
Metodología de desarrollo de software
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
 
Proceso unificado y modelo v
Proceso unificado y modelo vProceso unificado y modelo v
Proceso unificado y modelo v
 
Proceso unificado y modelo v
Proceso unificado y modelo vProceso unificado y modelo v
Proceso unificado y modelo v
 
Emilio granizo proceso unificado y modelo v
Emilio granizo proceso unificado y modelo vEmilio granizo proceso unificado y modelo v
Emilio granizo proceso unificado y modelo v
 
AMSI
AMSIAMSI
AMSI
 
Act18
Act18Act18
Act18
 
conceptos de ingenieria de software
conceptos de ingenieria de softwareconceptos de ingenieria de software
conceptos de ingenieria de software
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
 
prueva
pruevaprueva
prueva
 
Metodología rup final
Metodología rup finalMetodología rup final
Metodología rup final
 
DiseñO De Sistemas
DiseñO De SistemasDiseñO De Sistemas
DiseñO De Sistemas
 
Diseño de Sistemas
Diseño de SistemasDiseño de Sistemas
Diseño de Sistemas
 
DiseñO De Sistemas
DiseñO De SistemasDiseñO De Sistemas
DiseñO De Sistemas
 
ciclo_de_vida_software
ciclo_de_vida_softwareciclo_de_vida_software
ciclo_de_vida_software
 
Modelo de software en espiral
Modelo de software en espiralModelo de software en espiral
Modelo de software en espiral
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
 

Más de rezzaca

Método Simplex analitico
Método Simplex analiticoMétodo Simplex analitico
Método Simplex analitico
rezzaca
 
Recopilación y Análisis de Documentos.
Recopilación y Análisis de Documentos.Recopilación y Análisis de Documentos.
Recopilación y Análisis de Documentos.
rezzaca
 
El cuestionario
El cuestionarioEl cuestionario
El cuestionario
rezzaca
 
Listas c#
Listas c#Listas c#
Listas c#
rezzaca
 
Encuadre de Tópicos Selectos de Programación
Encuadre de Tópicos Selectos de ProgramaciónEncuadre de Tópicos Selectos de Programación
Encuadre de Tópicos Selectos de Programación
rezzaca
 
Encuadre Programación de Sistemas
Encuadre Programación de SistemasEncuadre Programación de Sistemas
Encuadre Programación de Sistemas
rezzaca
 
Cerradura
CerraduraCerradura
Cerradura
rezzaca
 
Metodos Constructor Y Destructor
Metodos Constructor Y DestructorMetodos Constructor Y Destructor
Metodos Constructor Y Destructor
rezzaca
 
Simetricas Y Transitivas
Simetricas Y TransitivasSimetricas Y Transitivas
Simetricas Y Transitivas
rezzaca
 
Recursividad Con C#
Recursividad Con C#Recursividad Con C#
Recursividad Con C#
rezzaca
 
U2 2 1 U2 2 2 Conjunto Reflexiba
U2 2 1  U2 2 2  Conjunto ReflexibaU2 2 1  U2 2 2  Conjunto Reflexiba
U2 2 1 U2 2 2 Conjunto Reflexiba
rezzaca
 
Propiedades De Las Relaciones
Propiedades De Las RelacionesPropiedades De Las Relaciones
Propiedades De Las Relaciones
rezzaca
 
Listas en C#
Listas en C#Listas en C#
Listas en C#
rezzaca
 
Relaciones Introducción
Relaciones IntroducciónRelaciones Introducción
Relaciones Introducción
rezzaca
 
Evaluacion De Expresiones
Evaluacion De ExpresionesEvaluacion De Expresiones
Evaluacion De Expresiones
rezzaca
 
Reglas De Inferencia
Reglas De InferenciaReglas De Inferencia
Reglas De Inferencia
rezzaca
 
Inducción Matematica
Inducción MatematicaInducción Matematica
Inducción Matematica
rezzaca
 
U1.5 Álgebra Declarativa
U1.5 Álgebra DeclarativaU1.5 Álgebra Declarativa
U1.5 Álgebra Declarativa
rezzaca
 
Cálculo de predicados
Cálculo de predicadosCálculo de predicados
Cálculo de predicados
rezzaca
 
Codigo Inseguro
Codigo InseguroCodigo Inseguro
Codigo Inseguro
rezzaca
 

Más de rezzaca (20)

Método Simplex analitico
Método Simplex analiticoMétodo Simplex analitico
Método Simplex analitico
 
Recopilación y Análisis de Documentos.
Recopilación y Análisis de Documentos.Recopilación y Análisis de Documentos.
Recopilación y Análisis de Documentos.
 
El cuestionario
El cuestionarioEl cuestionario
El cuestionario
 
Listas c#
Listas c#Listas c#
Listas c#
 
Encuadre de Tópicos Selectos de Programación
Encuadre de Tópicos Selectos de ProgramaciónEncuadre de Tópicos Selectos de Programación
Encuadre de Tópicos Selectos de Programación
 
Encuadre Programación de Sistemas
Encuadre Programación de SistemasEncuadre Programación de Sistemas
Encuadre Programación de Sistemas
 
Cerradura
CerraduraCerradura
Cerradura
 
Metodos Constructor Y Destructor
Metodos Constructor Y DestructorMetodos Constructor Y Destructor
Metodos Constructor Y Destructor
 
Simetricas Y Transitivas
Simetricas Y TransitivasSimetricas Y Transitivas
Simetricas Y Transitivas
 
Recursividad Con C#
Recursividad Con C#Recursividad Con C#
Recursividad Con C#
 
U2 2 1 U2 2 2 Conjunto Reflexiba
U2 2 1  U2 2 2  Conjunto ReflexibaU2 2 1  U2 2 2  Conjunto Reflexiba
U2 2 1 U2 2 2 Conjunto Reflexiba
 
Propiedades De Las Relaciones
Propiedades De Las RelacionesPropiedades De Las Relaciones
Propiedades De Las Relaciones
 
Listas en C#
Listas en C#Listas en C#
Listas en C#
 
Relaciones Introducción
Relaciones IntroducciónRelaciones Introducción
Relaciones Introducción
 
Evaluacion De Expresiones
Evaluacion De ExpresionesEvaluacion De Expresiones
Evaluacion De Expresiones
 
Reglas De Inferencia
Reglas De InferenciaReglas De Inferencia
Reglas De Inferencia
 
Inducción Matematica
Inducción MatematicaInducción Matematica
Inducción Matematica
 
U1.5 Álgebra Declarativa
U1.5 Álgebra DeclarativaU1.5 Álgebra Declarativa
U1.5 Álgebra Declarativa
 
Cálculo de predicados
Cálculo de predicadosCálculo de predicados
Cálculo de predicados
 
Codigo Inseguro
Codigo InseguroCodigo Inseguro
Codigo Inseguro
 

Último

Reglamento del salón - Intensa-mente.pdf
Reglamento del salón - Intensa-mente.pdfReglamento del salón - Intensa-mente.pdf
Reglamento del salón - Intensa-mente.pdf
Adri G Ch
 
PLAN ANUAL DE TRABAJO (PAT) 2024 MINEDU PERÚ
PLAN ANUAL DE TRABAJO (PAT) 2024 MINEDU PERÚPLAN ANUAL DE TRABAJO (PAT) 2024 MINEDU PERÚ
PLAN ANUAL DE TRABAJO (PAT) 2024 MINEDU PERÚ
Ferrer17
 
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
 
Discurso de Ceremonia de Graduación da la Generación 2021-2024.docx
Discurso de Ceremonia de Graduación da la Generación 2021-2024.docxDiscurso de Ceremonia de Graduación da la Generación 2021-2024.docx
Discurso de Ceremonia de Graduación da la Generación 2021-2024.docx
Centro de Bachillerato Tecnológico industrial y de servicios No. 209
 
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
 
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
 
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
 
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Cátedra Banco Santander
 
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Cátedra Banco Santander
 
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLADIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
JAVIER SOLIS NOYOLA
 
Evaluacion Formativa en el Aula ECH1 Ccesa007.pdf
Evaluacion Formativa en el Aula   ECH1  Ccesa007.pdfEvaluacion Formativa en el Aula   ECH1  Ccesa007.pdf
Evaluacion Formativa en el Aula ECH1 Ccesa007.pdf
Demetrio Ccesa Rayme
 
Los Formularios de Google: creación, gestión y administración de respuestas (...
Los Formularios de Google: creación, gestión y administración de respuestas (...Los Formularios de Google: creación, gestión y administración de respuestas (...
Los Formularios de Google: creación, gestión y administración de respuestas (...
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
 
Lecciones 02 Un día en el ministerio de Jesús.docx
Lecciones 02 Un día en el ministerio de Jesús.docxLecciones 02 Un día en el ministerio de Jesús.docx
Lecciones 02 Un día en el ministerio de Jesús.docx
Alejandrino Halire Ccahuana
 
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
 
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
 
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
 
Transformando la Evaluacion con Inteligencia Artificial Ccesa007.pdf
Transformando la Evaluacion con Inteligencia Artificial  Ccesa007.pdfTransformando la Evaluacion con Inteligencia Artificial  Ccesa007.pdf
Transformando la Evaluacion con Inteligencia Artificial Ccesa007.pdf
Demetrio Ccesa Rayme
 
Semana 1 Derecho a interponer recursos y reparación.
Semana 1 Derecho a interponer recursos y reparación.Semana 1 Derecho a interponer recursos y reparación.
Semana 1 Derecho a interponer recursos y reparación.
SergioAlfrediMontoya
 
Plataformas de vídeo online (2 de julio de 2024)
Plataformas de vídeo online (2 de julio de 2024)Plataformas de vídeo online (2 de julio de 2024)
Plataformas de vídeo online (2 de julio de 2024)
Cátedra Banco Santander
 

Último (20)

Reglamento del salón - Intensa-mente.pdf
Reglamento del salón - Intensa-mente.pdfReglamento del salón - Intensa-mente.pdf
Reglamento del salón - Intensa-mente.pdf
 
PLAN ANUAL DE TRABAJO (PAT) 2024 MINEDU PERÚ
PLAN ANUAL DE TRABAJO (PAT) 2024 MINEDU PERÚPLAN ANUAL DE TRABAJO (PAT) 2024 MINEDU PERÚ
PLAN ANUAL DE TRABAJO (PAT) 2024 MINEDU PERÚ
 
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
 
Discurso de Ceremonia de Graduación da la Generación 2021-2024.docx
Discurso de Ceremonia de Graduación da la Generación 2021-2024.docxDiscurso de Ceremonia de Graduación da la Generación 2021-2024.docx
Discurso de Ceremonia de Graduación da la Generación 2021-2024.docx
 
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
 
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
 
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
 
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
 
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)
 
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLADIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
 
Evaluacion Formativa en el Aula ECH1 Ccesa007.pdf
Evaluacion Formativa en el Aula   ECH1  Ccesa007.pdfEvaluacion Formativa en el Aula   ECH1  Ccesa007.pdf
Evaluacion Formativa en el Aula ECH1 Ccesa007.pdf
 
Los Formularios de Google: creación, gestión y administración de respuestas (...
Los Formularios de Google: creación, gestión y administración de respuestas (...Los Formularios de Google: creación, gestión y administración de respuestas (...
Los Formularios de Google: creación, gestión y administración de respuestas (...
 
El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........
 
Lecciones 02 Un día en el ministerio de Jesús.docx
Lecciones 02 Un día en el ministerio de Jesús.docxLecciones 02 Un día en el ministerio de Jesús.docx
Lecciones 02 Un día en el ministerio de Jesús.docx
 
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)
 
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)
 
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
 
Transformando la Evaluacion con Inteligencia Artificial Ccesa007.pdf
Transformando la Evaluacion con Inteligencia Artificial  Ccesa007.pdfTransformando la Evaluacion con Inteligencia Artificial  Ccesa007.pdf
Transformando la Evaluacion con Inteligencia Artificial Ccesa007.pdf
 
Semana 1 Derecho a interponer recursos y reparación.
Semana 1 Derecho a interponer recursos y reparación.Semana 1 Derecho a interponer recursos y reparación.
Semana 1 Derecho a interponer recursos y reparación.
 
Plataformas de vídeo online (2 de julio de 2024)
Plataformas de vídeo online (2 de julio de 2024)Plataformas de vídeo online (2 de julio de 2024)
Plataformas de vídeo online (2 de julio de 2024)
 

Unidad 4 Modelos de Procesos del Software

  • 2. Un proceso de software se puede caracterizar como se muestra en la Figura: Actividades del marco de trabajo Conjunto de tareas Tareas Hitos, entregas Puntos SQA Actividades de protección
  • 3.  Se establece un marco común del proceso definiendo:  Un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamaño o complejidad.  Un número de conjuntos de tareas –cada uno es una colección de tareas de trabajo de ingeniería del software, hitos de proyectos, productos de trabajo, y puntos de garantía de calidad- que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto.  Finalmente, las actividades de protección -tales como garantía de calidad del software, gestión de configuración del software y medición-abarcan el modelo de procesos.  Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.
  • 4. Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y capas de herramientas.  Esta estrategia a menudo se llama modelo de proceso o paradigma de ingeniería del software.  Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se requieren.
  • 6. Análisis de requerimientos y definición.  Diseño del sistema y del software.  Implementación y prueba de unidades  Integración y prueba del sistema.  Operación y mantenimiento. (Tarea investigar cada fase) La dificultad en esta modelo reside, en la dificultad de hacer cambios entre etapas.
  • 7.  No refleja realmente el proceso de desarrollo del software  Se tarda mucho tiempo en pasar por todo el ciclo  Perpetua el fracaso de la industria del software en su comunicación con el usuario final  El mantenimiento se realiza en el código fuente  Las revisiones de proyectos de gran complejidad son muy difíciles  Impone una estructura de gestión de proyectos
  • 8. El modelo espiral para la ingeniería de software ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. El modelo representado mediante la espiral define cuatro actividades principales:
  • 9. Planificación: determinación de objetivos, alternativas y restricciones.  Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos.  Ingeniería: desarrollo del producto del "siguiente nivel",  Evaluación del cliente: Valorización de los resultados de la ingeniería.
  • 11. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente.
  • 12. El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir".
  • 13. Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completa y, al final, al propio sistema operacional.
  • 14. El paradigma del modelo en espiral para la ingeniería de software es actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución del proyecto .
  • 15. El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos.
  • 17. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario.  Cada secuencia lineal produce un «incremento» del software.  Se debería tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos.
  • 18. El modelo incremento entrega el software en partes pequeñas, pero utilizables, llamadas ((incrementos).  En general, cada incremento se construye sobre aquél que ya ha sido entregado.  Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial.
  • 19. El cliente utiliza el producto central (o sufre la revisión detallada).  Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente.  El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y características adicionales.  Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.
  • 20. El modelo de proceso incremental, es iterativo por naturaleza.  El modelo incremental se centra en la entrega de un producto operacional con cada incremento.  Los primeros incrementos son versiones «incompletas» del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.  El desarrollo incremental es particularmente útil cuando la dotación de personal no está disponible para una implementación completa en la fecha límite que se haya establecido para el proyecto.  Los primeros incrementos se pueden implementar con menos personas.
  • 22. El Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.  Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo.  Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.
  • 23.  El Proceso Unificado tiene dos dimensiones (Figura 1):  Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento  Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza.
  • 24. La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).  La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.
  • 25.  El Proceso Unificado se basa en componentes (component-based), lo que significa que el sistema en construcción está hecho de componentes de software interconectados por medio de interfaces bien definidas (well-defined interfaces).  El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparación de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par.  Los aspectos distintivos del Proceso Unificado están capturados en tres conceptos clave: dirigido por casos de uso (use-case driven), centrado en la arquitectura (architecture-centric), iterativo e incremental. Esto es lo que hace único al Proceso Unificado.
  • 26. Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos.  El término usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el término usuario representa algo o alguien que interactúa con el sistema por desarrollar.
  • 27. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor.  Los casos de uso capturan los requerimientos funcionales.  Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema.  Este modelo reemplaza la tradicional especificación funcional del sistema.  Una especificación funcional tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer?  La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿por cada usuario?  Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que tuviera.
  • 28. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo.  Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada.  Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso.  Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.
  • 29. El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempeña en la construcción de edificios.  El edificio se mira desde diferentes puntos de vista: estructura, servicios, plomería, electricidad, etc.  Esto le permite al constructor ver una radiografía completa antes de empezar a construir.  Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que está siendo construido.
  • 30. El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más significativos del sistema.  La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en los casos de uso.  Sin embargo, también está influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutará, la disponibilidad de componentes reutilizables, consideraciones de instalación, sistemas legados, requerimientos no funcionales (ej. desempeño, confiabilidad).  La arquitectura es la vista del diseño completo con las características más importantes hechas más visibles y dejando los detalles de lado.  Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea.  Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y reúso.
  • 31. ¿Cómo se relacionan los casos de uso con la arquitectura? Cada producto tiene función y forma. Uno sólo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso función corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del “huevo y la gallina”. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realización de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.
  • 32.  Desarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o años.  Es práctico dividir el trabajo en pequeños pedazos o mini-proyectos.  Cada mini-proyecto es una iteración que finaliza en un incremento.  Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto.  Para ser más efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada.
  • 33. Los desarrolladores basan su selección de qué van a implementar en una iteración en dos factores.  Primero, la iteración trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto.  Segundo, la iteración trata con los riesgos más importantes.  Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteración anterior.
  • 34. En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso.  Si una iteración cumple sus metas – y usualmente lo hace – el desarrollo continúa con la siguiente iteración.  Cuando la iteración no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.
  • 35.  Los conceptos anteriormente tratados – dirigido por casos de uso, centrado en arquitectura, desarrollo iterativo e incremental – son igualmente importantes.  La arquitectura provee la estructura sobre la cual guiar el trabajo en iteraciones, mientras que los casos de uso definen las metas y dirigen el trabajo en cada iteración.  Remover cualquiera de estos conceptos reducirá severamente el valor del Proceso Unificado.