SlideShare una empresa de Scribd logo
marfonline@gmail.com            UGB San Miguel              Lic. Marvin Romero



              MODELOS DE PROCESOS
            DESARROLLO DE SOFTWARE
     EL MODELO EN CASCADA




  El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere




                           el o
un enfoque sistemático, secuencial hacia el desarrollo del software, que se

                        igu er
inicia con la especificación de requerimientos del cliente y que continúa con
                       M om
la planeación, el modelado, la construcción y el despliegue para culminar en
el soporte del software terminado.
  El modelo en cascada es el paradigma más antiguo para la ingeniería del
                     an R

software. Sin embargo, en las décadas pasadas.
                  , S rvin


     Problemas:
               GB a



1.   Es muy raro que los proyectos reales sigan el flujo secuencial que
              U c. M




     propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo
     hace de manera indirecta. Como resultado, los cambios confunden
     mientras el equipo de proyecto actúa.
     Con frecuencia es difícil para el cliente establecer todos los requisitos de
                Li




2.
     manera explícita. El modelo en cascada lo requiere y se enfrentan
     dificultades al incorporar la incertidumbre natural presente en el inicio de
     muchos proyectos.
3.   El cliente debe tener paciencia. Una versión que funcione de los
     programas estará disponible cuando el proyecto esté muy avanzado. Un
     error grave será desastroso si no se detecta antes de la revisión del
     programa.

En la actualidad, el trabajo del software está acelerado y sujeto a una cadena
infinita de cambios (de características, funciones y contenido de la
información). Con frecuencia, el modelo en cascada no es apropiado para
dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en
situaciones donde los requerimientos están fijos y donde el trabajo se
realiza, hasta su conclusión, de una manera lineal.




www.miceminfo.net         Busca en FB como CEMINFO          Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel             Lic. Marvin Romero



MODELO INCREMENTAL




                        el o
                     igu er
                    M om
                  an R
El modelo incremental combina elementos del modelo en cascada aplicado en
forma iterativa. El modelo incremental aplica secuencias lineales de manera
               , S rvin


escalonada conforme avanza el tiempo en el calendario. Cada secuencia
lineal produce "incrementos" del software. Por ejemplo, el software
procesador de texto, desarrollado con el paradigma incremental en su
            GB a




primer incremento, podría realizar funciones básicas de administración de
           U c. M




archivos, edición y producción de documentos; en el segundo incremento,
ediciones más sofisticadas, y tendría funciones más complejas de
producción de documentos; en el tercer incremento, funciones de corrección
             Li




ortográfica y gramatical; y en el cuarto, capacidades avanzadas de
configuración de página.

El modelo de proceso incremental, al igual que la construcción de prototipos
y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de
la construcción de prototipos, el modelo incremental se enfoca 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 necesita y una plataforma para evaluarlo.

El desarrollo incremental es útil sobre todo cuando el personal necesario
para una implementación completa no está disponible. Los primeros
incrementos se pueden implementar con menos gente. Si el producto
esencial es bien recibido se agrega (si se requiere) más personal para
implementar el incremento siguiente. Además, los incrementos se pueden
planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande
podría requerir la disponibilidad de un hardware nuevo que está en
desarrollo y cuya fecha de entrega es incierta. Sería posible planear los
primeros incrementos de forma que se evite el uso de este hardware, lo que




www.miceminfo.net      Busca en FB como CEMINFO           Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel               Lic. Marvin Romero


permitiría la entrega de funcionalidad parcial a los usuarios finales sin
retrasos desordenados.



MODELO DRA




                        el o
                     igu er
                    M om
                  an R
               , S rvin
            GB a
           U c. M
             Li




El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de
software incremental que resalta un ciclo de desarrollo corto. El modelo DRA
es una adaptación a "alta velocidad" del modelo en cascada en el que se logra
el desarrollo rápido mediante un enfoque de construcción basado en
componentes. Si se entienden bien los requisitos y se limita el ámbito del
proyecto, el proceso DRA permite que un equipo de desarrollo cree un
"sistema completamente funcional" dentro de un periodo muy corto (por
ejemplo, de 60 a 90 días).

Como otros modelos de proceso, el enfoque DRA cumple con las actividades
genéricas del marco de trabajo que ya se han presentado. La comunicación
trabaja para entender el problema de negocios y las características de
información que debe incluir el software. La planeación es esencial porque
varios equipos de software trabajan en paralelo sobre diferentes funciones
del sistema. El modelado incluye tres grandes fases —modelado de negocios,




www.miceminfo.net       Busca en FB como CEMINFO           Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel              Lic. Marvin Romero


modelado de datos y modelado del proceso— y establece representaciones
del diseño que sirven como base para la actividad de construcción del
modelo DRA. La construcción resalta el empleo de componentes de software
existente y la aplicación de la generación automática de código. Por último,
el despliegue establece una base para las iteraciones subsecuentes, si éstas
son necesarias.

Si una aplicación de negocios se puede modular de forma que cada gran
función pueda completarse en menos de tres meses (mediante la aplicación
del enfoque ya descrito), ésta es una candidata para el DRA. Cada gran
función se puede abordar mediante un equipo de DRA por separado, para
después integrarlas y formar un todo.

Como todos los modelos de proceso, el enfoque DRA tiene inconvenientes

1) para proyectos grandes, pero escalables, el DRA necesita suficientes
recursos humanos para crear el número correcto de equipos DRA;




                        el o
2) si los desarrolladores y clientes no se comprometen con las actividades


                     igu er
rápidas necesarias para completar el sistema en un marco de tiempo muy
breve, los proyectos de DRA fallarán;
                    M om
3) si un sistema no se puede modular en forma apropiada, la construcción de
                  an R

los componentes necesarios para el DRA será problemática;
               , S rvin


4) si el alto rendimiento es un aspecto importante, y se alcanzará al convertir
interfases en componentes del sistema, el enfoque DRA podría no funcionar;
y
            GB a
           U c. M




5) el DRA sería inapropiado cuando los riesgos técnicos son altos (por
ejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías).
             Li




www.miceminfo.net      Busca en FB como CEMINFO           Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel             Lic. Marvin Romero



                       MODELOS EVOLUTIVOS
Los modelos evolutivos son iterativos; los caracteriza la forma en que
permiten que los ingenieros de software desarrollen versiones cada vez más
completas del software.

   •   CONSTRUCCIÓN DE PROTOTIPOS

   •   MODELO EN ESPIRAL

   •   MODELO DE DESARROLLO CONCURRENTE



CONSTRUCCION DE PROTOTIPOS




                        el o
                     igu er
                    M om
                  an R
               , S rvin
            GB a
           U c. M
             Li




A menudo un cliente define un conjunto de objetivos generales para el
software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida. En otros casos, el responsable del desarrollo del
software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de




www.miceminfo.net      Busca en FB como CEMINFO          Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel              Lic. Marvin Romero


un sistema operativo o de la forma que debería tomar la interacción
humano-máquina. En éstas, y en muchas otras situaciones, un paradigma de
construcción de prototipos puede ofrecer el mejor enfoque.

