SlideShare una empresa de Scribd logo
1 de 11
Descargar para leer sin conexión
UNIDAD4: MODELOS DE
PROCESOS DE SOFWARE
UNIDAD 4
MODELOS DE PROCESOS DE SOFTWARE
Este enfoque metodológico que ordena rigurosamente las etapas del
ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a
la finalización de la inmediatamente anterior. la palabra cascada sugiere,
mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para
introducir un cambio en las fases más avanzadas de un proyecto.
Modelo en Cascada: El mas conocido, esta basado en el ciclo
convencional de una ingeniería, el paradigma del ciclo de vida abarca las
siguientes actividades:
- Ingeniería y Análisis del Sistema
- Análisis de los Requisitos
- Diseño
- Codificación
- Prueba
- Mantenimiento
1.- INGENIERÍA Y ANÁLISIS DEL SISTEMA
Debido a que el software es siempre parte de un sistema mayor, el trabajo
comienza estableciendo los requisitos de todos los elementos del sistema y luego
asignando algún subconjunto de estos requisitos al software.
2.- ANÁLISIS DE SISTEMAS DE COMPUTACIÓN
Se lleva a cabo teniendo den cuenta ciertos principios:
- Debe presentarse y entenderse el dominio de la información de un
problema.
- Defina las funciones que debe realizar el Software.
- Represente el comportamiento del Software a consecuencias de
acontecimientos externos.
- Divida en forma jerárquica los modelos que representa la información,
funciones y comportamiento.
Se analizan las necesidades de los usuarios finales del Software para
determinar que objetivos debe cubrir.
3.- DISEÑO
Traduce los requisitos en una representación del Software con la calidad
requerida antes de que comience la codificación.
- Diseño del sistema: Se descompone y organiza el sistema en elementos
que pueda elaborarse por separado, aprovechando los ventajas del desarrollo en
equipo, así como la manera en que se combinan unos con otros.
- Diseño del Programa: Es la fase en donde se realizan los algoritmos
necesarios para el cumplimiento de los requerimientos del usuario así como
también los análisis necesarios para saber que herramientas usar en la etapa de
Codificación.
4.- CODIFICACIÓN
El diseño debe traducirse en una forma legible para la maquina. Se
implementa el código fuente. Dependiendo del lenguaje de programación y su
versión se crean las librerías y componentes reutilizables dentro del mismo
proyecto para hacer que la programación sea un proceso mucha más rápido.
5.- PRUEBA
Los elementos, ya programados, se ensamblan para componer el sistema
y se comprueba que funciona correctamente antes de ser puesto en explotación.
Las pruebas de Software, testing o beta testing es un proceso usado para
identificar posibles fallos. En general, los usuarios distinguen entre errores de
programación ( o “bugs” ) y defectos de forma. en un defecto de forma, el
programa no realiza lo que el usuario espera. Por el contrario, un error de
programación puede describirse como un fallo en la semántica de un programa
de ordenador. A la versión del producto de pruebas y que es anterior a la versión
final ( o “master” ) se denomina beta, y a dicha fase de pruebas, beta testing.
Finalmente y antes de salir al mercado, es cada vez más habitual que se realice
una fase de RTM testing (Release To Marquet), dónde se comprueba cada
funcionalidad del programa completo en entornos de producción.
6.- IMPLANTACIÓN
El Software obtenido se pone en producción. Se implantan los niveles
Software y Hardware que componen el proyecto. La implantación es la fase con
más duración y con más cambios en el ciclo de elaboración de un proyecto. Es
una de las fases finales del proyecto. Durante la explotación del sistema
Software pueden surgir cambios, bien para corregir errores o bien para
introducir mejorar. Todo ello recoge en los Documentos de Cambios.
7.- MANTENIMIENTO
El Software sufrirá cambios después de que se entrega al cliente. Los
cambios ocurrirán debido a que hayan encontrado errores, a que el Software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.
Ventajas:
- Se tiene todo bien organizado y no se mezclan las fases.
- Es perfecto para proyectos que son rigidos.
- Idieal para proyectos donde se especifiquen muy bien los
requerimientos.
- Ideal para proyectos en que se conozca muy bien la herramienta a
utilizar.
- Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la
hora de desarrollar el Software.
Desventajas:
- Difícilmente un cliente va a establecer al principio todos los
requerimientos necesaríos, por lo que provoca un gran atraso trabajando en este
modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.
- Los resultados y/o mejoras no son visibles, el producto se ve recién
cuando este esté finalizado.
4.2 MODELOS DE ESPIRAL
El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por
Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software.
Las actividades de este modelo son una espiral, cada bucle es una
actividad.
Para cada actividad habrá cuatro tareas:
No. 1
Planificación:
Determinación de objetivos, alternativas y restricciones.
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si
continuamos con las fases siguientes y planificamos la próxima actividad.
No. 2
Análisis de riesgo:
Análisis de alternativas e identificación/resolución de riesgos.
No. 3
Ingeniería:
Desarrollo del producto del “siguiente nivel”
Tareas de la actividad propia y se prueba.
Análisis de alternativas e identificación resolución de riesgos.
No.4
Evaluación del cliente:
Valorización de los resultados de la ingeniería.
Ventajas:
- El análisis del riesgo se hace de forma explícita y clara. Une los mejores
elementos de los restantes modelos.
- Reduce riesgos del proyecto
- Incorpora objetivos de calidad
- Integra el desarrollo con el mantenimiento, etc.
- Además es posible tener en cuenta mejoras y nuevos requerimientos sin
romper con la metodología, ya que este ciclo de vida no es rígido ni estático.
Desventajas:
- Genera mucho tiempo en el desarrollo del sistema.
- Modelo costoso.
- Requiere experiencia en la identificación de riesgos.
CONCLUCION:
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 de prototipos.
4.3 MODELOS INCREMENTAL
El Modelo Incremental combina elementos del MLS con la filosofía
interactiva de construcción de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño,
Código y Prueba. Sin embargo, para la producción del Software, se usa el
principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de
programación. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o
desecha elementos al final de cada incremento a fin de que el software se adapte
mejor a sus necesidades reales. El proceso se repite hasta que se elabore el
producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de
naturaleza interactiva pero se diferencia de aquellos en que al final de cada
incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con
una dotación de personal suficiente. Los primeros pasos los pueden realizar un
grupo reducido de personas y en cada incremento se añadir• personal, de ser
necesario. Por otro lado los incrementos se pueden planear para gestionar
riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma grafica:
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con
cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir
transformando un flujo de datos en un proceso comprendido por varias fases
secuenciales, siendo la entrada de cada una la salida de la anterior.
Esta arquitectura es muy común en el desarrollo de programas para el
intérprete de comandos, ya que se pueden concatenar comandos fácilmente con
tuberías (pipe).
También es una arquitectura muy natural en el paradigma de
programación funcional, ya que equivale a la composición de funciones
matemáticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecución de
mandatos obtenidos del usuario por medio de una interfaz alfanumérica.
Características
- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con
cierta frecuencia.
- El usuario se involucre más.
- Difícil de evaluar el costo total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial,
ya que se implementa la funcionalidad parcial.
- También provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del Software.
- El modelo proporciona todas las ventajas del modelo en cascada
realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
- Permite entregar al cliente un producto más rápido en comparación del
modelo de cascada.
- Resulta más sencillo acomodar cambios al acotar el tamaño de los
incrementos.
- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel
administrativo como técnico.
Desventajas:
- El modelo Incremental no es recomendable para casos de sistemas de
tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de
alto índice de riesgos.
- Requiere de mucha planeación, tanto administrativa como técnica.
- Requiere de metas claras para conocer el estado del proyecto.
Conclusión:
Un modelo incremental lleva a pensar en un desarrollo modular, con
entregas parciales del producto Software denominados “incrementos” del
sistema, que son escogidos en base a prioridades predefinidas de algún modo.
El modelo permite una implementación con refinanciamientos sucesivos
(ampliación y/o mejora).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos
requisitos o bien se mejora la versión previamente implementada del producto
software.
4.4 PROCESO DE DESARROLLO UNIFICADO
El Proceso Unificado de Desarrollo Software o simplemente Proceso
Unificado es un marco de desarrollo software iterativo e incremental. El
refinamiento más conocido y documentado del Proceso Unificado es el Proceso
Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de
trabajo extensible que puede ser adaptado a organizaciones o proyectos
específicos. De la misma forma, el Proceso Unificado de Rational, también es un
marco de trabajo extensible, por lo que muchas veces resulta imposible decir si
un refinamiento particular del proceso ha sido derivado del Proceso Unificado o
del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un
mismo concepto.
Características:
- Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental
compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y
Transición. Cada una de estas fases es a su vez dividida en una serie de
iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes).
Estas iteraciones ofrecen como resultado un incremento del producto
desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.
- Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los
requisitos funcionales y para definir los contenidos de las iteraciones.
- Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo único que cubra
todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y
vistas que definen la arquitectura de software de un sistema
- Enfocado en los riesgos
El Proceso Unificado requiere que el equipo del proyecto se centre en
identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los
resultados de cada iteración, en especial los de la fase de Elaboración, deben ser
seleccionados en un orden que asegure que los riesgos principales son
considerados primero.
4.5 PROCESO DE SOFTWARE PERSONAL
El Proceso Personal Software, conocido por sus siglas como PSP, es una
metodología de reciente creación, proveniente del Instituto de Ingeniería del
Software (SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que
les permite mejorar la forma en la que construyen software. Considerando
aspectos como la planeación, calidad, estimación de costos y productividad, PSP
es una metodología que vale la pena revisar cuando el ingeniero de software está
interesado en aumentar la calidad de los productos de software que desarrolla
dentro de un contexto de trabajo individual.
Atendiendo a la premisa de que existe una fuerte relación entre las
habilidades de los ingenieros de software y la calidad de los productos que
desarrollan, las actividades establecidas en PSP están orientadas al
conocimiento, administración y mejora de sus habilidades al construir
programas.
En PSP todas las tareas y actividades que el ingeniero de software debe
realizar durante el proceso de desarrollo de un producto de software, están
puntualmente definidas en un conjunto de documentos conocidos como scripts.
Los scripts son el punto medular de PSP, por lo que se hace mucho énfasis en
que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito
de la mejora que se busca. Gran parte de las tareas y actividades definidas en los
scripts generará en su realización un conjunto de datos, fundamentalmente de
carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el
análisis de la información estadística generada en cada uno de éstos, permitirán
al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y
crecer a través de un proceso de autoaprendizaje y auto-mejora.
Los scripts se organizan en cuatro niveles, identificados del 0 al 3,
atendiéndose en cada nivel un conjunto de aspectos a mejorar del proceso de
desarrollo de software. Al primer nivel se le conoce como 0 o de medición
personal, al segundo como nivel 1 o de planeación personal, al tercero, como
nivel 2 o de calidad personal, y al cuarto, como nivel 3 o cíclico personal. Cada
uno de estos niveles, con excepción del 3, tiene una versión que los extiende,
introduciendo tareas y actividades para un mejor manejo de los aspectos de
interés en nivel, o bien para incluir nuevos aspectos.

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Caracteristicas rup
Caracteristicas rupCaracteristicas rup
Caracteristicas rup
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativo
 
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
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Rup (iteraciones)
Rup (iteraciones)Rup (iteraciones)
Rup (iteraciones)
 
Breve explicacion del Rup
Breve explicacion del RupBreve explicacion del Rup
Breve explicacion del Rup
 
Fases del rup
Fases del rupFases del rup
Fases del rup
 
Metodologia Incremental
Metodologia IncrementalMetodologia Incremental
Metodologia Incremental
 
Modelo en cascada
Modelo en cascadaModelo en cascada
Modelo en cascada
 
Proceso ( software )
Proceso ( software )Proceso ( software )
Proceso ( software )
 
Procesos del Software
Procesos del SoftwareProcesos del Software
Procesos del Software
 
procesos de desarrollo de software
procesos de desarrollo de softwareprocesos de desarrollo de software
procesos de desarrollo de software
 
Rup
RupRup
Rup
 
Presentación de software
Presentación de softwarePresentación de software
Presentación de software
 
Modelo Descrptivos Del Proceso Del Sofware
Modelo Descrptivos  Del  Proceso Del SofwareModelo Descrptivos  Del  Proceso Del Sofware
Modelo Descrptivos Del Proceso Del Sofware
 
Modelos Prescriptivos de Proceso
Modelos Prescriptivos de ProcesoModelos Prescriptivos de Proceso
Modelos Prescriptivos de Proceso
 
RUP - Fase de Elaboración
RUP - Fase de ElaboraciónRUP - Fase de Elaboración
RUP - Fase de Elaboración
 
Resumen rup
Resumen rupResumen rup
Resumen rup
 
Metodologia clasica en cascada
Metodologia clasica en cascadaMetodologia clasica en cascada
Metodologia clasica en cascada
 
02 rup
02 rup02 rup
02 rup
 

Destacado (12)

modelos para el desarrollo de sofware
modelos para el desarrollo de sofwaremodelos para el desarrollo de sofware
modelos para el desarrollo de sofware
 
Compuertas logicas
Compuertas logicasCompuertas logicas
Compuertas logicas
 
ciclosdevidasofware
ciclosdevidasofwareciclosdevidasofware
ciclosdevidasofware
 
Compuertas Logicas
Compuertas LogicasCompuertas Logicas
Compuertas Logicas
 
Compuertaslogicas
CompuertaslogicasCompuertaslogicas
Compuertaslogicas
 
Transistores
TransistoresTransistores
Transistores
 
Electrónica(4º ESO)
Electrónica(4º ESO)Electrónica(4º ESO)
Electrónica(4º ESO)
 
Transistores
TransistoresTransistores
Transistores
 
Compuertas Logicas
Compuertas LogicasCompuertas Logicas
Compuertas Logicas
 
Compuertas Logicas
Compuertas LogicasCompuertas Logicas
Compuertas Logicas
 
Definición de compuertas logicas
Definición de compuertas logicasDefinición de compuertas logicas
Definición de compuertas logicas
 
Compuertas Lógicas
Compuertas LógicasCompuertas Lógicas
Compuertas Lógicas
 

Similar a Apuntes

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
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de software
UVM
 

Similar a Apuntes (20)

Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
 
prueva
pruevaprueva
prueva
 
Investigación de modelos
Investigación de modelos Investigación de modelos
Investigación de modelos
 
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
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativo
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativo
 
Ciclo Vida del Software
Ciclo Vida del SoftwareCiclo Vida del Software
Ciclo Vida del Software
 
3. modelos prescriptivos de proceso
3. modelos prescriptivos de proceso3. modelos prescriptivos de proceso
3. modelos prescriptivos de proceso
 
Ciclo vida DESARROLLO DE SOFTWARE
Ciclo vida DESARROLLO DE SOFTWARECiclo vida DESARROLLO DE SOFTWARE
Ciclo vida DESARROLLO DE SOFTWARE
 
Tarea nayeli
Tarea nayeliTarea nayeli
Tarea nayeli
 
Modelos
ModelosModelos
Modelos
 
Parcial2
Parcial2Parcial2
Parcial2
 
Ciclo de vida del software
Ciclo de vida del softwareCiclo de vida del software
Ciclo de vida 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
 
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
 
Sdf p4
Sdf p4Sdf p4
Sdf p4
 
Luiscaraballo ensayo
Luiscaraballo ensayoLuiscaraballo ensayo
Luiscaraballo ensayo
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de software
 
Presentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del softwarePresentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del software
 

Apuntes

  • 2. UNIDAD 4 MODELOS DE PROCESOS DE SOFTWARE Este enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. la palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Modelo en Cascada: El mas conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades: - Ingeniería y Análisis del Sistema - Análisis de los Requisitos - Diseño - Codificación - Prueba - Mantenimiento 1.- INGENIERÍA Y ANÁLISIS DEL SISTEMA Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. 2.- ANÁLISIS DE SISTEMAS DE COMPUTACIÓN Se lleva a cabo teniendo den cuenta ciertos principios: - Debe presentarse y entenderse el dominio de la información de un problema. - Defina las funciones que debe realizar el Software. - Represente el comportamiento del Software a consecuencias de acontecimientos externos.
  • 3. - Divida en forma jerárquica los modelos que representa la información, funciones y comportamiento. Se analizan las necesidades de los usuarios finales del Software para determinar que objetivos debe cubrir. 3.- DISEÑO Traduce los requisitos en una representación del Software con la calidad requerida antes de que comience la codificación. - Diseño del sistema: Se descompone y organiza el sistema en elementos que pueda elaborarse por separado, aprovechando los ventajas del desarrollo en equipo, así como la manera en que se combinan unos con otros. - Diseño del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación. 4.- CODIFICACIÓN El diseño debe traducirse en una forma legible para la maquina. Se implementa el código fuente. Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucha más rápido. 5.- PRUEBA Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación. Las pruebas de Software, testing o beta testing es un proceso usado para identificar posibles fallos. En general, los usuarios distinguen entre errores de programación ( o “bugs” ) y defectos de forma. en un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un programa de ordenador. A la versión del producto de pruebas y que es anterior a la versión final ( o “master” ) se denomina beta, y a dicha fase de pruebas, beta testing. Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de RTM testing (Release To Marquet), dónde se comprueba cada funcionalidad del programa completo en entornos de producción.
  • 4. 6.- IMPLANTACIÓN El Software obtenido se pone en producción. Se implantan los niveles Software y Hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto. Durante la explotación del sistema Software pueden surgir cambios, bien para corregir errores o bien para introducir mejorar. Todo ello recoge en los Documentos de Cambios. 7.- MANTENIMIENTO El Software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el Software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Ventajas: - Se tiene todo bien organizado y no se mezclan las fases. - Es perfecto para proyectos que son rigidos. - Idieal para proyectos donde se especifiquen muy bien los requerimientos. - Ideal para proyectos en que se conozca muy bien la herramienta a utilizar. - Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el Software. Desventajas: - Difícilmente un cliente va a establecer al principio todos los requerimientos necesaríos, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases. - Los resultados y/o mejoras no son visibles, el producto se ve recién cuando este esté finalizado.
  • 5. 4.2 MODELOS DE ESPIRAL El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo son una espiral, cada bucle es una actividad. Para cada actividad habrá cuatro tareas: No. 1 Planificación: Determinación de objetivos, alternativas y restricciones. Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. No. 2 Análisis de riesgo: Análisis de alternativas e identificación/resolución de riesgos. No. 3 Ingeniería: Desarrollo del producto del “siguiente nivel” Tareas de la actividad propia y se prueba. Análisis de alternativas e identificación resolución de riesgos. No.4 Evaluación del cliente: Valorización de los resultados de la ingeniería. Ventajas:
  • 6. - El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. - Reduce riesgos del proyecto - Incorpora objetivos de calidad - Integra el desarrollo con el mantenimiento, etc. - Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático. Desventajas: - Genera mucho tiempo en el desarrollo del sistema. - Modelo costoso. - Requiere experiencia en la identificación de riesgos. CONCLUCION: 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 de prototipos. 4.3 MODELOS INCREMENTAL El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos. En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte
  • 7. mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos. El Modelo Incremental se puede ver aquí en forma grafica: - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucra más. - Difícil de evaluar el coste total. - Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. - Requiere gestores experimentados. - Los errores en los requisitos se detectan tarde. - El resultado puede ser muy positivo. Pipeline La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior. Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).
  • 8. También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas. Interprete de comandos Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica. Características - Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia. - El usuario se involucre más. - Difícil de evaluar el costo total. - Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. - Requiere gestores experimentados. - Los errores en los requisitos se detectan tarde. - El resultado puede ser muy positivo. Ventajas: - Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. - También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. - El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento. - Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
  • 9. - Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos. - Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico. Desventajas: - El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos. - Requiere de mucha planeación, tanto administrativa como técnica. - Requiere de metas claras para conocer el estado del proyecto. Conclusión: Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto Software denominados “incrementos” del sistema, que son escogidos en base a prioridades predefinidas de algún modo. El modelo permite una implementación con refinanciamientos sucesivos (ampliación y/o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software. 4.4 PROCESO DE DESARROLLO UNIFICADO El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo software iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
  • 10. Características: - Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. - Dirigido por los casos de uso En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. - Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema - Enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. 4.5 PROCESO DE SOFTWARE PERSONAL El Proceso Personal Software, conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto de Ingeniería del Software (SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software. Considerando aspectos como la planeación, calidad, estimación de costos y productividad, PSP es una metodología que vale la pena revisar cuando el ingeniero de software está interesado en aumentar la calidad de los productos de software que desarrolla dentro de un contexto de trabajo individual.
  • 11. Atendiendo a la premisa de que existe una fuerte relación entre las habilidades de los ingenieros de software y la calidad de los productos que desarrollan, las actividades establecidas en PSP están orientadas al conocimiento, administración y mejora de sus habilidades al construir programas. En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, están puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace mucho énfasis en que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará en su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información estadística generada en cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un proceso de autoaprendizaje y auto-mejora. Los scripts se organizan en cuatro niveles, identificados del 0 al 3, atendiéndose en cada nivel un conjunto de aspectos a mejorar del proceso de desarrollo de software. Al primer nivel se le conoce como 0 o de medición personal, al segundo como nivel 1 o de planeación personal, al tercero, como nivel 2 o de calidad personal, y al cuarto, como nivel 3 o cíclico personal. Cada uno de estos niveles, con excepción del 3, tiene una versión que los extiende, introduciendo tareas y actividades para un mejor manejo de los aspectos de interés en nivel, o bien para incluir nuevos aspectos.