A pesar de que la construcción de prototipos se puede utilizar como un
modelo de proceso independiente, se emplea más comúnmente como una
técnica susceptible de implementarse dentro del contexto de cualquiera de
los modelos de proceso expuestos en este capítulo. Sin importar la forma en
que éste se aplique, el paradigma de construcción de prototipos ayuda al
ingeniero de sistemas y al cliente a entender de mejor manera cuál será el
resultado de la construcción cuando los requisitos estén satisfechos.

El paradigma de construcción de prototipos se inicia con la comunicación. El
ingeniero de software y el cliente encuentran y definen los objetivos globales
para el software, identifican los requisitos conocidos y las áreas del esquema
en donde es necesaria más definición. Entonces se plantea con rapidez una
iteración de construcción de prototipos y se presenta el modelado (en la
forma de un diseño rápido). El diseño rápido se centra en una representación




                        el o
de aquellos aspectos del software que serán visibles para el cliente o el

                     igu er
usuario final (por ejemplo, la configuración de la interfaz con el usuario y el
                    M om
formato de los despliegues de salida). El diseño rápido conduce a la
construcción de un prototipo. Después, el prototipo lo evalúa el
                  an R
cliente/usuario y con la retroalimentación se refinan los requisitos del soft-
ware que se desarrollará. La iteración ocurre cuando el prototipo se ajusta
               , S rvin


para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo
el desarrollador entienda mejor lo que se debe hacer.
            GB a




De manera ideal, el prototipo debería servir como un mecanismo para
           U c. M




identificar los requisitos del software. Si se construye un prototipo de
trabajo, el desarrollador intenta emplear los fragmentos del programa ya
existentes o aplica herramientas (como generadores de informes,
administradores de ventanas, etcétera) que permiten producir programas de
             Li




trabajo con rapidez.

Pero ¿qué debe hacerse con el prototipo una vez cumplido el propósito
descrito? Brooks ofrece una respuesta:

En la mayoría de los proyectos, el primer sistema construido apenas se
utiliza. Tal vez sea demasiado lento, muy grande o torpe en su uso, o
reúna las tres características a la vez. No existe otra opción que comenzar
de nuevo, aunque sea doloroso, es lo mejor, y construir una revisión
rediseñada en la que se resuelvan estos problemas... Cuando se aplica un
concepto nuevo de sistema o una tecnología nueva, se tiene que construir
un sistema inservible y que sea necesario desechar, porque incluso la
mejor planeación no es omnisciente como para que el sistema esté
perfecto desde la primera vez. Por lo tanto, la pregunta de la
administración no es si debe construirse un sistema piloto y desecharlo.
Esto tendrá que hacerse. La única pregunta es si se planea la construcción
de un desechable o se promete entregárselo a los clientes.




www.miceminfo.net      Busca en FB como CEMINFO           Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel               Lic. Marvin Romero


El prototipo puede servir como "primer sistema", el que Brooks recomienda
desechar. Pero ésta tal vez sea una visión idealizada. Es verdad que a los
clientes y los desarrolladores les gusta el paradigma de construcción de
prototipos. A los usuarios les gusta el sistema real y a los desarrolladores les
gusta construir algo de inmediato. Sin embargo, la construcción de
prototipos también se torna problemática por las siguientes razones:

1. El cliente ve lo que parece una versión en funcionamiento del software, sin
saber que el prototipo está unido "con chicle y cable para embalaje", que por
la prisa de hacerlo funcionar no se ha considerado la calidad del software
global o la facilidad de mantenimiento a largo plazo. Cuando se informa que
el producto debe construirse otra vez para mantener los altos niveles de cali-
dad, el cliente no lo entiende y pide la aplicación de "unos pequeños ajustes"
para que se pueda elaborar un producto final a partir del prototipo. Es muy
frecuente que la gestión del desarrollo de software sea muy lenta.

2. A menudo, el desarrollador establece compromisos de implementación
para lograr que el prototipo funcione con rapidez. Tal vez se utilice un




                        el o
sistema operativo o lenguaje de programación inadecuado sólo porque está

                     igu er
disponible y es conocido; se puede implementar un algoritmo ineficiente
                    M om
sólo para mostrar capacidad. Después de un tiempo, el desarrollador quizá
se familiarice con estas selecciones y olvide las razones por las que son
                  an R
inapropiadas. La selección menos ideal ahora se convierte en una parte
integral del sistema.
               , S rvin


A pesar de que tal vez surjan problemas, la construcción de prototipos
puede ser un paradigma efectivo para la ingeniería del software. La clave
            GB a




es definir las reglas del juego desde el principio; es decir, el cliente y el
           U c. M




desarrollador se deben poner de acuerdo en que el prototipo se construya
y sirva como un mecanismo para la definición de requisitos, en que se
descarte, al menos en parte, y en que después se desarrolle el software
real con un enfoque hacia la calidad.
             Li




www.miceminfo.net       Busca en FB como CEMINFO           Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel             Lic. Marvin Romero



MODELO EN ESPIRAL




                        el o
                     igu er
                    M om
                  an R
               , S rvin


El modelo en espiral, que Boehm propuso originalmente, es un modelo de
proceso de software evolutivo que conjuga la naturaleza iterativa de la
construcción de prototipos con los aspectos controlados y sistemáticos del
            GB a



modelo en cascada. Proporciona el material para el desarrollo rápido de
           U c. M




versiones incrementales del software. Boehm describe este modelo de la
siguiente manera:

El modelo de desarrollo en espiral es un generador del modelo de proceso
             Li




guiado por el riesgo que se emplea para conducir sistemas intensivos de
ingeniería del software concurrente y con múltiples usuarios. Tiene dos
características distintivas principales. Una de ellas es un enfoque cíclico
para el crecimiento incremental del grado de definición e implementación
de un sistema, mientras disminuye su grado de riesgo. La otra es un con-
junto de puntos de fijación para asegurar el compromiso del usuario con
soluciones de sistema que sean factibles y mutuamente satisfactorias.

Cuando se aplica el modelo en espiral, el software se desarrolla en una serie
de entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez
sea un documento del modelo o un prototipo. Durante las últimas
iteraciones se producen versiones cada vez más completas del sistema
desarrollado.

Un proceso en espiral se divide en un conjunto de actividades del marco de
trabajo que define el equipo de ingeniería del software. Para propósitos
ilustrativos se aprovechan las actividades genéricas del marco de trabajo
expuestas páginas atrás. Cada una de las actividades del marco de trabajo
representa un segmento de la ruta en espiral. Cuando comienza este proceso




www.miceminfo.net      Busca en FB como CEMINFO          Blog, Foros, y más...
marfonline@gmail.com           UGB San Miguel              Lic. Marvin Romero


evolutivo el equipo de software realiza actividades implicadas en un circuito
alrededor de la espiral que tiene una dirección en el sentido del movimiento
de las manecillas del reloj, y que se inicia desde el centro. El riesgo es un
factor considerado en cada revolución. Los puntos de fijación —una
combinación de productos de trabajo y condiciones incluidas a lo largo de la
ruta de la espiral— se consideran para cada paso evolutivo.

El primer circuito alrededor de la espiral quizá genere el desarrollo de una
especificación del producto; los pasos subsecuentes alrededor de la espiral
se pueden aprovechar para desarrollar un prototipo y después, en forma
progresiva, versiones más elaboradas del software. Cada paso a través de la
región de planeación resulta en ajustes al plan del proyecto. Los costos y el
itinerario se ajustan con base en la retroalimentación derivada de la relación
con el cliente después de la entrega. Además, el administrador del proyecto
ajusta el número de iteraciones planeado que se requiere para completar el
software.

A diferencia de otros modelos de proceso que terminan cuando se entrega el




                        el o
software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la

                     igu er
vida del software de computadora. Por lo tanto, el primer circuito alrededor
                    M om
de la espiral podría representar un "proyecto de desarrollo del concepto", el
cual se inicia en el centro de la espiral y continúa por múltiples iteraciones 6
                  an R
hasta que el desarrollo del concepto esté completo. Si el concepto se
desarrollará en un producto real, el proceso continúa en la siguiente fase de
               , S rvin


la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El
nuevo producto evolucionará a través de un número de iteraciones alrededor
de la espiral. Después, un circuito alrededor de la espiral se podría emplear
            GB a




para representar un "proyecto de mejoramiento del producto". En esencia, la
           U c. M




espiral, cuando se caracteriza de esta forma, permanece operativa hasta que
el software se retira. En ocasiones el proceso está inactivo, pero siempre que
se inicie un cambio el proceso comienza en el punto de entrada aprobado
             Li




(por ejemplo, mejoramiento del producto).

El modelo en espiral es un enfoque realista para el desarrollo de software y
de sistemas a gran escala. Como el software evoluciona conforme avanza el
proceso, el desarrollador y el cliente entienden y reaccionan de mejor
manera ante los riesgos en cada etapa evolutiva. El modelo en espiral emplea
la construcción de prototipos como un mecanismo encaminado a reducir
riesgos pero, en forma más importante, permite al desarrollador la
aplicación del enfoque de la construcción de prototipos en cualquier etapa
evolutiva del producto. Mantiene el enfoque sistemático de los pasos que
sugiere el ciclo de vida clásico, pero lo incorpora al marco de trabajo ite-
rativo que refleja de forma más verídica el mundo real. El modelo en espiral
exige una consideración directa de los riesgos técnicos en todas las etapas del
proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de
que se vuelvan problemáticos.

Así como otros paradigmas, el modelo en espiral no es una panacea. Es
difícil convencer a los clientes (en particular en situaciones bajo contrato) de
que el enfoque evolutivo es controlable, ya que se requiere una habilidad




www.miceminfo.net       Busca en FB como CEMINFO           Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel              Lic. Marvin Romero


considerable para evaluar el riesgo y se confia en dicha habilidad para
obtener el éxito. Si un riesgo importante no se descubre y administra, sin
duda surgirán problemas.



MODELO DE DESARROLLO CONCURRENTE




                        el o
                     igu er
                    M om
                  an R
               , S rvin
            GB a
           U c. M
             Li




El modelo de desarrollo concurrente, llamado algunas veces ingeniería
concurrente, se representa en forma esquemática como una serie de
actividades del marco de trabajo, acciones y tareas de la ingeniería del
software y sus estados asociados. Por ejemplo, la actividad de modelado,
definida para el modelo en espiral, se lleva a cabo al invocar las acciones
siguientes: construcción de prototipos o modelado y especificación del
análisis y diseño.7




www.miceminfo.net       Busca en FB como CEMINFO          Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel               Lic. Marvin Romero


Se proporciona un esquema de una tarea de ingeniería de software
relacionada con la actividad de modelado para el modelo de proceso
concurrente. La actividad —modelado— puede estar en alguno de los
estados destacados mencionados antes en cualquier momento dado. De
forma similar, otras actividades o tareas (por ejemplo, la comunicación y la
construcción) se representan de una manera análoga. Todas las actividades
existen de forma concurrente, pero se encuentran en diferentes estados. Por
ejemplo, al principio del proyecto la actividad de comunicación (no se
muestra en la figura) ha completado su primera iteración y existe en el
estado de en espera de cambios. La actividad de modelado que existió en el
estado ninguno mientras se realizaba la comunicación inicial, ahora realiza
una transición al estado en desarrollo. Sin embargo, si el cliente indica
cambios en los requisitos, la actividad de modelado se mueve del estado en
desarrollo al estado de en espera de cambios.

El modelo de proceso concurrente define una serie de eventos que
dispararán transiciones de estado a estado para cada una de las actividades,




                        el o
acciones o tareas de la ingeniería del software. Por ejemplo, durante los


                     igu er
primeros estados del diseño (una acción de la ingeniería del software que
ocurre en el curso de la actividad de modelación) no se detecta una
                    M om
inconsistencia en el modelo del análisis. Esto genera el evento corrección del
análisis del modelo, el cual disparará la creación del análisis desde el estado
                  an R

realizado hasta el estado de en espera de cambios.
               , S rvin


El modelo de proceso concurrente se aplica a todos los tipos de desarrollo
de software y proporciona una visión exacta del estado actual de un
proyecto. En lugar de confinar las actividades, acciones y tareas de la
            GB a




ingeniería del software a una secuencia de eventos, define una red de
           U c. M




actividades. Cada actividad, acción o tarea en la red existe de manera
simultánea con otras actividades, acciones o tareas. Los eventos generados
entre los estados.
             Li




www.miceminfo.net       Busca en FB como CEMINFO           Blog, Foros, y más...
marfonline@gmail.com          UGB San Miguel               Lic. Marvin Romero


                               Actividad Nº 1




                         el o
                      igu er
                     M om
                               Actividad Nº 2
                   an R
Investigue Y Explique:
                , S rvin


   •   Cuáles son los Modelos Especializados de Proceso:

         – Desarrollo basado en C____________
             GB a




         – Modelo de _____________ Formales
            U c. M




         – Desarrollo de Software Orientado a A_________
              Li




www.miceminfo.net        Busca en FB como CEMINFO          Blog, Foros, y más...

Más contenido relacionado

La actualidad más candente

Modelos de desarrollo rápido de software
Modelos de desarrollo rápido de softwareModelos de desarrollo rápido de software
Modelos de desarrollo rápido de software
Juan Pablo Bustos Thames
 
Modelos en la ingeniería de software
Modelos en la ingeniería de softwareModelos en la ingeniería de software
Modelos en la ingeniería de software
Marco Aurelio
 
Unidad 2 ing de software
Unidad 2 ing de softwareUnidad 2 ing de software
Unidad 2 ing de software
Armando Barrera
 
Modelo en cascada
Modelo en cascadaModelo en cascada
Modelo en cascada
home
 
Acti deaprendizaje equipo_software1
Acti deaprendizaje equipo_software1Acti deaprendizaje equipo_software1
Acti deaprendizaje equipo_software1
Dalia Sandiego
 
Rup
RupRup
Grupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-softwareGrupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-software
PrimoLaura
 
Doc grupo2-webquest
Doc grupo2-webquestDoc grupo2-webquest
359287107 cuadro-comparativo-de-los-ciclos-de-vida
359287107 cuadro-comparativo-de-los-ciclos-de-vida359287107 cuadro-comparativo-de-los-ciclos-de-vida
359287107 cuadro-comparativo-de-los-ciclos-de-vida
Oscare Coy
 
Modelos de desarrollo de un software
Modelos de desarrollo de un softwareModelos de desarrollo de un software
Modelos de desarrollo de un software
Lucas Rodriguez Paredes
 
Modelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiralModelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiral
Juan Pablo Bustos Thames
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
Radel Fuentes
 
Comparativa Metodologias
Comparativa MetodologiasComparativa Metodologias
Comparativa Metodologias
Alipknot
 
Clase3 Is 0702 V1
Clase3 Is 0702 V1Clase3 Is 0702 V1
Clase3 Is 0702 V1
marlonyesith
 
Investigacion de modelos
Investigacion de modelosInvestigacion de modelos
Investigacion de modelos
emilii17061991
 
Expo modelocascada
Expo modelocascadaExpo modelocascada
Expo modelocascada
masilog
 

La actualidad más candente (16)

Modelos de desarrollo rápido de software
Modelos de desarrollo rápido de softwareModelos de desarrollo rápido de software
Modelos de desarrollo rápido de software
 
Modelos en la ingeniería de software
Modelos en la ingeniería de softwareModelos en la ingeniería de software
Modelos en la ingeniería de software
 
Unidad 2 ing de software
Unidad 2 ing de softwareUnidad 2 ing de software
Unidad 2 ing de software
 
Modelo en cascada
Modelo en cascadaModelo en cascada
Modelo en cascada
 
Acti deaprendizaje equipo_software1
Acti deaprendizaje equipo_software1Acti deaprendizaje equipo_software1
Acti deaprendizaje equipo_software1
 
Rup
RupRup
Rup
 
Grupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-softwareGrupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-software
 
Doc grupo2-webquest
Doc grupo2-webquestDoc grupo2-webquest
Doc grupo2-webquest
 
359287107 cuadro-comparativo-de-los-ciclos-de-vida
359287107 cuadro-comparativo-de-los-ciclos-de-vida359287107 cuadro-comparativo-de-los-ciclos-de-vida
359287107 cuadro-comparativo-de-los-ciclos-de-vida
 
Modelos de desarrollo de un software
Modelos de desarrollo de un softwareModelos de desarrollo de un software
Modelos de desarrollo de un software
 
Modelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiralModelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiral
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
 
Comparativa Metodologias
Comparativa MetodologiasComparativa Metodologias
Comparativa Metodologias
 
Clase3 Is 0702 V1
Clase3 Is 0702 V1Clase3 Is 0702 V1
Clase3 Is 0702 V1
 
Investigacion de modelos
Investigacion de modelosInvestigacion de modelos
Investigacion de modelos
 
Expo modelocascada
Expo modelocascadaExpo modelocascada
Expo modelocascada
 

Similar a Modelos de desarrollo de software separata

Insidencias En Los Paradigmas De La Ingeniera De Software
Insidencias En Los Paradigmas De La Ingeniera De SoftwareInsidencias En Los Paradigmas De La Ingeniera De Software
Insidencias En Los Paradigmas De La Ingeniera De Software
Universidad De Cordoba
 
Modelos del ciclo de vida del software
Modelos del ciclo de vida del softwareModelos del ciclo de vida del software
Modelos del ciclo de vida del software
Abner Torres
 
Jhostin vasquez modelos de software
Jhostin vasquez   modelos de softwareJhostin vasquez   modelos de software
Jhostin vasquez modelos de software
jhostinvasquez
 
Desarrollo eficiente de software
Desarrollo eficiente de softwareDesarrollo eficiente de software
Desarrollo eficiente de software
Alejandro Domínguez Torres
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
Jazmin Cr
 
Tarea 13
Tarea 13Tarea 13
Tarea 13
karinaaura
 
Presentacion grupo8
Presentacion grupo8Presentacion grupo8
Presentacion grupo8
KatherineFernanda18
 
Métodos de la ingeniería
Métodos de la ingenieríaMétodos de la ingeniería
Métodos de la ingeniería
Sam Stgo
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de software
UVM
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
Brihany Rossell
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
LuisSanchez1283
 
Tarea nayeli
Tarea nayeliTarea nayeli
el kap
el kapel kap
el kap
NIIIICKKoo
 
Apuntes
ApuntesApuntes
Investigación de modelos
Investigación de modelos Investigación de modelos
Investigación de modelos
bren1995
 
Curso Uml 3.1 Modelos De Desarrollo De Software
Curso Uml   3.1 Modelos De Desarrollo De SoftwareCurso Uml   3.1 Modelos De Desarrollo De Software
Curso Uml 3.1 Modelos De Desarrollo De Software
Emilio Aviles Avila
 
Inf162 diapositiva...
Inf162 diapositiva...Inf162 diapositiva...
Inf162 diapositiva...
CamiloCabreraFlores
 
Investigacion de modelos
Investigacion de modelosInvestigacion de modelos
Investigacion de modelos
emilii17061991
 
Sesión 3: Modelos prescriptivos de proceso
Sesión 3: Modelos prescriptivos de procesoSesión 3: Modelos prescriptivos de proceso
Sesión 3: Modelos prescriptivos de proceso
Coesi Consultoria
 
Sesión 3: Modelos prescriptivos de proceso de software
Sesión 3: Modelos prescriptivos de proceso de softwareSesión 3: Modelos prescriptivos de proceso de software
Sesión 3: Modelos prescriptivos de proceso de software
Luis Fernández
 

Similar a Modelos de desarrollo de software separata (20)

Insidencias En Los Paradigmas De La Ingeniera De Software
Insidencias En Los Paradigmas De La Ingeniera De SoftwareInsidencias En Los Paradigmas De La Ingeniera De Software
Insidencias En Los Paradigmas De La Ingeniera De Software
 
Modelos del ciclo de vida del software
Modelos del ciclo de vida del softwareModelos del ciclo de vida del software
Modelos del ciclo de vida del software
 
Jhostin vasquez modelos de software
Jhostin vasquez   modelos de softwareJhostin vasquez   modelos de software
Jhostin vasquez modelos de software
 
Desarrollo eficiente de software
Desarrollo eficiente de softwareDesarrollo eficiente de software
Desarrollo eficiente de software
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
 
Tarea 13
Tarea 13Tarea 13
Tarea 13
 
Presentacion grupo8
Presentacion grupo8Presentacion grupo8
Presentacion grupo8
 
Métodos de la ingeniería
Métodos de la ingenieríaMétodos de la ingeniería
Métodos de la ingeniería
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de software
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
 
Tarea nayeli
Tarea nayeliTarea nayeli
Tarea nayeli
 
el kap
el kapel kap
el kap
 
Apuntes
ApuntesApuntes
Apuntes
 
Investigación de modelos
Investigación de modelos Investigación de modelos
Investigación de modelos
 
Curso Uml 3.1 Modelos De Desarrollo De Software
Curso Uml   3.1 Modelos De Desarrollo De SoftwareCurso Uml   3.1 Modelos De Desarrollo De Software
Curso Uml 3.1 Modelos De Desarrollo De Software
 
Inf162 diapositiva...
Inf162 diapositiva...Inf162 diapositiva...
Inf162 diapositiva...
 
Investigacion de modelos
Investigacion de modelosInvestigacion de modelos
Investigacion de modelos
 
Sesión 3: Modelos prescriptivos de proceso
Sesión 3: Modelos prescriptivos de procesoSesión 3: Modelos prescriptivos de proceso
Sesión 3: Modelos prescriptivos de proceso
 
Sesión 3: Modelos prescriptivos de proceso de software
Sesión 3: Modelos prescriptivos de proceso de softwareSesión 3: Modelos prescriptivos de proceso de software
Sesión 3: Modelos prescriptivos de proceso de software
 

Más de Marvin Romero

Procesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas OperativosProcesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas Operativos
Marvin Romero
 
Gestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas OperativosGestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas Operativos
Marvin Romero
 
Guía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de ProgramaciónGuía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de Programación
Marvin Romero
 
Guia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de ProgramacionGuia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de Programacion
Marvin Romero
 
Todo sobre Sistemas Operativos
Todo sobre Sistemas OperativosTodo sobre Sistemas Operativos
Todo sobre Sistemas Operativos
Marvin Romero
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
Marvin Romero
 
Clasificación de los Sistemas Operativos
Clasificación de los Sistemas OperativosClasificación de los Sistemas Operativos
Clasificación de los Sistemas Operativos
Marvin Romero
 
Introducción a los Sistemas Operativos
Introducción a los Sistemas OperativosIntroducción a los Sistemas Operativos
Introducción a los Sistemas Operativos
Marvin Romero
 
Importancia de los Sistemas Operativos
Importancia de los Sistemas OperativosImportancia de los Sistemas Operativos
Importancia de los Sistemas Operativos
Marvin Romero
 
Máquina de von neumann
Máquina de von neumannMáquina de von neumann
Máquina de von neumann
Marvin Romero
 
Estructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje CEstructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje C
Marvin Romero
 
Variables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en CVariables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en C
Marvin Romero
 
Importancia de la programación estructurada opt
Importancia de la programación estructurada optImportancia de la programación estructurada opt
Importancia de la programación estructurada opt
Marvin Romero
 
Historia y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c optHistoria y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c opt
Marvin Romero
 
Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012
Marvin Romero
 
Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012
Marvin Romero
 
Metodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de SoftwareMetodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de Software
Marvin Romero
 
Especificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de SoftwareEspecificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de Software
Marvin Romero
 
Cocomo ejemplo
Cocomo ejemploCocomo ejemplo
Cocomo ejemplo
Marvin Romero
 
Planificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera partePlanificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera parte
Marvin Romero
 

Más de Marvin Romero (20)

Procesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas OperativosProcesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas Operativos
 
Gestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas OperativosGestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas Operativos
 
Guía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de ProgramaciónGuía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de Programación
 
Guia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de ProgramacionGuia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de Programacion
 
Todo sobre Sistemas Operativos
Todo sobre Sistemas OperativosTodo sobre Sistemas Operativos
Todo sobre Sistemas Operativos
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
 
Clasificación de los Sistemas Operativos
Clasificación de los Sistemas OperativosClasificación de los Sistemas Operativos
Clasificación de los Sistemas Operativos
 
Introducción a los Sistemas Operativos
Introducción a los Sistemas OperativosIntroducción a los Sistemas Operativos
Introducción a los Sistemas Operativos
 
Importancia de los Sistemas Operativos
Importancia de los Sistemas OperativosImportancia de los Sistemas Operativos
Importancia de los Sistemas Operativos
 
Máquina de von neumann
Máquina de von neumannMáquina de von neumann
Máquina de von neumann
 
Estructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje CEstructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje C
 
Variables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en CVariables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en C
 
Importancia de la programación estructurada opt
Importancia de la programación estructurada optImportancia de la programación estructurada opt
Importancia de la programación estructurada opt
 
Historia y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c optHistoria y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c opt
 
Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012
 
Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012
 
Metodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de SoftwareMetodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de Software
 
Especificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de SoftwareEspecificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de Software
 
Cocomo ejemplo
Cocomo ejemploCocomo ejemplo
Cocomo ejemplo
 
Planificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera partePlanificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera parte
 

Último

Apuntes Unidad I Conceptos Básicos_compressed.pdf
Apuntes Unidad I Conceptos Básicos_compressed.pdfApuntes Unidad I Conceptos Básicos_compressed.pdf
Apuntes Unidad I Conceptos Básicos_compressed.pdf
VeronicaCabrera50
 
Acuerdo tercer periodo - Grado Sextos.pptx
Acuerdo tercer periodo - Grado Sextos.pptxAcuerdo tercer periodo - Grado Sextos.pptx
Acuerdo tercer periodo - Grado Sextos.pptx
Carlos Andrés Hernández Cabrera
 
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
 
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
 
Presentación sobré la culturas Lima, la cultura Paracas y la cultura Vicús.
Presentación  sobré la culturas Lima,  la  cultura Paracas y la cultura Vicús.Presentación  sobré la culturas Lima,  la  cultura Paracas y la cultura Vicús.
Presentación sobré la culturas Lima, la cultura Paracas y la cultura Vicús.
Juan Luis Cunya Vicente
 
BLOQUE II SEMANA DE GESTION EN INSTITUVIONES EDUCATIVAS.pptx
BLOQUE II SEMANA DE GESTION EN INSTITUVIONES EDUCATIVAS.pptxBLOQUE II SEMANA DE GESTION EN INSTITUVIONES EDUCATIVAS.pptx
BLOQUE II SEMANA DE GESTION EN INSTITUVIONES EDUCATIVAS.pptx
royguzman5
 
Informe de Evaluacion Diagnostica de Comunicacion 1-5 Ccesa007.pdf
Informe de Evaluacion Diagnostica de Comunicacion 1-5 Ccesa007.pdfInforme de Evaluacion Diagnostica de Comunicacion 1-5 Ccesa007.pdf
Informe de Evaluacion Diagnostica de Comunicacion 1-5 Ccesa007.pdf
Demetrio Ccesa Rayme
 
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/
 
LABERINTOS DE DISCIPLINAS OLÍMPICAS. Por JAVIER SOLIS NOYOLA
LABERINTOS DE DISCIPLINAS OLÍMPICAS.  Por JAVIER SOLIS NOYOLALABERINTOS DE DISCIPLINAS OLÍMPICAS.  Por JAVIER SOLIS NOYOLA
LABERINTOS DE DISCIPLINAS OLÍMPICAS. Por JAVIER SOLIS NOYOLA
JAVIER SOLIS NOYOLA
 
Presentación sobré las culturas del Perú .
Presentación sobré las culturas del Perú .Presentación sobré las culturas del Perú .
Presentación sobré las culturas del Perú .
Juan Luis Cunya Vicente
 
🔴 (AC-S18) Semana 18 – TRABAJO FINAL (INFORMATICA APLICADA TERMINADO y revisa...
🔴 (AC-S18) Semana 18 – TRABAJO FINAL (INFORMATICA APLICADA TERMINADO y revisa...🔴 (AC-S18) Semana 18 – TRABAJO FINAL (INFORMATICA APLICADA TERMINADO y revisa...
🔴 (AC-S18) Semana 18 – TRABAJO FINAL (INFORMATICA APLICADA TERMINADO y revisa...
FernandoEstebanLlont
 
INFORME RESULTADOS DE CREA Y EMPRENDE 2024.pdf
INFORME RESULTADOS DE CREA Y EMPRENDE 2024.pdfINFORME RESULTADOS DE CREA Y EMPRENDE 2024.pdf
INFORME RESULTADOS DE CREA Y EMPRENDE 2024.pdf
Juan Carlos Catura Arapa
 
fase intensiva taller intensivo de CTE julio
fase intensiva taller intensivo de CTE juliofase intensiva taller intensivo de CTE julio
fase intensiva taller intensivo de CTE julio
leydijazminguevaragu
 
La Relación Mixta DA ( Riesgo)- Matriz DA
La Relación Mixta DA ( Riesgo)- Matriz DALa Relación Mixta DA ( Riesgo)- Matriz DA
La Relación Mixta DA ( Riesgo)- Matriz DA
JonathanCovena1
 
2024 DIA DEL LOGRO IE HONORIO DELGADO ESPINOZA
2024 DIA DEL LOGRO IE HONORIO DELGADO ESPINOZA2024 DIA DEL LOGRO IE HONORIO DELGADO ESPINOZA
2024 DIA DEL LOGRO IE HONORIO DELGADO ESPINOZA
Sandra Mariela Ballón Aguedo
 
Apuntes de Enfermería (para estudiantes)
Apuntes de Enfermería (para estudiantes)Apuntes de Enfermería (para estudiantes)
Apuntes de Enfermería (para estudiantes)
milyluna0207
 
Análisis y Evaluación del Impacto Ambiental.pdf
Análisis y Evaluación del Impacto Ambiental.pdfAnálisis y Evaluación del Impacto Ambiental.pdf
Análisis y Evaluación del Impacto Ambiental.pdf
JonathanCovena1
 
PPT II BLOQUE SG 2024 - semana de gestion.pdf
PPT  II BLOQUE SG 2024 - semana de gestion.pdfPPT  II BLOQUE SG 2024 - semana de gestion.pdf
PPT II BLOQUE SG 2024 - semana de gestion.pdf
ISAACMAMANIFLORES2
 
homeostasis.pptx. Enfermería técnica periodo 1
homeostasis.pptx. Enfermería técnica periodo 1homeostasis.pptx. Enfermería técnica periodo 1
homeostasis.pptx. Enfermería técnica periodo 1
NohemiLumiereLopezHu1
 
FORMATO APA - JOHNNY FELIX SURI MAMANI 2024
FORMATO APA - JOHNNY FELIX SURI MAMANI 2024FORMATO APA - JOHNNY FELIX SURI MAMANI 2024
FORMATO APA - JOHNNY FELIX SURI MAMANI 2024
JOHNNY SURI MAMANI
 

Último (20)

Apuntes Unidad I Conceptos Básicos_compressed.pdf
Apuntes Unidad I Conceptos Básicos_compressed.pdfApuntes Unidad I Conceptos Básicos_compressed.pdf
Apuntes Unidad I Conceptos Básicos_compressed.pdf
 
Acuerdo tercer periodo - Grado Sextos.pptx
Acuerdo tercer periodo - Grado Sextos.pptxAcuerdo tercer periodo - Grado Sextos.pptx
Acuerdo tercer periodo - Grado Sextos.pptx
 
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
 
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
 
Presentación sobré la culturas Lima, la cultura Paracas y la cultura Vicús.
Presentación  sobré la culturas Lima,  la  cultura Paracas y la cultura Vicús.Presentación  sobré la culturas Lima,  la  cultura Paracas y la cultura Vicús.
Presentación sobré la culturas Lima, la cultura Paracas y la cultura Vicús.
 
BLOQUE II SEMANA DE GESTION EN INSTITUVIONES EDUCATIVAS.pptx
BLOQUE II SEMANA DE GESTION EN INSTITUVIONES EDUCATIVAS.pptxBLOQUE II SEMANA DE GESTION EN INSTITUVIONES EDUCATIVAS.pptx
BLOQUE II SEMANA DE GESTION EN INSTITUVIONES EDUCATIVAS.pptx
 
Informe de Evaluacion Diagnostica de Comunicacion 1-5 Ccesa007.pdf
Informe de Evaluacion Diagnostica de Comunicacion 1-5 Ccesa007.pdfInforme de Evaluacion Diagnostica de Comunicacion 1-5 Ccesa007.pdf
Informe de Evaluacion Diagnostica de Comunicacion 1-5 Ccesa007.pdf
 
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
 
LABERINTOS DE DISCIPLINAS OLÍMPICAS. Por JAVIER SOLIS NOYOLA
LABERINTOS DE DISCIPLINAS OLÍMPICAS.  Por JAVIER SOLIS NOYOLALABERINTOS DE DISCIPLINAS OLÍMPICAS.  Por JAVIER SOLIS NOYOLA
LABERINTOS DE DISCIPLINAS OLÍMPICAS. Por JAVIER SOLIS NOYOLA
 
Presentación sobré las culturas del Perú .
Presentación sobré las culturas del Perú .Presentación sobré las culturas del Perú .
Presentación sobré las culturas del Perú .
 
🔴 (AC-S18) Semana 18 – TRABAJO FINAL (INFORMATICA APLICADA TERMINADO y revisa...
🔴 (AC-S18) Semana 18 – TRABAJO FINAL (INFORMATICA APLICADA TERMINADO y revisa...🔴 (AC-S18) Semana 18 – TRABAJO FINAL (INFORMATICA APLICADA TERMINADO y revisa...
🔴 (AC-S18) Semana 18 – TRABAJO FINAL (INFORMATICA APLICADA TERMINADO y revisa...
 
INFORME RESULTADOS DE CREA Y EMPRENDE 2024.pdf
INFORME RESULTADOS DE CREA Y EMPRENDE 2024.pdfINFORME RESULTADOS DE CREA Y EMPRENDE 2024.pdf
INFORME RESULTADOS DE CREA Y EMPRENDE 2024.pdf
 
fase intensiva taller intensivo de CTE julio
fase intensiva taller intensivo de CTE juliofase intensiva taller intensivo de CTE julio
fase intensiva taller intensivo de CTE julio
 
La Relación Mixta DA ( Riesgo)- Matriz DA
La Relación Mixta DA ( Riesgo)- Matriz DALa Relación Mixta DA ( Riesgo)- Matriz DA
La Relación Mixta DA ( Riesgo)- Matriz DA
 
2024 DIA DEL LOGRO IE HONORIO DELGADO ESPINOZA
2024 DIA DEL LOGRO IE HONORIO DELGADO ESPINOZA2024 DIA DEL LOGRO IE HONORIO DELGADO ESPINOZA
2024 DIA DEL LOGRO IE HONORIO DELGADO ESPINOZA
 
Apuntes de Enfermería (para estudiantes)
Apuntes de Enfermería (para estudiantes)Apuntes de Enfermería (para estudiantes)
Apuntes de Enfermería (para estudiantes)
 
Análisis y Evaluación del Impacto Ambiental.pdf
Análisis y Evaluación del Impacto Ambiental.pdfAnálisis y Evaluación del Impacto Ambiental.pdf
Análisis y Evaluación del Impacto Ambiental.pdf
 
PPT II BLOQUE SG 2024 - semana de gestion.pdf
PPT  II BLOQUE SG 2024 - semana de gestion.pdfPPT  II BLOQUE SG 2024 - semana de gestion.pdf
PPT II BLOQUE SG 2024 - semana de gestion.pdf
 
homeostasis.pptx. Enfermería técnica periodo 1
homeostasis.pptx. Enfermería técnica periodo 1homeostasis.pptx. Enfermería técnica periodo 1
homeostasis.pptx. Enfermería técnica periodo 1
 
FORMATO APA - JOHNNY FELIX SURI MAMANI 2024
FORMATO APA - JOHNNY FELIX SURI MAMANI 2024FORMATO APA - JOHNNY FELIX SURI MAMANI 2024
FORMATO APA - JOHNNY FELIX SURI MAMANI 2024
 

Modelos de desarrollo de software separata

  • 1. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero MODELOS DE PROCESOS DESARROLLO DE SOFTWARE EL MODELO EN CASCADA El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere el o un enfoque sistemático, secuencial hacia el desarrollo del software, que se igu er inicia con la especificación de requerimientos del cliente y que continúa con M om la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. El modelo en cascada es el paradigma más antiguo para la ingeniería del an R software. Sin embargo, en las décadas pasadas. , S rvin Problemas: GB a 1. Es muy raro que los proyectos reales sigan el flujo secuencial que U c. M propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa. Con frecuencia es difícil para el cliente establecer todos los requisitos de Li 2. manera explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 3. El cliente debe tener paciencia. Una versión que funcione de los programas estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se detecta antes de la revisión del programa. En la actualidad, el trabajo del software está acelerado y sujeto a una cadena infinita de cambios (de características, funciones y contenido de la información). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en situaciones donde los requerimientos están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal. www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 2. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero MODELO INCREMENTAL el o igu er M om an R El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. El modelo incremental aplica secuencias lineales de manera , S rvin escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del software. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su GB a primer incremento, podría realizar funciones básicas de administración de U c. M archivos, edición y producción de documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer incremento, funciones de corrección Li ortográfica y gramatical; y en el cuarto, capacidades avanzadas de configuración de página. El modelo de proceso incremental, al igual que la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se enfoca 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 necesita y una plataforma para evaluarlo. El desarrollo incremental es útil sobre todo cuando el personal necesario para una implementación completa no está disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se requiere) más personal para implementar el incremento siguiente. Además, los incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande podría requerir la disponibilidad de un hardware nuevo que está en desarrollo y cuya fecha de entrega es incierta. Sería posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 3. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero permitiría la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados. MODELO DRA el o igu er M om an R , S rvin GB a U c. M Li El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción basado en componentes. Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a 90 días). Como otros modelos de proceso, el enfoque DRA cumple con las actividades genéricas del marco de trabajo que ya se han presentado. La comunicación trabaja para entender el problema de negocios y las características de información que debe incluir el software. La planeación es esencial porque varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases —modelado de negocios, www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 4. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero modelado de datos y modelado del proceso— y establece representaciones del diseño que sirven como base para la actividad de construcción del modelo DRA. La construcción resalta el empleo de componentes de software existente y la aplicación de la generación automática de código. Por último, el despliegue establece una base para las iteraciones subsecuentes, si éstas son necesarias. Si una aplicación de negocios se puede modular de forma que cada gran función pueda completarse en menos de tres meses (mediante la aplicación del enfoque ya descrito), ésta es una candidata para el DRA. Cada gran función se puede abordar mediante un equipo de DRA por separado, para después integrarlas y formar un todo. Como todos los modelos de proceso, el enfoque DRA tiene inconvenientes 1) para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear el número correcto de equipos DRA; el o 2) si los desarrolladores y clientes no se comprometen con las actividades igu er rápidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos de DRA fallarán; M om 3) si un sistema no se puede modular en forma apropiada, la construcción de an R los componentes necesarios para el DRA será problemática; , S rvin 4) si el alto rendimiento es un aspecto importante, y se alcanzará al convertir interfases en componentes del sistema, el enfoque DRA podría no funcionar; y GB a U c. M 5) el DRA sería inapropiado cuando los riesgos técnicos son altos (por ejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías). Li www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 5. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero MODELOS EVOLUTIVOS Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del software. • CONSTRUCCIÓN DE PROTOTIPOS • MODELO EN ESPIRAL • MODELO DE DESARROLLO CONCURRENTE CONSTRUCCION DE PROTOTIPOS el o igu er M om an R , S rvin GB a U c. M Li A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 6. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero un sistema operativo o de la forma que debería tomar la interacción humano-máquina. En éstas, y en muchas otras situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. A pesar de que la construcción de prototipos se puede utilizar como un modelo de proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos de proceso expuestos en este capítulo. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. El paradigma de construcción de prototipos se inicia con la comunicación. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño rápido se centra en una representación el o de aquellos aspectos del software que serán visibles para el cliente o el igu er usuario final (por ejemplo, la configuración de la interfaz con el usuario y el M om formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo. Después, el prototipo lo evalúa el an R cliente/usuario y con la retroalimentación se refinan los requisitos del soft- ware que se desarrollará. La iteración ocurre cuando el prototipo se ajusta , S rvin para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer. GB a De manera ideal, el prototipo debería servir como un mecanismo para U c. M identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta emplear los fragmentos del programa ya existentes o aplica herramientas (como generadores de informes, administradores de ventanas, etcétera) que permiten producir programas de Li trabajo con rapidez. Pero ¿qué debe hacerse con el prototipo una vez cumplido el propósito descrito? Brooks ofrece una respuesta: En la mayoría de los proyectos, el primer sistema construido apenas se utiliza. Tal vez sea demasiado lento, muy grande o torpe en su uso, o reúna las tres características a la vez. No existe otra opción que comenzar de nuevo, aunque sea doloroso, es lo mejor, y construir una revisión rediseñada en la que se resuelvan estos problemas... Cuando se aplica un concepto nuevo de sistema o una tecnología nueva, se tiene que construir un sistema inservible y que sea necesario desechar, porque incluso la mejor planeación no es omnisciente como para que el sistema esté perfecto desde la primera vez. Por lo tanto, la pregunta de la administración no es si debe construirse un sistema piloto y desecharlo. Esto tendrá que hacerse. La única pregunta es si se planea la construcción de un desechable o se promete entregárselo a los clientes. www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 7. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero El prototipo puede servir como "primer sistema", el que Brooks recomienda desechar. Pero ésta tal vez sea una visión idealizada. Es verdad que a los clientes y los desarrolladores les gusta el paradigma de construcción de prototipos. A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos también se torna problemática por las siguientes razones: 1. El cliente ve lo que parece una versión en funcionamiento del software, sin saber que el prototipo está unido "con chicle y cable para embalaje", que por la prisa de hacerlo funcionar no se ha considerado la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa que el producto debe construirse otra vez para mantener los altos niveles de cali- dad, el cliente no lo entiende y pide la aplicación de "unos pequeños ajustes" para que se pueda elaborar un producto final a partir del prototipo. Es muy frecuente que la gestión del desarrollo de software sea muy lenta. 2. A menudo, el desarrollador establece compromisos de implementación para lograr que el prototipo funcione con rapidez. Tal vez se utilice un el o sistema operativo o lenguaje de programación inadecuado sólo porque está igu er disponible y es conocido; se puede implementar un algoritmo ineficiente M om sólo para mostrar capacidad. Después de un tiempo, el desarrollador quizá se familiarice con estas selecciones y olvide las razones por las que son an R inapropiadas. La selección menos ideal ahora se convierte en una parte integral del sistema. , S rvin A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave GB a es definir las reglas del juego desde el principio; es decir, el cliente y el U c. M desarrollador se deben poner de acuerdo en que el prototipo se construya y sirva como un mecanismo para la definición de requisitos, en que se descarte, al menos en parte, y en que después se desarrolle el software real con un enfoque hacia la calidad. Li www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 8. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero MODELO EN ESPIRAL el o igu er M om an R , S rvin El modelo en espiral, que Boehm propuso originalmente, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del GB a modelo en cascada. Proporciona el material para el desarrollo rápido de U c. M versiones incrementales del software. Boehm describe este modelo de la siguiente manera: El modelo de desarrollo en espiral es un generador del modelo de proceso Li guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería del software concurrente y con múltiples usuarios. Tiene dos características distintivas principales. Una de ellas es un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras disminuye su grado de riesgo. La otra es un con- junto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias. Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento del modelo o un prototipo. Durante las últimas iteraciones se producen versiones cada vez más completas del sistema desarrollado. Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de ingeniería del software. Para propósitos ilustrativos se aprovechan las actividades genéricas del marco de trabajo expuestas páginas atrás. Cada una de las actividades del marco de trabajo representa un segmento de la ruta en espiral. Cuando comienza este proceso www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 9. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero evolutivo el equipo de software realiza actividades implicadas en un circuito alrededor de la espiral que tiene una dirección en el sentido del movimiento de las manecillas del reloj, y que se inicia desde el centro. El riesgo es un factor considerado en cada revolución. Los puntos de fijación —una combinación de productos de trabajo y condiciones incluidas a lo largo de la ruta de la espiral— se consideran para cada paso evolutivo. El primer circuito alrededor de la espiral quizá genere el desarrollo de una especificación del producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar para desarrollar un prototipo y después, en forma progresiva, versiones más elaboradas del software. Cada paso a través de la región de planeación resulta en ajustes al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentación derivada de la relación con el cliente después de la entrega. Además, el administrador del proyecto ajusta el número de iteraciones planeado que se requiere para completar el software. A diferencia de otros modelos de proceso que terminan cuando se entrega el el o software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la igu er vida del software de computadora. Por lo tanto, el primer circuito alrededor M om de la espiral podría representar un "proyecto de desarrollo del concepto", el cual se inicia en el centro de la espiral y continúa por múltiples iteraciones 6 an R hasta que el desarrollo del concepto esté completo. Si el concepto se desarrollará en un producto real, el proceso continúa en la siguiente fase de , S rvin la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El nuevo producto evolucionará a través de un número de iteraciones alrededor de la espiral. Después, un circuito alrededor de la espiral se podría emplear GB a para representar un "proyecto de mejoramiento del producto". En esencia, la U c. M espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. En ocasiones el proceso está inactivo, pero siempre que se inicie un cambio el proceso comienza en el punto de entrada aprobado Li (por ejemplo, mejoramiento del producto). El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas a gran escala. Como el software evoluciona conforme avanza el proceso, el desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos en cada etapa evolutiva. El modelo en espiral emplea la construcción de prototipos como un mecanismo encaminado a reducir riesgos pero, en forma más importante, permite al desarrollador la aplicación del enfoque de la construcción de prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque sistemático de los pasos que sugiere el ciclo de vida clásico, pero lo incorpora al marco de trabajo ite- rativo que refleja de forma más verídica el mundo real. El modelo en espiral exige una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de que se vuelvan problemáticos. Así como otros paradigmas, el modelo en espiral no es una panacea. Es difícil convencer a los clientes (en particular en situaciones bajo contrato) de que el enfoque evolutivo es controlable, ya que se requiere una habilidad www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 10. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero considerable para evaluar el riesgo y se confia en dicha habilidad para obtener el éxito. Si un riesgo importante no se descubre y administra, sin duda surgirán problemas. MODELO DE DESARROLLO CONCURRENTE el o igu er M om an R , S rvin GB a U c. M Li El modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, se representa en forma esquemática como una serie de actividades del marco de trabajo, acciones y tareas de la ingeniería del software y sus estados asociados. Por ejemplo, la actividad de modelado, definida para el modelo en espiral, se lleva a cabo al invocar las acciones siguientes: construcción de prototipos o modelado y especificación del análisis y diseño.7 www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 11. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero Se proporciona un esquema de una tarea de ingeniería de software relacionada con la actividad de modelado para el modelo de proceso concurrente. La actividad —modelado— puede estar en alguno de los estados destacados mencionados antes en cualquier momento dado. De forma similar, otras actividades o tareas (por ejemplo, la comunicación y la construcción) se representan de una manera análoga. Todas las actividades existen de forma concurrente, pero se encuentran en diferentes estados. Por ejemplo, al principio del proyecto la actividad de comunicación (no se muestra en la figura) ha completado su primera iteración y existe en el estado de en espera de cambios. La actividad de modelado que existió en el estado ninguno mientras se realizaba la comunicación inicial, ahora realiza una transición al estado en desarrollo. Sin embargo, si el cliente indica cambios en los requisitos, la actividad de modelado se mueve del estado en desarrollo al estado de en espera de cambios. El modelo de proceso concurrente define una serie de eventos que dispararán transiciones de estado a estado para cada una de las actividades, el o acciones o tareas de la ingeniería del software. Por ejemplo, durante los igu er primeros estados del diseño (una acción de la ingeniería del software que ocurre en el curso de la actividad de modelación) no se detecta una M om inconsistencia en el modelo del análisis. Esto genera el evento corrección del análisis del modelo, el cual disparará la creación del análisis desde el estado an R realizado hasta el estado de en espera de cambios. , S rvin El modelo de proceso concurrente se aplica a todos los tipos de desarrollo de software y proporciona una visión exacta del estado actual de un proyecto. En lugar de confinar las actividades, acciones y tareas de la GB a ingeniería del software a una secuencia de eventos, define una red de U c. M actividades. Cada actividad, acción o tarea en la red existe de manera simultánea con otras actividades, acciones o tareas. Los eventos generados entre los estados. Li www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  • 12. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero Actividad Nº 1 el o igu er M om Actividad Nº 2 an R Investigue Y Explique: , S rvin • Cuáles son los Modelos Especializados de Proceso: – Desarrollo basado en C____________ GB a – Modelo de _____________ Formales U c. M – Desarrollo de Software Orientado a A_________ Li www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...